[Touch-packages] [Bug 1588562] Re: Please add ~/.local/bin to the default $PATH

2020-04-24 Thread klogg
Bug persists in xubuntu 20.04 - checked with fresh install today:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04 LTS
Release:20.04
Codename:   focal

$ bash --version
GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu)

must be reopened

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1588562

Title:
  Please add ~/.local/bin to the default $PATH

Status in bash package in Ubuntu:
  Fix Released
Status in bash source package in Xenial:
  Fix Released
Status in bash package in Debian:
  Fix Released

Bug description:
  Starting in Xenial, 'pip install' by default places executables into
  ~/.local/bin. This is the de-facto standard place to put per-user
  executables -- for example, Fedora/Redhat puts it on the $PATH by
  default, and PEP 370 makes it the standard place for unprivileged
  installs of Python packages to put their scripts.

  But unfortunately, Ubuntu's does *not* add this directory to $PATH by
  default, which means that 'pip install' doesn't actually work -- any
  scripts that are installed are inaccessible, and every user has to
  manually add this to their PATH.

  Ubuntu should put ~/.local/bin onto PATH by default.

  Minor details (discussed with @doko at the PyCon sprints):

  - this should go at the beginning of PATH rather than the end, in accordance 
with Debian policy saying that more-local paths go before more-upstream paths. 
(This is inconsistent with how Fedora/RH do it, but consistent with how Python 
itself searches for packages.)
  - this will be added to /etc/skel/profile, so that it won't change any 
existing user accounts; it will only be applied to user accounts created 
*after* this change lands
  - unlike ~/bin (which Debian/Ubuntu have supported for ages), it will be 
added to PATH unconditionally, even if the directory doesn't exist. This is 
important to avoid a nasty trap for new users, where the first time they try to 
install a Python package they have to restart their shell. Since this only 
applies to new accounts, the directory will always start out nonexistent/empty, 
so having it in $PATH won't cause any unexpected changes in behavior.
  - possibly it would make sense to set this in /etc/environment or 
/etc/skel/.gnomerc or similar, so that it would also apply to non-shell 
processes (e.g. if the user wants to add a global key-binding to launch a 
Python program, then generally ~/.profile *doesn't* affect the environment 
where this command gets executed, and that can frustrate and confuse users if a 
command works fine from the terminal but not from a keybinding). But we should 
defer this discussion for the future, because even if this is a good idea, it 
isn't a good idea in a Xenial stable update.

  Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820856

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1588562/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1851056] Re: "Proceeding WITHOUT firewalling in effect!" warning

2019-11-20 Thread klogg
That's interesting. With secure boot and lockdown in place there is no
bpf, and without bpf systemd services' acls dont work. Not critical but
essentially totally broken :D

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1851056

Title:
  "Proceeding WITHOUT firewalling in effect!" warning

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  In Progress

Bug description:
  Hello everyone,

  I noticed a strange systemd warning in my kernel log about "Proceeding
  WITHOUT firewalling in effect!" There is an older Debian bug mention
  about this same issue and it is said there that it was fixed last
  year: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872560

  Release: Ubuntu 19.10, fresh install, latest updates with updates-testing 
repository enabled
  Systemd-package version: 242-7ubuntu3
  Kernel: Linux 5.3.0-21-generic

  Here is the relevant warning information via running sudo dmesg after
  boot:

  [2.096064] Lockdown: systemd: /dev/mem,kmem,port is restricted; see man 
kernel_lockdown.7
  [2.101034] Lockdown: systemd: BPF is restricted; see man kernel_lockdown.7
  [2.136885] systemd[1]: File 
/lib/systemd/system/systemd-journald.service:12 configures an IP firewall 
(IPAddressDeny=any), but the local system does not support BPF/cgroup based 
firewalling.
  [2.142209] systemd[1]: Proceeding WITHOUT firewalling in effect! (This 
warning is only shown for the first loaded unit using IP firewalling.)
  [2.158190] systemd[1]: /lib/systemd/system/dbus.socket:4: ListenStream= 
references a path below legacy directory /var/run/, updating 
/var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update 
the unit file accordingly.
  [2.197029] systemd[1]: Listening on Journal Socket.
  [2.203708] systemd[1]: Starting Create list of required static device 
nodes for the current kernel...
  [2.243900] bpfilter: Loaded bpfilter_umh pid 420
  #Continues normally from here without anything that seems odd

  The included attachment .txt has more information. From what I've read
  online from various bug trackers from other distributions this should
  be related to a missing kernel option (CONFIG_BPF_SYSCALL=y), but this
  option seems to be enabled:

  # Output after running in commandline: grep BPF /boot/config-`uname -r`
  # Kernel settings seem to be correct?
  CONFIG_CGROUP_BPF=y
  CONFIG_BPF=y
  CONFIG_BPF_SYSCALL=y
  CONFIG_BPF_JIT_ALWAYS_ON=y
  CONFIG_IPV6_SEG6_BPF=y
  CONFIG_NETFILTER_XT_MATCH_BPF=m
  CONFIG_BPFILTER=y
  CONFIG_BPFILTER_UMH=m
  CONFIG_NET_CLS_BPF=m
  CONFIG_NET_ACT_BPF=m
  CONFIG_BPF_JIT=y
  CONFIG_BPF_STREAM_PARSER=y
  CONFIG_LWTUNNEL_BPF=y
  CONFIG_HAVE_EBPF_JIT=y
  CONFIG_BPF_EVENTS=y
  CONFIG_BPF_KPROBE_OVERRIDE=y
  CONFIG_TEST_BPF=m

  Also my friend just installed 19.10 on his machine and is seeing the
  same warning, but I haven't found anyone else mentioning this issue at
  least on the latest Ubuntu 19.10. The same warning message is
  appearing if I run Ubuntu 19.10 in live mode from the USB stick.

  What I expected to happen: no such error (it doesn't appear on Fedora
  or openSUSE Tumbleweed that I've recently had installed on my other
  SSD)

  What happened instead: error appears during every boot sequence

  It's also worth stressing that the firewall is functioning just fine
  (using standard ufw) despite the error, so I'm guessing this is a
  harmless warning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1851056/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1624320] Re: systemd-resolved appends 127.0.0.53 to resolv.conf alongside existing entries

2018-11-03 Thread klogg
Same issue here with 18.10
The bug is here and ignoring it for 2 years is just ridiculous

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1624320

Title:
  systemd-resolved appends 127.0.0.53 to resolv.conf alongside existing
  entries

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  systemd-resolved, or more precisely the hook script
  /lib/systemd/system/systemd-resolved.service.d/resolvconf.conf, causes
  resolvconf to add 127.0.0.53 to the set of nameservers in
  /etc/resolv.conf alongside the other nameservers.  That makes no sense
  because systemd-resolved sets up 127.0.0.53 as a proxy for those other
  nameservers.  The effect is similar to bug 1624071 but for
  applications doing their own DNS lookups.  It breaks any DNSSEC
  validation that systemd-resolved tries to do; applications will
  failover to the other nameservers, bypassing validation failures.  And
  it makes failing queries take twice as long.

  /etc/resolv.conf should have only 127.0.0.53 when systemd-resolved is
  active.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1730993] Re: Bluetooth stops working shortly after connecting to WiFi

2017-11-26 Thread klogg
Workaround with disabling bt_coex described here:
https://unix.stackexchange.com/questions/335329/bluetooth-mouse-stops-working-after-a-few-seconds-networkmanager-issue

It _seemingly_ works for me, but this is not a solution

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1730993

Title:
  Bluetooth stops working shortly after connecting to WiFi

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  On a Lenovo T570 laptop with an Intel Dual Band Wireless-AC 8265, Wi-
  Fi, 2x2 802.11ac + BT4.2 chipset and a fresh install of Ubuntu 17.10,
  when using WiFi, bluetooth will stop working within a minute or two of
  connecting to WiFI.  Specifically a bluetooth mouse (Logitech
  MXAnywhere2) will stop working under these circumstances and will not
  work again until the laptop is restarted.  This does not happen when
  WiFi is not in use (no network or wired network).  This did not happen
  at all in Ubuntu 17.04.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: network-manager 1.8.4-1ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Nov  8 10:16:05 2017
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2017-11-06 (1 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
  IpRoute:
   default via 192.168.18.1 dev enp0s31f6 proto static metric 100 
   169.254.0.0/16 dev enp0s31f6 scope link metric 1000 
   172.16.208.0/24 dev vmnet1 proto kernel scope link src 172.16.208.1 
   192.168.18.0/24 dev enp0s31f6 proto kernel scope link src 192.168.18.39 
metric 100 
   192.168.85.0/24 dev vmnet8 proto kernel scope link src 192.168.85.1
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: network-manager
  UpgradeStatus: No upgrade log present (probably fresh install)
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.8.4connected  started  full  enabled enabled  
enabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1730993/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1730993] Re: Bluetooth stops working shortly after connecting to WiFi

2017-11-26 Thread klogg
Same issue:
 - Lenovo X1 Carbon (5th gen) with Intel Dual Band Wireless-AC 8265 Wi-Fi 2x2 
802.11ac + BT4.2 chipset
 - Ubuntu 17.10
 - Logitech MX Anywhere 2 bluetooth mouse

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1730993

Title:
  Bluetooth stops working shortly after connecting to WiFi

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  On a Lenovo T570 laptop with an Intel Dual Band Wireless-AC 8265, Wi-
  Fi, 2x2 802.11ac + BT4.2 chipset and a fresh install of Ubuntu 17.10,
  when using WiFi, bluetooth will stop working within a minute or two of
  connecting to WiFI.  Specifically a bluetooth mouse (Logitech
  MXAnywhere2) will stop working under these circumstances and will not
  work again until the laptop is restarted.  This does not happen when
  WiFi is not in use (no network or wired network).  This did not happen
  at all in Ubuntu 17.04.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: network-manager 1.8.4-1ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Nov  8 10:16:05 2017
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2017-11-06 (1 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
  IpRoute:
   default via 192.168.18.1 dev enp0s31f6 proto static metric 100 
   169.254.0.0/16 dev enp0s31f6 scope link metric 1000 
   172.16.208.0/24 dev vmnet1 proto kernel scope link src 172.16.208.1 
   192.168.18.0/24 dev enp0s31f6 proto kernel scope link src 192.168.18.39 
metric 100 
   192.168.85.0/24 dev vmnet8 proto kernel scope link src 192.168.85.1
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: network-manager
  UpgradeStatus: No upgrade log present (probably fresh install)
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.8.4connected  started  full  enabled enabled  
enabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1730993/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp