Bug#1012230: systemd: emergency target fails to stop journald
Package: systemd Version: 247.3 Severity: normal "systemctl isolate emergency" fails to stop systemd-journald.. it's not an upstream issue since the problem does not occurr with other distributions. having systemd-journald to be stopped is desirable since the administrator can then use e2fsck to repair filesystems(after the problematic filesystem read-only -- "mount -o ro,remount /" for instance) upstream won't look into this because it is not happening on other distributions. please take a look thanks
Bug#999695: systemd: emergency/rescue targets fail to stop journald
On 2021-11-15 10:10 a.m., Michael Biebl wrote: I think, what you see is that systemd-journald.service *is* actually stopped when you run `systemctl emergency`. systemctl isolate emergency and systemctl emergency have the same results unfortunately.. Could you check the following: - When you enter the emergency shell, check the journal if systemd-journald.service has been stopped (and started again) - If any of the above sockets are active? they're all active... systemd-journald.socket systemd-journald-dev-log.socket, and systemd-audit.socket while in emergency.. I can only report against the latest two versions of systemd to github upstream. was told so, over here, https://github.com/systemd/systemd/issues/21370 I tried to report upstream as much as possible in general, but with the systemd project --- the upstream requires very recent builds --- which debian doesn't have any... so I can't report my bugs upstream at that location. instead I am told by their lead developer to file things over here. I also would like that other issue(I pasted url above), to be fixed as well... are you going to tell me to report that upstream as well? Mister Lennard Poettering is blaming broken debian md-raid packages --- which is 100% not true at all.. it's just that he doesn't want to bother for "older" systemd builds... I am 100% sure he could of looked more into it, but he doesn't want to.. so fix it please. FIX IT NOW!! THANKS!
Bug#1000627: apache2: missing dependency setting
Package: apache2 Version: 2.4.48-3.1+deb11u1 Severity: important apache2 can fail to start if the user defines a specific interface. the workaround meanwhile is to add "network-online.target" to the systemd unit. The issue noticeably occurs when the user decides to use "systemd-networkd" for the configuration rather than /etc/network/interfaces. A bugreport was initially provided to systemd explaining the problem in greater detail, however a lead maintainer replied that the bug is to be forwarded to the server package in question. -- a copy of this original bugreport to systemd/systemd-networkd is here for further referencing: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000510 A server should not fail to "start" just because it is using a specific interface. I attempted to provide the suggestion for systemd/systemd-networkd maintainers to give a policy of having "network-online.target" for server programs but I was told that the issue is the specific server-package in question. (only two server packages that I use often have this problem, openssh-server and apache2) journalctl -xe -u [package] -- shows nothing revealing than ".. failed to bind to address x.x.x.x". "networkctl" -- all shows green highlighting --- the .network definitions are all correct. the problem seems to me the systemd policy of having network-online.target as a practice for server unit files is not enforced enough.. though the traditional ifup-networking scripts doesn't have this issue afaict. .. it happens more often when the user opts not to be using the default networking.service and instead go with the newer systemd-networkd method for bringing up interfaces during the bootup. the user here is not at fault, and should be allowed to set specific interfaces for the apache2 and ssh service. (fwiw, -- prior setting up the workaround, both ssh and apache2 servers will both exhibit the same binding-interface error, as shown in journalctl. However when starting these services manually: such as, systemctl start apache2.service, and systemctl start ssh.service there is no problem at all starting these up The interfaces are set at the system-level. There is no dbus-triggered/Desktop-login interface settings. The problem is systemd++network-online.target not set in the unit files. Systemd and Server package maintainers should enforce a better policy so that simple changes do not affect the ability to start the service. ) (this bugreport is getting cc'd to the ssh package -- as the problem also exists with that package) thanks
Bug#1000626: openssh-server: missing dependency setting
Package: openssh-server Version: 1:8.4p1-5 Severity: important openssh-server can fail to start if the user defines a specific interface. the workaround meanwhile is to add "network-online.target" to the systemd unit. The issue noticeably occurs when the user decides to use "systemd-networkd" for the configuration rather than /etc/network/interfaces. A bugreport was initially provided to systemd explaining the problem in greater detail, however a lead maintainer replied that the bug is to be forwarded to the server package in question. -- a copy of this original bugreport to systemd/systemd-networkd is here for further referencing: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000510 A server should not fail to "start" just because it is using a specific interface. I attempted to provide the suggestion for systemd/systemd-networkd maintainers to give a policy of having "network-online.target" for server programs but I was told that the issue is the specific server-package in question. (only two server packages that I use often have this problem, openssh-server and apache2) journalctl -xe -u [package] -- shows nothing revealing than ".. failed to bind to address x.x.x.x". "networkctl" -- all shows green highlighting --- the .network definitions are all correct. the problem seems to me the systemd policy of having network-online.target as a practice for server unit files is not enforced enough.. though the traditional ifup-networking scripts doesn't have this issue afaict. .. it happens more often when the user opts not to be using the default networking.service and instead go with the newer systemd-networkd method for bringing up interfaces during the bootup. the user here is not at fault, and should be allowed to set specific interfaces for the apache2 and ssh service. (fwiw, -- prior setting up the workaround, both ssh and apache2 servers will both exhibit the same binding-interface error, as shown in journalctl. However when starting these services manually: such as, systemctl start apache2.service, and systemctl start ssh.service there is no problem at all starting these up The interfaces are set at the system-level. There is no dbus-triggered/Desktop-login interface settings. The problem is systemd++network-online.target not set in the unit files. Systemd and Server package maintainers should enforce a better policy so that simple changes do not affect the ability to start the service. ) (this bugreport is getting cc'd to the apache2 package -- as the problem also exists with that package) thanks
Bug#1000510: systemd: all server programs fail when they are set to specified interfaces
Package: systemd Version: 247.3-6 Severity: important systemd-networkd causes issues around services that do not have "network-online.target" as part of "Wanted=" in their unit file. For example, apache2.service has the following under their [Unit] in apache2.service, "After=network.target remote-fs.target nss-lookup.target" , this is invalid, as it should rather be:: "After=network.target network-online.target remote-fs.target nss-lookup.target" same goes for ssh.service "After=network.target auditd.service", should be "After=network.target network-online.target auditd.service" and for any other service omitting network-online.target.. . otherwise those services will say "fail" on boot-up.. without any other further detail. journactl -xe -u doesn't show any further detail other that the service failed to "bind" to an address. ^ The ssh service I have set is set to bind to a "specific" interface that is defined by systemd-networkd's settings in /etc/systemd/network. (networkctl was shows fully configured interfaces, so there is no issue happening over here) The apache2 service is also set to bind to a "specific" interface. ^ By default these services run on 0.0.0.0 -- to run on all interfacaes, including 127.0.0.1 << which is pretty much ready much earlier. This explains as to why there is failure when the user defines specified interfaces later on. .. whoever is in charge of systemd, should inform other server-package maintainers to add "network-online.target" as a dependency-check otherwise those services will fail to start when the user decides to use specific interfaces. thanks
Bug#999695: systemd: emergency/rescue targets fail to stop journald
Package: systemd Version: 247.3-6 Severity: normal Upon booting up with "systemd.unit=emergency.target" to the kernel bootline, there are no systemd-journald services running. However if the user boots normally into multi-user or graphical targets, and types "systemctl isolate emergency" or "systemctl emergency", debian does not stop systemd-journald services. this is a problem noticeably if the user wants to perform work on "/" with "mount -o ro,remount /". please fix this thanks scott
Bug#982484: RFP: mailspring
Package: wnpp Version: N/A Severity: wishlist * Package name: mailspring Version: 1.8.0+ Upstream Author: * URL : https://github.com/Foundry376/Mailspring * License : GPLv3 Description: email client there was a recent announcement from the mailspring developer team that the core of their mailspring application is going opensource and will be using the GPLv3 license. there was added mention of being able to "opt-out" of their "mailspring-id" which should also attract it as a free software. recent news , https://community.getmailspring.com/t/a-free-open-source-future-for-mailspring/484 related github pages, "GitHub - Foundry376/Mailspring-Sync" https://github.com/Foundry376/Mailspring-Sync "GitHub - Foundry376/Mailspring: A beautiful, fast and maintained fork of @Nylas Mail by one of the original authors." https://github.com/Foundry376/Mailspring
Bug#976004: can close
took note is already packaged in sid and bullseye-testing.
Bug#976004: RFP: exfatprogs
Package: wnpp Version: N/A Severity: wishlist * Package name: exfatprogs Version: 1.0.4 Upstream Author: namjaejeon * URL : https://github.com/exfatprogs/exfatprogs * License : GPL-2.0 License Description: exfat utilities for the kernel's version of the exfat filesystem driver. "exfatprogs As new exfat filesystem is merged into linux-5.7 kernel, exfatprogs is created as an official userspace utilities that contain all of the standard utilities for creating and fixing and debugging exfat filesystem in linux system. The goal of exfatprogs is to provide high performance and quality at the level of exfat utilities in windows. And this software is licensed under the GNU General Public License Version 2. " Long description taken from its github page. This is the official exfat utilities meant to support the kernel's implementation of the exfat driver. Note there are 3 exfat drivers, this one being the only one meant to be used directly within the kernel giving the best performance of all 3. Since this exfat driver performance is better than the others, it would be a good idea to request that support for the reverse-engineered exfat implementation no longer be adequate. ^ Debian should drop support for the package exfat-utils, and instead rely on Kernel 5.7 (for its available built-in exfat driver support), and have exfatprogs to maintain and work with the exfat-linux driver. ^ The mistake I see happening is untested and possible incompatibilities(and/or issues) going with "exfat-utils" along with the native exfat-linux driver. Instead it should be only "exfatprogs" with "exfat-linux". It would imho make more sense to package this by the time kernel 5.7 becomes packaged into debian, as by then users would be getting confused which exfat driver they should be using. Some sources online mention that Kernel 5.7 is favorable to start using with the exfatprogs utilities. https://lore.kernel.org/lkml/001201d60e12$8454abb0$8cfe0310$@samsung.com/ "The initial version(1.0.1) of exfat-utils is now available. This is the official userspace utilities for exfat filesystem of linux-kernel." ^ Also keep in mind, that namjaejeon, had the project renamed to "exfatprogs" --- likely due to the already named package "exfat-utils" in debian. so https://github.com/exfat-utils/exfat-utils now redirects to https://github.com/exfatprogs/exfatprogs Important note: afaict, the exfat-utils and exfatprogs have no relevance to one another. This can be seen by reading discussions about announcements on their bugtracker on github between these two projects, neither one are merging and it appears that these two projects will remain separate. The confusion for me finding out about this, is that the URL/project page has been renamed, as even the story about the new "exfatprogs" announcement on the phoronix site also uses the prior confusing name. https://www.phoronix.com/scan.php?page=news_item=Samsung-exFAT-Utils-Release " Samsung Releases exFAT-Utils To Format File-System, Fsck With the new exFAT file-system merged for Linux 5.7, Samsung engineers responsible for this open-source native Linux kernel driver for Microsoft's exFAT file-system support have now issued their first official release of exfat-utils. The exfat-utils 1.0.1 release out this morning is their first official release of these user-space utilities for exFAT on Linux. The exFAT-utils package allows creating an exFAT file-system with mkfs.exfat as well as adjusting the cluster size and setting a volume label. There is also fsck.exfat for consistency checking of an exFAT file-system on Linux. " The github link entitled with the name "exfat-utils" provide on phoronix now also redirects to exfatprogs -- should there be a renewed editorial on both LKML and phoronix, they should instead be edited and re-titled with the project name "exfatprogs". So the confusion I hope regarding the naming could be set aside, even though the official announcement and other reports about it uses the obsolete naming for it but afaict it has nothing to do with "relan's" exfat project which is stored at a separate location somewhere on github.
Bug#972120: medit: icon-theme.cache file conflict
Package: medit Version: 1.2.0-3 Severity: important dpkg -S /usr/share/icons/hicolor/icon-theme.cache medit: /usr/share/icons/hicolor/icon-theme.cache other packages such as terminator(1.92-1~bpo10+1) cannot install because icon-theme.cache is attached to package medit.
Bug#972119: terminator: conflicts with icon-theme.cache on install
Package: terminator Version: 1.92-1~bpo10+1 Severity: important apt-get install terminator refuses to install due to a file conflict from another package. "Preparing to unpack .../terminator_1.92-1~bpo10+1_all.deb ... Unpacking terminator (1.92-1~bpo10+1) ... dpkg: error processing archive /var/cache/apt/archives/terminator_1.92-1~bpo10+1_all.deb (--unpack): trying to overwrite '/usr/share/icons/hicolor/icon-theme.cache', which is also in package medit 1.2.0-3 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/terminator_1.92-1~bpo10+1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) "
Bug#951411: systemd: user service units not getting precedence
Package: systemd Version: 244-3~bpo10+1 Severity: important Dear maintainer, please repair the precedence for the user's service units. having an example.service unit in ~/.config/systemd/user overrides it's counterpart in /usr/lib/systemd/user. however having example.service in /etc/systemd/user is not getting overrided by ~/.config/systemd/user $ systemd-analyze --user unit-paths /home/westlake/.config/systemd/user.control /run/user/1000/systemd/user.control /run/user/1000/systemd/transient /run/user/1000/systemd/generator.early /home/westlake/.config/systemd/user /etc/systemd/user /run/user/1000/systemd/user /run/systemd/user /run/user/1000/systemd/generator /home/westlake/.local/share/systemd/user /home/westlake/.local/share/flatpak/exports/share/systemd/user /var/lib/flatpak/exports/share/systemd/user /usr/local/share/systemd/user /usr/share/systemd/user /var/lib/snapd/desktop/systemd/user /usr/local/lib/systemd/user /usr/lib/systemd/user /run/user/1000/systemd/generator.late
Bug#944589: gsequencer: stalls system
It looks like I needed to do a reboot to verify the RT-bandwidth cap at the 50 limit for kernel.sched_rt_runtime_us in sysctl.. so "top" shows gsequencer at 200% (when ags is set with 'jack') 50 is about half rt period of 1 second(100), and so 200% on this computer means it is half the cpu bandwidth on a 4-core machine I'm using.. so this confirms the application is still saturating the RT bandwidth. 50/100 = 50% 200/400% = 50% If you have a 2-core system, then saturation in the output of "top" would be saying "100%" because the maximum cpu-bandwidth capacity is 200% for 2 cores. By default, the cap-protection for RT-bandwidth is set at 95.. I was curious to see if sysctl's setting of kernel.sched_rt_runtime_us was effective.. I've only known the basics, and I suppose there's something verifying for me here as well, I'm pretty confident I've been learning about RT things correctly as I've been setting up ardour+jack to work effectively.. maybe someone from debian team can help with the scheduling call things.. unfortunately I wouldn't be able to mentor coding specifics, but I know it has something to do with schedule functions. good luck..
Bug#944589: gsequencer: stalls system
it will just spike back to 110% when there is even a small load because you're not addressing the scheduling issue. On a 4-core system, when 50% is reserved for the RT-bandwidth the greatest percentage for CPU% utilization becomes 200%. But it is 200% that is shared for all RT-policy tasks.. basically this means 2 cores are fully saturated by that task in "cpu bandwidth".. it could be 2 cores each at 100% or 4 cores each having 50% utilization by the various threads by the application. A properly made application wouldn't saturate all available RT bandwidth, as that's called an out-of-control RT application...it's a scheduling-function coding issue... Any-time you have a run-away and in-appropriately scheduled application, you automatically have an improperly behaving application that can be used to do things it shouldn't.. eg:: fork-bombing a webserver to saturate a server, ddos-attacks is doing what ags is doing in saturating the cpu so that no other security task can run.. haven't coded in long time, but I'm experienced enough to understand the implications about process-bombing/saturation and run-away tasks.. The "FIFO" you see in the pictures -- threads with this policy class are RT, and so is RR, as well as BATCH policy task.. so everything of these three all need to fit inside the same RT bandwidth. Ags incorrectly saturates the whole rt bandwidth leaving no RT bandwidth for any other RT task --- such as "drivers" which run on FIFO threads. I wouldn't be a strong mentor on programming at this point in time... but basically your application is running out of control when it is doing this -- and there's stability as well security issue related. My gut feeling here is you should be investigating scheduling functions as I think it's pretty obvious because there's an error message showing exactly this.. Come back and update this report and let me know when this gets fixed. -- I could wait .. thanks
Bug#945561: dbus: fails for user context
somehow it got fixed with-> "dbus-launch systemctl --user" for some reason that did something and I now just use "systemctl --user" (even after a reboot) I'm able to see user-specific unit files I created in ~/.config/systemd/user , so I know I am really looking at the user context entries.. I wonder if a setting got marked when I used dbus-launch.. thanks
Bug#945431: systemd: missing files
somehow it got fixed with-> "dbus-launch systemctl --user" for some reason that did something and I now just use "systemctl --user" (even after a reboot) I'm able to see user-specific unit files I created in ~/.config/systemd/user , so I know I am really looking at the user context entries.. I wonder if a setting got marked when I used dbus-launch.. thanks
Bug#945431: systemd: missing files
somehow it got fixed with-> "dbus-launch systemctl --user" for some reason that did something and I now just use "systemctl --user" (even after a reboot) I'm able to see user-specific unit files I created in ~/.config/systemd/user , so I know I am really looking at the user context entries.. I wonder if a setting got marked when I used dbus-launch.. thanks
Bug#945431: systemd: missing files
Bugreport relayed to the dbus package, immediately closes bug with the following response, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945561 "" Even if systemd --user was suitable for being started by a D-Bus service file org.freedesktop.systemd1.service, it would be systemd (not dbus) that would be responsible for providing that file. smcv "" dbus does not handle the service file you spoke about... the dbus maintainer says your package is supposed to be hosting it.. "This file was removed deliberately as it is no longer needed." ^ "systemctl --user" is still used by many users and this user-context requires "org.freedesktop.systemd1.service" or some sort of replacement wherever that may be. So if not systemd, and changes need to be made with dbus, you should be informing other system service package maintainers to now be including it. A question I have is, why remove production features? Shouldn't this be going to sid/testing things? https://github.com/systemd/systemd/blob/master/NEWS "User units are now loaded also from $XDG_RUNTIME_DIR/systemd/user/. This is similar to the /run/systemd/user directory that was already previously supported, but is under the control of the user. " systemctl --user, was supported starting from 2014, ... there's no removal of this feature upstream according to the official changelog..
Bug#944589: gsequencer: stalls system
the system here sets RT for the applications without issue, "$ pgrep -fa jack 1717 /usr/bin/jackdbus auto $ chrt -a -p 1717 pid 1717's current scheduling policy: SCHED_OTHER pid 1717's current scheduling priority: 0 pid 1959's current scheduling policy: SCHED_OTHER pid 1959's current scheduling priority: 0 pid 1960's current scheduling policy: SCHED_FIFO pid 1960's current scheduling priority: 25 pid 1961's current scheduling policy: SCHED_OTHER pid 1961's current scheduling priority: 0 " " $ pgrep -fa ardour-5.12 7358 /opt/Ardour-5.12.0/bin/ardour-5.12.0 $ chrt -a -p 7358 pid 7358's current scheduling policy: SCHED_OTHER .. pid 7415's current scheduling policy: SCHED_FIFO pid 7415's current scheduling priority: 20 pid 7424's current scheduling policy: SCHED_FIFO pid 7424's current scheduling priority: 71 " the system does not show anything pulseaudio here, "$ pgrep -fa pulseaudio $ " I do have alsarawjack set for applications that want to connect to jack, so here alsa is already being used in this configuration. (~/.asoundrc) The ags.conf file you provided was tested with and it still causes failure even without jack and not configuring alsarawjack.. The rtkit-daemon.service is running, and limits.conf is set as it is supposed to for @audio group.. The stall occurs with both a custom kernel as well as a bpo-stocked one from debian.. both 5.2.x kernels.. Other applications can get their requested process/threads elevated to RT... spotted on the ags website, "systemd-run -p CPUAccounting=false -p MemoryAccounting=false -p TasksAccounting=false -p IOAccounting=false -p BlockIOAccounting=false --scope gsequencer" would not make a difference because these would need be set specifically for Debian(cgroups), and I suppose it is for the other mainstream distributions as well. ags was tried with various audio settings, different kernels- same error message. the bug must be in ags because all other RT applications here can be set with rt priority. recap:: The stall occurs with both a custom kernel as well as a bpo-stocked one from debian.. both 5.2.x kernels. The CPU is plenty resourceful with 4-core "Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz" with 8 gigs ram. The ags software has caused more than 12 stalls. -- filesystem checks and other extra things were tried to see if it can load past the plugin-loading stage. If someone knows how to fix this, feel free to give it a look.
Bug#945561: dbus: fails for user context
Package: dbus Version: 1.12.16-1 Severity: important "systemctl --user Failed to list units: The name org.freedesktop.systemd1 was not provided by any .service files " service org.freedesktop.systemd1 is missing, please add it back. thanks
Bug#945448: hostapd: bpo update fails to set service properly
a user can revert hostapd just using apt-get install hostapd=2:2.4-1+deb9u4 "apt-cache policy hostapd hostapd: Installed: 2:2.4-1+deb9u4 Candidate: 2:2.7+git20190128+0c1e29f-4~bpo9+2 Version table: 2:2.7+git20190128+0c1e29f-4~bpo9+2 500 500 http://debian.mirror.iweb.ca/debian stretch-backports/main i386 Packages *** 2:2.4-1+deb9u4 500 500 http://debian.mirror.iweb.ca/debian stretch/main i386 Packages 500 http://security.debian.org stretch/updates/main i386 Packages 100 /var/lib/dpkg/status " ^ the 2:2.7+git20190128+0c1e29f-4~bpo9+2 release was coming from stretch-backports https://wiki.debian.org/LTS "Debian 9 Stretch i386, amd64, armel, armhf and arm64 (to review before start) 2020 to June 2022"
Bug#945448: hostapd: bpo update fails to set service properly
Package: hostapd Version: 2:2.4-1+deb9u4 Severity: important using kernel 4.16.0-0.bpo.2-686-pae, the hostapd update to 2:2.7+git20190128+0c1e29f-4~bpo9+2 causes wlan0 to no longer work reverting back to 2:2.4-1+deb9u4 , allowed hostapd to run again correctly /etc/network/interfaces "auto wlan0 iface wlan0 inet static hostapd /etc/hostapd/hostapd.conf address 10.9.9.1 netmask 255.255.255.0 broadcast 10.9.9.255 " fwiw, the module the wireless chipset is using is ath5k observation: - ifconfig lists wlan0 - A client scanning the AP will see it appear for a couple of seconds before it disappears, even though ifconfig still says that wlan0 is still up. the issue is replicated for each of these release, tested multiple times and the result is the same for hostapd never working correctly with 2:2.7+git20190128+0c1e29f-4~bpo9+2.
Bug#944589: gsequencer: stalls system
""** Message: 13:46:42.039: loading preferences for: /home/user/.gsequencer/ags.conf sched_setscheduler failed: Operation not permitted " I managed to get the full error message before gsequencer fully stalls the system.. "timeout -s kill -k 30 30 gsequencer"[enter] something is wrong because the "timeout" command is not able to auto-shutdown the gsequencer process..
Bug#945431: systemd: missing files
Package: systemd Version: 242-8~bpo10 Severity: important listing the contents of systemd_242-8~bpo10+1_amd64.deb shows that org.freedesktop.systemd1.service is missing from this package please add this service file as it is needed for systemctl --user commands thanks
Bug#944589: gsequencer: stalls system
I tested with bpo kernel 5.2.0-0.bpo.3-rt-amd64 and similar issue. I notice there's a set_schedul* something message along with "operation not permitted"... that might provide a hint.. there's no ~/.gsequencer directory made yet, as the stall occurs either while still scanning ladspa or lv2 plugins. The point of the stall is random but it occurs during the plugin-scan.. -- terminal text shows the point that it stalls is random.. Sometimes I am able to do Ctl-c, sometimes not and I need to do a hard shutdown (power button)..
Bug#944839: linux-image-5.2.0-0.bpo.3-rt-amd64-unsigned: issues for application crash with this kernel
that solves it, thanks fwiw, I'm reading about this kernel option from lwn, https://lwn.net/Articles/673597/ and the opinions vary whether there's security improvement having it enabled/disabled... this may not be desirable for multi-user systems, here it's just a workstation so I suppose it is ok to use this mode as enabled. On 2019-11-16 3:13 a.m., Bastian Blank wrote: On Fri, Nov 15, 2019 at 11:23:09PM -0500, westlake wrote: When this kernel is used, the latest version of chrome crashes saying it can't launch because it is not able to create its own sandbox. (chrome "Version 78.0.3904.97 (Official Build) (64-bit)") Please try: | sysctl -w kernel.unprivileged_userns_clone=1 Bastian
Bug#944839: linux-image-5.2.0-0.bpo.3-rt-amd64-unsigned: issues for application crash with this kernel
Package: linux-image-5.2.0-0.bpo.3-rt-amd64-unsigned Version: 5.2.17-1~bpo10+1 Severity: important When this kernel is used, the latest version of chrome crashes saying it can't launch because it is not able to create its own sandbox. (chrome "Version 78.0.3904.97 (Official Build) (64-bit)") I like to have an rt kernel because I sometimes use jackdbus and ardour. I do not know if earlier versions of this application are an issue with this bpo kernel, but another application I have called "pulse-sms"(an .appimage application that is self contained) also shares the same error of not being able to create a "sandbox" and abruptly quits. I think there's something missing in this kernel, because I can boot into my custom "make deb-pkg" kernel with RT patches and both chrome and pulse-sms work again without issue. So it's more than chrome -- probably even affects debian-packaged applications. But the ubiquity of chrome tells me that filing this bug is important, so I marked it as such. If this helps: my kernel was compiled with gcc-8, and is kernel release 5.2.14 with official 5.2.14-rt7 RT-patches from kernel.org -- nothing else than kernel optons with "make menuconfig" and then performing "make deb-pkg"..
Bug#944589: gsequencer: stalls system
Bugreport on "Gsequencer" Case: - Kernel I've been using while using Gsequencer was a non-debian build that has RT support. (built on this system by me) Bugreport on Debian Kernel Backports: --- I am about to file a report. - bpo Kernel has an issue: Chrome cannot start and complains about not being able to run due to not being able to create a "sandbox" -> ( fwiw I'm filing a report on this to linux-image-5.2.0-0.bpo.3-rt-amd64-unsigned ) Kernel rebooted my system and sticking with my custom boot-kernel for now as I can run chrome again. I did not check to see if I can run gsequencer with the bpo kernel. I am using the basic "make deb-pkg" with RT patches. gcc-8 was used to compile this kernel. I am using other RT applications such as ardour, and jackd2/jackdbus and I'm not noticing issues.. cat /proc/version "Linux version 5.2.14-rt7 (customx@debian) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP PREEMPT RT Mon Sep 30 05:58:30 EDT 2019 " On 2019-11-13 5:50 a.m., Joël Krähemann wrote: Hi, thank you for reporting the bug. Do you use a custom realtime kernel configuration? best regards, Joël On Tue, Nov 12, 2019 at 10:18 AM westlake wrote: Package: gsequencer Version: 2.1.53-2 Severity: important stalls a system that is running on an RT kernel
Bug#944589: gsequencer: stalls system
Package: gsequencer Version: 2.1.53-2 Severity: important stalls a system that is running on an RT kernel
Bug#944381: (no subject)
apt-get output:
'Error in file "/usr/share/applications/Projucer.desktop":
"applications/x-juce" is an
invalid MIME type ("applications" is an unregistered media type)'
Bug#944382: xscreensaver-data-extra: invalid syntax in glitchpeg.desktop
Package: xscreensaver-data-extra Version: 5.42+dfsg1-1 Severity: normal from apt display error output, "Could not parse file "/usr/share/applications/screensavers/glitchpeg.desktop": Key file contains line ?several times a second. After a while, finds a new image to corrupt. Written by Jamie Zawinski; 2018.? which is not a key-value pair, group, or comment "
Bug#944381: juce-tools: invalid syntax in desktop file
Package: juce-tools
Version: 5.4.1+really5.4.1~repack-3
Severity: normal
'Error in file "/usr/share/applications/Projucer.desktop":
"applications/x-juce" is an
invalid MIME type ("applications" is an unregistered media type)'
Bug#943668: chromium disabling update component
revisited this again -- for some reason this build of chromium does not
honor this setting.
On 2019-11-03 3:21 a.m., westlake wrote:
a workaround that works is to use "--disable-component-update"
/etc/chromium.d/disable-chromium-update
CHROMIUM_FLAGS="${CHROMIUM_FLAGS} --disable-component-update"
that should prevent the update component from running..
Bug#943668: chromium disabling update component
a workaround that works is to use "--disable-component-update"
/etc/chromium.d/disable-chromium-update
CHROMIUM_FLAGS="${CHROMIUM_FLAGS} --disable-component-update"
that should prevent the update component from running..
Bug#939300: qsampler: missing dependencies
Package: qsampler Version: 0.5.0-1+b1 Severity: important Missing dependency "linuxsampler' otherwise application fails to work https://download.linuxsampler.org/packages/debian/ The latest available is 2.1.1, but would require an update for libgig https://download.linuxsampler.org/packages/linuxsampler-2.1.1.tar.bz2 https://www.linuxsampler.org/libgig/ https://download.linuxsampler.org/packages/libgig-4.2.0.tar.bz2
Bug#936012: pulseaudio: manpage missing
Package: pulseaudio Version: 12.2-4 Severity: normal manpage missing for daemon.conf https://www.debian.org/doc/debian-policy/ch-docs.html#manual-pages "If no manual page is available, this is considered as a bug and should be reported to the Debian Bug Tracking System (the maintainer of the package is allowed to write this bug report themselves, if they so desire). Do not close the bug report until a proper man page is available. "
Bug#935858: nftables: lacks documentation
actually there's still no mention of chain names able to be stored in capitals. The migratory tools automatically make capitals from iptables, and users would be tempted to try out documented commands. (even the link provided says nothing) .. so you re-consider adding this as a side-note. new users are tempted to try, "nft list chain filter output Error: No such file or directory list chain filter output ^^ " the nft syntax is difficult to grasp, and the output here is not even clear. If the output (I would say upstream is to blame) was actually more clear, then I would not need to report on confusion about this, and not have to dwell on telling you to provide some insight on what migratory tools actually do. The fact that error output and online documentation mentions nothing about having capitals for chain names, is the reason why I decided to file this report. The fact that many users also use migratory tools and likely face this same issue, is another reason why I think many users would actually benefit from a note or two in the README.Debian file. You should take the perspective that new adopters face this issue, and that I wouldn't be the only one facing this. Let it not be a main reason why NFT has not been widely adopted on Debian, because the least thing you could have done is to show me where I am wrong. Show me where it is documented. Show me where it says that chain names can be in capitals. Otherwise document it in README.Debian. ^ It's a Debian policy, and if you don't do it, then I will have to complain to the top leader about you being such a baby and revoke your abilities in maintaining this package. You also closed my other bugreport without a real good explanation on why you need to have nft binary executables at the header of .conf files. To me that is not just silly but impractical. Online documentation sources mention about using "nft list ruleset > nftables.conf" and effectively that overwrites the header. Use a bit of logic in maintaining this package. thanks
Bug#935858: nftables: lacks documentation
According to the nftables manpage, "The inet address family is a dummy family which is used to create hybrid IPv4/IPv6 tables. When no address family is specified, ip is used by default." considering a lot of users wanting to migrating from iptables to nft, would come across the issue that chain names need to be in capitals, .. I believe I have scathed incorrectly on the usage of "ip" over "inet" . inet can be used to set rules for both ipv4 and ipv6, but I haven't tested how well this works yet in this latest backports update.
Bug#935858: nftables: lacks documentation
Package: nftables Version: 0.9.1-2~bpo10+1 Severity: important All of the documentation I have uncovered online completely use things like, -> eg, take this nft add rule line nft add rule inet filter input counter drop Here there's two problems when trying to do this on Debian. 1) Debian uses "nft add rule ip" and not "nft add rule inet" 2) Debian uses "INPUT" << capitals for the chain name and not small caps. (small caps for the chain name also does not work on Debian's nft) Debian needs to document these changes in /usr/share/doc/nftables/README.Debian
Bug#935857: nftables: improvement for nft settings
Package: nftables Version: 0.9.1-2~bpo10+1 Severity: important there's a question on where firewall rules are supposed to be stored when it comes to nft on debian, A user looking at nft's systemd service will notice that rules are stored in /etc/nftables.conf Nftables.conf needs to have the header "#!/usr/sbin/nft -f" but why not make it simpler for users and instead put the nft command outside of this file? .conf files are not supposed to store executables at the header, that's non-intuitive and imho not a good idea. other distributions simply keep rules only in this file without any confusing header executable.. this also makes it non-standard , .conf files are not highly not regarded to be treated as scripting executables...
Bug#934030: xscreensaver-data-extra: glitchpeg.desktop contains split comment section
Package: xscreensaver-data-extra: Version: 5.42+dfsg1-1 Severity: normal the file /usr/share/applications/screensavers/glitchpeg.desktop has a comment line "Comment=" but is split across two lines..
Bug#932423: update
if I can update to this, a test was done on another desktop(same machine), so perhaps something is not properly set correctly in the mate desktop environment. I cannot figure it out, so if anyone knows they can give a hint. Not sure if it is just my desktop with mate on it, but flameshot was working previously on this same machine prior the upgrade.
Bug#932423: flameshot: copy function fails and stalls
Package: flameshot Version: 0.6.0-11 Severity: normal mate-desktop on debian buster here flameshot starts but stalls after drawing a selection on the screen and then choosing 'copy' . -- the 'save' and many of the draw functions work, but 'copy' for some reason causes a stall. (the mouse cursor can still be moved, but then nothing is selectable with mouse-click. So I cannot choose 'save' or even hit 'Escape' to get out of the selection mode of flameshot.) when ran from the terminal box, " flameshot QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::setRenderHint: Painter must be active to set rendering hints QPainter::setCompositionMode: Painter not active QPainter::translate: Painter not active QPainter::setPen: Painter not active QPainter::setBrush: Painter not active QPainter::setBrush: Painter not active Killed " the user needs to go to another terminal (ctl-alt-f1) and do kill -9 _flameshot_pid_ , otherwise nothing happens. The other function buttons are not selectable after choosing the 'copy' function.
Bug#931767: bash: shell parses ! when it shouldn't
Package: bash Version: 5.0.3(1) Severity: normal This bug occurs with the root account, If a normal user types "su -l" and issues this "ls" statement, ls -ld .!(?(.)) the output is without error. (the output lists all dot items with the exception of the annoying literals "." and "..") If "su" (without the -l), is given instead, then "!" is taken to be something else as though I am attempting to fire up a bash history command (eg: "!100" to run the 100th command from bash's history list) The error with ls -ld .!(?(.)) after doing "su" "bash: !: event not found" I could run this command in any directory without any issue, the error only occurs when entering the root account in bash with "su"
Bug#917929: lightdm: multiseat causes ghost-logins
Package: lightdm Version: 1.18.3-1 Severity: important Multi-seat works perfectly up to the point which I decribe below. There are existing users who do not login who automatically appear to login onto the workstation. (no remote services -- it's not a compromised system) loginctl SESSION UID USERSEAT TTY 145180 root 8901 1000 userA seat0 c14 131 lightdm seat0 c33 131 lightdm seat-1 Even after clearing the logged-in users (there's only about 2 or 3 users on this system.. ) , with loginctl terminate-user ... a user or two then re-appear again... ps shows gvfs things. I looked at timers with systemctl list-timers and disabled/stopped any of them. I also tried to look at timers with user accounts using, "systemctl --user" list-timers and couldn't find anything under there. I wonder what is "triggering" these processes... it must be a bug lightdm. /etc/lightdm/lightdm.conf [Seat:seat0] logind-check-graphical=true type=xlocal #xserver-config=/etc/X11/xorg.conf.intel_seat0 #note: debian's current Xorg (in this system), manpage does not indicate -seat seat_id but Xorg --help shows it is available xserver-config=/etc/X11/xorg.conf.seat0 xserver-command=/usr/bin/Xorg -nolisten tcp -layout layout_seat0 -seat seat0 -novtswitch [Seat:seat-1] logind-check-graphical=true type=xlocal xserver-config=/etc/X11/xorg.conf.seat-1 xserver-command=/usr/bin/Xorg -nolisten tcp -layout layout_seat-1 -seat seat-1 -novtswitch - I provided xserver-config for the two seats, there's nothing special I can find which can be triggering this... Despite the multiple ghost-logins, I am able to login via lightdm with the already listed users shown with loginctl list-users. -Scott Section "ServerLayout" Identifier "layout_seat-1" MatchSeat "seat-1" Screen 0 "Screen0" InputDevice"Mouse0" InputDevice"Keyboard0" Option "SingleCard" "on" EndSection Section "ServerFlags" Option "DefaultServerLayout" "layout_seat-1" Option "AllowMouseOpenFail" "true" Option "AutoAddDevices" "false" Option "Xinerama" "false" EndSection Section "InputDevice" Identifier "Keyboard0" # Driver "kbd" Driver "evdev" Option "GrabDevice" "on" Option "Device" "/dev/input/by-id/usb-Darfon_USB_Combo_Keyboard-event-kbd" Option "XkbRules" "base" Option "XkbModel" "pc105" Option "XkbLayout" "us" Option "CoreKeyboard" "on" EndSection Section "InputDevice" Identifier "Mouse0" # Driver "mouse" Driver "evdev" Option "GrabDevice" "on" Option "Protocol" "auto" Option "Device" "/dev/input/by-id/usb-Logitech_G400s_Optical_Gaming_Mouse-event-mouse" Option "CorePointer" "on" EndSection Section "Monitor" Identifier "Monitor_BL" VendorName "Acer" ModelName"1201(BL)" EndSection Section "Device" Identifier "Card0" Driver "nouveau" BusID "PCI:1:0:0" Option "Monitor-HDMI-A-2" "Monitor_BL" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor"Monitor_BL" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Section "ServerLayout" Identifier "layout_seat0" MatchSeat "seat0" Screen 0 "Screen0" InputDevice"Keyboard0" InputDevice"Mouse0" Option "SingleCard" "on" EndSection Section "ServerFlags" Option "DefaultServerLayout" "layout_seat0" Option "AllowMouseOpenFail" "true" Option "AutoAddDevices" "false" Option "Xinerama" "false" EndSection Section "InputDevice" Identifier "Keyboard0" # Driver "kbd" Driver "evdev" Option "GrabDevice" "on" # prevent send event to other X-servers Option "Device" "/dev/input/by-id/usb-Microsoft_Wired_Keyboard_600-event-kbd" Option "XkbRules" "base" Option "XkbModel" "pc105" Option "XkbLayout" "us" Option "CoreKeyboard" "on" EndSection Section "InputDevice" Identifier "Mouse0" # Driver "mouse" Driver "evdev" Option "GrabDevice" "on" Option "Protocol" "auto" Option "Device" "/dev/input/by-id/usb-Logitech_USB-PS_2_Optical_Mouse-event-mouse"
Bug#902705: chromium-widevine: missing component
Package: chromium-widevine Version: 66.0.3359.117-1~deb9u1 Severity: normal online services that use widevine won't run without /opt/google/chrome/libwidevinecdm.so which was copied to /usr/lib/chromium dpkg -L chromium-widevine /. /usr /usr/lib /usr/lib/chromium /usr/lib/chromium/libwidevinecdmadapter.so /usr/share /usr/share/doc /usr/share/doc/chromium-widevine /usr/share/doc/chromium-widevine/NEWS.Debian.gz /usr/share/doc/chromium-widevine/changelog.Debian.gz /usr/share/doc/chromium-widevine/copyright
Bug#887791: calf-plugins: dssi file missing
Package: calf-plugins Version: 0.0.60-5 Severity: important the dssi files are missing in /usr/lib/dssi/
Bug#879991: lynx: missing documentation
Package: lynx Version: 2.8.9dev16-1 Severity: normal on accessing help going to link "Lynx Users Guide — complete account of all Lynx features" " Main configuration file lynx.cfg Lynx has several levels of customization: from the Options Menu (accessible on-line, and possibly stored in your local .lynxrc file), via command-line switches on startup (mainly for batch processing). The most important and numerous default settings are stored in the Lynx configuration file lynx.cfg. If you are on a UNIX system you should have appropriate permissions to make changes there or ask your system administrator to modify lynx.cfg for your needs. This file provides default settings for all accounts on your system. It may be copied to your shell account and included with -cfg command line switch or via an environment variable LYNX_CFG (if you have shell access). Starting with version 2.8.1 Lynx has an include facility so you can load the system-wide configuration file and easily add one or more settings from your local add-on configuration file. It is really cool to read lynx.cfg with its comments for hundreds of options, most of them commented out because they are built-in defaults. You may visit an index of options: by category or by alphabet. " there is a link "by category" and "by alphabet" , when clicking on "by category", an error shows up, "The requested URL /release/breakout/lynx_help/cattoc.html was not found on this server."
Bug#848914: [debian-mysql] Bug#848914: mysql-server: supply configuration file for command-line arguments
I looked at it again and solved it.. I could not tell whether systemd was using /etc/init.d/mysql or an actual unit file so perhaps there should be a quick mention about this in /usr/share/doc/mysql-server/readme.debian.. thanks On 20/12/16 02:49 PM, Robie Basak wrote: severity 848914 wishlist tags 848914 + help thanks Hi, On Tue, Dec 20, 2016 at 02:07:22PM -0500, westlake wrote: please add support for /etc/default/mysql-server, otherwise users would need to edit script files in order to pass custom command-line arguments Our focus is on the systemd service as this is the default. It can be overridden in the usual way. I don't think anyone is currently looking after or testing the Sys V init script, if this is what you are referring to. Patches welcome, as long as you're also prepared to deal with any problems as a consequence of making changes there. Robie
Bug#848914: mysql-server: supply configuration file for command-line arguments
Package: mysql-server Version: mysql-server-5.6 Severity: normal please add support for /etc/default/mysql-server, otherwise users would need to edit script files in order to pass custom command-line arguments
Bug#848268: RFP: opentoonz
Package: wnpp Version: 1.1.2 Severity: wishlist * Package name: opentoonz Version: 1.1.2 Upstream Author: DWANGO * URL : https://github.com/opentoonz/opentoonz * License : (BSD) Description: OpenToonz is a 2D animation software OpenToonz is a 2D animation software published by DWANGO.
Bug#841060: (no subject)
still recurrs in 1:2.7+dfsg-3~bpo8+1
Bug#840648: fail2ban: missing settings
Package: fail2ban Version: 0.8.13-1 Severity: normal dbfile and dbpurgeage are missing
Bug#838607: linux-image-4.7.0-0.bpo.1-amd64-unsigned: new file date writing issue
Package: linux-image-4.7.0-0.bpo.1-amd64-unsigned Version: 4.7.2-1~bpo8+1 Severity: normal There's a bug with ext4 on the new 4.7 kernel -- rare but it happened here on an ext4 mountpoint (/home /dev/md1 ext4 rw,relatime,data=ordered) when a new file is created, the "create time" is not properly set.(2014 was written as the create year instead of 2016) it occured today after I updated to 4.7 so I can only assume it has something to do with it.. my system here has "mdadm" containers, and perhaps it's possible a set of conditions allowed this rarity to occur.
Bug#829401: linux-image-4.5.0-2-grsec-amd64: breaks qemu-nbd
"..it's obviously something from upstream." You got proof? Or is this just another jabbing guess of yours? Fedora's latest does not have this bug and it uses kernel 4.5.x The problem is definitely not upstream, as other distros which have kernel 4.5.x do not have this problem -- and Fedora is just one of them. Do I need to talk in a "pussy-cat tone" to make you feel special? You obviously didn't even bother to check if the bug is upstream. Afaict this bug is not on other distro kernels running 4.5. If you're so sure it is an upstream bug, then why not test it and prove me wrong? Here there other distros (NON DEBIAN) that work without issue. So do you actually "have proof" that it is a bug upstream? No you don't. Instead of creating another diversion and distraction, maybe you should let someone here give themselves the chance to add to this report than merely trying to discredit it. If you can't discredit the report, then at least try to replicate and "understand" -- even appreciate the time someone tries to "clarify" the confusion you have about anything. Since you are confused from the very start, I would suggest you let somebody else take care of it. Make the best of it.
Bug#829532: linux-image-4.6.0-0.bpo.1-amd64: breaks qemu-nbd
Package: linux-image-4.6.0-0.bpo.1-amd64
Version: 4.6.1-1~bpo8+1
Severity: normal
kernels 4.5 and 4.6 breaks qemu-nbd from mapping partitions
qemu-nbd can map partitions from VM images and raw disk images to
/dev/nbdNpM nodes, but proper module options have to be loaded prior so
that qemu-nbd performs these additional mappings (the general consensus
around mapping image files has users issuing "kpartx -a /dev/",
but kpartx is not needed at all after issuing qemu-nbd)
nothing is specially set up other than a module option file and that's
pretty much it -- there's just 2 or 3 commands for the testing --- all
which indicates the issue is more towards kernel than it is with qemu-nbd.
after a modprobe nbd is issued, there is no "/dev/nbd0p1"-like devices,
so the main problem with kernels 4.5/4.6 is that qemu-nbd is not being
allowed to generate any device nodes. ("partition" device nodes that is
-- "/dev/nbd0" and "/dev/nbd1" nodes are generated by modprobe nbd)
here in nbd(module) options, there is a hint for max_part that needs to
be specified in order for qemu-nbd to later work in generating the
partition devices /dev/nbdNpM.
(nbds_max=2 just means for modprobe to create "/dev/nbd0" and "/dev/nbd1")
/etc/modprobe.d/mynbd.conf
"
options nbd nbds_max=2 max_part=10
"
basically just a raw disk image containing one partition
dd if=/dev/zero of=1.bin bs=10M count=10
,creates a raw diskimage called 1.bin
any tool to create a dosmbr table containing at least 1 partition
(qemu-nbd can also work with GPT tables but it is not used)
cfdisk 1.bin , and exit the partition tool
no mkfs is needed, so one can immediately try to map the partitions from
the disk image 1.bin just by using qemu-nbd (here again "kpartx" is not
used at all. If one uses "kpartx", then it would rather create partition
device nodes in /dev/mapper. Using qemu-nbd -d [/dev/nbdN] also unmaps
partition nodes.. so forgetting to issue kpartx -d /dev/nbd0 prior
qemu-nbd -d, would leave a mess of broken device links in /dev/mapper)
qemu-nbd should map 1.bin to /dev/nbd0 and its first partition to
"/dev/nbd0p1". this partition device node does not exist yet but is
something that qemu-nbd would generate
"qemu-nbd -c /dev/nbd0 1.bin"
there is an option "-P "(qemu-nbd command) for specifying an exposure to
a single partition, but this has null effect
" -P, --partition=num
only expose partition I"
it is always "qemu-nbd -c /dev/nbd0 [IMAGE FILE]" that works (and after
max_part is used with "modprobe nbd") -- the /dev/nbd0p1 node then gets
generated... so something is up with the later kernels in breaking this
particular behaviour feature on behalf of qemu-nbd
Here the qemu-utils was updated and still no success...dmesg shows no
errors... there's also no errors from qemu-nbd's output but there is a
new notice about using "-f raw" for more safety for the end-user.
... the outcome is still the same (with or without "-f raw") -- the end
result is the image file is still treated as a "raw disk" which is
correct but there is no generation of partition devices
some output for the report,
modprobe -vvv nbd
insmod /lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko
nbds_max=20 max_part=10
modprobe: DEBUG: ../libkmod/libkmod-module.c:728 kmod_module_get_path()
name='nbd'
path='/lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko'
dpkg -l 'linux-image*'
ii linux-image-4.5.0-0.bpo.2-amd64 4.5.4-1~bpo8+1 amd64 Linux 4.5 for
64-bit PCs
ii linux-image-4.5.0-2-grsec-amd64 4.5.7-1+grsec201606222150+1~bpo8+1
amd64 Linux 4.5 for 64-bit PCs, Grsecurity protection
ii linux-image-4.6.0-0.bpo.1-amd64 4.6.1-1~bpo8+1 amd64 Linux 4.6 for
64-bit PCs
apt-cache policy qemu-utils
qemu-utils:
Installed: 1:2.1+dfsg-12+deb8u6
Candidate: 1:2.1+dfsg-12+deb8u6
Version table:
1:2.5+dfsg-4~bpo8+1 0
100 http://debian.bhs.mirrors.ovh.net/debian/
jessie-backports/main amd64 Packages
*** 1:2.1+dfsg-12+deb8u6 0
500 http://debian.bhs.mirrors.ovh.net/debian/ jessie/main amd64
Packages
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
linux-image-4.3.0-0.bpo.1-amd64 4.3.5-1~bpo8+1
latest kernel that works is 4.3, though i don't have access to a 4.4
kernel, i can't tell when between 4.3 and 4.5 qemu-nbd started to fail
Bug#829530: linux-image-4.5.0-0.bpo.2: breaks qemu-nbd
Package: linux-image-4.5.0-0.bpo.2-amd64
Version: 4.5.4-1~bpo8+1
Severity: normal
kernels 4.5 and 4.6 breaks qemu-nbd from mapping partitions
qemu-nbd can map partitions from VM images and raw disk images to
/dev/nbdNpM nodes, but proper module options have to be loaded prior so
that qemu-nbd performs these additional mappings (the general consensus
around mapping image files has users issuing "kpartx -a /dev/",
but kpartx is not needed at all after issuing qemu-nbd)
nothing is specially set up other than a module option file and that's
pretty much it -- there's just 2 or 3 commands for the testing --- all
which indicates the issue is more towards kernel than it is with qemu-nbd.
after a modprobe nbd is issued, there is no "/dev/nbd0p1"-like devices,
so the main problem with kernels 4.5/4.6 is that qemu-nbd is not being
allowed to generate any device nodes. ("partition" device nodes that is
-- "/dev/nbd0" and "/dev/nbd1" nodes are generated by modprobe nbd)
here in nbd(module) options, there is a hint for max_part that needs to
be specified in order for qemu-nbd to later work in generating the
partition devices /dev/nbdNpM.
(nbds_max=2 just means for modprobe to create "/dev/nbd0" and "/dev/nbd1")
/etc/modprobe.d/mynbd.conf
"
options nbd nbds_max=2 max_part=10
"
basically just a raw disk image containing one partition
dd if=/dev/zero of=1.bin bs=10M count=10
,creates a raw diskimage called 1.bin
any tool to create a dosmbr table containing at least 1 partition
(qemu-nbd can also work with GPT tables but it is not used)
cfdisk 1.bin , and exit the partition tool
no mkfs is needed, so one can immediately try to map the partitions from
the disk image 1.bin just by using qemu-nbd (here again "kpartx" is not
used at all. If one uses "kpartx", then it would rather create partition
device nodes in /dev/mapper. Using qemu-nbd -d [/dev/nbdN] also unmaps
partition nodes.. so forgetting to issue kpartx -d /dev/nbd0 prior
qemu-nbd -d, would leave a mess of broken device links in /dev/mapper)
qemu-nbd should map 1.bin to /dev/nbd0 and its first partition to
"/dev/nbd0p1". this partition device node does not exist yet but is
something that qemu-nbd would generate
"qemu-nbd -c /dev/nbd0 1.bin"
there is an option "-P "(qemu-nbd command) for specifying an exposure to
a single partition, but this has null effect
" -P, --partition=num
only expose partition I"
it is always "qemu-nbd -c /dev/nbd0 [IMAGE FILE]" that works (and after
max_part is used with "modprobe nbd") -- the /dev/nbd0p1 node then gets
generated... so something is up with the later kernels in breaking this
particular behaviour feature on behalf of qemu-nbd
Here the qemu-utils was updated and still no success...dmesg shows no
errors... there's also no errors from qemu-nbd's output but there is a
new notice about using "-f raw" for more safety for the end-user.
... the outcome is still the same (with or without "-f raw") -- the end
result is the image file is still treated as a "raw disk" which is
correct but there is no generation of partition devices
some output for the report,
modprobe -vvv nbd
insmod /lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko
nbds_max=20 max_part=10
modprobe: DEBUG: ../libkmod/libkmod-module.c:728 kmod_module_get_path()
name='nbd'
path='/lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko'
dpkg -l 'linux-image*'
ii linux-image-4.5.0-0.bpo.2-amd64 4.5.4-1~bpo8+1 amd64 Linux 4.5 for
64-bit PCs
ii linux-image-4.5.0-2-grsec-amd64 4.5.7-1+grsec201606222150+1~bpo8+1
amd64 Linux 4.5 for 64-bit PCs, Grsecurity protection
ii linux-image-4.6.0-0.bpo.1-amd64 4.6.1-1~bpo8+1 amd64 Linux 4.6 for
64-bit PCs
apt-cache policy qemu-utils
qemu-utils:
Installed: 1:2.1+dfsg-12+deb8u6
Candidate: 1:2.1+dfsg-12+deb8u6
Version table:
1:2.5+dfsg-4~bpo8+1 0
100 http://debian.bhs.mirrors.ovh.net/debian/
jessie-backports/main amd64 Packages
*** 1:2.1+dfsg-12+deb8u6 0
500 http://debian.bhs.mirrors.ovh.net/debian/ jessie/main amd64
Packages
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
linux-image-4.3.0-0.bpo.1-amd64 4.3.5-1~bpo8+1
latest kernel that works is 4.3, though i don't have access to a 4.4
kernel, i can't tell when between 4.3 and 4.5 qemu-nbd started to fail
Bug#829518: qemu-utils: qemu-nbd max_part issue
Package: qemu-utils
Version: 1:2.1+dfsg-12+deb8u6
Severity: normal
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829401
The report I sent this against package linux-image-4.5.0-2-grsec-amd64
breaks qemu-nbd's ability to work with max_part. Since the kernel team
is unwillingly to bother about it because they have to try commands with
"qemu-nbd", they are unwilling to look into it.
Here I've tried 4 kernels, the ones that are output with dpkg -l has
been tried. The excuse the kernel team gives about "grsec/non-grsec" is
a mere distration. The bug occurs whether the kernel has grsec built
into it or not, but it occurs against the kernel package it is report
against. They're just unwillingly to bother about it.
My observation is "qemu-nbd" (latest 1:2.5) or "1:2.1" both work fine
and exhibit the same "bug" for kernels above 4.3
"
kernels 4.5 and 4.6 breaks qemu-nbd from mapping partitions.
"qemu-nbd can map partitions from VM images and raw disk images to
/dev/nbdNpM nodes, but proper module options have to be loaded prior so
that qemu-nbd performs these additional mappings (the general consensus
around mapping image files has users issuing "kpartx -a /dev/",
but kpartx is not needed at all after issuing qemu-nbd)
nothing is specially set up other than a module option file and that's
pretty much it -- there's just 2 or 3 commands for the testing --- all
which indicates the issue is more towards kernel than it is with qemu-nbd.
after a modprobe nbd is issued, there is no "/dev/nbd0p1"-like devices,
so the main problem with kernels 4.5/4.6 is that qemu-nbd is not being
allowed to generate any device nodes. ("partition" device nodes that is
-- "/dev/nbd0" and "/dev/nbd1" nodes are generated by modprobe nbd)
here in nbd(module) options, there is a hint for max_part that needs to
be specified in order for qemu-nbd to later work in generating the
partition devices /dev/nbdNpM.
(nbds_max=2 just means for modprobe to create "/dev/nbd0" and "/dev/nbd1")
/etc/modprobe.d/mynbd.conf
"
options nbd nbds_max=2 max_part=10
"
basically just a raw disk image containing one partition
dd if=/dev/zero of=1.bin bs=10M count=10
,creates a raw diskimage called 1.bin
any tool to create a dosmbr table containing at least 1 partition
(qemu-nbd can also work with GPT tables but it is not used)
cfdisk 1.bin , and exit the partition tool
no mkfs is needed, so one can immediately try to map the partitions from
the disk image 1.bin just by using qemu-nbd (here again "kpartx" is not
used at all. If one uses "kpartx", then it would rather create partition
device nodes in /dev/mapper. Using qemu-nbd -d [/dev/nbdN] also unmaps
partition nodes.. so forgetting to issue kpartx -d /dev/nbd0 prior
qemu-nbd -d, would leave a mess of broken device links in /dev/mapper)
qemu-nbd should map 1.bin to /dev/nbd0 and its first partition to
"/dev/nbd0p1". this partition device node does not exist yet but is
something that qemu-nbd would generate
"qemu-nbd -c /dev/nbd0 1.bin"
there is an option "-P "(qemu-nbd command) for specifying an exposure to
a single partition, but this has null effect
" -P, --partition=num
only expose partition I"
it is always "qemu-nbd -c /dev/nbd0 [IMAGE FILE]" that works (and after
max_part is used with "modprobe nbd") -- the /dev/nbd0p1 node then gets
generated... so something is up with the later kernels in breaking this
particular behaviour feature on behalf of qemu-nbd
Here the qemu-utils was updated and still no success...dmesg shows no
errors... there's also no errors from qemu-nbd's output but there is a
new notice about using "-f raw" for more safety for the end-user.
... the outcome is still the same (with or without "-f raw") -- the end
result is the image file is still treated as a "raw disk" which is
correct but there is no generation of partition devices
some output for the report,
modprobe -vvv nbd
insmod /lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko
nbds_max=20 max_part=10
modprobe: DEBUG: ../libkmod/libkmod-module.c:728 kmod_module_get_path()
name='nbd'
path='/lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko'
dpkg -l 'linux-image*'
ii linux-image-4.5.0-0.bpo.2-amd64 4.5.4-1~bpo8+1 amd64 Linux 4.5 for
64-bit PCs
ii linux-image-4.5.0-2-grsec-amd64 4.5.7-1+grsec201606222150+1~bpo8+1
amd64 Linux 4.5 for 64-bit PCs, Grsecurity protection
ii linux-image-4.6.0-0.bpo.1-amd64 4.6.1-1~bpo8+1 amd64 Linux 4.6 for
64-bit PCs
apt-cache policy qemu-utils
qemu-utils:
Installed: 1:2.1+dfsg-12+deb8u6
Candidate: 1:2.1+dfsg-12+deb8u6
Version table:
1:2.5+dfsg-4~bpo8+1 0
100 http://debian.bhs.mirrors.ovh.net/debian/ jessie-backports/main
amd64 Packages
*** 1:2.1+dfsg-12+deb8u6 0
500 http://debian.bhs.mirrors.ovh.net/debian/ jessie/main amd64 Packages
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
linux-image-4.3.0-0.bpo.1-amd64 4.3.5-1~bpo8+1
latest kernel that works is 4.3,
Bug#829401: linux-image-4.5.0-2-grsec-amd64: breaks qemu-nbd
You're confused from a dpkg -l output? I think it's pretty clear what the full package for "4.6" really is. Try reading the dpkg -l output from above. thanks On 03/07/16 03:18 AM, Yves-Alexis Perez wrote: On sam., 2016-07-02 at 20:36 -0400, westlake wrote: kernels 4.5 and 4.6 breaks qemu-nbd from mapping partitions There's no 4.6 grsec kernel, so I'm a bit confused about your report. Can you check with the non grsec 4.5 and 4.6 kernel and report back? I have the feeling it's completely unrelated and thus should be reported to the non grsec linux images. Regards,
Bug#829401: linux-image-4.5.0-2-grsec-amd64: breaks qemu-nbd
Package: linux-image-4.5.0-2-grsec-amd64
Version: 4.5.7-1+grsec201606222
Severity: normal
kernels 4.5 and 4.6 breaks qemu-nbd from mapping partitions
qemu-nbd can map partitions from VM images and raw disk images to
/dev/nbdNpM nodes, but proper module options have to be loaded prior so
that qemu-nbd performs these additional mappings (the general consensus
around mapping image files has users issuing "kpartx -a /dev/",
but kpartx is not needed at all after issuing qemu-nbd)
nothing is specially set up other than a module option file and that's
pretty much it -- there's just 2 or 3 commands for the testing --- all
which indicates the issue is more towards kernel than it is with qemu-nbd.
after a modprobe nbd is issued, there is no "/dev/nbd0p1"-like devices,
so the main problem with kernels 4.5/4.6 is that qemu-nbd is not being
allowed to generate any device nodes. ("partition" device nodes that is
-- "/dev/nbd0" and "/dev/nbd1" nodes are generated by modprobe nbd)
here in nbd(module) options, there is a hint for max_part that needs to
be specified in order for qemu-nbd to later work in generating the
partition devices /dev/nbdNpM.
(nbds_max=2 just means for modprobe to create "/dev/nbd0" and "/dev/nbd1")
/etc/modprobe.d/mynbd.conf
"
options nbd nbds_max=2 max_part=10
"
basically just a raw disk image containing one partition
dd if=/dev/zero of=1.bin bs=10M count=10
,creates a raw diskimage called 1.bin
any tool to create a dosmbr table containing at least 1 partition
(qemu-nbd can also work with GPT tables but it is not used)
cfdisk 1.bin , and exit the partition tool
no mkfs is needed, so one can immediately try to map the partitions from
the disk image 1.bin just by using qemu-nbd (here again "kpartx" is not
used at all. If one uses "kpartx", then it would rather create partition
device nodes in /dev/mapper. Using qemu-nbd -d [/dev/nbdN] also unmaps
partition nodes.. so forgetting to issue kpartx -d /dev/nbd0 prior
qemu-nbd -d, would leave a mess of broken device links in /dev/mapper)
qemu-nbd should map 1.bin to /dev/nbd0 and its first partition to
"/dev/nbd0p1". this partition device node does not exist yet but is
something that qemu-nbd would generate
"qemu-nbd -c /dev/nbd0 1.bin"
there is an option "-P "(qemu-nbd command) for specifying an exposure to
a single partition, but this has null effect
" -P, --partition=num
only expose partition I"
it is always "qemu-nbd -c /dev/nbd0 [IMAGE FILE]" that works (and after
max_part is used with "modprobe nbd") -- the /dev/nbd0p1 node then gets
generated... so something is up with the later kernels in breaking this
particular behaviour feature on behalf of qemu-nbd
Here the qemu-utils was updated and still no success...dmesg shows no
errors... there's also no errors from qemu-nbd's output but there is a
new notice about using "-f raw" for more safety for the end-user.
... the outcome is still the same (with or without "-f raw") -- the end
result is the image file is still treated as a "raw disk" which is
correct but there is no generation of partition devices
some output for the report,
modprobe -vvv nbd
insmod /lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko
nbds_max=20 max_part=10
modprobe: DEBUG: ../libkmod/libkmod-module.c:728 kmod_module_get_path()
name='nbd'
path='/lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko'
dpkg -l 'linux-image*'
ii linux-image-4.5.0-0.bpo.2-amd64 4.5.4-1~bpo8+1 amd64 Linux 4.5 for
64-bit PCs
ii linux-image-4.5.0-2-grsec-amd64 4.5.7-1+grsec201606222150+1~bpo8+1
amd64 Linux 4.5 for 64-bit PCs, Grsecurity protection
ii linux-image-4.6.0-0.bpo.1-amd64 4.6.1-1~bpo8+1 amd64 Linux 4.6 for
64-bit PCs
apt-cache policy qemu-utils
qemu-utils:
Installed: 1:2.1+dfsg-12+deb8u6
Candidate: 1:2.1+dfsg-12+deb8u6
Version table:
1:2.5+dfsg-4~bpo8+1 0
100 http://debian.bhs.mirrors.ovh.net/debian/
jessie-backports/main amd64 Packages
*** 1:2.1+dfsg-12+deb8u6 0
500 http://debian.bhs.mirrors.ovh.net/debian/ jessie/main amd64
Packages
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
linux-image-4.3.0-0.bpo.1-amd64 4.3.5-1~bpo8+1
latest kernel that works is 4.3, though i don't have access to a 4.4
kernel, i can't tell when between 4.3 and 4.5 qemu-nbd started to fail
Bug#829291: qemu-system-x86: missing object iothread
Package: qemu-system-x86 Version: 1:2.5+dfsg-4~bpo8+1 Severity: important x-data-plane is now known as iothread and is missing from this build of qemu
Bug#817113: apt: buggy string expansion
Package: apt Version: 1.0.9.8.2 Severity: normal an odd bug,.. here when I do "apt-cache show streamer0.10-plugins-good", reveals the description for package "gstreamer0.10-plugins-good".
Bug#797237: not gone completely
systemd is still causing network shares to auto-disconnect when "auto" is being used let me know if this has been fixed in sid thanks
Bug#797237: systemd: network shares auto-disconnect
this bug seems to have vanished after an update.
Bug#807503: vlc: snapshots
Package: vlc Version: 2.2.0~rc2-2+deb8u1 Severity: normal take snapshot works but only for .flv files
Bug#797237: systemd: network shares auto-disconnect
Package: systemd Version: 215-17+deb8u1 Severity: normal network shares auto-disconnect themselves after a certain amount of time -- this happens after a couple of hours but it occurs at least twice a day.. not sure why this happens but it did not occurr with wheezy. here i'm using the following webdav and samba mountpoints defined in /etc/fstab, #webdav https://dav1.localdomain/dav1 /mnt/dav1 davfs rw,uid=wstlk,gid=wstlk,dir_mode=750,_netdev 0 0 https://dav2.localdomain/dav2 /mnt/dav2 davfs rw,uid=wstlk,gid=wstlk,dir_mode=750,_netdev 0 0 #smb //smb1.localdomain/smb1 /mnt/smb1 cifs credentials=/root/.mysmbcred/.res,dir_mode=0750,rw,uid=wstlk,gid=wstlk,_netdev 0 0 //smb2.localdomain/smb2 /mnt/smb2 cifs credentials=/root/.mysmbcred/.bookshelf,dir_mode=0750,rw,uid=wstlk,gid=wstlk,_netdev 0 0 applying mount -a quicktly remounts the shares without issue
Bug#797236: cifs-utils: share disconnects after time
Package: cifs-utils Version: 2:6.4-1 Severity: normal the network shares auto-disconnect themselves after a certain amount of time, happens after a couple of hourse but it occurs at least twice a day.. not sure why this happens but it's never showed up on wheezy. this has actually been going on ever since I updated to jessie, .. not sure where to look in the logs, but nothing seems to show up i'd really like to investigate this but I double checked things -- the mountpoints automatically load up properly on systemboot, the system does not go to sleep when these mountpoints get disconnected, and the servers on the otherside are always on, there's nothing between 2 servers and this workstation other than a switch box so there can't be a networking issue. anyone else experience this issue? couldn't find another bug related to this. here i'm using the following with /etc/fstab #webdav https://dav1.localdomain/dav1 /mnt/dav1 davfs rw,uid=wstlk,gid=wstlk,dir_mode=750,_netdev 0 0 https://dav2.localdomain/dav2 /mnt/dav2 davfs rw,uid=wstlk,gid=wstlk,dir_mode=750,_netdev 0 0 #smb //smb1.localdomain/smb1 /mnt/smb1 cifs credentials=/root/.mysmbcred/.res,dir_mode=0750,rw,uid=wstlk,gid=wstlk,_netdev 0 0 //smb2.localdomain/smb2 /mnt/smb2 cifs credentials=/root/.mysmbcred/.bookshelf,dir_mode=0750,rw,uid=wstlk,gid=wstlk,_netdev 0 0 applying mount -a remounts the shares without issue (there's a notice that a 5th share cannot be mounted -- this is normal as that server is not up)
Bug#796594: mate-desktop: can't launch menu item after editing
Package: mate-desktop Version: 1.8.1+dfsg1-3+deb8u1 Severity: normal can't launch menu item after editing it. the portion edited is just the description/label, it shouldn't affect it.
Bug#796136: xdg-utils: editing menu item fails to launch
Package: xdg-utils Version: 1.1.0~rc1+git20111210-7.4 Severity: normal Editing an menu item (Description and label) later fails to launch. Relogged-in to an alternative Desktop, the menu item is still not launchable.
Bug#795929: libreoffice-writer: printing not available unless starting from terminal
Package: libreoffice-writer Version: 1:4.3.3-2+deb8u1 Severity: normal (also occurs with the latest) when using a cups print configuration with /etc/cups/client.conf, libreoffice-writer fails to open a dialog printing window unless libreoffice-writer is started from a terminal Does not work: start Libreoffice-writer from the Desktop menu, open a document, and choose File/Print. The Loffice writer window grays and offers no further input. Printing works: start a terminal, and run Libreoffice-writer using lowriter, open a document, and choose File/Print. A prompt in the terminal shows up. ... continuing.. A password is prompted to the user (The printing service is password protected). Typing the password correctly, a secondary password prompt shows up again, and then a third prompt shows up graphically printing then works after
Bug#794350: RFP: yaf
Package: wnpp Version: 2.7.1 Severity: wishlist * Package name: yaf Version: 2.7.1 Upstream Author: Brian Trammell * URL : http://tools.netsa.cert.org/yaf/index.html * License : (GPLv2) Description: a network packet flowmeter tool with ipfix support -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794033: scanlogd: fails to pick up scan
Package: scanlogd Version: 2.2.5-3.2 Severity: important Scanlogd fails to pick up scan, here it has been tested on two public ips, computer 1: where it is running scanlogd and tcpdump computer 2: where nmap ran nmap -PS22-28 [ip of computer 1] When running nmap from machine 2, tcpdump shows the scanning of ports from 22 to 28. Though scanlogd never reports anything to syslog. using syslog-ng -- all traffic, no filter, sourcing - system() and internal() which should pick up all default logging facilities The only thing that gets logged during this session is tcpdump messages of an interface(basic messages with promiscuous mode going on and ofF) I'd really like to have this package working as I don't think there are any other alternatives I can find that can provide the very feature I'm looking for.(pads, and psad do something else) It is also difficutl to find this package with apt-cache search, perhaps there can be additional keywords in its description, eg: nids and network, thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664841: packaging
it would be great if this were packaged. it makes a lot of sense since elasticsearch is already provided. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788304: bind9: can't stop properly with rndc
Package: bind9
Version: 1:9.9.5.dfsg-9
Severity: normal
the user should be given the option not to use rndc if he so wishes to.
here when controls {}; is issued with named.conf, the daemon scripts
fail with rndc.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788170: syslog-ng: syslog() function not supported
Package: syslog-ng Version: 3.3.5-4 Severity: normal This particular feature is a main contributing factor why syslog-ng was supported in design, but this doesn't seem to work in the edition released in debian. output: syslog-ng --syntax-only Error parsing afsocket, syntax error, unexpected KW_IP, expecting LL_IDENTIFIER or LL_STRING in /etc/syslog-ng/syslog-ng.conf at line 31, column 9: syslog( ip(1.1.1.1) port(601) transport(tcp) ); the legacy options of using udp() and tcp() work, but the newer messaging with syslog() doesn't. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787596: cups-daemon: authinforequired directive not documented
Is there a good reason why all directives except this one shouldn't be mentioned in the printers.conf manpage? It's just this directive that seems to be missing. thanks On 03/06/15 12:02 PM, Brian Potkin wrote: Thank you for your report, westlake. On Wed 03 Jun 2015 at 04:17:00 -0400, westlake wrote: setting AuthInfoRequired is missing from documentation http://localhost:631/help/spec-ipp.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/556fe8fd.6080...@videotron.ca
Bug#787596: cups-daemon: authinforequired directive not documented
Package: cups-daemon Version: 1.7.5-11 Severity: normal setting AuthInfoRequired is missing from documentation -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786559: cryptsetup: broken boot delay when using keyfile
Package: cryptsetup Version: 2:1.6.6-5 Severity: normal Dear Maintainer, When using a keyfile with a luks volume on bootup there's a delay with the message showing a dependency failure but the given volume actually opens A start job is running for dev-disk-by\x2duuid- s / 1 min 30s which displays the uuid of the filesystem containing the keyfile journalctl -b shows May 22 14:41:36 debian systemd[1]: Job dev-disk-by\x2duuid of /dev/sda2:-mykeyfile.device/start May 22 14:41:36 debian systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-uuid May 22 14:41:36 debian systemd[1]: Dependency failed for Cryptography Setup for sdb1_crypt. May 22 14:41:36 debian systemd[1]: Dependency failed for Encrypted Volumes. The encrypted volume does not fail and the system continues to boot as normal The delay is very long of 30 seconds so this is problematic The system setup here is, /dev/sda1 (300 MB ext2) for /boot /dev/sda2 (1 MB ext2) for one keyfile -- this partition contains the keyfile which was created as (I know this is not the ideal location for the keyfile -- using a test machine) dd if=/dev/urandom of=mykeyfile bs=512 count=8 iflag=fullblock /dev/sdb1 which contains the luks volume - there is just 1 ext2 filesystem on it (/dev/mapper/sdb1_crypt which maps to /) The steps done after post-install was the creation of a secret partition (/dev/sda2) containing the keyfile, added this key to the luks key slot (crypsetup luksAddKey) for /dev/sdb1, /etc/crypttab was edited to contain the following, sdb1_crypt UUID=crypt uuid /dev/disk/by-uuid/sda2's uuid:/mykeyfile luks,keyscript=passdev the previous line in this file was commented out sdb1_crypt UUID=uuid none luk so there's just one line in /etc/crypttab..and as usual, update-initramfs -u -k all according to /usr/share/doc/cryptsetup/README.initramfs.gz the startup should immediately forget the partition containing the keyfile 0. The passdev keyscript If you have a keyfile on a removable device (e.g. a USB-key), you can use the *passdev keyscript. It will wait for the device to appear, mount it read-only, read the key and then unmount the device. but here same boot delay occurs with removable devices please have a look thanks Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786578: (no subject)
sdb1_crypt UUID=05a7ec49-f4b3-4d58-b906-932b7bec8457 /dev/fd0:/mykeyfile
luks,keyscript=passdev
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2 /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=quiet
GRUB_CMDLINE_LINUX=cryptdevice=/dev/disk/by-uuid/05a7ec49-f4b3-4d58-b906-932b7bec8457:sdb1_crypt
cryptkey=/dev/fd0:ext2:/mykeyfile
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM=0x01234567,0xfefefefe,0x89abcdef,0xefefefef
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass root=UUID=xxx parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY=true
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE=480 440 1
GRUB_ENABLE_CRYPTODISK=y
Disk /dev/fd0: 1.4 MiB, 1474560 bytes, 2880 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/sda: 5 GiB, 5368709120 bytes, 10485760 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8e12fed5
Device Boot Start End Sectors Size Id Type
/dev/sda12048 10483711 10481664 5G 83 Linux
Disk /dev/mapper/sdb1_crypt: 5 GiB, 5364514816 bytes, 10477568 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ ${next_entry} ] ; then
set default=${next_entry}
set next_entry=
save_env next_entry
set boot_once=true
else
set default=0
fi
if [ x${feature_menuentry_id} = xy ]; then
menuentry_id_option=--id
else
menuentry_id_option=
fi
export menuentry_id_option
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_msdos
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha1
insmod ext2
cryptomount -u 05a7ec49f4b34d58b906932b7bec8457
set root='cryptouuid/05a7ec49f4b34d58b906932b7bec8457'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1 --hint-efi=hd1
--hint-baremetal=ahci1 --hint='cryptouuid/05a7ec49f4b34d58b906932b7bec8457'
2d432860-7f6a-49bb-bfc7-d8e4aebfb16e
else
search --no-floppy --fs-uuid --set=root 2d432860-7f6a-49bb-bfc7-d8e4aebfb16e
fi
font=/usr/share/grub/unicode.pf2
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_CA
insmod gettext
fi
terminal_output gfxterm
if [ ${recordfail} = 1 ] ; then
set timeout=-1
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload=${1}
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-2d432860-7f6a-49bb-bfc7-d8e4aebfb16e' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod cryptodisk
insmod luks
insmod
Bug#786578: cryptsetup: crypt asks passphrase instead of using keyfile
Package: cryptsetup Version: 2:1.6.6-5 Severity: wishlist Dear Maintainer, I suppose this is still in the works as other distros there are guides on having /boot included within the encrypted volume. The procedure, if this is something of interest to debian, is relatively simple. I believe this might be a wishful feature but it might even be a bug -- I'm still new to using luks but I know using a keyfile with luks works perfectly -- however with /boot in a luks container a keyfile won't be picked up even if it were on removable media (as it were tested) Afaict this also wasn't reported, so here is... the report! :p A manual partitioning was done with debian's installer using just a removable device (for the crypt key), and one drive containing a luks partition. I'm using virtualbox so it's more convenient for me to use this -- but it could be another removable device to hold the cryptkey. The drive partitioned: /dev/sda1 luks and /dev/sda2 for /boot (can set it 50-300 mb -- smallest possible as it will be deleted later. technically I really used another drive for this since it is difficult to resize the luks container if possible.) sda1 luks is mapped to /dev/mapper/cryptroot (cryptroot contains one ext2 partition which itself gets mounted to / (there is no sdb as it eventually takes sda's place) On post-install I attempted to use the keyfile while having /boot inside the luks volume (passphrase and floppy containing the keyfile both tested to work perfectly). Here the things done after install: - created a keyfile, stored it to floppy(or usb storage), and added the key to the luks container - moved /boot partition files to the encrypted volume (removed /boot from /etc/fstab) - updated /etc/default/grub and /etc/crypttab and carried out the update commands (update-initramfs, update-grub2, grub-install -- basically these three) The changes needed for /etc/default/grub: GRUB_ENABLE_CRYPTODISK=y GRUB_CMDLINE_LINUX=cryptdevice=/dev/disk/by-uuid/05a7ec49-f4b3-4d58-b906-932b7bec8457:sdb1_crypt cryptkey=/dev/fd0:ext2:/mykeyfile The file /etc/crypttab needs to be done before update-initramfs, and I made sure to remove the default line which defines only using a passphrase. I know there is some referencing towards the floppy as I'm seeing the delay error message(reported bug #786559) and I have also set the floppy module in /etc/modules and /etc/initramfs-tools/modules. I tried seeing if this made a difference but still no success. I have made attachments where there's sdb1_crypt referenced instead of cryptroot -- a second drive was used to hold /boot but this drive was permanently removed. thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785251: kpartx: unmapping with image files
Package: kpartx Version: 0.5.0-6 Severity: normal kpartx -a path to raw image file adds /dev/mapper/loop0pN entries successfully, however kpartx -d path to raw image file doesn't appear to do anything as mappings still show up in /dev/mapper and losetup in order to delete mappings, one has to do kpartx -d /dev/loopN then apply losetup -d /dev/loopN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783747: (no subject)
L.J.Lane you could ask what kernel this occurs on than marking it as non-reproducible. The default kernel that gets installed with Jessie 8 amd64 (3.16.0-4), does not work with iptables. If you are trying to reproduce this bug, be sure you are using Jessie 8 amd64 as I don't know whether it affects the 32-bit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783958: linux-image-3.16.0-4-amd64: iptables fails to work with jessie's kernel
Package: linux-image-3.16.0-4-amd64 Version: 3.16.7-ckt9-3~deb8u1 Severity: important A simple test with iptables against Jessie's default kernel fails to work, but using a custom kernel not from repositories and iptables works. A simple test is done allowing one match rule, and it can immediately be seen there is a problem with either iptables or Jessie's default kernel of 3.16.0-4-amd64. eg, iptables -I INPUT -p tcp --dport 22 -j ACCEPT iptables -P INPUT DROP traffic to port 22 later works if I apply iptables -P INPUT ACCEPT Using a non-stock kernel, the above example works exactly as expected. Since iptables can work with another kernel then I suppose there is something wrong with linux-image-3.16.0-4-amd64 preventing iptables from working. please have a look thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783958: linux-image-3.16.0-4-amd64: iptables fails to work with jessie's kernel
please close this bugreport (discovered this bug should be handled better by another source -- openvswitch) thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783747: iptables: not accepting rule
Package: iptables Version: 1.4.21-2+b1 Severity: important a simple test with ssh doesn't pass, eg, iptables -I INPUT -p tcp --dport 22 -j ACCEPT iptables -P INPUT DROP traffic to port 22 later works if I apply iptables -P INPUT ACCEPT, but for some reason the match rule is not being picked up please fix this thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783766: packagekit: goes missing from systemctl list-units
Package: packagekit Version: 1.0.1-2 Severity: normal after disabling and stopping packagekit, it not longer shows up in systemctl list-units please have a look thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783437: linux-image-3.16.0-4-amd64: buggy debian patch to kernel upstream.
Package: linux-image-3.16.0-4-amd64 Version: 3.16.7-ckt9-3~deb8u1 Severity: normal Not sure what is being changed in the kernel going for jessie, but from what I can tell for two upgrades I had to resort to a newer kernel from debian's experimental. I have got two systems here that get the same problem, and this relates to the video/Xorg driver issue. Though it may sound remotely unrelated, I think something that debian is doing with upstream is the reason why there is the same video driver issue. kernel linux-image-3.16.0-4-amd64 is problematic (as well as the others of amd64 3.14+ from backports or updates,.. no different result), for nvidia and intel gfx. The driver loads up shown in X log, and there is nothing extra more in detail to know really -- same symptom going all the way back from kernel 3.2 and up. So it's been happening before jessie but the user can manage to find a workaround with it.(though not easily, it's difficult unless one is familiar with it) 1- Video driver loads 2- Xorg attempts to start, no edid information is ever picked up. Graphic server fails to find any screens configured because for some reason it knows there is a video card(using the desired driver) but doesn't apply to using it at all and X immediately quits. (I don't bother to using fallback drivers as there's no point to using them when accelerated graphics is instead needed) If the same thing is broken (two machines, one nvidia, the other stocked intel) and I know it has something to do with debian's adjustments to the upstream because when I recompile outside debian's standard repository (backports or stable), the problem is then resolved. but maybe someone out there knows it better than I can-- something in 3.17 rc5 from experimental is enabling more support for video drivers to be working in general, at least for the two systems here being tested. What's common between these two machines. One uses the nvidia driver with the 3.17rc5 kernel, the other uses just this same kernel and uses the stocked intel video driver. Both systems then get their video detection resolved as E-did can be picked up by the X server.. I know there's a lot of blame on nvidia drivers, but this also happens with a kernel's stocked intel driver which should be working regardless the problems with nouveau and nvidia. Since there is a problem with even the stocked intel driver in a debian repackaging for Jessie(3.16.0-4), and using 3.17rc5 actually overcomes it, then perhaps this might offer a clue to something wrong with one of the patches going into 3.16. so please have a look thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782511: pitivi: segmentation fault
Package: pitivi Version: 0.93-4.2 Severity: important pitivi initially was able to start up with a welcome box. pitivi later fails to start after the missing dependencies button is selected. The 'missing dependencies' button was clicked from the welcome box. When pitivi fails, the following terminal message shows (pitivi:30402): Clutter-WARNING **: clutter_x11_set_use_argb_visual() can only be used before calling clutter_init() (pitivi:30402): Clutter-WARNING **: clutter_x11_set_display() can only be used before calling clutter_init() (pitivi:30402): Clutter-WARNING **: clutter_x11_disable_event_retrieval() can only be used before calling clutter_init() (pitivi:30402): Clutter-WARNING **: clutter_disable_accessibility() can only be called before initializing Clutter. Missing soft dependency: - pycanberra not found on the system - enables sound notifications when rendering is complete Segmentation fault -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782425: fuss-launcher: fails to function
Package: fuss-launcher Version: 0.5-1 Severity: important Software fails to function properly for its primary goals (searching) and it can't query application names properly. It would be best to remove it as it's been 5 years it was last updated. thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781788: (no subject)
Problem doesn't seem to replicate, it must have occured by some condition I wouldn't know about. Feel free to look into it, if you can't replicate this then it is good to close this. thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781788: kpartx: unmaps incorrect devices
Package: kpartx Version: 0.5.0-5 Severity: normal Items loop0p1 and nbd0p1 existing in /dev/mapper, when issuing kpartx -d /dev/nbd0, loop0p1 disappears Expected result is the command should only remove nbd0 mappings and not loop0p1 .. There's generally three ways I make mappings with kpartx when working with raw image files. [attaching] 1- Use qemu-nbd, then apply kpartx on an /dev/nbdN device 2- Use losetup on a raw image, then apply kpartx on an /dev/loopN device 3- Use kpartx directly on a raw image file There's a related concern if kpart -d should perform losetup after creating a mapping in 3- situation. I've noticed the following when applying kpartx -d for each of the above scenarios [detaching] 1- qemu-nbd -d /dev/nbdN would need to applied to fully remove the mapping (normal) 2- losetup -d /dev/loopN would need to be applied to fully remove the mapping (normal) 3- kpartx -d fully removes /dev/loopN and any /dev/mapper/loopNpM entries, so losetup -d is not needed .. If testing this, in the way I set things up is as follows, Use losetup on a raw image file containing a partition table Use qemu-nbd on a separate image with a partition table Issue kpartx -a /dev/nbd0 followed by kpartx -a /dev/loop0 Verify there are entries in /dev/mapper (nbd0pN, loop0pN ...) Now issue kpartx -d /dev/nbd0, and notice /dev/mapper/loop0pN entries would also be removed(which shouldn't) thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777429: update
i verified it again, udisks --inhibit-all-polling didn't catch it on time, and there was two mounts on the same partition... So far at this point this problem doesn't show up again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777429: dosfstools: mkfs doesn't clear table
Package: dosfstools Version: 3.0.27-1 Severity: important If an item at the top node of the filesystem is written, it'll show up again after a format. ls -la /mnt/vfatmount/ exhibits say abc umount /mnt/vfatmount mkfs.vfat /dev/[device partition] , output indicates nothing out of the unordinary remount this same fat32 partition and listing the remount shows that abc gets listed. udisks --inhibit-all-polling is also used on any Desktop login screen. -Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775967: RFP: selector
Package: wnpp Version: N/A Severity: wishlist * Package name: selector Version: 1.1.7 Upstream Author: F.Fleuret * URL : http://www.idiap.ch/~fleuret/software.html#selector * License : (GPL 3) Description: selector is a real-time pattern matcher for console The selector command is a real-time interactive pattern matcher in console. It can be used to visit efficiently files in general, and shell history in particular. For the latter, contrary to what the readline C-r does, it does not show only one entry at a time, but restricts in real time the display to all the entries matching the pattern. You can at any time select one, which will be injected in the input buffer of the current tty. It is a bit difficult to explain what this does without indicating an example or two. pretty much it is a program that offers to auto-type text to the command prompt but from the convenience of a menu list. The menu list in question is something that selector presents upon execution after given a text file to it (or a redirected stream if no textfile). The real-time pattern matching of the program is presented to the user when selector has started. Using up and down arrow keys selects different list items but while using a-z keys(or typing strings) the menu list dynamically updates itself on the matched alhanumeric string. Once an item is chosen, the enter key is used to quickly close selector and the selected text is auto-typed into the command-prompt. Finally on the the command-prompt, the selected text which has been auto-typed is not sent with an ending enter, so in case there needs to be a minor edit of the command it can still be done before finally committing it. it would be good if this program is available for debian.. thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775879: libgnome-2-0: single-click becomes double-click at random
Package: libgnome-2-0 Version: 2.32.1-5 Severity: important https://bugzilla.gnome.org/show_bug.cgi?id=743276 Anyone want to look at this be my guest.. thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774271: whohas: outdated search references
Package: whohas Version: 0.29-0.3 Severity: important a simple test of 'whohas bash' shows there's no result please update -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774272: qbittorent: app exits immediately using rt-mouse button
Package: qbittorent Version: 3.1.10-1 Severity: normal In the Content section if the right-mouse button is applied twice then the application would immediately exit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772685: sagan: abandoned package/no longer works
A software package that does not work at all deems to be reported in critical state. thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772685: sagan: abandoned package/no longer works
Pierre, what are your intentions regarding this package? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772685: sagan: abandoned package/no longer works
Package: sagan Version: 0.2.1.r1-1 Severity: critical The upstream of this package is edition 1.0 while this package edition on debian is actually quite 2 years out of date. bug 681794 here on Jessie/testing appears to be the same as filed back in 2012 ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681794 ) It would be great if this package got updated as this software is still being actively developed. thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
