Bug#852765: Info received (Bug#852765: Acknowledgement (playonlinux: Nothing happens when I press the run button))
Hi, I was having this problem today, it seems it has something to do with netcat. There are three packages, one dummy and two implementations: netcat-openbsd and netcat-traditional. I noticed that while using netcat-openbsd a lot of "nc" process were spawned after Playonlinux started. I just replaced netcat-openbsd with netcat-traditional and everything is working fine now. -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com
Bug#849122: Wifi stop working with wpasupplicant 2.6-2
Hi, I'm having this issue as well. For weeks now, every time I forget about it and do an aptitude upgrade I have to manually downgrade to 2.5-2+v2.4-3+b1 because my dongle USB stop working. I'm afraid that in some more upgrades the package won't install and I get stuck without wifi! :-) Device: Bus 001 Device 004: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter dmesg got filled with: [ 1182.365621] IPv6: ADDRCONF(NETDEV_UP): wlxe8de271f313a: link is not ready [ 1183.650554] R8188EU: ERROR indicate disassoc /var/log/syslog Jan 14 10:56:18 debian wpa_supplicant[3966]: Successfully initialized wpa_supplicant Jan 14 10:56:18 debian NetworkManager[3929]: [1484405778.9175] supplicant: wpa_supplicant running Jan 14 10:56:18 debian NetworkManager[3929]: [1484405778.9182] device (wlxe8de271f313a): supplicant interface state: init -> starting Jan 14 10:56:18 debian wpa_supplicant[3966]: nl80211: Driver does not support authentication/association or connect commands Jan 14 10:56:18 debian wpa_supplicant[3966]: nl80211: deinit ifname=wlxe8de271f313a disabled_11b_rates=0 Jan 14 10:56:18 debian wpa_supplicant[3966]: ioctl[SIOCSIWAP]: Operation not permitted Jan 14 10:56:18 debian wpa_supplicant[3966]: ioctl[SIOCSIWENCODEEXT]: Invalid argument Jan 14 10:56:18 debian wpa_supplicant[3966]: ioctl[SIOCSIWENCODEEXT]: Invalid argument Jan 14 10:56:18 debian NetworkManager[3929]: [1484405778.9751] sup-iface[0x55d776f7c0a0,wlxe8de271f313a]: supports 1 scan SSIDs Jan 14 10:56:18 debian kernel: [ 1232.450878] IPv6: ADDRCONF(NETDEV_UP): wlxe8de271f313a: link is not ready Jan 14 10:56:18 debian NetworkManager[3929]: [1484405778.9761] device (wlxe8de271f313a): supplicant interface state: starting -> ready Jan 14 10:56:18 debian NetworkManager[3929]: [1484405778.9762] device (wlxe8de271f313a): state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42] Jan 14 10:56:18 debian kernel: [ 1232.457289] R8188EU: ERROR indicate disassoc Jan 14 10:56:19 debian NetworkManager[3929]: [1484405779.0836] device (wlxe8de271f313a): set-hw-addr: new MAC address XX:XX:XX:XX:XX:XX not successfully set (scanning) -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com
Bug#835342: Fwd: Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets
-- Forwarded message -- From: marcelomen...@gmail.com Date: 2016-09-13 9:25 GMT-04:00 Subject: Re: Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets To: Andreas Metzler 2016-09-03 1:51 GMT-04:00 Andreas Metzler : > Control: tags -1 moreinfo > > On 2016-08-28 Andreas Metzler wrote: >> On 2016-08-26 "marcelomven...@gmail.com" wrote: > [...] >> > First, let me say I'm behind a proxy server. >> [ no. Looks like no access without proxy, which gnutls-cli does not >> seem to support ] > >> Could use git bisect to find the offending commit? > > Any specific difficulties I could help you with there? Never used git bisect before, so I don't know how much time until I figure out how it works and give you proper feedback. Today 13/09 I noticed a new version of gnutls-bin and libgnutls30 (3.5.4-2) Tried to do a "vagrant box update" to update my boxes and got the same little error, now from vagrant: - There was an error while downloading the metadata for this box. The error message is shown below: gnutls_handshake() failed: Public key signature verification has failed. - Then, I downgrade manually to the working version: --- sudo dpkg -i libgnutls30_3.5.2-3_amd64.deb gnutls-bin_3.5.2-3_amd64.deb dpkg: warning: downgrading libgnutls30:amd64 from 3.5.4-2 to 3.5.2-3 (Reading database ... 365601 files and directories currently installed.) Preparing to unpack libgnutls30_3.5.2-3_amd64.deb ... Unpacking libgnutls30:amd64 (3.5.2-3) over (3.5.4-2) ... dpkg: warning: downgrading gnutls-bin from 3.5.4-2 to 3.5.2-3 Preparing to unpack gnutls-bin_3.5.2-3_amd64.deb ... Unpacking gnutls-bin (3.5.2-3) over (3.5.4-2) ... Setting up libgnutls30:amd64 (3.5.2-3) ... Setting up gnutls-bin (3.5.2-3) ... Processing triggers for libc-bin (2.24-2) ... Processing triggers for man-db (2.7.5-1) ... And everything works as expected with vagrant, git, curl, etc. -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com
Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets
2016-09-13 13:50 GMT-04:00 Andreas Metzler :
> On 2016-09-13 "marcelomen...@gmail.com" wrote:
>> 2016-09-03 1:51 GMT-04:00 Andreas Metzler :
> {git bisect]
>> > Any specific difficulties I could help you with there?
>
>> Never used git bisect before, so I don't know how much time until I
>> figure out how it works and give you proper feedback.
>
> In essence you tell git that revision #50 worked and #100 didn't. Then
> git checks out #75 for you to test. Depending on whether #75 was already
> broken it then moves on to let you check either #62 or #87, continously
> narrowing down the suspect subset and after ten tries or so you know
> which commit broke.
>
>> Today 13/09 I noticed a new version of gnutls-bin and libgnutls30 (3.5.4-2)
>
>> Tried to do a "vagrant box update" to update my boxes and got the same
>> little error, now from vagrant:
> [...]
>> sudo dpkg -i libgnutls30_3.5.2-3_amd64.deb gnutls-bin_3.5.2-3_amd64.deb
> [...]
>> And everything works as expected with vagrant, git, curl, etc.
>
> In short you need this:
>
...
> cu Andreas
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
Hey there,
After struggling a bit with the process of "bisecting", I think I got
something :).
You can view git bisect log here http://pastebin.com/sj1ZbbqA
c801a15bca9ea8f3f7abd4be48bebd36c54eeba2 is the first bad commit
commit c801a15bca9ea8f3f7abd4be48bebd36c54eeba2
Author: Nikos Mavrogiannopoulos
Date: Mon Aug 1 10:48:46 2016 +0200
nettle: use rsa_*_key_prepare
Previously we calculated the size of the key directly, but
by using the rsa_*_key_prepare we benefit from any checks that
may be introduced in the future. Specifically any checks for invalid
public keys (e.g., keys that may crash the underlying gmp functions).
:04 04 29a2377df28240d7688082ac12318baacdd1bb7c
23aa890386085677a878268578e9a2c27d396c80 Mlib
It seems the commit "b0d560b" reverts "c801a15", and commit 186dc9c
breaks it again.
I hope that helps.
--
"Free Software is not the only way, but it's a correct way."
Marcelo Mendes
http://underlabs.org
mmendes @ IRC [OFTC-Freenode]
Gtalk: marcelomendes at gmail dot com
Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets
2016-09-17 12:15 GMT-04:00 Andreas Metzler : > On 2016-09-16 "marcelomen...@gmail.com" wrote: > [...] >> After struggling a bit with the process of "bisecting", I think I got >> something :). >> You can view git bisect log here http://pastebin.com/sj1ZbbqA > [...] > > Thank you. Could you please alo provide a session capture? > > How to: > | I'd run wireshark -i eth0 (replace eth0 with the ethernet interface > | name), and click start capture. > | Then on another terminal run the command that makes the TLS connection > | fail. > | Then click capture -> Stop, In "apply display filter", type ssl, then > | File -> Export specified packets and send the saved pcap file. This link has two files: pcap_gnutls.pcapng (Fail, libgnutls30:amd64 3.5.4-2) pcap_gnutls_v352.pcapng (Working version, libgnutls30:amd64 3.5.2-3) https://drive.google.com/drive/folders/0B3_AQUiHn1qMcEVjdVpNeHBJUHc Cheers. -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com
Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets
2016-09-20 12:48 GMT-04:00 Andreas Metzler : > On 2016-09-19 "marcelomen...@gmail.com" wrote: >> 2016-09-17 12:15 GMT-04:00 Andreas Metzler : > [...] >> > | Then click capture -> Stop, In "apply display filter", type ssl, then >> > | File -> Export specified packets and send the saved pcap file. > >> This link has two files: > >> pcap_gnutls.pcapng (Fail, libgnutls30:amd64 3.5.4-2) >> pcap_gnutls_v352.pcapng (Working version, libgnutls30:amd64 3.5.2-3) > >> https://drive.google.com/drive/folders/0B3_AQUiHn1qMcEVjdVpNeHBJUHc > > Hello Marcelo, > > this seems to be hard to debug/reproduce, Nikos (upstream) writes: Yeah, I know, I'm following his replies. I saw that he is making his tests using gnutls-cli, but as I stated before, gnutls-cli doesn't work at all behind the proxy here. Regardless of the version, either 3.5.2-x or 3.5.3+ The commands that I'm using to test are curl and git (and vagrant). And these commands only work if I'm using libgnutls30:amd64 3.5.2-3. > > === > I do not see anything wrong in the capture. I even created a small > program to replay the connection locally (I have a debian installation > on x86_64 with the same packages available), and the connection > continued past the failure point on that system. > > I'm searching in the dark here, but the following info could help: > 1. run gnutls-cli www.server-that-fails -d 9 Same as shown in Message #15, except with the debug > 2. run valgrind gnutls-cli www.server-that-fails > 3. compile the attached program as "gcc -O2 -g sim.c -lgmp -lhogweed && > ./a.out", and also run valgrind ./a.out I could try this, but where is the source code? > [...] > One 4th item suggested by Niels Moeller: > 4. run ldd /usr/bin/gnutls-cli # (that way we can see whether the > client is linked to the expected nettle library) > === ldd /usr/lib/x86_64-linux-gnu/libgnutls.so.30.10.0 linux-vdso.so.1 (0x7ffc34f7d000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f5cdb8a7000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7f5cdb642000) libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x7f5cdb40e000) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x7f5cdb1fb000) libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x7f5cdafc4000) libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x7f5cdad8d000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x7f5cdab0a000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5cda76c000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x7f5cda563000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5cda35f000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f5cda142000) /lib64/ld-linux-x86-64.so.2 (0x561651905000) ldd /usr/bin/gnutls-cli linux-vdso.so.1 (0x7ffd0c36b000) libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x7f57473f3000) libopts.so.25 => /usr/lib/x86_64-linux-gnu/libopts.so.25 (0x7f57471d2000) libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x7f5746f9e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5746c0) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f57469e5000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7f574677e000) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x7f574656b000) libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x7f5746334000) libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x7f57460ff000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x7f5745e7c000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5745b78000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5745972000) /lib64/ld-linux-x86-64.so.2 (0x5581363e8000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x7f5745769000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f574554c000) dpkg -l | grep nettle ii libnettle4:amd64 2.7.1-5+deb8u1 amd64low level cryptographic library (symmetric and one-way cryptos) ii libnettle6:amd64 3.2-1 amd64low level cryptographic library (symmetric and one-way cryptos) ii nettle-dev 3.2-1 amd64low level cryptographic library (development files) -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com
Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets
Package: libgnutls30 Version: 3.5.3-2 Severity: important Tags: upstream Dear Maintainer, Trying to git clone a github repo using libgnutls30 3.5.3-2 trhow the following error: fatal: unable to access 'https://github.com/xxx/yyy/': gnutls_handshake() failed: Public key signature verification has failed. Same happens for curl: curl https://duckduckgo.com curl: (35) gnutls_handshake() failed: Public key signature verification has failed. Downgrading to libgnutls30 3.5.2-2 solves the issue PS.: For some reason I can't find this version on the debian repository anymore, but I did on another machine previously and it worked as stated above: dpkg -l | grep libgnutls ii libgnutls30:amd64 3.5.2-2 amd64 GNU TLS library - main runtime library PS2.: A (maybe) related bug can be found here https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=834724 -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/8 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 libgnutls30 depends on: ii libc62.23-5 ii libgmp10 2:6.1.1+dfsg-1 ii libhogweed4 3.2-1 ii libidn11 1.33-1 ii libnettle6 3.2-1 ii libp11-kit0 0.23.2-5 ii libtasn1-6 4.9-4 ii zlib1g 1:1.2.8.dfsg-2+b1 libgnutls30 recommends no packages. Versions of packages libgnutls30 suggests: pn gnutls-bin -- no debconf information -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com
Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets
2016-08-25 13:25 GMT-04:00 Andreas Metzler : > On 2016-08-24 "marcelomen...@gmail.com" wrote: >> Package: libgnutls30 >> Version: 3.5.3-2 >> Severity: important >> Tags: upstream > >> Dear Maintainer, > >> Trying to git clone a github repo using libgnutls30 3.5.3-2 throw the >> following error: > >> fatal: unable to access 'https://github.com/xxx/yyy/': gnutls_handshake() >> failed: Public key signature verification has failed. > >> Same happens for curl: > >> curl https://duckduckgo.com >> curl: (35) gnutls_handshake() failed: Public key signature verification has >> failed. > > Hello, > Are you able to reproduce either of these errors with gnutls-cli? First, let me say I'm behind a proxy server. Both versions of gnutls-bin (3.5.3-3 and the old 3.5.2-3) have the same behavior: gnutls-cli -V --port 443 duckduckgo.com Processed 173 CA certificate(s). Resolving 'duckduckgo.com:443'... Connecting to '107.21.1.61:443'... Connecting to '184.72.106.52:443'... Connecting to '184.72.115.86:443'... and stay there for some quit some time until I ctrl+c But, with the old version of libgnutls30 (3.5.2-3) got from here: http://snapshot.debian.org/package/gnutls28/3.5.2-3/#libgnutls30_3.5.2-3 commands like git clone/pull works and curl -I https://... works too. I tried from my vps and this issue doesn't happen with either version, thats a weird thing :) Out of curiosity, the commands worked from inside a ubuntu-xenial vagrant box (virtualbox vms) with older versions of libgnutls30 (3.4.x) >> Downgrading to libgnutls30 3.5.2-2 solves the issue > >> PS.: For some reason I can't find this version on the debian repository >> anymore, but I did on another machine previously and it worked as stated >> above: > > The Debian mirrors only carry packages which are part of release > (stable, unstable, testing, etc.). 3.5.2-2 is not. Old versions can be > found on http://snapshot.debian.org/ > > cu Andreas > -- > `What a good friend you are to him, Dr. Maturin. His other friends are > so grateful to you.' > `I sew his ears on from time to time, sure' -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com
Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets
Ok, this is very odd! Long time ago I did some testing with some deb-multimedia packages. After the tests I made a clean up and removed all the packages, and the repo from my source lists, until the libgnutls30 upgrade everything was fine. Now when Mariusz pointed out his experience with similar issue I went to check the package and: As you can see, this package (librtmp1) remained of the deb-multimedia packages and has a old libgnutls dependency, my clean up wasn't so clean after all. :( - Package: librtmp1 Version: 1:2.4+20130918.git79459a2-dmo6 State: installed Automatically installed: yes Multi-Arch: same Priority: extra Section: libs Maintainer: Christian Marillat Architecture: amd64 Uncompressed Size: 160 k Depends: libc6 (>= 2.14), libgmp10, libgnutls-deb0-28 (>= 3.2.10-0), libhogweed2, libnettle4, zlib1g (>= 1:1.1.4) PreDepends: multiarch-support Breaks: librtmp1:i386 (!= 1:2.4+20130918.git79459a2-dmo6) Replaces: librtmp1:i386 (< 1:2.4+20130918.git79459a2-dmo6) Description: Toolkit for RTMP streams (shared library). A small dumper for media content streamed over the RTMP protocol (like BBC's iPlayer high quality streams). Supplying an RTMP URL will result in a dumped flv file, which can be played/transcoded with standard tools. This package contains the shared libraries, header files needed by programs that want to use librtmp. Homepage: http://rtmpdump.mplayerhq.hu/ Tags: role::shared-lib - When I downgraded(!) to from multimedia package to debian package, as suggested by Mariusz: Unpacking librtmp1:amd64 (2.4+20151223.gitfa8646d.1-1) over (1:2.4+20130918.git79459a2-dmo6) ... Setting up librtmp1:amd64 (2.4+20151223.gitfa8646d.1-1) ... Things are now working again. I'm still curious to know why the package didn't upgrade since the version of debian is from 20151223 That was a bit of a mess (my fault), but I'm glad things get to work again. Thanks Mariusz for pointing out, and Thanks to Andreas and Nikos for the pentience. :) -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com
Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets
Both libcurl3-gnutls and libcurl3 depends on librtmp1 and git depends on libcurl3-gnutls Thats the only relation I could find 2016-09-23 9:43 GMT-04:00 Nikos Mavrogiannopoulos : > Thanks for the update, your case was really challenging my computing > knowledge :) > However, out of curiosity how does librtmp comes into play here? It > doesn't seem to be a dependency (direct at least) or either curl or > git. > > On Fri, Sep 23, 2016 at 3:01 PM, marcelomen...@gmail.com > wrote: >> Ok, this is very odd! >> Long time ago I did some testing with some deb-multimedia packages. >> After the tests I made a clean up and removed all the packages, and >> the repo from my source lists, until the libgnutls30 upgrade >> everything was fine. Now when Mariusz pointed out his experience with >> similar issue I went to check the package and: >> >> As you can see, this package (librtmp1) remained of the deb-multimedia >> packages and has a old libgnutls dependency, my clean up wasn't so >> clean after all. :( >> >> - >> Package: librtmp1 >> Version: 1:2.4+20130918.git79459a2-dmo6 >> State: installed >> Automatically installed: yes >> Multi-Arch: same >> Priority: extra >> Section: libs >> Maintainer: Christian Marillat >> Architecture: amd64 >> Uncompressed Size: 160 k >> Depends: libc6 (>= 2.14), libgmp10, libgnutls-deb0-28 (>= 3.2.10-0), >> libhogweed2, libnettle4, zlib1g (>= 1:1.1.4) >> PreDepends: multiarch-support >> Breaks: librtmp1:i386 (!= 1:2.4+20130918.git79459a2-dmo6) >> Replaces: librtmp1:i386 (< 1:2.4+20130918.git79459a2-dmo6) >> Description: Toolkit for RTMP streams (shared library). >> A small dumper for media content streamed over the RTMP protocol >> (like BBC's iPlayer high quality streams). Supplying an RTMP URL will >> result in a dumped flv file, which can >> be played/transcoded with standard tools. >> >> This package contains the shared libraries, header files needed by >> programs that want to use librtmp. >> Homepage: http://rtmpdump.mplayerhq.hu/ >> Tags: role::shared-lib >> - >> >> >> When I downgraded(!) to from multimedia package to debian package, as >> suggested by Mariusz: >> >> Unpacking librtmp1:amd64 (2.4+20151223.gitfa8646d.1-1) over >> (1:2.4+20130918.git79459a2-dmo6) ... >> Setting up librtmp1:amd64 (2.4+20151223.gitfa8646d.1-1) ... >> >> Things are now working again. >> >> I'm still curious to know why the package didn't upgrade since the >> version of debian is from 20151223 >> >> >> That was a bit of a mess (my fault), but I'm glad things get to work again. >> >> Thanks Mariusz for pointing out, and Thanks to Andreas and Nikos for >> the pentience. :) >> >> -- >> "Free Software is not the only way, but it's a correct way." >> Marcelo Mendes >> http://underlabs.org >> mmendes @ IRC [OFTC-Freenode] >> Gtalk: marcelomendes at gmail dot com -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com
