Bug#695523: no bug; missing package?
Hi all, Some friends of mine ran into the same problem. They're using the gnome desktop environment and pulseaudio. I've just did some test on my machine. I think it's an configuration issue, based on a specific software combination: - without pulseaudio, using alsa: pause/unpause in working as expected - with pulseaudio and vlc without plugins: pause/unpause causes mute problems - with pulseaudio and vlc-plugin-pulse [1] installed: pause/unpause is working as expected vlc -vv (without vlc-plugin-pulse): [...] [0x1bb38e8] main audio output warning: buffer way too late (185630), dropping buffer [0x1b97a88] mpgatofixed32 audio filter debug: libmad error: bad main_data_begin pointer [0x1bb38e8] main audio output warning: not synchronized (104463 us), resampling [0x1bb38e8] main audio output warning: buffer way too late (263947), dropping buffer [...] vlc -vv (with vlc-plugin-pulse): [...] [0x26e1ea8] pulse audio output debug: missing latency from input [0x26e1ea8] pulse audio output warning: too late by 101093 us [0x26e1ea8] pulse audio output debug: changed sample rate to 44186 Hz [...] Maybe this helps someone, Georg [1] http://packages.debian.org/wheezy/vlc-plugin-pulse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#780939: virtualbox-dkms does not work for backported kernels.
Hi, Just a quick follow-up question: On Mon, 14 Sep 2015 05:11:58 + (UTC) Gianfranco Costamagna wrote: > Unfortunately we can't know *in advance* the kernel that will be > backported to jessie, so we can't make it build with a newer kernel > that the one in jessie when it was released. Does this mean, if running jessie and a backported kernel, each time the kernel receives an update, virtualbox has to be updated as well? > Fortunately with the security updates this problem won't be there > anymore. Could you elaborate on this? Thanks for your work and all the best, Georg signature.asc Description: Digital signature
Bug#838355: needrestart: Automatic restart mode doesn't work
Hi Thomas, On 16-11-03 22:42:47, Thomas Liske wrote: > "ge...@riseup.net" writes: > > needrestart tells me that it restarted a service, however, this > > doesn't seem to be true: > > absolutely! The codepath for list and automatic mode was missing the > composite command execution for systemd. The upstream fix will be part > of needrestart 2.10. Thanks for the quick fix, much appreciated! Given that it's already in unstable, I assume that it will go in j-bp as well soon, right? If so, any ETA for this? Something like ~ four weeks? > Thanks for reporting! Thanks for your work! All the best, Georg signature.asc Description: Digital signature
Bug#824198: ITP: pry-nav -- Binding navigation commands for Pry to make a simple debugger
Package: wnpp Owner: Georg Faerber Severity: wishlist Package name: pry-nav Version : 0.2.4 Upstream Author : Gopal Patel URL : https://github.com/nixme/pry-nav License : Expat Programming Lang: Ruby Description : Binding navigation commands for Pry to make a simple debugger Turn Pry into a primitive debugger. Adds 'step' and 'next' commands to control execution. This package will be maintained within the Debian Ruby team. I'm packaging this, to satisfy a dependency of ruby-mail-gpg [1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823771 signature.asc Description: Digital signature
Bug#824199: ITP: pry-remote -- Connect to Pry remotely
Package: wnpp Owner: Georg Faerber Severity: wishlist Package name: pry-remote Version : 0.1,7 Upstream Author : Mon ouie URL : https://github.com/Mon-Ouie/pry-remote License : Zlib Programming Lang: Ruby Description : Connect to Pry remotely using DRb This package will be maintained within the Debian Ruby team. I'm packaging this, to satisfy a dependency of pry-nav [1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824198 signature.asc Description: Digital signature
Bug#824460: testing using alpha versions?
On 16-05-16 10:57:03, Holger Levsen wrote: > one problem debugging this is that this problem occurs only if+when > there is a new upstream version of torbrowser to be updated too, which > only happens every 6-8 weeks or so. Not sure if I'm missing something obvious here, but: If testing would happen in a clean, new, environment (a virtual machine for example) each time, one could run these tests multiple times without the need for any releases or updates. (I could provide hardware for this for regular, automated use or to set up a proof of concept.) signature.asc Description: Digital signature
Bug#824460: torbrowser upgrades still broken with apparmor enabled
version: 0.1.9-1+deb8u3
On 16-05-16 10:47:54, Holger Levsen wrote:
> so it seems upgrades of torbrowser are still not working using the
> apparmor rules from torbrowser-launcher in sid.
Jessie is affected as well.
Here are the relevant logs from my test made yesterday:
May 15 08:12:38 debian kernel: [ 106.598753] audit: type=1400
audit(1463314358.156:61): apparmor="STATUS" operation="profile_load"
name="system_tor" pid=2489 comm="apparmor_parser"
May 15 08:12:38 debian tor[2536]: Starting tor daemon...done.
May 15 08:12:39 debian kernel: [ 108.413825] audit: type=1400
audit(1463314359.968:62): apparmor="STATUS" operation="profile_load"
name="/usr/bin/torbrowser-launcher" pid=2586 comm="apparmor_parser"
May 15 08:12:40 debian kernel: [ 108.592963] audit: type=1400
audit(1463314360.152:63): apparmor="STATUS" operation="profile_load"
name="/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/{Browser/TorBrowser/,}Tor/tor"
pid=2594 comm="apparmor_parser"
May 15 08:12:40 debian kernel: [ 109.047827] audit: type=1400
audit(1463314360.608:64): apparmor="STATUS" operation="profile_load"
name="/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox"
pid=2602 comm="apparmor_parser"
May 15 08:12:53 debian kernel: [ 121.839612] audit: type=1400
audit(1463314373.400:65): apparmor="ALLOWED" operation="mknod"
profile="/usr/bin/torbrowser-launcher"
name="/usr/lib/python2.7/dist-packages/torbrowser_launcher/__init__.pyc"
pid=2653 comm="torbrowser-laun" requested_mask="c" denied_mask="c" fsuid=1000
ouid=1000
May 15 08:12:53 debian kernel: [ 121.878588] audit: type=1400
audit(1463314373.436:66): apparmor="ALLOWED" operation="mknod"
profile="/usr/bin/torbrowser-launcher"
name="/usr/lib/python2.7/dist-packages/torbrowser_launcher/common.pyc" pid=2653
comm="torbrowser-laun" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
May 15 08:12:54 debian kernel: [ 123.063284] audit: type=1400
audit(1463314374.624:67): apparmor="ALLOWED" operation="mknod"
profile="/usr/bin/torbrowser-launcher"
name="/usr/lib/python2.7/dist-packages/torbrowser_launcher/settings.pyc"
pid=2653 comm="torbrowser-laun" requested_mask="c" denied_mask="c" fsuid=1000
ouid=1000
May 15 08:12:54 debian kernel: [ 123.070623] audit: type=1400
audit(1463314374.628:68): apparmor="ALLOWED" operation="mknod"
profile="/usr/bin/torbrowser-launcher"
name="/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.pyc"
pid=2653 comm="torbrowser-laun" requested_mask="c" denied_mask="c" fsuid=1000
ouid=1000
May 15 08:14:14 debian kernel: [ 203.266401] audit: type=1400
audit(1463314454.824:69): apparmor="DENIED" operation="link"
profile="/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox"
name="/home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/.cache/fontconfig/CACHEDIR.TAG.LCK"
pid=2685 comm="firefox" requested_mask="l" denied_mask="l" fsuid=1000
ouid=1000 target="/home/use
May 15 08:14:14 debian kernel: [ 203.266520] audit: type=1400
audit(1463314454.824:70): apparmor="DENIED" operation="link"
profile="/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox"
name="/home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/.cache/fontconfig/8131ec73ed69543fcdb4c5ad42e8e92e-le64.cache-4.LCK"
pid=2685 comm="firefox" requested_mask="l" denied_mask="l" fsuid
May 15 08:14:17 debian kernel: [ 205.728555] audit: type=1400
audit(1463314457.284:71): apparmor="DENIED" operation="link"
profile="/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox"
name="/home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/.cache/fontconfig/8131ec73ed69543fcdb4c5ad42e8e92e-le64.cache-4.LCK"
pid=2685 comm="firefox" requested_mask="l" denied_mask="l" fsuid
signature.asc
Description: Digital signature
Bug#803171: [Pkg-privacy-maintainers] Bug#803171: this only affects one profile in complaint mode
On 16-05-09 15:13:36, Holger Levsen wrote: > > Which suites are we talking about: unstable, testing, ...? Something > > else? > > unstable mostly, jessie is good to know as well :) I've tested both jessie and unstable, both broken currently, see [1] for details. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824460 signature.asc Description: Digital signature
Bug#824460: testing using alpha versions?
On 16-05-22 15:45:48, intrigeri wrote: > Holger Levsen wrote (22 May 2016 12:52:46 GMT) : > > as I tried to say above: the problem is, an update arrives, and people > > update their system. After this the update cannot be tested anymore (as > > people are understandably not really willing to go back to a backed up > > state and retest again). > > I suspect that Georg had automated testing in mind, so what *people* > are ready to do or not doesn't matter this much. E.g. an automated > test could keep around copies of ~/.local/share/torbrowser/, restore > the one corresponding to the previous Tor Browser release, and test > the update to the last version as Georg described, right? (no, > I didn't volunteer :) *people* and *automated* are keywords...so, yes, I proposed to set up automated tests. Either like intrigeri described, aka keeping copies of ~/.local/share/torbrowser/, or, maybe easier to achieve, for each test create a new virtual machine or use an existing one (or one, just set up for this task), and delete ~/.local/share/torbrowser/ and ~/.config/torbrowser/ before or after the test. This way, in case I'm not overlooking something, it would be possible to do the tests without relying on alpha releases. I guess, it would make sense, to create an environment which mimics the environments of the "normal users", aka no alpha releases, if I'm not mistaken. If this sounds like a possible way to go in your ears, I could write / set up a proof of concept. (But we would have to decide first roughly how this should look like / how this should work.) Notes: - I proposed this way to test apparmor profiles etc, which doesn't necessarily check for a smooth upgrade path between different versions. If we would like to do this as well, we would indeed have to keep copies of ~/.local/share/torbrowser/ (and ~/.config/torbrowser/ ?) like intrigeri described. - Even if one would test using alpha versions, there would have to be a way to do this multiple times in a row, which would mean, as far as I understand the things currently, having some sort of deleting / restoring the directories and running the update(s) again. Cheers, Georg signature.asc Description: Digital signature
Bug#824460: [Pkg-privacy-maintainers] Bug#824460: testing using alpha versions?
On 16-05-23 11:30:33, Holger Levsen wrote: > On Mon, May 23, 2016 at 12:02:20PM +0200, ge...@riseup.net wrote: > > Notes: > > > > - I proposed this way to test apparmor profiles etc, which doesn't > > necessarily check for a smooth upgrade path between different > > versions. If we would like to do this as well, we would indeed have > > to keep copies of ~/.local/share/torbrowser/ (and > > ~/.config/torbrowser/ ?) like intrigeri described. > > while it certainly would be great to test the apparmor profiles without > testing upgrades, I'd like to emphasize/repeat that the apparmor > profiles currently are working fine except for the upgrade usecase. Thus > "just" adding tests for the stuff which is non-broken ain't too helpful. Well, not sure what "upgrade" actually means, no tbl installed -> tbl installed [case 1] (AND?) OR old tbl installed -> current tbl installed [case 2] but, FWIW, case 1 *is* currently broken (not sure if this counts as an "upgrade"). Not sure if this is an edge-case right now, but, given the current situation, I think it would be worth to test this. (And for this, it would be sufficient to just delete the directories and run the upgrade.) It would prevent users from running into a situation like: "I've installed tbl, but it doesn't work". I think / hope there are new users, which would / will install tbl a some point in time "from scratch". This should be tested, in my opinion. > Once these tests work nicely it should be rather straightforward to > enable apparmor in a VM, install torbrowser-launcher and run it. And: > this framework has snapshotting too… > > It would be a long shot, but maybe worth it? Yes! signature.asc Description: Digital signature
Bug#824460: [Pkg-privacy-maintainers] testing using alpha versions?
On 16-05-23 13:22:16, Holger Levsen wrote: > On Mon, May 23, 2016 at 03:14:34PM +0200, ge...@riseup.net wrote: > > Well, not sure what "upgrade" actually means, > > > > no tbl installed -> tbl installed [case 1] > > (AND?) OR > > old tbl installed -> current tbl installed [case 2] > > upgrade is #2, #1 is called install :) > > and it's not about tbl but tb(!) Thanks for the clarification! > > but, FWIW, case 1 *is* currently broken (not sure if this counts as an > > "upgrade"). Not sure if this is an edge-case right now, but, given the > > current situation, I think it would be worth to test this. > > (And for this, it would be sufficient to just delete the directories and > > run the upgrade.) > > you mean torbrowser is broken with apparmor always? in sid? jessie? > both? Actually, now I see where some misunderstanding might come from... :( I _thought_ #1 is an "upgrade" as well, that's why I wrote so in [1]. (Sorry for not paying enough attention to the bug title.. :[ ) So, to be clear: I've tested the _install_ in sid and jessie, and both are broken right now, hence testing *this* (with whatever framework) is needed, in my opinion, or the apparmor profiles should be removed, like discussed already. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824460#20 signature.asc Description: Digital signature
Bug#824460: [Pkg-privacy-maintainers] Bug#824460: testing using alpha versions?
On 16-05-23 15:43:09, Holger Levsen wrote: > next ambigity: is installation and usage broken, or just installation? > (IOW: can I disable the apparmor profile for installation and then > reenable it for using it…) Tested both sid and jessie now: Install fails (with aa enabled), but usage is possible (with aa disabled). > this distincion is important when looking at what needs fixing :) Something along the lines of [1]. Cheers, Georg [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824460#20 signature.asc Description: Digital signature
Bug#824460: [Pkg-privacy-maintainers] Bug#824460: testing using alpha versions?
On 16-05-23 17:24:12, Holger Levsen wrote:
> On Mon, May 23, 2016 at 07:00:29PM +0200, ge...@riseup.net wrote:
> > On 16-05-23 15:43:09, Holger Levsen wrote:
> > > next ambigity: is installation and usage broken, or just installation?
> > > (IOW: can I disable the apparmor profile for installation and then
> > > reenable it for using it…)
> >
> > Tested both sid and jessie now: Install fails (with aa enabled), but
> > usage is possible (with aa disabled).
>
> and is usage possible with aa enabled after you installed with aa
> disabled?
No, this applies to both sid and jessie.
/var/log/syslog shows:
May 23 16:50:35 debian kernel: [ 163.913573] audit: type=1400
audit(1464036635.462:65): apparmor="ALLOWED" operation="open"
profile="/usr/bin/torbrowser-launcher"
name="/sys/devices/pci:00/:00:0d.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/queue/hw_sector_size"
pid=1359 comm="torbrowser-laun" requested_mask="r" denied_mask="r" fsuid=1000
ouid=0
May 23 16:50:36 debian kernel: [ 164.797894] audit: type=1400
audit(1464036636.346:66): apparmor="ALLOWED" operation="exec"
profile="/usr/bin/torbrowser-launcher" name="/sbin/ldconfig" pid=1363 comm="sh"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
target="/usr/bin/torbrowser-launcher//null-1"
May 23 16:50:36 debian kernel: [ 164.819898] audit: type=1400
audit(1464036636.366:67): apparmor="ALLOWED" operation="open"
profile="/usr/bin/torbrowser-launcher//null-1"
name="/usr/lib/locale/locale-archive" pid=1363 comm="ldconfig"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
May 23 16:50:36 debian kernel: [ 164.820069] audit: type=1400
audit(1464036636.366:68): apparmor="ALLOWED" operation="getattr"
profile="/usr/bin/torbrowser-launcher//null-1"
name="/usr/lib/locale/locale-archive" pid=1363 comm="ldconfig"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
May 23 16:50:36 debian kernel: [ 164.820225] audit: type=1400
audit(1464036636.366:69): apparmor="ALLOWED" operation="open"
profile="/usr/bin/torbrowser-launcher//null-1" name="/etc/ld.so.cache" pid=1363
comm="ldconfig" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
May 23 16:50:36 debian kernel: [ 164.820290] audit: type=1400
audit(1464036636.366:70): apparmor="ALLOWED" operation="getattr"
profile="/usr/bin/torbrowser-launcher//null-1" name="/etc/ld.so.cache" pid=1363
comm="ldconfig" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
May 23 16:50:36 debian kernel: [ 164.821061] audit: type=1400
audit(1464036636.370:71): apparmor="ALLOWED" operation="open"
profile="/usr/bin/torbrowser-launcher//null-1" name="/etc/locale.alias"
pid=1363 comm="ldconfig" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
May 23 16:50:36 debian kernel: [ 164.821136] audit: type=1400
audit(1464036636.370:72): apparmor="ALLOWED" operation="getattr"
profile="/usr/bin/torbrowser-launcher//null-1" name="/etc/locale.alias"
pid=1363 comm="ldconfig" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
May 23 16:50:37 debian kernel: [ 166.026773] audit: type=1400
audit(1464036637.575:73): apparmor="DENIED" operation="open"
profile="/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox"
name="/run/NetworkManager/resolv.conf" pid=1383 comm="firefox"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
May 23 16:50:37 debian kernel: [ 166.027256] audit: type=1400
audit(1464036637.575:74): apparmor="DENIED" operation="open"
profile="/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox"
name="/run/NetworkManager/resolv.conf" pid=1383 comm="firefox"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
May 23 16:50:43 debian kernel: [ 171.823494] audit: type=1400
audit(1464036643.374:75): apparmor="DENIED" operation="open"
profile="/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox"
name="/run/NetworkManager/resolv.conf" pid=1383 comm="firefox"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
signature.asc
Description: Digital signature
Bug#820583: flashplugin-nonfree: should notify when an update is not yet available, not just reinstall current version
unmerge 820583 reopen 820583 thanks Hi all, As per the subject, this bug is about "flashplugin-nonfree: should notify when an update is not yet available, not just reinstall [the] current version". This has nothing to do with a specific situation like when an update is delayed, but it's a more general issue. In my opinion, this bug isn't "Done:", because this is not fixed. I'm thus unmerging and reopening this bug. Thanks and all the best, Georg signature.asc Description: Digital signature
Bug#814489: [Pkg-privacy-maintainers] Bug#814489: tails-installer: fails with "Could not find the 'ifcpu64.c32' COM32 module"
(Sorry for missing In-Reply-To: and References:) @intrigeri: Do you need support / help with this? Just in case you're missing the time: Would you be happy to get a patch? signature.asc Description: PGP signature
Bug#814489: [Pkg-privacy-maintainers] Bug#814489: tails-installer: fails with "Could not find the 'ifcpu64.c32' COM32 module"
On 16-04-29 14:01:07, ge...@riseup.net wrote: > @intrigeri: Do you need support / help with this? Just in case you're > missing the time: Would you be happy to get a patch? Sorry, just overlooked the fact that it's already fixed in git. Sorry for the noise then.. :( signature.asc Description: PGP signature
Bug#823771: ITP: ruby-mail-gpg -- GPG/MIME encryption plugin for the Ruby Mail Library
Package: wnpp Owner: Georg Faerber Severity: wishlist Package name: ruby-mail-gpg Version : 0.2.6 Upstream Author : Jens Krämer URL : https://github.com/jkraemer/mail-gpg License : MIT Programming Lang: Ruby Description : GPG/MIME encryption plugin for the Ruby Mail Library This tiny library adds GPG capabilities to Mail::Message and ActionMailer::Base. Because privacy matters. This package will be maintained within the Debian Ruby team; the git repository can be found at anonscm [1]. I'm packaging this, to satisfy a dependency of schleuder3 [2], a "gpg-enabled mailinglist with remailing-capabilities", which I'll package soon as well. [1] https://anonscm.debian.org/cgit/pkg-ruby-extras/ruby-mail-gpg.git/ [2] https://git.codecoop.org/schleuder/schleuder3/ signature.asc Description: Digital signature
Bug#803171: this only affects one profile in complaint mode
Hi, On 16-03-06 09:28:02, Holger Levsen wrote: > Could someone using apparmor (or having access to test setup) please > comment whether just setting it to enforce now works or else include > the logs here? Will do that on the upcoming Sunday. Which suites are we talking about: unstable, testing, ...? Something else? Cheers, Georg signature.asc Description: Digital signature
Bug#825317: Bug #825317: bash-completion: Un-escaped "~*" leads to spurious NSS lookups
found 825317 1:2.1-4 thanks Hi Daniel, Thanks for reporting this. Actually, this issue is quite old; [1] points to the corresponding Ubuntu bug. According to this, just removing the patch fixes this issue, but I'm unsure about the potential downside(s) doing so and lacking time to check. All the best, Georg [1] https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1390061 signature.asc Description: Digital signature
Bug#768618: Bug#768922: [Debian-ha-maintainers] Bug#768618: Bug#768922: Bug#768618: pacemaker: FTBFS in jessie: build-dependency not installable: libqb-dev (>= 0.16.0.real)
On 15-01-20 15:36:39, Raoul Bhatia wrote: > I'd also like to know how to get involved on that. > > I currently see two possibilities: > > a) address the important, release critical bugs. > However, ideally would need someone of the old maintainers/uploaders > (added as CC) to sponsor that. > > b) See if a quick backport will be possible after the release. > > What do you think? > Raoul Anyone interested in setting up a "team" to take care of this, to bring pacemaker into jessie-backports or to find an alternative way to make it usable in jessie? signature.asc Description: Digital signature
Bug#777453: tracker.debian.org: Reset forgotten password not working
Package: tracker.debian.org Severity: normal Using [1] to reset a forgotten password doesn't work; after one enters a valid and registered email into the corresponding field, and clicks "Reset Password", the following gets displayed: "In order to complete the password reset, you must confirm that you are the owner of the account by following an email sent to the given email address. Please check your email inbox for details." However, it seems, that the mail in question never gets sent; maybe it's stuck somewhere or it doesn't get created. Would be great if someone could have a look into this. Cheers, Georg [1] https://tracker.debian.org/accounts/+forgot-password/ signature.asc Description: Digital signature
Bug#777453: tracker.debian.org: Reset forgotten password not working
Hi Raphael, Thanks for looking into this! On 15-02-09 22:39:06, Raphael Hertzog wrote: > On Sun, 08 Feb 2015, ge...@riseup.net wrote: > > However, it seems, that the mail in question never gets sent; maybe > > it's stuck somewhere or it doesn't get created. > > It's sent but it gets rejected because of: > > [...] > > I have pushed a fix to the tracker to use ow...@tracker.debian.org as > sender address. Seems appropriate... :) > Please try again and let me know if it works better. Works as expected now, thus closing this bug, thanks for the fast fix. Cheers, Georg signature.asc Description: Digital signature
Bug#775921: unblock: torbrowser-launcher/0.1.8-1 (pre-approval)
Hi all, On 15-01-27 20:43:27, Holger Levsen wrote: > On Dienstag, 27. Januar 2015, Niels Thykier wrote: > > Ack, please go ahead and remove the moreinfo tag once it has been > > uploaded to unstable. > > thanks! but sadly 0.1.8-1 is not suitable and probably I dont want 0.1.9-1 > neither, the changes due to github tickets #155 and 157 might be too > invasive/unsafe... > > So maybe the diff will be even smaller than 0.1.8-1 in which case i'll just > upload to sid as 0.1.7+debian-1. If we decide to go with 0.1.9-1 instead, > I'll > come back to you first though. > > de13483 (from 0.1.8) and 3f1146e (from 0.1.9, fixing de13483) are the > problematic upstream commits I'm talking about... I've spoke with Holger about how to proceed with this, which version to build and upload for Debian and which commits to include. He asked if I could write a summary which I'll now try to. Caution: up until now I'm not involved with the upstream or packaging process of torbrowser-launcher, so please don't take my words for granted: - The current version included in Debian wheezy/jessie at the moment is 0.1.7-1, which is broken because of [01] and [03]. - Holger fixed this via building and uploading 0.1.9-1 to experimental [02]. However, this version is still affected by [03]: "The Tor Project changed how alphas and betas are versioned and now torbrowser-launcher always suggests downloading available alphas/betas. Please apply this patch from upstream to fix this issue in sid and ask the release team to include it in Debian jessie.", making it not suitable for wheezy/jessie. Problem was fixed upstream via [04], but is now back, see [05] and upstream [06]. - Regarding the two commits Holger wrote about: - de13483 (upstream ticket [07] and commit [08]): "Without this commit, if you run torbrowser-launcher and then torbrowser-launcher "https://github.com";, you'll get popup says TBB already open. This commit fix it, so torbrowser-launcher "https://github.com"; opens GitHub in a new tab of already launched TBB. The problem with -allow-remote in #157 is that if you have Firefox (not Iceweasel) installed, for some reason it opens tab in Firefox instead of TBB. It's a bug in upsteam. they should add some build flags." (These last two sentences are quite important, because it could put users into unwanted and probably dangerous situations.) - This problem was (partially) adressed via 3f1146e (upstream ticket [09] and commit [10]): "Since the last update (nominally 0.1.6-1 -> 0.1.7-1, but I'm building from git), torbrowser-launcher has stopped working if Firefox is already running. Instead, it just opens a new window from the currently running FF profile." - README.md [11] now reads: "Tor Browser Launcher allows you to set Tor Browser as your default web browser. Unfortunately, there's a gnarly issue that prevents this from working if Firefox is open in the background. If Tor Browser is set as your default browser and Firefox is open in the background, links will get opened in Firefox. Likewise, if Firefox is your default browser and Tor Browser is open in the background, links will get opened in Tor Browser. See more information here. You can only use Tor Browser as your default browser if you don't use Firefox at the same time. Other browser (such as Iceweasel, Chromium, or Chrome) will work fine. You must check "Allow opening links with Tor Browser" in the settings to enable it." - It seems quite messy, but after a closer look, one is able to find the way through... :) Regarding the further process I would propose, to check if vanilla v0.1.9 (with these two commits included) works as expected, and if that's the case, include these, because it's a nice feature. If these don't work, I would recommend to revert these, to favor security instead of convenience. Maybe it would be wise to inform the users while using apt-get dist-upgrade about the issue in combination with Firefox. - However, [03] has to be solved anyway, before this is usable again. Cheers, Georg [01] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775871 [02] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775871#34 [03] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775891 [04] https://github.com/micahflee/torbrowser-launcher/commit/143cbf4ee13fa4b227688b1e55f69fd65b2decfc.patch [05] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775891#15 [06] https://github.com/micahflee/torbrowser-launcher/issues/169 [07] https://github.com/micahflee/torbrowser-launcher/pull/155 [08] https://github.com/micahflee/torbrowser-launcher/commit/de134835a05b74e750da291e90fa86cfc43feae6 [09] https://github.com/micahflee/torbrowser-launcher/issues/157 [10] https://github.com/micahflee/torbrowser-launcher/commit/3f1146e1a084c4e8021da968104cbc2877ae01e6 [11] https://github.com/micahflee/torbrowser-launcher#using-tor-browser-as-yo
Bug#762362: flashplugin-nonfree: support request
On Sat, 3 Jan 2015 21:47:43 + Bart Martens wrote: > Marcel's problem is clearly a problem in Knoppix, not in Debian. A friend of mine just experienced this problem, she's using a vanilla Debian wheezy. The system in question was set up around October 2014. Since then, flashplugin-nonfree wasn't updated. Using flashplugin-nonfree --install leads to: > Flash Player version installed on this system : 11.2.202.411 > ERROR: wget failed to download > http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/get-upstream-version.pl.gz.pgp > More information might be available at: > http://wiki.debian.org/FlashPlayer I'm able to provide anything that helps to find the root cause. Any advice on this? signature.asc Description: Digital signature
Bug#768618:
On 15-04-09 19:25:55, Stefan Bauer wrote: > I'm not into the deadlines for jessie release but is there still a > chance to get pacemaker back into the upcoming jessie release? > > This is quite a show stopper to ship debian 8 without a working cluster > stack. Not an expert on this, but it would be possible for sure, to get it into jessie via the backports mechanism. Cheers, Georg signature.asc Description: Digital signature
Bug#784041: [Pkg-anonymity-tools] Bug#784041: exceptions.OSError: [Errno 2] No such file or directory
On Sun, 13 Sep 2015 10:35:44 +0200 Holger Levsen wrote: > On Sonntag, 13. September 2015, Cyril Brulebois wrote: > > > Followup-For: Bug #784041 > > > Confirmed. The bug is still present in Debian 8.1. > > It would be nice to have a fix in Jessie at some point. > > I agree, someone needs to hunt down the relevant commit though. I think it's 5f833d7 [1]. Regards, Georg [1] https://github.com/micahflee/torbrowser-launcher/commit/5f833d73290bd3623bf22caffaed599381d454d9 signature.asc Description: Digital signature
Bug#801866: flashplugin-nonfree: update-flashplugin-nonfree fails to install last falsh version (again)
Hi, # flashplugin-nonfree --install checks at first, which version should be installed, via downloading a file from https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/, as seen by: # update-flashplugin-nonfree --install --verbose options : --install --verbose -- temporary directory: /tmp/flashplugin-nonfree.1oEjqiJhsJ importing public key ... selected action = --install installed version = 11.2.202.521 upstream version = 11.2.202.540 wgetoptions= -nd -P . -v --progress=dot:default downloading http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.amd64.pgp.asc ... --2015-10-16 22:39:22-- http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.amd64.pgp.asc Resolving people.debian.org (people.debian.org)... 5.153.231.30, 2001:41c8:1000:21::21:30 Connecting to people.debian.org (people.debian.org)|5.153.231.30|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.amd64.pgp.asc [following] --2015-10-16 22:39:23-- https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.amd64.pgp.asc Connecting to people.debian.org (people.debian.org)|5.153.231.30|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1250 (1.2K) [text/plain] Saving to: ‘./fp10.sha512.amd64.pgp.asc’ 0K . 100% 8.21M=0s 2015-10-16 22:39:23 (8.21 MB/s) - ‘./fp10.sha512.amd64.pgp.asc’ saved [1250/1250] verifying PGP fp10.sha512.amd64.pgp.asc ... copying /var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz ... verifying checksum install_flash_player_11_linux.x86_64.tar.gz ... wgetoptions= -nd -P . -v --progress=dot:default -O /tmp/flashplugin-nonfree.1oEjqiJhsJ/install_flash_player_11_linux.x86_64.tar.gz downloading https://fpdownload.adobe.com/get/flashplayer/pdc/11.2.202.521/install_flash_player_11_linux.x86_64.tar.gz ... verifying checksum install_flash_player_11_linux.x86_64.tar.gz ... unpacking install_flash_player_11_linux.x86_64.tar.gz ... verifying checksum contents of install_flash_player_11_linux.x86_64.tar.gz ... moving libflashplayer.so to /usr/lib/flashplugin-nonfree ... setting permissions and ownership of /usr/lib/flashplugin-nonfree/libflashplayer.so ... Flash Player version: 11.2.202.521 moving install_flash_player_11_linux.x86_64.tar.gz to /var/cache/flashplugin-nonfree ... flash-mozilla.so - auto mode link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50 Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'. calling update-alternatives ... flash-mozilla.so - auto mode link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50 Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'. already exists: /usr/bin/flash-player-properties already exists: /usr/share/applications/flash-player-properties.desktop already exists: /usr/share/icons/hicolor/16x16/apps/flash-player-properties.png already exists: /usr/share/icons/hicolor/22x22/apps/flash-player-properties.png already exists: /usr/share/icons/hicolor/24x24/apps/flash-player-properties.png already exists: /usr/share/icons/hicolor/32x32/apps/flash-player-properties.png already exists: /usr/share/icons/hicolor/48x48/apps/flash-player-properties.png already exists: /usr/share/pixmaps/flash-player-properties.png end of action --install cleaning up temporary directory /tmp/flashplugin-nonfree.1oEjqiJhsJ ... end of update-flashplugin-nonfree @Bart: Could you provide a file for 11.2.202.540? Is there anything people could do to support you? Thanks, Georg signature.asc Description: Digital signature
Bug#731742: [Pkg-systemd-maintainers] Bug#731742: systemd will not start syslog.socket. This causes rsyslogd to not start
On Fri, 11 Dec 2015 16:26:12 +0100 Michael Biebl wrote: > On Thu, 6 Mar 2014 10:08:27 -0500 Eric Cooper wrote: > > On Thu, Mar 06, 2014 at 06:20:54AM +0100, Michael Biebl wrote: > > > Ah good, we are finally getting somewhere. Could you try to > > > compare the date of the /etc/systemd/system/syslog.service symlink > > > with you dpkg.log. If you find a match, please also check, which > > > version of i-s-h was installed then. > > > > Unfortunately, I already did a "systemctl disable rsyslog" and then > > "systemctl enable rsyslog" to recreate the symlink in > > multi-user.target.wants/. > > > > The good news is that fixed my problem, but I no longer have the > > metadata you're asking for. > > Given this, I'm going to close this old bug report. > > Feel free to reopen, if you run into this issue again. Sorry to do this, but I've just run into the same problem while doing a dist-upgrade from wheezy to jessie. After doing a reboot: # systemctl daemon-reload # systemctl restart syslog.service Failed to restart syslog.service: Unit syslog.service failed to load: No such file or directory. # systemctl disable rsyslog Synchronizing state for rsyslog.service with sysvinit using update-rc.d... Executing /usr/sbin/update-rc.d rsyslog defaults Executing /usr/sbin/update-rc.d rsyslog disable insserv: warning: current start runlevel(s) (empty) of script `rsyslog' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `rsyslog' overrides LSB defaults (0 1 6). # systemctl enable rsyslog.service Synchronizing state for rsyslog.service with sysvinit using update-rc.d... Executing /usr/sbin/update-rc.d rsyslog defaults insserv: warning: current start runlevel(s) (empty) of script `rsyslog' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `rsyslog' overrides LSB defaults (0 1 6). Executing /usr/sbin/update-rc.d rsyslog enable Created symlink from /etc/systemd/system/syslog.service to /lib/systemd/system/rsyslog.service. [Please note: This symlink was missing before.] # systemctl status rsyslog.service ● rsyslog.service - System Logging Service Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled) Active: inactive (dead) Docs: man:rsyslogd(8) http://www.rsyslog.com/doc/ # systemctl restart syslog.service # systemctl status syslog.socket ● syslog.socket - Syslog Socket Loaded: loaded (/lib/systemd/system/syslog.socket; static) Active: active (running) since Mon 2016-01-11 02:42:50 CET; 6s ago Docs: man:systemd.special(7) http://www.freedesktop.org/wiki/Software/systemd/syslog Listen: /run/systemd/journal/syslog (Datagram) I didn't had the time to debug this further yet, but I suspect, that during dist-upgrade, the symlink isn't created correctly / at all. Thats all for the moment, Georg signature.asc Description: Digital signature
Bug#804184: torbrowser-launcher: It's still not fixed!
On 15-12-29 14:42:13, 24t350c254t0hc wrote: > The bug is still not fixed (half a month later). Please do something > about these constant problems. All the people working on this package are aware of this. In the meantime, please use the version out of jessie-backports. signature.asc Description: Digital signature
Bug#814315: tracker.debian.org: Please switch URLs to https
Hi all, As this bug is still open, I'm just replying here instead of creating a new one: The confirmation mail which one gets after adding a mail address to an account contains a link to t.d.o which starts with http://. Maybe this could be fixed as well. Thanks for your work and all the best, Georg signature.asc Description: Digital signature
Bug#790241: 0.9.1 is out
Hi Andrii, Paolo, all, Just wanted to ask how the work is going? Do you need support? Thanks and all the best, Georg signature.asc Description: Digital signature
Bug#813658: Reverting gtk/virgl support in qemu for stretch
Hi Michael, all, Thanks for reverting - the additional needed dependencies to be installed on a headless server were just way too invasive. Could just push this to j-bp as well? Cheers and thanks for your work! Best, Georg signature.asc Description: Digital signature
Bug#839695: 67 X11/GTK related packages on a headless server
Hi Michael, all, As written by Rob already: Thanks for reverting the changes - the additional dependencies to install on a headless server were just insane. Cheers, Georg signature.asc Description: Digital signature
Bug#852707: schleuder: FTBFS : refresh_keys test suite fails
Hi, On 17-01-26 16:51:19, schleu...@nadir.org wrote: > From: Daniel Kahn Gillmor > > Finished in 1 minute 33.09 seconds (files took 1.06 seconds to load) > 157 examples, 2 failures > > Failed examples: > > rspec ./spec/schleuder/integration/cli_spec.rb:109 # cli #refresh_keys > reports errors from refreshing keys > rspec ./spec/schleuder/integration/cli_spec.rb:92 # cli #refresh_keys updates > one key from the keyserver FWIW, I can't reproduce this locally, neither within a chroot, nor LXC, nor KVM. I'm debugging with dkg searching for the cause. Cheers, Georg signature.asc Description: Digital signature
Bug#845636: ITP: schleuder -- a gpg-enabled mailinglist with remailing-capabilities
Package: wnpp Owner: Georg Faerber Severity: wishlist Package name: schleuder Version : 3.0.0 Upstream Author : schleuder dev team URL : https://schleuder.nadir.org/ License : GPL-3.0 Programming Lang: Ruby Description : Schleuder is a gpg-enabled mailinglist with remailing-capabilities. Schleuder is a group's email-gateway: subscribers can exchange encrypted emails among themselves, receive emails from non-subscribers and send emails to non-subscribers via the list. Schleuder takes care of all decryption and (re-)encryption, stripping of headers, and more. Schleuder can also send out its own public key upon request and process administrative commands by email. This package will be maintained within the Debian Ruby team; the git repository can be found at anonscm [1]. [1] https://anonscm.debian.org/cgit/pkg-ruby-extras/schleuder.git/ signature.asc Description: Digital signature
Bug#846257: ITP: schleuder-cli -- a command line tool to create and manage schleuder-lists
Package: wnpp Owner: Georg Faerber Severity: wishlist Package name: schleuder-cli Version : 0.0.1 Upstream Author : schleuder dev team URL : https://schleuder.nadir.org/ License : GPL-3.0 Programming Lang: Ruby Description : A command line tool to create and manage schleuder-lists. Schleuder-cli enables creating, configuring, and deleting lists, subscriptions, keys, etc. It uses the schleuder API, either unencrypted via localhost (default) or TLS-encrypted via any network. It does *not* authorize access. Only people who are supposed to have full access to all lists should be allowed to use it on/with your server. This package will be maintained within the Debian Ruby team; the git repository can be found at anonscm [1]. [1] https://anonscm.debian.org/git/pkg-ruby-extras/schleuder-cli.git/ signature.asc Description: Digital signature
Bug#846257: ITP: schleuder-cli -- a command line tool to create and manage schleuder-lists
Schleuder is not yet packaged in Debian but will very soon be, [1]. Even until then this package is useful to work with manually installed schleuder instances, which do exist. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845636 signature.asc Description: Digital signature
Bug#838360: needrestart: Wants to restart services, even if these were restarted already
(I'm subscribed to the bug, not need to mail me directly.) Hi Patrick, Thanks for your response: On 17-01-14 23:31:13, Thomas Liske wrote: > the repeating restart of ssh.service might be triggered by one or more > running user session. Do you have libpam-systemd installed and > enabled? Yes, it's installed. I guess it's enabled as well, because I didn't touched the defaults. 'sd-pam' is running which loads pam_systemd.po. Besides: I'm using SSSD, to check ssh keys and sudo roles against LDAP servers, but I don't think this has any influence. > There is an issue in needrestart assuming that libpam-systemd (if > systemd is used at all) is used to assign user sessions processes into > according cgroups. If libpam-systemd is not running all session > process are part of sshd's cgroup, so needrestart suggests to restart > ssh.service (which won't affect any session processes). A new config > option has been added[1] to address this option. > > [1] > https://github.com/liske/needrestart/commit/6a29143e1c6439e1f851b172e468aeef17b261b2 > > The repeating restart of ganeti.service might be triggered by some > ganeti child processes managing virtual machines. It might not be > possible to fix this problem without stopping the VMs. Just to clarify: Does this mean it's not possible to fix this in needrestart? Thanks, Georg signature.asc Description: Digital signature
Bug#838360: needrestart: Wants to restart services, even if these were restarted already
Hi Patrick,
On 16-09-20 12:12:50, ge...@riseup.net wrote:
> needrestart wants to restart {ganeti,ssh}.service, even if these were
> restarted already:
Did you had any chance to look into this?
Thanks,
Georg
signature.asc
Description: Digital signature
Bug#792101: ITP: gogs -- self hosted git service
Hi Michael, By changing the title of this bug to ITP and recording yourself as the owner, can one assume you're packaging gogs within Debian? If so, any ETA on this? Thanks for your work and all the best, Georg signature.asc Description: Digital signature
Bug#781607: [Pkg-freeipa-devel] Bug#781607: freeipa: please package new upstream version
(Sorry for missing In-Reply-To: and References:) Hi all, I'm wondering if FreeIPA is still maintained? Is there anything people could do to help with the work, etc.? Thanks and all the best, Georg signature.asc Description: Digital signature
Bug#838355: needrestart: Automatic restart mode doesn't work
Package: needrestart Version: 2.8-1~bpo8+1 Severity: normal Hi, needrestart tells me that it restarted a service, however, this doesn't seem to be true: # date && systemctl status ganeti.service | grep Active && needrestart -v -m a -r a && date && systemctl status ganeti.service | grep Active Tue Sep 20 09:19:10 UTC 2016 Active: active (running) since Tue 2016-09-20 09:07:09 UTC; 12min ago [main] eval /etc/needrestart/needrestart.conf [main] running in root-mode [Core] Using UI 'NeedRestart::UI::stdio'... [main] detected systemd [Core] #1209 is a NeedRestart::Interp::Java [Core] #1376 is a NeedRestart::Interp::Python [Core] #1575 is a NeedRestart::Interp::Ruby [main] #3023 uses deleted /usr/lib/x86_64-linux-gnu/libxenguest-4.4.so [main] #3023 is not a child [main] #3141 uses deleted /usr/lib/x86_64-linux-gnu/libxenguest-4.4.so [main] #3141 is not a child [main] # uses deleted /usr/lib/x86_64-linux-gnu/libxenguest-4.4.so [main] # is not a child [Core] #14391 is a NeedRestart::Interp::Python [Core] #14442 is a NeedRestart::Interp::Python [main] #3023 exe => /usr/bin/qemu-system-x86_64 [main] #3023 is ganeti.service [main] #3141 exe => /usr/bin/qemu-system-x86_64 [main] #3141 is ganeti.service [main] # exe => /usr/bin/qemu-system-x86_64 [main] # is ganeti.service [Kernel] Linux: kernel release 4.6.0-0.bpo.1-amd64, kernel version #1 SMP Debian 4.6.4-1~bpo8+1 (2016-08-11) Failed to load NeedRestart::Kernel::kFreeBSD: [Kernel/kFreeBSD] Not running on GNU/kFreeBSD! [Kernel/Linux] /boot/vmlinuz-4.6.0-0.bpo.1-amd64 => 4.6.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) #1 SMP Debian 4.6.4-1~bpo8+1 (2016-08-11) [4.6.0-0.bpo.1-amd64]* [Kernel/Linux] /boot/vmlinuz-4.5.0-0.bpo.2-amd64 => 4.5.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) #1 SMP Debian 4.5.4-1~bpo8+1 (2016-05-13) [4.5.0-0.bpo.2-amd64] [Kernel/Linux] Expected linux version: 4.6.0-0.bpo.1-amd64 Running kernel seems to be up-to-date. Restarting services... systemctl restart ganeti.service No containers need to be restarted. No user sessions are running outdated binaries. Tue Sep 20 09:19:10 UTC 2016 Active: active (running) since Tue 2016-09-20 09:07:09 UTC; 12min ago -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages needrestart depends on: ii dpkg 1.17.27 ii gettext-base 0.19.3-2 ii libintl-perl 1.23-1+deb8u1 ii libmodule-find-perl0.12-1 ii libmodule-scandeps-perl1.16-1 ii libproc-processtable-perl 0.51-1 ii libsort-naturally-perl 1.03-1 ii libterm-readkey-perl 2.32-1+b1 ii perl 5.20.2-3+deb8u6 ii xz-utils 5.1.1alpha+20120614-2+b3 needrestart recommends no packages. Versions of packages needrestart suggests: pn needrestart-session | libnotify-bin -- no debconf information If there is anything I can do / provide to debug this further, please let me know. Thanks in advance and for your work! All the best, Georg signature.asc Description: Digital signature
Bug#838360: needrestart: Wants to restart services, even if these were restarted already
Package: needrestart
Version: 2.8-1~bpo8+1
Severity: normal
Hi,
needrestart wants to restart {ganeti,ssh}.service, even if these were restarted
already:
# date && systemctl restart ganeti.service && systemctl restart ssh.service &&
systemctl status ganeti.service | grep Active: && systemctl status ssh.service
| grep Active: && needrestart -v -m a -r a
Tue Sep 20 10:11:23 UTC 2016
Active: active (running) since Tue 2016-09-20 10:11:24 UTC; 18ms ago
Active: active (running) since Tue 2016-09-20 10:11:24 UTC; 4ms ago
├─29037 grep Active:
[main] eval /etc/needrestart/needrestart.conf
[main] running in root-mode
[Core] Using UI 'NeedRestart::UI::stdio'...
[main] detected systemd
[main] #3023 uses deleted /lib/x86_64-linux-gnu/libnss_files-2.19.so
[main] #3023 is not a child
[main] #3141 uses deleted /lib/x86_64-linux-gnu/libnss_files-2.19.so
[main] #3141 is not a child
[main] # uses deleted /lib/x86_64-linux-gnu/libnss_files-2.19.so
[main] # is not a child
[main] #18682 uses deleted /lib/x86_64-linux-gnu/libnss_files-2.19.so
[main] #18682 is not a child
[main] #20336 uses deleted /lib/x86_64-linux-gnu/libnss_files-2.19.so
[main] #20336 is not a child
[Core] #27133 is a NeedRestart::Interp::Python
[Core] #27226 is a NeedRestart::Interp::Java
[Core] #27328 is a NeedRestart::Interp::Ruby
[Core] #28929 is a NeedRestart::Interp::Python
[Core] #28980 is a NeedRestart::Interp::Python
[Core] #29007 is a NeedRestart::Interp::Python
[main] #30258 uses deleted /lib/x86_64-linux-gnu/libnss_dns-2.19.so
[main] #30258 is not a child
[main] #30262 uses deleted /lib/x86_64-linux-gnu/libnss_dns-2.19.so
[main] #30262 is a child of #30258
[main] #30263 uses deleted /lib/x86_64-linux-gnu/libnss_files-2.19.so
[main] #30263 is a child of #30262
[main] #30269 uses deleted /lib/x86_64-linux-gnu/libcrypt-2.19.so
[main] #30269 is a child of #30263
[main] #3023 exe => /usr/bin/qemu-system-x86_64
[main] #3023 is ganeti.service
[main] #3141 exe => /usr/bin/qemu-system-x86_64
[main] #3141 is ganeti.service
[main] # exe => /usr/bin/qemu-system-x86_64
[main] # is ganeti.service
[main] #18682 exe => /usr/bin/qemu-system-x86_64
[main] #18682 is ganeti.service
[main] #20336 exe => /usr/bin/qemu-system-x86_64
[main] #20336 is ganeti.service
[main] #30258 exe => /usr/sbin/sshd
[main] #30258 is ssh.service
[main] #30262 exe => /usr/sbin/sshd
[main] #30262 is ssh.service
[main] #30263 exe => /bin/bash
[main] #30263 is ssh.service
[Kernel] Linux: kernel release 4.6.0-0.bpo.1-amd64, kernel version #1 SMP
Debian 4.6.4-1~bpo8+1 (2016-08-11)
Failed to load NeedRestart::Kernel::kFreeBSD: [Kernel/kFreeBSD] Not running on
GNU/kFreeBSD!
[Kernel/Linux] /boot/vmlinuz-4.6.0-0.bpo.1-amd64 => 4.6.0-0.bpo.1-amd64
(debian-ker...@lists.debian.org) #1 SMP Debian 4.6.4-1~bpo8+1 (2016-08-11)
[4.6.0-0.bpo.1-amd64]*
[Kernel/Linux] /boot/vmlinuz-4.5.0-0.bpo.2-amd64 => 4.5.0-0.bpo.2-amd64
(debian-ker...@lists.debian.org) #1 SMP Debian 4.5.4-1~bpo8+1 (2016-05-13)
[4.5.0-0.bpo.2-amd64]
[Kernel/Linux] Expected linux version: 4.6.0-0.bpo.1-amd64
Running kernel seems to be up-to-date.
Restarting services...
systemctl restart ganeti.service ssh.service
No containers need to be restarted.
No user sessions are running outdated binaries.
-- System Information:
Debian Release: 8.5
APT prefers stable
APT policy: (900, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages needrestart depends on:
ii dpkg 1.17.27
ii gettext-base 0.19.3-2
ii libintl-perl 1.23-1+deb8u1
ii libmodule-find-perl0.12-1
ii libmodule-scandeps-perl1.16-1
ii libproc-processtable-perl 0.51-1
ii libsort-naturally-perl 1.03-1
ii libterm-readkey-perl 2.32-1+b1
ii perl 5.20.2-3+deb8u6
ii xz-utils 5.1.1alpha+20120614-2+b3
needrestart recommends no packages.
Versions of packages needrestart suggests:
pn needrestart-session | libnotify-bin
-- no debconf information
If there is anything I can do / provide to debug this further, please
let me know.
Thanks in advance and for your work!
All the best,
Georg
signature.asc
Description: Digital signature
Bug#834594: [Pkg-privacy-maintainers] Bug#834594: irssi-plugin-otr: segfault when trying to initialize a OTR private conversation
On 16-08-20 13:12:02, intrigeri wrote: > simon.cruanes.2...@m4x.org: > > Package: irssi-plugin-otr > > Version: 1.0.0-1~bpo70+1+b2 > > Severity: important > > > I tried to open an OTR conversation, which results into irssi > > segfaulting when calling /otr init. > [...] > > Versions of packages irssi-plugin-otr depends on: > > ii irssi0.8.15-5 > > It might be that irssi-plugin-otr from wheezy-backports depends on > irssi from wheezy-backports to work properly, but I don't remember the > details. I've encountered this in the past as well. Simon: Try to use both irssi and irssi-plugin-otr out of w-bp. signature.asc Description: Digital signature
