Bug#882085: [cowsay] Package includes ASCII representation of Zoophilia
Hi Ævar (cool name btw!) and thanks for pointing out the two inaccuracies in my first comment. I still would like to know why a project like Debian (used ostensibly by every kind of human on the planet, across ages, sexes, political and religious divides and whatnot) feels like it needs to include anything that's as you state yourself (a) silly and (b) as such not really useful or necessary for anything in any way while it /will/ (c) be clear to /any/one within the "large and diverse community of users and developers" (https://wiki.debian.org/Community) that pictures of sheep being sodomized, voluntarily so or not, may cause very real troubles of various sorts for an unknowable number of members of the that diverse community. Unfortunately Felicia took a step back saying this is not about tastelessness or offensiveness, but only about possible legal issues. I'll kindly ask you to yourself come up with examples of where all three of these occur at once, it isn't going to take you very long to do so. Since I was asked, outside this forum, what, in my opinion should happen: Felicia, I agree it's a reasonable course of action to ask for user confirmation on install of cowsay-off and possible other packages like it. I also agree with you, Ævar, "whatever naming convention is used should be consistent across all of Debian". I'll go one step further though and say that the naming convention should be "-offensive". In addition to that, I /really, /please, want to hear from a member of Debian as to what the reasoning is for including such imagery in the biggest and oldest distribution of the largest non-commercial operating system in the world. I'd further like to ask for that statement to be well thought-through and non-humorous in nature. That's all the things that, in my opinion, should happen. Cheers, Jonathan
Bug#882085: [cowsay] Package includes ASCII representation of Zoophilia
You people are beyond me. Why in the world would you want a picture of a sheep (?) being forced (??) into sex (???) it quite likely does not want () in a distribution of computer programs (?) even if there was no legal issue whatsoever. If you can judge by the number of question marks, this is a serious question. I'm looking forward to the attempt of a serious answer.
Bug#818484: thunar: Crashing on file/folder rename for me, too
Package: thunar Version: 1.6.10-4 Followup-For: Bug #818484 I second what is being reported by the original reporter as well as what is described in 804816, 804819, 805574, 815017, and 818484. I'm unsure about 823578 which says to patch "frequent crashes in Thunar". Happy to provide any additional information asked for! -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages thunar depends on: ii desktop-file-utils 0.23-1 ii exo-utils 0.10.7-1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-3 ii libcairo2 1.14.6-1+b1 ii libdbus-1-3 1.10.12-1 ii libdbus-glib-1-20.108-1 ii libexo-1-0 0.10.7-1 ii libgdk-pixbuf2.0-0 2.36.0-1 ii libglib2.0-02.50.1-1 ii libgtk2.0-0 2.24.31-1 ii libgudev-1.0-0 230-3 ii libice6 2:1.0.9-1+b1 ii libnotify4 0.7.7-1 ii libpango-1.0-0 1.40.3-2 ii libsm6 2:1.2.2-1+b1 ii libthunarx-2-0 1.6.10-4 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util7 4.12.1-2 ii libxfconf-0-2 4.12.0-3 ii shared-mime-info1.7-1 ii thunar-data 1.6.10-4 Versions of packages thunar recommends: ii dbus-x11 1.10.12-1 ii gvfs 1.30.1-1 ii libfontconfig1 2.11.0-6.7 ii libfreetype6 2.6.3-3+b1 ii libpangocairo-1.0-0 1.40.3-2 ii libpangoft2-1.0-01.40.3-2 ii thunar-volman0.8.1-2 ii tumbler 0.1.31-2+b3 ii xdg-user-dirs0.15-2 ii xfce4-panel 4.12.0-4 Versions of packages thunar suggests: ii thunar-archive-plugin 0.3.1-4 ii thunar-media-tags-plugin 0.2.1-1+b2 -- no debconf information
Bug#832530: network-manager-openvpn: Route and DNS server are not applied to the system,, no matter where they come from
Package: network-manager-openvpn Version: 1.2.4-1 Severity: important Tags: ipv6 Dear Maintainer, in a OpenVPN setup where everything is proven to work as expected using the `openvpn` command line client, the following happens when using NetworkManager to connect to the VPN instead: - first, the connection is established successfully - but then, no extra routes or DNS servers are set The extra routes (i.e. any routes not to 10.8.0.0) or DNS servers are not set whether the OpenVPN server pushes them down or whether they are set manually in the NM GUI. In the latter case, the settings for them are properly written into `/etc/NetworkManager/system-connections/`, though. If routes and DNS servers are manually set after the VPN connection has been established by NM, everything works normally. This bug might be connected to #487378, even though that bug report does not mention DNS servers at all, nor the distinction between pushed routes/DNS servers and ones set through the NM GUI. Cheers, Jonathan -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager-openvpn depends on: ii adduser 3.115 ii libc62.23-2 ii libglib2.0-0 2.48.1-2 ii libnm0 1.2.2-2 ii network-manager 1.2.2-2 ii openvpn 2.3.11-2 network-manager-openvpn recommends no packages. network-manager-openvpn suggests no packages. -- no debconf information
Bug#781582: base: Removable media accessible r/o for users - solution perhaps simple.
Package: base Severity: important Tags: d-i Dear Maintainer, there are several bug reports in the BTS regarding removable media ending up being readonly for normal users and writable for root only. Various solutions are suggested (such as adding a policykit rule [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740190]) but the cause of these problems might simply be superfluous (historical?) entries in /etc/fstab, so Torquil Macdonald Sørensen gets it right in [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740190] where he suggests that /etc/fstab entries for the devices affected might have to be removed. I have tried a fresh installation of Debian Jessie with the RC2 installer and ended up seeing these exact /etc/fstab entries (for /dev/sdc1 and /dev/sdc2 in my case, probably as these are the partitions on the USB stick used as an installation medium). Removing them as suggested lead to USB thumbdrives being writable by normal users again. Please note that SD cards were never affected, which is another hint at the /etc/fstab entries be ing the problem. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781582: closed by Holger Levsen hol...@layer-acht.org (Re: Bug#781582: base: Removable media accessible r/o for users - solution perhaps simple.)
Sorry for the dupe Holger. I also forgot to mention https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767233. Thank you for giving this matter your attention! 0x53847E3F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
