Re: transcode replacement to rip audio from video dvd

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, May 30, 2017 at 12:24:53AM +0100, Brian wrote:
> On Mon 29 May 2017 at 21:38:53 +0200, to...@tuxteam.de wrote:

[...]

> > You can try (caution: untested!) something like
> > 
> >   ffmpeg -i  -vn -acodec copy 
> > 
> > This would leave the audio format unchanged. By playing with the
> > "-acodec copy" you can change the output audio format.
> > 
> > I'm sure other programs, like mplayer are also capable to do the
> > trick.
> 
> I successfully used vobcopy and then your command with output.ac3 as
> .

Thanks, now I'm smarter too :)

cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlktHsYACgkQBcgs9XrR2kZnQwCeOnks1rddC1ASWLrjfoNOHleQ
/XMAn1KprfOOix3tWKkpv2e8sX5GfA8E
=eAXd
-END PGP SIGNATURE-

Re: is AMD B350 chipset supported? (AMD Ryzen CPU)

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, May 29, 2017 at 08:21:20PM -0700, Sergei G wrote:
> I am considering buying
> 
> GIGABYTE GA-AB350M-D3H (rev. 1.0) AM4 AMD B350 SATA 6Gb/s USB 3.1HDMI Micro
> ATX Motherboards - AMD
> 
> 
> but I am concerned about Linux Debian 8.8 support of its hardware.
> Onboard features are a concern and even CPU itself.
> 
> Here are a few listed:
> 
> Audio: Realtek ALC887
> LAN: Realtek GbE LAN chip
> 
> I've read conflicting reviews on Linux and ARM B350 chipset.  It appears to
> be too new to go with and so I am considering Intel i5, even if I get a
> lower performance at the same cost.

Not the motherboard you mention, and no idea whether the chipsets are
comparable, but, fwiw, the German c't magazine[1] has put together and
tested a Ryzen based system, which seems to run Linux OK:

[1] 
https://www.heise.de/ct/ausgabe/2017-12-Bauvorschlag-fuer-einen-leistungsfaehigen-Desktop-PC-mit-AMD-Ryzen-7-1700-3718504.html

- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlktIhEACgkQBcgs9XrR2kbHDwCdGWvsw/8WySaTRPyIM9qMK13I
GT0An0zW6YT+QJ59JImX/emLsY2FtOrM
=I5lu
-END PGP SIGNATURE-

Re: Intresting dd fsck grub uuid fstab action

[Fungi4All]

From: deb...@lionunicorn.co.uk

I'm not going to wade through all these imaginings again; sorry.
Just some points.

Your use of the term imaginings emphasizes clearly how you do not
reas but "assume" that this all mighty perfect system can't be at fault
and it all lies in my mistakes, without ever referring on what should
have been done and didn't.

>> How would I know which fstab you edited? […]
>> IOW how did you decide which disk the kernel had decided to call sda?
>> How did you tell which was the original and which was the identical copy?
>
> Because the source was on hd0 (physical unit) to target hd1,
> I suspect grub does not worry much about sda/sdb label
> but according to bios knows the master and slave.

What does grub have to do with it. By the time you edited fstab,
the linux kernel was running, sda and sdb are indeterminate, and
choices have been made between duplicate UUIDs.

You are focusing on grub out of context. You ask one clarification,
you get it and you keep IMAGINING things because you did not read.
And you waste my time repeating everything again and again.
If you read previous posts I have stated clearly three times at least,
that I did not edit fstab from "the live" kernel of the systems mentioned
but by "another" system. You want me to be specific? I used a debian
system installed on a usb-stick. to edit the fstab on both debian
installations. Does it matter? Even if dos5.0 would give access to
an ext4 disk I could edit fstab and grub.cfg from there. Why bother
with a live kernel on a system that wouldn't boot.

Whatever system started and booted the system its live identification
of partitions and UUIDs were very accurate at any given time. Those
transferred to fstab and a reboot was an attempt for them to boot correctly.

Assuming you want to avoid the issues involved with cloning an
active root filesystem, close down your A system and boot up a
system on a stick.
Copy the partitions from A to B.
Check for errors. /var/log/kern/log is worth inspecting.
Use tune2fs -U random /dev/sdbN to assign new UUIDs to the
copied filesystems.
If you've copied a swap partition, mkswap /dev/sdbN will create
a new UUID by default.
You can now reboot into your A system as per usual.
Assuming you want to make the copied partitions available when
the A system is running, edit A's fstab to add mountpoints for
your new partitions, then mount -a.

I have described the process in extemely boring detail, you both
fail to read and try to force situations that never existed.
I DID NOT TRY TO COPY A LIVE SYSTEM, it was DEAD! This was
very clear to anyone who bothers and can read basic english.
I did not expect a system that is functional and running well, it is then
shutdown then a "different" system is used to copy it and then
edit the fstab of the COPY to match the uuids on the system.

> Also please explain the logic of the developer of dd in "copying and 
> transfering"
> a UUID that is supposedly meant to be unique. Why not always asign a new
> one every time? Because it is meant for backup work and not for copying?

dd doesn't know what a filesystem is, or what a UUID is. It just
copies what you tell it to (or converts it in specific ways).

Does it duplicate uuids or doesn't it? Does it do it consistently or does
it sometimes it leaves the uuid as it was and sometimes it duplicated one?
WHY Because not all changed, or were duplicated, it was a mismatch.
I understand swap because it wasn't copied, but the other 4 3 had new ids
and one had a duplicate. I say I understand that dd made all duplicates and
fsck only assigned new uuids to partitions that were realigned, covering
the 1MB gap that was left by gparted.

The steps you described as doing in the order given were effectively
like trying to make a poached egg out of an egg you'd already scrambled.

You are trying to draw pictures and I have no clue what your intentions are.
Are you offended because you wrote the code for dd and grub? I have been
doing this long enough to recognize an irregular behavior. If you are trying
to figure out what the problem is don't refer to me anymore because I
said over and over again I fixed the unreasonably complex mess that was
created especially by having to edit grub.cfg as automatically it kept 
configuring
itsled WRONG Both installations were perfect, 10 unique UUIDs and
responding fstabs. Grub would update and mix two systems. All I changed was
the second like of the entry to the correct ID and both systems worked
flawlessly (eventually).

David.

Over and out!

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Richard Owlett]

On 05/29/2017 10:55 PM, Michael Milliman wrote:



On 05/29/2017 01:19 PM, Brian wrote:

On Sat 27 May 2017 at 19:13:25 +0100, Brian wrote:


On Sat 27 May 2017 at 09:52:45 -0500, David Wright wrote:


On Sat 27 May 2017 at 12:32:06 (+0100), Brian wrote:

On Fri 26 May 2017 at 17:57:40 -0500, Michael Milliman wrote:


And actually, the --no-xinerama flag is not needed, at least on my
system.  I use feh --bg-fill ... and it works just fine.  Of course,
that is a very limited (and safe) usage of feh.  I don't think it wise
to use it for anything much more (IMHO).


Surprising after all these years that feh is now revealed as an unsafe
image viewer.


Wow, I didn't realise I'd participated in a revelation.


It happens all the time on -user. :)


Fancy another one?

There are legitimate concerns about aspects of feh's behaviour, not
sufficient as yet to prevent my recommending it, but the topic prompted
a bit of exploring. So I took a look at Debian's sxiv in Stretch.

sxiv is somewhat similar to feh. It has an installed size a third of
feh's (an advantage?) and is fast at rendering and responsive. Nothing
scientific, but thumbnails (without caching) seem to render quicker than
feh does it. One can easily switch between thumbnail view and picture
display. The upstream developer is also active, which is never a bad
thing.

Downsides? Definitely. But this post is an advocacy one for those Debian
users who just want to view their pictures without installing tons of
GNOME dependencies or like to be able to configure things for their
particular use case.

I am now torn between feh and sxiv. That is the problem with threads
like this, which promote delving into available packages and having to
make a choice. :)


For me, though, the important aspect is will sxiv change the desktop
background like feh will?


I found no mention of anything like that in its man page.
YMMV


I have been following this thread closely
since opening it and have learned quit a bit.  I agree an active
upstream is always a good thing.  And I admit, I am concerned about some
of what has been reported of feh's behavior, though most of that
behavior is inconsequential in my use case.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Brian]

On Tue 30 May 2017 at 04:15:10 -0500, Richard Owlett wrote:

> On 05/29/2017 10:55 PM, Michael Milliman wrote:
> >
> >On 05/29/2017 01:19 PM, Brian wrote:
> >>
> >>There are legitimate concerns about aspects of feh's behaviour, not
> >>sufficient as yet to prevent my recommending it, but the topic prompted
> >>a bit of exploring. So I took a look at Debian's sxiv in Stretch.
> >>
> >>sxiv is somewhat similar to feh. It has an installed size a third of
> >>feh's (an advantage?) and is fast at rendering and responsive. Nothing
> >>scientific, but thumbnails (without caching) seem to render quicker than
> >>feh does it. One can easily switch between thumbnail view and picture
> >>display. The upstream developer is also active, which is never a bad
> >>thing.
> >>
> >>Downsides? Definitely. But this post is an advocacy one for those Debian
> >>users who just want to view their pictures without installing tons of
> >>GNOME dependencies or like to be able to configure things for their
> >>particular use case.
> >>
> >>I am now torn between feh and sxiv. That is the problem with threads
> >>like this, which promote delving into available packages and having to
> >>make a choice. :)
> >>
> >For me, though, the important aspect is will sxiv change the desktop
> >background like feh will?
> 
> I found no mention of anything like that in its man page.
> YMMV

 Nope. There are lots of wallpaper setters available. You can
 also integrate the tool of your choice via the key handler.

  https://github.com/muennich/sxiv/issues/192

-- 
Brian.

Re: buying ssl certificate

[Joe Collins]

Hello sir,


It’s my pleasure that connect with you, I am working as network admin in
reputed web development companies and regularly purchased ssl certificate
for our clients. In the most case, I preferred free ssl certificate from
https://letsencrypt.org/ for basic requirements, otherwise I favored
https://www.ssl2buy.com for less priced and best after selling support.


I hope this will help you!


Thanks.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Greg Wooledge]

On Mon, May 29, 2017 at 10:55:28PM -0500, Michael Milliman wrote:
> For me, though, the important aspect is will sxiv change the desktop
> background like feh will?

If all you want is to set the root window (desktop/background) image,
"xsetbg" from the xloadimage package will do nicely.

If you want additional features like thumbnail galleries, then I don't
have any recommendations, as I don't use such programs.

Re: How to set ISO date/time with en_US.utf8 as system default?

[Greg Wooledge]

On Sat, May 27, 2017 at 08:33:16AM -0400, gwmf...@openmailbox.org wrote:
> I want to make everything proper and swapping to all en_DK variables 
> fixes some things but not others. The only proper solution is to:
> 
> 1) be able to change individual variables within Gnome (which I don't 
> think is possible in current gnome)
> 2) create my own locale, which I do not know how to do.

3) Somehow get the GNOME developers to fix their crap.
4) Stop using GNOME.

As long as we're being comprehensive. ;-)

Perhaps a GNOME-specific mailing list might have more options for you.
Maybe there's some way to tell GNOME not to touch the locale settings
*at all*, and simply let them pass through from the underlying operating
system.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, May 30, 2017 at 08:28:52AM -0400, Greg Wooledge wrote:
> On Mon, May 29, 2017 at 10:55:28PM -0500, Michael Milliman wrote:
> > For me, though, the important aspect is will sxiv change the desktop
> > background like feh will?
> 
> If all you want is to set the root window (desktop/background) image,
> "xsetbg" from the xloadimage package will do nicely.

This might not interact well with "Desktop environments" (i.e. Gnome,
KDE and derivatives, and perhaps to a lesser extent XFCE). As far as
I remember, those tend to cover the X root with an own window and play
other funny games, so backgrounds (and screen savers) become less
obvious as under the simpler arrangement "X + window manager".

But things may have improved since then.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlktbaMACgkQBcgs9XrR2kaiOwCggiSu5zBnuUQqf4IcmuulBIy/
fD0An39gmpgTSj1elarHPWS9pFZb3O+g
=5JrP
-END PGP SIGNATURE-

dpkg error

[tony]

I'm trying to upgrade my packages, but am getting:

root@picam1:~# apt-get upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  uv4l-raspidisp-extras
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 422 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 104725 files and directories currently installed.)
Removing uv4l-raspidisp-extras (1.5) ...
insserv: warning: script 'uv4l_uvc' missing LSB tags and overrides
insserv: There is a loop between service watchdog and uv4l_uvc if stopped
insserv:  loop involving service uv4l_uvc at depth 2
insserv:  loop involving service watchdog at depth 1
insserv: Stopping uv4l_uvc depends on watchdog and therefore on system
facility `$all' which can not be true!
insserv: exiting now without changing boot order!
update-rc.d: error: insserv rejected the script header
dpkg: error processing package uv4l-raspidisp-extras (--remove):
 subprocess installed post-removal script returned error exit status 1
Errors were encountered while processing:
 uv4l-raspidisp-extras
E: Sub-process /usr/bin/dpkg returned an error code (1)


How do I get out of this pickle?

bluetooth hci0: firmware: failed to load brcm/BCM20702A1-0a5c-21e6.hcd

[inkbottle]

Dear all, (debian/sid)

Because I had this error in journalctl:
Mar 09 15:17:09 pluto kernel: Bluetooth: hci0: BCM20702A
Mar 09 15:17:09 pluto kernel: Bluetooth: hci0: BCM20702A1 (001.002.014) build 

Mar 09 15:17:09 pluto kernel: bluetooth hci0: firmware: failed to load brcm/
BCM20702A1-0a5c-21e6.hcd (-2)
Mar 09 15:17:09 pluto kernel: bluetooth hci0: Direct firmware load for brcm/
BCM20702A1-0a5c-21e6.hcd failed with error -2
Mar 09 15:17:09 pluto kernel: Bluetooth: hci0: BCM: Patch brcm/
BCM20702A1-0a5c-21e6.hcd not found

And because my BT was working... But not so well...

And after taking advices on #debian-next...

(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831592)

I followed the instructions there:
https://github.com/winterheart/broadcom-bt-firmware

and simply copied the file:
BCM20702A1-0a5c-21e6.hcd
there:
/lib/firmware/brcm

=

After that, and some reboot, I didn't have any bluetooth at all anymore:
The only thing BT in journalctl was:
May 30 17:18:03 pluto dbus[416]: [system] Failed to activate service 
'org.bluez': timed out

And no trace anymore of the mere string "BCM20702" (ignore case option...)

I did even thought that it had "burnt" my chipset

=

So I removed the file BCM20702A1-0a5c-21e6.hcd altogether,

And rebooted,

And now I do have BT again;

Though minimalist and not working well...
(actually can't be used, broken; can be use 1 minute, with difficulties...)

=

I would appreciate help to have that working.


Best,
Chris

Re: How to set ISO date/time with en_US.utf8 as system default?

[gwmfms6]

On 2017-05-30 08:46, Greg Wooledge wrote:


Perhaps a GNOME-specific mailing list might have more options for you.
Maybe there's some way to tell GNOME not to touch the locale settings
*at all*, and simply let them pass through from the underlying 
operating

system.


Yes, I have switched to taking up the issue with GNOME, but they appear 
not to care at all. I did not know the problem was with GNOME initially 
and discussing it with the Debian folks (which are awesome by the way) 
helped me figure out it was GNOME that is the problem.

RE: How to set ISO date/time with en_US.utf8 as system default?

[Emanuele Bernardi]

My system has en_US.utf8 for default, but I wanted the iso time so I just
added the it_IT.utf8 (dpkg-reconfigure locales) and changed in gnome Region
& Language the Formats.

-Original Message-
From: gwmf...@openmailbox.org [mailto:gwmf...@openmailbox.org] 
Sent: martedì 30 maggio 2017 18:22
To: debian-user@lists.debian.org
Subject: Re: How to set ISO date/time with en_US.utf8 as system default?

On 2017-05-30 08:46, Greg Wooledge wrote:
> 
> Perhaps a GNOME-specific mailing list might have more options for you.
> Maybe there's some way to tell GNOME not to touch the locale settings 
> *at all*, and simply let them pass through from the underlying 
> operating system.

Yes, I have switched to taking up the issue with GNOME, but they appear not
to care at all. I did not know the problem was with GNOME initially and
discussing it with the Debian folks (which are awesome by the way) helped me
figure out it was GNOME that is the problem.

Re: bluetooth hci0: firmware: failed to load brcm/BCM20702A1-0a5c-21e6.hcd

[inkbottle]

(note: that chipset is probably used by all recent thinkpad, which probably 
show that when iphones have no jack anymore, BT might not be so much used by 
Linux users)

If I do a "modprobe" (https://ubuntuforums.org/showthread.php?t=2346879)
modprobe -r btusb
modprobe btusb

I get that:

May 30 18:53:06 pluto kernel: usbcore: deregistering interface driver btusb
May 30 18:53:06 pluto kernel: Bluetooth: hci0 urb 8de95167e600 failed to 
resubmit (2)
May 30 18:53:06 pluto systemd[1]: Starting Load/Save RF Kill Switch Status...
May 30 18:53:06 pluto bluetoothd[457]: Endpoint unregistered: sender=:1.33 
path=/MediaEndpoint/A2DPSource
May 30 18:53:06 pluto systemd[1]: bluetooth.target: Unit not needed anymore. 
Stopping.
May 30 18:53:06 pluto bluetoothd[457]: Endpoint unregistered: sender=:1.33 
path=/MediaEndpoint/A2DPSink
May 30 18:53:06 pluto systemd[1]: Stopped target Bluetooth.
May 30 18:53:06 pluto dbus[458]: [system] Rejected send message, 3 matched 
rules; type="error", sender=":1.33" (uid=1000 pid=1859 comm="/usr/bin/
pulseaudio --start --log-target=syslog ") in
May 30 18:53:06 pluto systemd[1]: Started Load/Save RF Kill Switch Status.
May 30 18:53:06 pluto dbus[458]: [system] Rejected send message, 3 matched 
rules; type="error", sender=":1.33" (uid=1000 pid=1859 comm="/usr/bin/
pulseaudio --start --log-target=syslog ") in
May 30 18:53:06 pluto dbus[458]: [system] Rejected send message, 3 matched 
rules; type="error", sender=":1.33" (uid=1000 pid=1859 comm="/usr/bin/
pulseaudio --start --log-target=syslog ") in
May 30 18:53:06 pluto dbus[458]: [system] Rejected send message, 3 matched 
rules; type="error", sender=":1.33" (uid=1000 pid=1859 comm="/usr/bin/
pulseaudio --start --log-target=syslog ") in
May 30 18:53:11 pluto systemd[1]: Reached target Bluetooth.
May 30 18:53:11 pluto kernel: usbcore: registered new interface driver btusb
May 30 18:53:11 pluto kernel: Bluetooth: hci0: BCM: chip id 63
May 30 18:53:11 pluto kernel: Bluetooth: hci0: ChromeLinux_8A81
May 30 18:53:11 pluto kernel: Bluetooth: hci0: BCM20702A1 (001.002.014) build 

May 30 18:53:11 pluto kernel: bluetooth hci0: firmware: direct-loading 
firmware brcm/BCM20702A1-0a5c-21e6.hcd
May 30 18:53:12 pluto kernel: Bluetooth: hci0: BCM20702A1 (001.002.014) build 
1757
May 30 18:53:12 pluto kernel: Bluetooth: hci0: Broadcom Bluetooth Device


root@pluto:/lib/firmware/brcm# hciconfig -a
hci0:   Type: Primary  Bus: USB
BD Address: 9C:2A:70:82:50:FB  ACL MTU: 1021:8  SCO MTU: 64:1
DOWN 
RX bytes:3374 acl:0 sco:0 events:409 errors:0
TX bytes:36217 acl:0 sco:0 commands:408 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link policy: RSWITCH SNIFF 
Link mode: SLAVE ACCEPT 

Seems nice, but actually, I do not have any adapter anymore:

root@pluto:/lib/firmware/brcm# bluetoothctl
[bluetooth]# list
[bluetooth]# 


You can see that here too:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801084



I also did that:
sudo cp /lib/firmware/brcm/BCM43142A0-0a5c-21e6.hcd /lib/firmware/brcm/BCM.hcd

Then modprobe -r and modprobe btusb 

And then the result: "bluetooth.target: Unit not needed anymore. Stopping"

May 30 18:53:06 pluto kernel: usbcore: deregistering interface driver btusb
May 30 18:53:06 pluto kernel: Bluetooth: hci0 urb 8de95167e600 failed to 
resubmit (2)
May 30 18:53:06 pluto systemd[1]: Starting Load/Save RF Kill Switch Status...
May 30 18:53:06 pluto bluetoothd[457]: Endpoint unregistered: sender=:1.33 
path=/MediaEndpoint/A2DPSource
May 30 18:53:06 pluto systemd[1]: bluetooth.target: Unit not needed anymore. 
Stopping.
May 30 18:53:06 pluto bluetoothd[457]: Endpoint unregistered: sender=:1.33 
path=/MediaEndpoint/A2DPSink
May 30 18:53:06 pluto systemd[1]: Stopped target Bluetooth.
May 30 18:53:06 pluto dbus[458]: [system] Rejected send message, 3 matched 
rules; type="error", sender=":1.33" (uid=1000 pid=1859 comm="/usr/bin/
pulseaudio --start --log-target=syslog ") in
May 30 18:53:06 pluto systemd[1]: Started Load/Save RF Kill Switch Status.
May 30 18:53:06 pluto dbus[458]: [system] Rejected send message, 3 matched 
rules; type="error", sender=":1.33" (uid=1000 pid=1859 comm="/usr/bin/
pulseaudio --start --log-target=syslog ") in
May 30 18:53:06 pluto dbus[458]: [system] Rejected send message, 3 matched 
rules; type="error", sender=":1.33" (uid=1000 pid=1859 comm="/usr/bin/
pulseaudio --start --log-target=syslog ") in
May 30 18:53:06 pluto dbus[458]: [system] Rejected send message, 3 matched 
rules; type="error", sender=":1.33" (uid=1000 pid=1859 comm="/usr/bin/
pulseaudio --start --log-target=syslog ") in
May 30 18:53:11 pluto systemd[1]: Reached target Bluetooth.
May 30 18:53:11 pluto kernel: usbcore: registered new interface driver btusb
May 30 18:53:11 pluto kernel: Bluetooth: hci0: BCM: chip id 63
May 30 18:53:11 pluto kernel: Bluetooth: hci0: ChromeLinux_8A81
May 30 18:53:11 pluto kernel: Blu

dirmngr hangs when importing keys

[Tomas Barton]

Hi,

I'm having problems with importing GPG apt keys on Stretch. I'm using
Puppet for managing apt keys, for some reason Puppet considers key missing
and tries to import it. Which results in many dirmngr processes running on
the system:

dirmngr --daemon --homedir /tmp/apt-key-gpghome.0Iq6GBV3gF

These are the problematic keys:

pub   rsa2048 2013-09-12 [SC]
 D27A 72F3 2D86 7DF9 300A  2415 7449 0FD6 EC51 E8C4
uid   [ unknown] Draios Inc. 
sub   rsa2048 2013-09-12 [E]

pub   rsa4096 2015-09-28 [SC]
 05CE 1508 5FC0 9D18 E99E  FB22 684A 14CF 2582 E0C5
uid   [ unknown] InfluxDB Packaging Service 
sub   rsa4096 2015-09-28 [E]

Puppet executes something like this:

 mkdir /tmp/apt-key-gpghome.o22a3cK7lA
 touch /tmp/apt-key-gpghome.o22a3cK7lA/empty.gpg
gpg --ignore-time-conflict --no-options --no-default-keyring --homedir
/tmp/apt-key-gpghome.o22a3cK7lA --quiet --check-trustdb --keyring
/tmp/apt-key-gpghome.o22a3cK7lA/empty.gpg
sh /tmp/apt-key-gpghome.o22a3cK7lA/gpg.0.sh --batch --import
gpg --ignore-time-conflict --no-options --no-default-keyring --homedir
/tmp/apt-key-gpghome.o22a3cK7lA --no-auto-check-trustdb --trust-model
always --batch --import
sh /tmp/apt-key-gpghome.o22a3cK7lA/gpg.0.sh --keyring
/tmp/apt-key-gpghome.o22a3cK7lA/pubring.gpg --with
-colons --fingerprint
gpg --ignore-time-conflict --no-options --no-default-keyring --homedir
/tmp/apt-key-gpghome.o22a3cK7lA -
-no-auto-check-trustdb --trust-model always --keyring
/tmp/apt-key-gpghome.o22a3cK7lA/pubring.gpg --with-colons --fingerprint
 gpgconf --kill gpg-agent
 gpg-connect-agent --no-autostart KILLAGENT


The commands list is incomplete. It works fine on Jessie, I'm not sure what
causes the problem. So far I didn't manage to replicate the behaviour from
command line.

Regards,
Tomas

Re: bluetooth hci0: firmware: failed to load brcm/BCM20702A1-0a5c-21e6.hcd

[inkbottle]

It might be that the heart of the problem could be:
# hciconfig hci0 up
Can't init device hci0: Invalid request code (56)
And that consequently, at some point, "btusb" could be unloaded, with the 
consequence that
hciconfig --all
wouldn't show anything anymore.

If I put that point aside... Some things are working:

# systemctl status bluetooth
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Wed 2017-05-31 01:45:22 CEST; 7min ago
 Docs: man:bluetoothd(8)
 Main PID: 12520 (bluetoothd)
   Status: "Running"
Tasks: 1 (limit: 4915)
   CGroup: /system.slice/bluetooth.service
   └─12520 /usr/lib/bluetooth/bluetoothd

May 31 01:45:22 pluto systemd[1]: Stopping Bluetooth service...
May 31 01:45:22 pluto systemd[1]: Stopped Bluetooth service.
May 31 01:45:22 pluto systemd[1]: Starting Bluetooth service...
May 31 01:45:22 pluto bluetoothd[12520]: Bluetooth daemon 5.43
May 31 01:45:22 pluto systemd[1]: Started Bluetooth service.
May 31 01:45:22 pluto bluetoothd[12520]: Starting SDP server
May 31 01:45:22 pluto bluetoothd[12520]: Bluetooth management interface 1.14 
initialized

# hciconfig --all
hci0:   Type: Primary  Bus: USB
BD Address: 9C:2A:70:82:50:FB  ACL MTU: 1021:8  SCO MTU: 64:1
DOWN 
RX bytes:10122 acl:0 sco:0 events:1227 errors:0
TX bytes:108651 acl:0 sco:0 commands:1224 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link policy: RSWITCH SNIFF 
Link mode: SLAVE ACCEPT 

But hci0 can't be brought up, and therefore nobody can see it,
starting with bluetoothctl.

I might have gathered sufficient information to take that issue to bluez-devel 
mailing list.

On Tuesday, May 30, 2017 7:15:18 PM CEST you wrote:
> (note: that chipset is probably used by all recent thinkpad, which probably
> show that when iphones have no jack anymore, BT might not be so much used by
> Linux users)
> 
> If I do a "modprobe" (https://ubuntuforums.org/showthread.php?t=2346879)
> modprobe -r btusb
> modprobe btusb
> 
> I get that:
> 
> May 30 18:53:06 pluto kernel: usbcore: deregistering interface driver btusb
> May 30 18:53:06 pluto kernel: Bluetooth: hci0 urb 8de95167e600 failed to
> resubmit (2)
> May 30 18:53:06 pluto systemd[1]: Starting Load/Save RF Kill Switch
> Status... May 30 18:53:06 pluto bluetoothd[457]: Endpoint unregistered:
> sender=:1.33 path=/MediaEndpoint/A2DPSource
> May 30 18:53:06 pluto systemd[1]: bluetooth.target: Unit not needed anymore.
> Stopping.
> May 30 18:53:06 pluto bluetoothd[457]: Endpoint unregistered: sender=:1.33
> path=/MediaEndpoint/A2DPSink
> May 30 18:53:06 pluto systemd[1]: Stopped target Bluetooth.
> May 30 18:53:06 pluto dbus[458]: [system] Rejected send message, 3 matched
> rules; type="error", sender=":1.33" (uid=1000 pid=1859 comm="/usr/bin/
> pulseaudio --start --log-target=syslog ") in
> May 30 18:53:06 pluto systemd[1]: Started Load/Save RF Kill Switch Status.
> May 30 18:53:06 pluto dbus[458]: [system] Rejected send message, 3 matched
> rules; type="error", sender=":1.33" (uid=1000 pid=1859 comm="/usr/bin/
> pulseaudio --start --log-target=syslog ") in
> May 30 18:53:06 pluto dbus[458]: [system] Rejected send message, 3 matched
> rules; type="error", sender=":1.33" (uid=1000 pid=1859 comm="/usr/bin/
> pulseaudio --start --log-target=syslog ") in
> May 30 18:53:06 pluto dbus[458]: [system] Rejected send message, 3 matched
> rules; type="error", sender=":1.33" (uid=1000 pid=1859 comm="/usr/bin/
> pulseaudio --start --log-target=syslog ") in
> May 30 18:53:11 pluto systemd[1]: Reached target Bluetooth.
> May 30 18:53:11 pluto kernel: usbcore: registered new interface driver btusb
> May 30 18:53:11 pluto kernel: Bluetooth: hci0: BCM: chip id 63
> May 30 18:53:11 pluto kernel: Bluetooth: hci0: ChromeLinux_8A81
> May 30 18:53:11 pluto kernel: Bluetooth: hci0: BCM20702A1 (001.002.014)
> build 
> May 30 18:53:11 pluto kernel: bluetooth hci0: firmware: direct-loading
> firmware brcm/BCM20702A1-0a5c-21e6.hcd
> May 30 18:53:12 pluto kernel: Bluetooth: hci0: BCM20702A1 (001.002.014)
> build 1757
> May 30 18:53:12 pluto kernel: Bluetooth: hci0: Broadcom Bluetooth Device
> 
> 
> root@pluto:/lib/firmware/brcm# hciconfig -a
> hci0:   Type: Primary  Bus: USB
> BD Address: 9C:2A:70:82:50:FB  ACL MTU: 1021:8  SCO MTU: 64:1
> DOWN
> RX bytes:3374 acl:0 sco:0 events:409 errors:0
> TX bytes:36217 acl:0 sco:0 commands:408 errors:0
> Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> Link policy: RSWITCH SNIFF
> Link mode: SLAVE ACCEPT
> 
> Seems nice, but actually, I do not have any adapter anymore:
> 
> root@pluto:/lib/firmware/brcm# bluetoothctl
> [bluetooth]# list
> [bluetooth]#
> 
> 
> You can see that here too:
> https://bugs.

Re: buying ssl certificate

[kc atgb]

Le 2017-05-28 17:46, Umarzuki Mochlis a écrit :
>> 
>>> Recently came to the market some lowcoast ssl certificate providers. 
>>> Or free ssl providers. What do you think about them ?
>> 
>> I think the best of the free ones is letsencrypt.
>> 
>> Cheers,
>> Andy
>> 
>> --
>> https://bitfolk.com/ -- No-nonsense VPS hosting
>> 
> 
> I'm using letsencrypt with certbot on debian 8 for owncloud 9 with
> apache2 and it works great so far.
> 

I don't know certbot. I'll have to take a look at this for maybe futur 
personal use.

We have not just only one host, but in fact, a lot, so don't know if 
that could help.

> If you feel that you must pay for it, take a look at comparisons of
> ssl certificates at below URL to make informed decision
> https://www.instantssl.com/compare-ssl-certificates.html

We have a wildcard certificate, so I think we will have to buy one.

K.