[Touch-packages] [Bug 1941752] Re: Regression: exiv2 0.27.3-3ubuntu1.5 makes Gwenview crash when opening images exported by darktable

2021-12-30 Thread Ubuntu Foundations Team Bug Bot
The attachment "1-0.27.2-8ubuntu2.7.debdiff" seems to be a debdiff.  The
ubuntu-sponsors team has been subscribed to the bug report so that they
can review and hopefully sponsor the debdiff.  If the attachment isn't a
patch, please remove the "patch" flag from the attachment, remove the
"patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe
the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issue please contact him.]

** Tags added: patch

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

Title:
  Regression: exiv2 0.27.3-3ubuntu1.5 makes Gwenview crash when opening
  images exported by darktable

Status in Gwenview:
  Fix Released
Status in exiv2 package in Ubuntu:
  Confirmed
Status in gwenview package in Ubuntu:
  Confirmed

Bug description:
  Since the recent security update of exiv2, Gwenview crashes when
  trying to open image files that got exported by darktable.

  Steps to reproduce:

  * Make a test installation of Kubuntu 21.04 in VirtualBox
  * Install all updates
  * Install darktable
  * Copy one of the images in /usr/share/wallpapers (or any other image) to 
your home directory and open it with darktable
  * Within darktable, export a copy of the image (no need to do any actual 
modifications)
  * Try to open that copy with Gwenview. Gwenview will crash.

  I'm attaching a crash report hinting that this is related to exiv2.

  Temporary workaround:
  If I downgrade libexiv2-27 to 0.27.3-3ubuntu1.4, Gwenview doesn't crash, so 
it seems the crash is related to changes in 0.27.3-3ubuntu1.5.

  I don't know if the underlying cause is actually some bug in exiv2,
  Gwenview or darktable.

  Kind regards, Jan

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: libexiv2-27 0.27.3-3ubuntu1.5
  ProcVersionSignature: Ubuntu 5.11.0-31.33-generic 5.11.22
  Uname: Linux 5.11.0-31-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: KDE
  Date: Thu Aug 26 15:16:47 2021
  InstallationDate: Installed on 2021-08-26 (0 days ago)
  InstallationMedia: Kubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  SourcePackage: exiv2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gwenview/+bug/1941752/+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 1956062] [NEW] vim mis-manages modifyOtherKeys on xterms

2021-12-30 Thread Douglas Miller
Public bug reported:

This began as question #76. I've observed odd behavior in vim since
my upgrade from 18.04 to 20.04. One in particular is when I use the "r"
command to replace a single character, shifted letters fail to work
correctly and vim sputters and changes the case of letters in the line,
instead of replace a single character. Another place is in search
strings where I want to use the carriage-return character and type
Ctrl-V Ctrl-M, the Ctrl-M appears as an ESC sequence instead of "^M" and
the search fails to do what I intended.

Analyzing the problem in question #76 revealed this:

When vim initializes (the xterm), it sends "^[[>4;2m" which sets the
modifyOtherKeys=2 parameter. This appears to send *any* keys that use
modifiers (Shift, Ctrl, Alt) as ESC sequences, as we've seen. This
explains why the un-shifted keys "r" and "s" appear normally. But, it
appears that there are certain cases where vim is not properly
interpreting the sequences that it requested.

In the case of the "s" command, vim sends an "^[[>4;m"
(modifyOtherKeys=0) before I can type the "A", so the "A" comes in as a
normal ASCII character. It appears that vim should also be doing the
same thing for "r" but does not. There are probably other contexts where
vim is failing to properly manage the modifyOtherKeys setting, such as
when I try ^V^M in search commands.

In the case of the "r" command, vim sends no ESC sequences after the "r"
so the "A" comes in as the ESC sequence "^[[27;2;65~" and confuses vim.

In the case of search commands, vim is also failing to reset the
modifyOtherKeys setting, so the ^V and ^M are sent as ESC sequences -
although it appears that vim recognizes the ^V "^[[27;5;118~" and then
(correctly) ignores the ESC in the ^M sequence "^[[27;5;109~". FYI, I
understand that vim can now recognize "\r" in search strings, but that
still leaves the problem of all the other control characters I must
often manipulate in search commands.

It is looking now as though there is actually a bug in vim, where it
does not properly manage the modifyOtherKeys setting even though it
explicitly requests that setting.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: vim 2:8.1.2269-1ubuntu5.4
ProcVersionSignature: Ubuntu 5.4.0-91.102-generic 5.4.151
Uname: Linux 5.4.0-91-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Thu Dec 30 15:49:03 2021
InstallationDate: Installed on 2017-02-22 (1772 days ago)
InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.2)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: vim
UpgradeStatus: Upgraded to focal on 2020-10-04 (451 days ago)

** Affects: vim (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug focal

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

Title:
  vim mis-manages modifyOtherKeys on xterms

Status in vim package in Ubuntu:
  New

Bug description:
  This began as question #76. I've observed odd behavior in vim
  since my upgrade from 18.04 to 20.04. One in particular is when I use
  the "r" command to replace a single character, shifted letters fail to
  work correctly and vim sputters and changes the case of letters in the
  line, instead of replace a single character. Another place is in
  search strings where I want to use the carriage-return character and
  type Ctrl-V Ctrl-M, the Ctrl-M appears as an ESC sequence instead of
  "^M" and the search fails to do what I intended.

  Analyzing the problem in question #76 revealed this:

  When vim initializes (the xterm), it sends "^[[>4;2m" which sets the
  modifyOtherKeys=2 parameter. This appears to send *any* keys that use
  modifiers (Shift, Ctrl, Alt) as ESC sequences, as we've seen. This
  explains why the un-shifted keys "r" and "s" appear normally. But, it
  appears that there are certain cases where vim is not properly
  interpreting the sequences that it requested.

  In the case of the "s" command, vim sends an "^[[>4;m"
  (modifyOtherKeys=0) before I can type the "A", so the "A" comes in as
  a normal ASCII character. It appears that vim should also be doing the
  same thing for "r" but does not. There are probably other contexts
  where vim is failing to properly manage the modifyOtherKeys setting,
  such as when I try ^V^M in search commands.

  In the case of the "r" command, vim sends no ESC sequences after the
  "r" so the "A" comes in as the ESC sequence "^[[27;2;65~" and confuses
  vim.

  In the case of search commands, vim is also failing to reset the
  modifyOtherKeys setting, so the ^V and ^M are sent as ESC sequences -
  although it appears that vim recognizes the ^V "^[[27;5;118~" and then
  (correctly) ignores the ESC in the ^M sequence 

[Touch-packages] [Bug 1941752] Re: Regression: exiv2 0.27.3-3ubuntu1.5 makes Gwenview crash when opening images exported by darktable

2021-12-30 Thread simonschmeisser
This is a debdiff applicable for focal-security. This backports an
upstream fix for the regression introduced when fixing CVE-2021-37620. I
build it locally in pbuilder and it fixes the crash in gwenview as
expected.

** Patch added: "1-0.27.2-8ubuntu2.7.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/exiv2/+bug/1941752/+attachment/5550448/+files/1-0.27.2-8ubuntu2.7.debdiff

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

Title:
  Regression: exiv2 0.27.3-3ubuntu1.5 makes Gwenview crash when opening
  images exported by darktable

Status in Gwenview:
  Fix Released
Status in exiv2 package in Ubuntu:
  Confirmed
Status in gwenview package in Ubuntu:
  Confirmed

Bug description:
  Since the recent security update of exiv2, Gwenview crashes when
  trying to open image files that got exported by darktable.

  Steps to reproduce:

  * Make a test installation of Kubuntu 21.04 in VirtualBox
  * Install all updates
  * Install darktable
  * Copy one of the images in /usr/share/wallpapers (or any other image) to 
your home directory and open it with darktable
  * Within darktable, export a copy of the image (no need to do any actual 
modifications)
  * Try to open that copy with Gwenview. Gwenview will crash.

  I'm attaching a crash report hinting that this is related to exiv2.

  Temporary workaround:
  If I downgrade libexiv2-27 to 0.27.3-3ubuntu1.4, Gwenview doesn't crash, so 
it seems the crash is related to changes in 0.27.3-3ubuntu1.5.

  I don't know if the underlying cause is actually some bug in exiv2,
  Gwenview or darktable.

  Kind regards, Jan

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: libexiv2-27 0.27.3-3ubuntu1.5
  ProcVersionSignature: Ubuntu 5.11.0-31.33-generic 5.11.22
  Uname: Linux 5.11.0-31-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: KDE
  Date: Thu Aug 26 15:16:47 2021
  InstallationDate: Installed on 2021-08-26 (0 days ago)
  InstallationMedia: Kubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  SourcePackage: exiv2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gwenview/+bug/1941752/+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 1769936] Re: [80X7, Realtek ALC236, Mic, Internal] Sound is distorted Lenovo Yoga 720

2021-12-30 Thread oleg.sobchuk
Hope this solution will be helpful for someone else
https://forums.linuxmint.com/viewtopic.php?t=322530

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

Title:
  [80X7, Realtek ALC236, Mic, Internal] Sound is distorted Lenovo Yoga
  720

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  Happy to do further testing, fresh install of Bionic. Discovered this
  when trying to do a video conference using the built in mic and was
  able to verify the issue by installing gnome-sound-recorder.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   asif   2213 F...m pulseaudio
   /dev/snd/controlC0:  asif   2213 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Tue May  8 11:58:37 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2018-04-28 (9 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH successful
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Mic, Internal
  Symptom_PulseAudioRecordingTest: PulseAudio recording test through plughw:PCH 
successful
  Symptom_Type: Digital clip or distortion, or "overdriven" sound
  Title: [80X7, Realtek ALC236, Mic, Internal] Sound is distorted
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/08/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 4MCN31WW(V2.03)
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40709 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 31
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo YOGA 720-15IKB
  dmi.modalias: 
dmi:bvnLENOVO:bvr4MCN31WW(V2.03):bd03/08/2018:svnLENOVO:pn80X7:pvrLenovoYOGA720-15IKB:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct31:cvrLenovoYOGA720-15IKB:
  dmi.product.family: YOGA 720-15IKB
  dmi.product.name: 80X7
  dmi.product.version: Lenovo YOGA 720-15IKB
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1769936/+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 1956029] Re: ufw remains inactive at boot time

2021-12-30 Thread Myron Szymanskyj
Right after reboot I tried to get the status.

Result is . . . .

root@loki:~# s ufw status
ERROR: problem running iptables: Another app is currently holding the xtables 
lock. Perhaps you want to use the -w option?

. . . . while fail2ban is setting up its rules.

Anyway...  After a reeboot, whatever I've done seems to have worked.
I'm assuming adding "ufw.service" to fail2ban.service may have done the
trick as has been mentioned on comment 4.

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

Title:
  ufw remains inactive at boot time

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  I was advised to start a bug report (Comment 38):
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856

  I "ufw enable" then several seconds later networking stops. I have get
  Ubuntu to gracefully power-down using the power-button and then
  gracefully power-up.

  Out of curiosity, is anyone here having this problem wish ufw starting
  up at boot time while also using having fail2ban installed?

  Here is my theory. It takes a while for fail2ban to issue all the
  iptable commands to configure the firewall. When ufw tries to
  initialise there may be a clash or lock held either by an iptables
  instance spawned by fail2ban or an iptables instance spawned by ufw.
  One of them will fail and will quite probably mess-up ufw's rules
  breaking network connectivity.

  This time I waited for fail2ban to finish establishing its iptables
  rules before issuing "ufw enable" and this time round network
  connectivity was not lost.

  How to I ensure that ufw is fully up and initialised BEFORE the
  fail2ban service starts?

  -
  root@loki:~# ./ufw-diag.sh
  Has python: pass (binary: python3, version: 3.8.10, py3)
  Has iptables: pass
  Has ip6tables: pass

  Has /proc/net/dev: pass
  Has /proc/net/if_inet6: pass

  This script will now attempt to create various rules using the iptables
  and ip6tables commands. This may result in module autoloading (eg, for
  IPv6).
  Proceed with checks (Y/n)?
  == IPv4 ==
  Creating 'ufw-check-requirements'... done
  Inserting RETURN at top of 'ufw-check-requirements'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  addrtype (LOCAL): pass
  addrtype (MULTICAST): pass
  addrtype (BROADCAST): pass
  icmp (destination-unreachable): pass
  icmp (source-quench): pass
  icmp (time-exceeded): pass
  icmp (parameter-problem): pass
  icmp (echo-request): pass

  == IPv6 ==
  Creating 'ufw-check-requirements6'... done
  Inserting RETURN at top of 'ufw-check-requirements6'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  icmpv6 (destination-unreachable): pass
  icmpv6 (packet-too-big): pass
  icmpv6 (time-exceeded): pass
  icmpv6 (parameter-problem): pass
  icmpv6 (echo-request): pass
  icmpv6 with hl (neighbor-solicitation): pass
  icmpv6 with hl (neighbor-advertisement): pass
  icmpv6 with hl (router-solicitation): pass
  icmpv6 with hl (router-advertisement): pass
  ipv6 rt: pass

  All tests passed
  -
  root@loki:/lib/systemd/system# cat ufw.service
  [Unit]
  Description=Uncomplicated firewall
  Documentation=man:ufw(8)
  DefaultDependencies=no
  Before=network.target
  After=NetworkManager.service

  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/lib/ufw/ufw-init start quiet
  # ExecStartPost=/bin/sleep 10
  ExecStop=/lib/ufw/ufw-init stop

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/lib/systemd/system# cat fail2ban.service
  [Unit]
  Description=Fail2Ban Service
  Documentation=man:fail2ban(1)
  After=network.target iptables.service firewalld.service ip6tables.service 
ipset.service nftables.service ufw.service
  PartOf=firewalld.service

  [Service]
  Type=simple
  ExecStartPre=/bin/mkdir -p /run/fail2ban
  ExecStart=/usr/bin/fail2ban-server -xf start
  # if should be logged in systemd journal, use following line or set logtarget 
to sysout in fail2ban.local
  # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start
  ExecStop=/usr/bin/fail2ban-client stop
  ExecReload=/usr/bin/fail2ban-client 

[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time

2021-12-30 Thread Myron Szymanskyj
By networking stops means that I can not establish a connection with the
Lemaker BananaPi Pro on any port so I can't get a SSHed shell, can't
access the VPN server, etc...  It behaves like someone has plugged the
network cable.

Putting "ufw.service" was a guess, but I've not rebooted the OS yet with
that in place.

root@loki:~# iptables --version
iptables v1.8.4 (legacy)
root@loki:~# uname -a
Linux loki 5.10.60-sunxi #21.08.2 SMP Tue Sep 14 16:28:44 UTC 2021 armv7l 
armv7l armv7l GNU/Linux
root@loki:~# fail2ban-client --version
Fail2Ban v0.11.1

OS in use obtained from here: https://www.armbian.com/banana-pi-pro/

I will try a reboot and see what happens. Will report result back here.

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

Title:
  ufw remains inactive at boot time

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  I was advised to start a bug report (Comment 38):
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856

  I "ufw enable" then several seconds later networking stops. I have get
  Ubuntu to gracefully power-down using the power-button and then
  gracefully power-up.

  Out of curiosity, is anyone here having this problem wish ufw starting
  up at boot time while also using having fail2ban installed?

  Here is my theory. It takes a while for fail2ban to issue all the
  iptable commands to configure the firewall. When ufw tries to
  initialise there may be a clash or lock held either by an iptables
  instance spawned by fail2ban or an iptables instance spawned by ufw.
  One of them will fail and will quite probably mess-up ufw's rules
  breaking network connectivity.

  This time I waited for fail2ban to finish establishing its iptables
  rules before issuing "ufw enable" and this time round network
  connectivity was not lost.

  How to I ensure that ufw is fully up and initialised BEFORE the
  fail2ban service starts?

  -
  root@loki:~# ./ufw-diag.sh
  Has python: pass (binary: python3, version: 3.8.10, py3)
  Has iptables: pass
  Has ip6tables: pass

  Has /proc/net/dev: pass
  Has /proc/net/if_inet6: pass

  This script will now attempt to create various rules using the iptables
  and ip6tables commands. This may result in module autoloading (eg, for
  IPv6).
  Proceed with checks (Y/n)?
  == IPv4 ==
  Creating 'ufw-check-requirements'... done
  Inserting RETURN at top of 'ufw-check-requirements'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  addrtype (LOCAL): pass
  addrtype (MULTICAST): pass
  addrtype (BROADCAST): pass
  icmp (destination-unreachable): pass
  icmp (source-quench): pass
  icmp (time-exceeded): pass
  icmp (parameter-problem): pass
  icmp (echo-request): pass

  == IPv6 ==
  Creating 'ufw-check-requirements6'... done
  Inserting RETURN at top of 'ufw-check-requirements6'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  icmpv6 (destination-unreachable): pass
  icmpv6 (packet-too-big): pass
  icmpv6 (time-exceeded): pass
  icmpv6 (parameter-problem): pass
  icmpv6 (echo-request): pass
  icmpv6 with hl (neighbor-solicitation): pass
  icmpv6 with hl (neighbor-advertisement): pass
  icmpv6 with hl (router-solicitation): pass
  icmpv6 with hl (router-advertisement): pass
  ipv6 rt: pass

  All tests passed
  -
  root@loki:/lib/systemd/system# cat ufw.service
  [Unit]
  Description=Uncomplicated firewall
  Documentation=man:ufw(8)
  DefaultDependencies=no
  Before=network.target
  After=NetworkManager.service

  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/lib/ufw/ufw-init start quiet
  # ExecStartPost=/bin/sleep 10
  ExecStop=/lib/ufw/ufw-init stop

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/lib/systemd/system# cat fail2ban.service
  [Unit]
  Description=Fail2Ban Service
  Documentation=man:fail2ban(1)
  After=network.target iptables.service firewalld.service ip6tables.service 
ipset.service nftables.service ufw.service
  PartOf=firewalld.service

  [Service]
  Type=simple
  ExecStartPre=/bin/mkdir -p /run/fail2ban
  ExecStart=/usr/bin/fail2ban-server -xf start
  # if should 

[Touch-packages] [Bug 574287] Re: tasksel: forcefully removes packages when tasks overlap

2021-12-30 Thread Norbert
** Tags added: bionic focal hirsute impish jammy rls-jj-incoming xenial

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

Title:
  tasksel: forcefully removes packages when tasks overlap

Status in apt package in Ubuntu:
  Invalid
Status in tasksel package in Ubuntu:
  Confirmed
Status in tasksel package in Debian:
  Fix Released

Bug description:
  TEST CASE

  1. Boot Lucid LiveCD

  2. run "sudo tasksel" and select "virtual machine host"

  3. run "sudo tasksel" and deselect "virtual machine host"

  4. watch how tasksel uninstalls your system

  OBSERVATIONS

  What seems to happen is that apt vengefully removes ALL of the items
  associated with one task, including several base dependencies of other
  tasks (e.g. ubuntu-desktop)

  One illustrative example is the openssh-server task:
  This one includes the packages openssh-server, tcpd and libwrap0.
  From a normal ubuntu-desktop (e.g. ~liveCD) both tcpd and libwrap0 are 
already installed, and the task-install pulls in only openssh-server.
  However when the task is removed, all these three packages (openssh-server, 
tcpd and libwrap0) are forcefully removed.
  Since libwrap0 is a core dependency of gnome, a large part of gnome will be 
removed alongside the removal of the task.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/574287/+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 1769936] Re: [80X7, Realtek ALC236, Mic, Internal] Sound is distorted Lenovo Yoga 720

2021-12-30 Thread oleg.sobchuk
Any update for this? Use 20.04. Mic or doesn't work or make just a
noise.

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

Title:
  [80X7, Realtek ALC236, Mic, Internal] Sound is distorted Lenovo Yoga
  720

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  Happy to do further testing, fresh install of Bionic. Discovered this
  when trying to do a video conference using the built in mic and was
  able to verify the issue by installing gnome-sound-recorder.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   asif   2213 F...m pulseaudio
   /dev/snd/controlC0:  asif   2213 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Tue May  8 11:58:37 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2018-04-28 (9 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH successful
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Mic, Internal
  Symptom_PulseAudioRecordingTest: PulseAudio recording test through plughw:PCH 
successful
  Symptom_Type: Digital clip or distortion, or "overdriven" sound
  Title: [80X7, Realtek ALC236, Mic, Internal] Sound is distorted
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/08/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 4MCN31WW(V2.03)
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40709 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 31
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo YOGA 720-15IKB
  dmi.modalias: 
dmi:bvnLENOVO:bvr4MCN31WW(V2.03):bd03/08/2018:svnLENOVO:pn80X7:pvrLenovoYOGA720-15IKB:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct31:cvrLenovoYOGA720-15IKB:
  dmi.product.family: YOGA 720-15IKB
  dmi.product.name: 80X7
  dmi.product.version: Lenovo YOGA 720-15IKB
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1769936/+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 1956059] [NEW] Backport gspawn fixes to impish

2021-12-30 Thread Dan Nicholson
Public bug reported:

A few changes for gspawn landed in the 2.67 series that had some bugs
which were later fixed and backported to 2.70 as seen in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2394. These bugs
are present in 2.68 as on impish, but that series won't see any more
updates upstream.

Currently this is causing a bug in the OSTree test suite as seen in
https://github.com/ostreedev/ostree/issues/2495 with
https://github.com/ostreedev/ostree/issues/2495#issuecomment-1000247260
confirming from glib's maintainer that these bugs are likely the issue.

Attached is a debdiff with the 3 patches that were backported to 2.70.

** Affects: glib2.0 (Ubuntu)
 Importance: Undecided
 Status: New

** Attachment added: "Debdiff for 3 gspawn backport patches"
   
https://bugs.launchpad.net/bugs/1956059/+attachment/5550436/+files/glib2.0_2.68.4-1ubuntu2.diff

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

Title:
  Backport gspawn fixes to impish

Status in glib2.0 package in Ubuntu:
  New

Bug description:
  A few changes for gspawn landed in the 2.67 series that had some bugs
  which were later fixed and backported to 2.70 as seen in
  https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2394. These bugs
  are present in 2.68 as on impish, but that series won't see any more
  updates upstream.

  Currently this is causing a bug in the OSTree test suite as seen in
  https://github.com/ostreedev/ostree/issues/2495 with
  https://github.com/ostreedev/ostree/issues/2495#issuecomment-1000247260
  confirming from glib's maintainer that these bugs are likely the
  issue.

  Attached is a debdiff with the 3 patches that were backported to 2.70.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1956059/+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 1956029] Re: ufw remains inactive at boot time

2021-12-30 Thread Jamie Strandboge
> How to I ensure that ufw is fully up and initialised BEFORE the
fail2ban service starts?

This line from your existing fail2ban.service should be sufficient:

After=network.target iptables.service firewalld.service
ip6tables.service ipset.service nftables.service ufw.service

See https://www.freedesktop.org/software/systemd/man/systemd.unit.html
for details ("After= is the inverse of Before=, i.e. while Before=
ensures that the configured unit is started before the listed unit
begins starting up, After= ensures the opposite, that the listed unit is
fully started up before the configured unit is started.")

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

Title:
  ufw remains inactive at boot time

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  I was advised to start a bug report (Comment 38):
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856

  I "ufw enable" then several seconds later networking stops. I have get
  Ubuntu to gracefully power-down using the power-button and then
  gracefully power-up.

  Out of curiosity, is anyone here having this problem wish ufw starting
  up at boot time while also using having fail2ban installed?

  Here is my theory. It takes a while for fail2ban to issue all the
  iptable commands to configure the firewall. When ufw tries to
  initialise there may be a clash or lock held either by an iptables
  instance spawned by fail2ban or an iptables instance spawned by ufw.
  One of them will fail and will quite probably mess-up ufw's rules
  breaking network connectivity.

  This time I waited for fail2ban to finish establishing its iptables
  rules before issuing "ufw enable" and this time round network
  connectivity was not lost.

  How to I ensure that ufw is fully up and initialised BEFORE the
  fail2ban service starts?

  -
  root@loki:~# ./ufw-diag.sh
  Has python: pass (binary: python3, version: 3.8.10, py3)
  Has iptables: pass
  Has ip6tables: pass

  Has /proc/net/dev: pass
  Has /proc/net/if_inet6: pass

  This script will now attempt to create various rules using the iptables
  and ip6tables commands. This may result in module autoloading (eg, for
  IPv6).
  Proceed with checks (Y/n)?
  == IPv4 ==
  Creating 'ufw-check-requirements'... done
  Inserting RETURN at top of 'ufw-check-requirements'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  addrtype (LOCAL): pass
  addrtype (MULTICAST): pass
  addrtype (BROADCAST): pass
  icmp (destination-unreachable): pass
  icmp (source-quench): pass
  icmp (time-exceeded): pass
  icmp (parameter-problem): pass
  icmp (echo-request): pass

  == IPv6 ==
  Creating 'ufw-check-requirements6'... done
  Inserting RETURN at top of 'ufw-check-requirements6'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  icmpv6 (destination-unreachable): pass
  icmpv6 (packet-too-big): pass
  icmpv6 (time-exceeded): pass
  icmpv6 (parameter-problem): pass
  icmpv6 (echo-request): pass
  icmpv6 with hl (neighbor-solicitation): pass
  icmpv6 with hl (neighbor-advertisement): pass
  icmpv6 with hl (router-solicitation): pass
  icmpv6 with hl (router-advertisement): pass
  ipv6 rt: pass

  All tests passed
  -
  root@loki:/lib/systemd/system# cat ufw.service
  [Unit]
  Description=Uncomplicated firewall
  Documentation=man:ufw(8)
  DefaultDependencies=no
  Before=network.target
  After=NetworkManager.service

  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/lib/ufw/ufw-init start quiet
  # ExecStartPost=/bin/sleep 10
  ExecStop=/lib/ufw/ufw-init stop

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/lib/systemd/system# cat fail2ban.service
  [Unit]
  Description=Fail2Ban Service
  Documentation=man:fail2ban(1)
  After=network.target iptables.service firewalld.service ip6tables.service 
ipset.service nftables.service ufw.service
  PartOf=firewalld.service

  [Service]
  Type=simple
  ExecStartPre=/bin/mkdir -p /run/fail2ban
  ExecStart=/usr/bin/fail2ban-server -xf start
  # if should be logged in systemd journal, use following line or set logtarget 
to sysout in 

[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time

2021-12-30 Thread Jamie Strandboge
> 4. you didn't mention which distro you are using

This would be good to know since some distros are using iptables 1.8.x
which has two different backends that are in play. Which distro are you
using and what is the output of `iptables --version`

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

Title:
  ufw remains inactive at boot time

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  I was advised to start a bug report (Comment 38):
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856

  I "ufw enable" then several seconds later networking stops. I have get
  Ubuntu to gracefully power-down using the power-button and then
  gracefully power-up.

  Out of curiosity, is anyone here having this problem wish ufw starting
  up at boot time while also using having fail2ban installed?

  Here is my theory. It takes a while for fail2ban to issue all the
  iptable commands to configure the firewall. When ufw tries to
  initialise there may be a clash or lock held either by an iptables
  instance spawned by fail2ban or an iptables instance spawned by ufw.
  One of them will fail and will quite probably mess-up ufw's rules
  breaking network connectivity.

  This time I waited for fail2ban to finish establishing its iptables
  rules before issuing "ufw enable" and this time round network
  connectivity was not lost.

  How to I ensure that ufw is fully up and initialised BEFORE the
  fail2ban service starts?

  -
  root@loki:~# ./ufw-diag.sh
  Has python: pass (binary: python3, version: 3.8.10, py3)
  Has iptables: pass
  Has ip6tables: pass

  Has /proc/net/dev: pass
  Has /proc/net/if_inet6: pass

  This script will now attempt to create various rules using the iptables
  and ip6tables commands. This may result in module autoloading (eg, for
  IPv6).
  Proceed with checks (Y/n)?
  == IPv4 ==
  Creating 'ufw-check-requirements'... done
  Inserting RETURN at top of 'ufw-check-requirements'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  addrtype (LOCAL): pass
  addrtype (MULTICAST): pass
  addrtype (BROADCAST): pass
  icmp (destination-unreachable): pass
  icmp (source-quench): pass
  icmp (time-exceeded): pass
  icmp (parameter-problem): pass
  icmp (echo-request): pass

  == IPv6 ==
  Creating 'ufw-check-requirements6'... done
  Inserting RETURN at top of 'ufw-check-requirements6'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  icmpv6 (destination-unreachable): pass
  icmpv6 (packet-too-big): pass
  icmpv6 (time-exceeded): pass
  icmpv6 (parameter-problem): pass
  icmpv6 (echo-request): pass
  icmpv6 with hl (neighbor-solicitation): pass
  icmpv6 with hl (neighbor-advertisement): pass
  icmpv6 with hl (router-solicitation): pass
  icmpv6 with hl (router-advertisement): pass
  ipv6 rt: pass

  All tests passed
  -
  root@loki:/lib/systemd/system# cat ufw.service
  [Unit]
  Description=Uncomplicated firewall
  Documentation=man:ufw(8)
  DefaultDependencies=no
  Before=network.target
  After=NetworkManager.service

  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/lib/ufw/ufw-init start quiet
  # ExecStartPost=/bin/sleep 10
  ExecStop=/lib/ufw/ufw-init stop

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/lib/systemd/system# cat fail2ban.service
  [Unit]
  Description=Fail2Ban Service
  Documentation=man:fail2ban(1)
  After=network.target iptables.service firewalld.service ip6tables.service 
ipset.service nftables.service ufw.service
  PartOf=firewalld.service

  [Service]
  Type=simple
  ExecStartPre=/bin/mkdir -p /run/fail2ban
  ExecStart=/usr/bin/fail2ban-server -xf start
  # if should be logged in systemd journal, use following line or set logtarget 
to sysout in fail2ban.local
  # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start
  ExecStop=/usr/bin/fail2ban-client stop
  ExecReload=/usr/bin/fail2ban-client reload
  PIDFile=/run/fail2ban/fail2ban.pid
  Restart=on-failure
  RestartPreventExitStatus=0 255

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/etc/default# cat ufw
  # /etc/default/ufw
  

[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time

2021-12-30 Thread Jamie Strandboge
Thanks for the bug report. A few things:

1. I'm not sure what 'networking stops' means precisely in the context
of this bug report. Does 'ufw disable' restore the network? Is the
network torn down? Something else (you are using a lot of limit rules
instead of allow rules, I wonder if you are hitting limits...)?

2. 'journalctl -u ufw.service' isn't normally going to show you much
since the command run from the service isn't very chatty. Better would
be to look at /var/log/ufw.log around the time the networking stops. If
/var/log/ufw.log doesn't exist on your distro, you should check
/var/log/kern.log for firewall denials and then try to resolve them with
new/modified firewall rules

3. It isn't clear if you used the check-requirements from
https://git.launchpad.net/ufw/tree/tests/check-requirements or the one
on the system. Which did you use? (Note, I just made a change to
https://git.launchpad.net/ufw/tree/tests/check-requirements that you
might want to use)

4. you didn't mention which distro you are using, but the ufw.service
file is not what is shipped upstream (or Ubuntu or Debian). This is what
has been shipped in Ubuntu and Debian for several years:

[Unit]
Description=Uncomplicated firewall
Documentation=man:ufw(8)
DefaultDependencies=no
Before=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/ufw/ufw-init start quiet
ExecStop=/lib/ufw/ufw-init stop

[Install]
WantedBy=multi-user.target

  and this is what is upstream (Debian is the same except omits the
'Conflicts') and what should solve some issues (though I'm not sure it
would solve your issues:

[Unit]
Description=Uncomplicated firewall
Documentation=man:ufw(8)
Before=network-pre.target
Wants=network-pre.target
Conflicts=iptables.service ip6tables.service nftables.service 
firewalld.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/ufw/ufw-init start quiet
ExecStop=/lib/ufw/ufw-init stop

[Install]
WantedBy=multi-user.target

  You may want to adjust the service file to be like the upstream one,
then run 'sudo systemctl daemon-reload' and reboot.

** Changed in: ufw (Ubuntu)
   Status: New => Incomplete

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

Title:
  ufw remains inactive at boot time

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  I was advised to start a bug report (Comment 38):
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856

  I "ufw enable" then several seconds later networking stops. I have get
  Ubuntu to gracefully power-down using the power-button and then
  gracefully power-up.

  Out of curiosity, is anyone here having this problem wish ufw starting
  up at boot time while also using having fail2ban installed?

  Here is my theory. It takes a while for fail2ban to issue all the
  iptable commands to configure the firewall. When ufw tries to
  initialise there may be a clash or lock held either by an iptables
  instance spawned by fail2ban or an iptables instance spawned by ufw.
  One of them will fail and will quite probably mess-up ufw's rules
  breaking network connectivity.

  This time I waited for fail2ban to finish establishing its iptables
  rules before issuing "ufw enable" and this time round network
  connectivity was not lost.

  How to I ensure that ufw is fully up and initialised BEFORE the
  fail2ban service starts?

  -
  root@loki:~# ./ufw-diag.sh
  Has python: pass (binary: python3, version: 3.8.10, py3)
  Has iptables: pass
  Has ip6tables: pass

  Has /proc/net/dev: pass
  Has /proc/net/if_inet6: pass

  This script will now attempt to create various rules using the iptables
  and ip6tables commands. This may result in module autoloading (eg, for
  IPv6).
  Proceed with checks (Y/n)?
  == IPv4 ==
  Creating 'ufw-check-requirements'... done
  Inserting RETURN at top of 'ufw-check-requirements'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  addrtype (LOCAL): pass
  addrtype (MULTICAST): pass
  addrtype (BROADCAST): pass
  icmp (destination-unreachable): pass
  icmp (source-quench): pass
  icmp (time-exceeded): pass
  icmp (parameter-problem): pass
  icmp (echo-request): pass

  == IPv6 ==
  Creating 'ufw-check-requirements6'... done
  Inserting RETURN at top of 'ufw-check-requirements6'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: 

[Touch-packages] [Bug 1956043] Re: I need to stop my monitor scree from constant flicking

2021-12-30 Thread Ubuntu Foundations Team Bug Bot
** Package changed: ubuntu => xorg (Ubuntu)

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

Title:
  I need to stop my monitor scree from constant flicking

Status in xorg package in Ubuntu:
  New

Bug description:
  This PC was working normally, in May 17, 2021 at Kennedy Airport
  check-in for a trip to Panama Republic of Panama, I followed the
  commands  of the security personnel to place computer and cell phones
  in a tray for examination.They examined my PC and two cell phone three
  times before returning them to me. After that examination session
  neither my PC nor cell phones could work.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 5.4.0-73.82~18.04.1-generic 5.4.106
  Uname: Linux 5.4.0-73-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.27
  Architecture: amd64
  CompositorRunning: None
  Date: Thu Dec 30 08:17:43 2021
  DistUpgraded: Fresh install
  DistroCodename: bionic
  DistroVariant: ubuntu
  ExtraDebuggingInterest: No
  GraphicsCard:
   NVIDIA Corporation Device [10de:1f51] (rev a1) (prog-if 00 [VGA controller])
 Subsystem: CLEVO/KAPOK Computer Device [1558:7510]
  MachineType: System76 Serval
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-73-generic 
root=UUID=d5244e1e-601c-42de-a015-225055a76c68 ro 
nvidia.NVreg_EnableBacklightHandler=1 quiet splash
  Renderer: Software
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/10/2019
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1.05.25-1
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: Serval
  dmi.board.vendor: System76
  dmi.board.version: serw11
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: System76
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1.05.25-1:bd07/10/2019:svnSystem76:pnServal:pvrserw11:rvnSystem76:rnServal:rvrserw11:cvnSystem76:ct10:cvrN/A:
  dmi.product.family: Not Applicable
  dmi.product.name: Serval
  dmi.product.sku: Not Applicable
  dmi.product.version: serw11
  dmi.sys.vendor: System76
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.99-1ubuntu1~18.04.2
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.8-0ubuntu0~18.04.2
  version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.8-0ubuntu0~18.04.2
  version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.10
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
  xserver.bootTime: Wed Dec 29 15:03:36 2021
  xserver.configfile: default
  xserver.errors:
   [drm] Failed to open DRM device for pci::01:00.0: -19
   open /dev/dri/card0: No such file or directory
   open /dev/dri/card0: No such file or directory
   Screen 0 deleted because of no matching config section.
   AIGLX: reverting to software rendering
  xserver.logfile: /var/log/Xorg.0.log
  xserver.outputs:
   
  xserver.version: 2:1.19.6-1ubuntu4.9

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1956043/+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 1956043] [NEW] I need to stop my monitor scree from constant flicking

2021-12-30 Thread Launchpad Bug Tracker
You have been subscribed to a public bug:

This PC was working normally, in May 17, 2021 at Kennedy Airport check-
in for a trip to Panama Republic of Panama, I followed the commands  of
the security personnel to place computer and cell phones in a tray for
examination.They examined my PC and two cell phone three times before
returning them to me. After that examination session neither my PC nor
cell phones could work.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 5.4.0-73.82~18.04.1-generic 5.4.106
Uname: Linux 5.4.0-73-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.27
Architecture: amd64
CompositorRunning: None
Date: Thu Dec 30 08:17:43 2021
DistUpgraded: Fresh install
DistroCodename: bionic
DistroVariant: ubuntu
ExtraDebuggingInterest: No
GraphicsCard:
 NVIDIA Corporation Device [10de:1f51] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: CLEVO/KAPOK Computer Device [1558:7510]
MachineType: System76 Serval
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-73-generic 
root=UUID=d5244e1e-601c-42de-a015-225055a76c68 ro 
nvidia.NVreg_EnableBacklightHandler=1 quiet splash
Renderer: Software
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/10/2019
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1.05.25-1
dmi.board.asset.tag: Tag 12345
dmi.board.name: Serval
dmi.board.vendor: System76
dmi.board.version: serw11
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: System76
dmi.chassis.version: N/A
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1.05.25-1:bd07/10/2019:svnSystem76:pnServal:pvrserw11:rvnSystem76:rnServal:rvrserw11:cvnSystem76:ct10:cvrN/A:
dmi.product.family: Not Applicable
dmi.product.name: Serval
dmi.product.sku: Not Applicable
dmi.product.version: serw11
dmi.sys.vendor: System76
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.99-1ubuntu1~18.04.2
version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.8-0ubuntu0~18.04.2
version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.8-0ubuntu0~18.04.2
version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.10
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
xserver.bootTime: Wed Dec 29 15:03:36 2021
xserver.configfile: default
xserver.errors:
 [drm] Failed to open DRM device for pci::01:00.0: -19
 open /dev/dri/card0: No such file or directory
 open /dev/dri/card0: No such file or directory
 Screen 0 deleted because of no matching config section.
 AIGLX: reverting to software rendering
xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 
xserver.version: 2:1.19.6-1ubuntu4.9

** Affects: xorg (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic ubuntu
-- 
I need to stop my monitor scree from constant flicking
https://bugs.launchpad.net/bugs/1956043
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to xorg in Ubuntu.

-- 
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 1915238] Re: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ

2021-12-30 Thread Bug Watch Updater
** Changed in: postfix (Debian)
   Status: Incomplete => Fix Committed

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

Title:
  warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and
  /etc/ssl/certs/ca-certificates.crt differ

Status in ca-certificates package in Ubuntu:
  Invalid
Status in postfix package in Ubuntu:
  Triaged
Status in postfix package in Debian:
  Fix Committed

Bug description:
  Postfix package doesn't utilize update-ca-certificate's hooks
  mechanism. By simply copying certs from /etc/ssl/certs/ca-
  certificates.crt to /var/spool/postfix/etc/ssl/certs/ca-
  certificates.crt, this warning and potential security issues could be
  avoided.

  Something like this would be a start:

  $ cat /etc/ca-certificates/update.d/postfix 
  #!/bin/bash

  if [ -e /var/spool/postfix/etc/ssl/certs/ca-certificates.crt ]; then
  echo "Updating postfix chrooted certs"
  cp /etc/ssl/certs/ca-certificates.crt 
/var/spool/postfix/etc/ssl/certs/ca-certificates.crt
  systemctl reload postfix
  fi

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1915238/+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 1956029] Re: ufw remains inactive at boot time

2021-12-30 Thread Myron Szymanskyj
root@loki:/home/myron# journalctl -u ufw.service
-- Logs begin at Wed 2021-12-29 15:30:45 GMT, end at Thu 2021-12-30 13:10:27 
GMT. --
-- No entries --

-

Current status of service. ufw was enabled manually so is actually
active. It won't be once I reboot.

root@loki:/home/myron# systemctl status ufw
‚óŹ ufw.service - Uncomplicated firewall
 Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: 
enabled)
 Active: active (exited) since Wed 2021-12-29 15:30:34 GMT; 21h ago
   Docs: man:ufw(8)
   Main PID: 295 (code=exited, status=0/SUCCESS)
  Tasks: 0 (limit: 4915)
 Memory: 0B
 CGroup: /system.slice/ufw.service

Warning: journal has been rotated since unit was started, output may be
incomplete.

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

Title:
  ufw remains inactive at boot time

Status in ufw package in Ubuntu:
  New

Bug description:
  I was advised to start a bug report (Comment 38):
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856

  I "ufw enable" then several seconds later networking stops. I have get
  Ubuntu to gracefully power-down using the power-button and then
  gracefully power-up.

  Out of curiosity, is anyone here having this problem wish ufw starting
  up at boot time while also using having fail2ban installed?

  Here is my theory. It takes a while for fail2ban to issue all the
  iptable commands to configure the firewall. When ufw tries to
  initialise there may be a clash or lock held either by an iptables
  instance spawned by fail2ban or an iptables instance spawned by ufw.
  One of them will fail and will quite probably mess-up ufw's rules
  breaking network connectivity.

  This time I waited for fail2ban to finish establishing its iptables
  rules before issuing "ufw enable" and this time round network
  connectivity was not lost.

  How to I ensure that ufw is fully up and initialised BEFORE the
  fail2ban service starts?

  -
  root@loki:~# ./ufw-diag.sh
  Has python: pass (binary: python3, version: 3.8.10, py3)
  Has iptables: pass
  Has ip6tables: pass

  Has /proc/net/dev: pass
  Has /proc/net/if_inet6: pass

  This script will now attempt to create various rules using the iptables
  and ip6tables commands. This may result in module autoloading (eg, for
  IPv6).
  Proceed with checks (Y/n)?
  == IPv4 ==
  Creating 'ufw-check-requirements'... done
  Inserting RETURN at top of 'ufw-check-requirements'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  addrtype (LOCAL): pass
  addrtype (MULTICAST): pass
  addrtype (BROADCAST): pass
  icmp (destination-unreachable): pass
  icmp (source-quench): pass
  icmp (time-exceeded): pass
  icmp (parameter-problem): pass
  icmp (echo-request): pass

  == IPv6 ==
  Creating 'ufw-check-requirements6'... done
  Inserting RETURN at top of 'ufw-check-requirements6'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  icmpv6 (destination-unreachable): pass
  icmpv6 (packet-too-big): pass
  icmpv6 (time-exceeded): pass
  icmpv6 (parameter-problem): pass
  icmpv6 (echo-request): pass
  icmpv6 with hl (neighbor-solicitation): pass
  icmpv6 with hl (neighbor-advertisement): pass
  icmpv6 with hl (router-solicitation): pass
  icmpv6 with hl (router-advertisement): pass
  ipv6 rt: pass

  All tests passed
  -
  root@loki:/lib/systemd/system# cat ufw.service
  [Unit]
  Description=Uncomplicated firewall
  Documentation=man:ufw(8)
  DefaultDependencies=no
  Before=network.target
  After=NetworkManager.service

  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/lib/ufw/ufw-init start quiet
  # ExecStartPost=/bin/sleep 10
  ExecStop=/lib/ufw/ufw-init stop

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/lib/systemd/system# cat fail2ban.service
  [Unit]
  Description=Fail2Ban Service
  Documentation=man:fail2ban(1)
  After=network.target iptables.service firewalld.service ip6tables.service 
ipset.service nftables.service ufw.service
  PartOf=firewalld.service

  [Service]
  Type=simple
  ExecStartPre=/bin/mkdir -p /run/fail2ban
  

[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time

2021-12-30 Thread Myron Szymanskyj
** Description changed:

- I was advised to start a bug report:
- https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/comments/38
+ I was advised to start a bug report (Comment 38):
+ https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856
  
  I "ufw enable" then several seconds later networking stops. I have get
  Ubuntu to gracefully power-down using the power-button and then
  gracefully power-up.
  
  Out of curiosity, is anyone here having this problem wish ufw starting
  up at boot time while also using having fail2ban installed?
  
  Here is my theory. It takes a while for fail2ban to issue all the
  iptable commands to configure the firewall. When ufw tries to initialise
  there may be a clash or lock held either by an iptables instance spawned
  by fail2ban or an iptables instance spawned by ufw. One of them will
  fail and will quite probably mess-up ufw's rules breaking network
  connectivity.
  
  This time I waited for fail2ban to finish establishing its iptables
  rules before issuing "ufw enable" and this time round network
  connectivity was not lost.
  
  How to I ensure that ufw is fully up and initialised BEFORE the fail2ban
  service starts?
  
  -
  root@loki:~# ./ufw-diag.sh
  Has python: pass (binary: python3, version: 3.8.10, py3)
  Has iptables: pass
  Has ip6tables: pass
  
  Has /proc/net/dev: pass
  Has /proc/net/if_inet6: pass
  
  This script will now attempt to create various rules using the iptables
  and ip6tables commands. This may result in module autoloading (eg, for
  IPv6).
  Proceed with checks (Y/n)?
  == IPv4 ==
  Creating 'ufw-check-requirements'... done
  Inserting RETURN at top of 'ufw-check-requirements'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  addrtype (LOCAL): pass
  addrtype (MULTICAST): pass
  addrtype (BROADCAST): pass
  icmp (destination-unreachable): pass
  icmp (source-quench): pass
  icmp (time-exceeded): pass
  icmp (parameter-problem): pass
  icmp (echo-request): pass
  
  == IPv6 ==
  Creating 'ufw-check-requirements6'... done
  Inserting RETURN at top of 'ufw-check-requirements6'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  icmpv6 (destination-unreachable): pass
  icmpv6 (packet-too-big): pass
  icmpv6 (time-exceeded): pass
  icmpv6 (parameter-problem): pass
  icmpv6 (echo-request): pass
  icmpv6 with hl (neighbor-solicitation): pass
  icmpv6 with hl (neighbor-advertisement): pass
  icmpv6 with hl (router-solicitation): pass
  icmpv6 with hl (router-advertisement): pass
  ipv6 rt: pass
  
  All tests passed
  -
  root@loki:/lib/systemd/system# cat ufw.service
  [Unit]
  Description=Uncomplicated firewall
  Documentation=man:ufw(8)
  DefaultDependencies=no
  Before=network.target
  After=NetworkManager.service
  
  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/lib/ufw/ufw-init start quiet
  # ExecStartPost=/bin/sleep 10
  ExecStop=/lib/ufw/ufw-init stop
  
  [Install]
  WantedBy=multi-user.target
  
  -
  root@loki:/lib/systemd/system# cat fail2ban.service
  [Unit]
  Description=Fail2Ban Service
  Documentation=man:fail2ban(1)
  After=network.target iptables.service firewalld.service ip6tables.service 
ipset.service nftables.service ufw.service
  PartOf=firewalld.service
  
  [Service]
  Type=simple
  ExecStartPre=/bin/mkdir -p /run/fail2ban
  ExecStart=/usr/bin/fail2ban-server -xf start
  # if should be logged in systemd journal, use following line or set logtarget 
to sysout in fail2ban.local
  # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start
  ExecStop=/usr/bin/fail2ban-client stop
  ExecReload=/usr/bin/fail2ban-client reload
  PIDFile=/run/fail2ban/fail2ban.pid
  Restart=on-failure
  RestartPreventExitStatus=0 255
  
  [Install]
  WantedBy=multi-user.target
  
  -
  root@loki:/etc/default# cat ufw
  # /etc/default/ufw
  #
  
  # Set to yes to apply rules to support IPv6 (no means only IPv6 on loopback
  # accepted). You will need to 'disable' and then 'enable' the firewall for
  # the changes to take affect.
  IPV6=yes
  
  # Set the default input policy to ACCEPT, DROP, or REJECT. Please note that if
  # you change this you will most likely want to adjust your rules.
  

[Touch-packages] [Bug 1939455] Re: Upgrading from 20.0.4-2ubuntu1 to 21.0.3-0ubuntu0.2~20.04.1 breaks vlc video output

2021-12-30 Thread Tony Smith
For the benefit of others I had a similar problem with Kaffeine 2.0.18
on Lubuntu 20.04.3, no video with DVB-T broadcast and only audio
working. The upgrade to 21.0.3 broke a system that was stable for about
a year. Also Kaffeine will crash changing channels. Running Kaffeine
from command prompt shows unable to decode video messages type messages.
Finally tracked down this ticket and down leveling to 20.0.4 solved
problem.

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

Title:
  Upgrading from 20.0.4-2ubuntu1 to 21.0.3-0ubuntu0.2~20.04.1 breaks vlc
  video output

Status in mesa package in Ubuntu:
  New

Bug description:
  Hello!

  As reported here
  https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1939447 upgrading
  mesa-vdpau-drivers package from 20.0.4-2ubuntu1 to
  21.0.3-0ubuntu0.2~20.04.1 breaks vlc video hardware acceleration.

  Thanks!

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: mesa-vdpau-drivers 21.0.3-0ubuntu0.2~20.04.1
  ProcVersionSignature: Ubuntu 5.4.0-80.90-generic 5.4.124
  Uname: Linux 5.4.0-80-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: XFCE
  Date: Wed Aug 11 02:21:08 2021
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R4/R5 Graphics] 
[1002:9851] (rev 40) (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company Mullins [Radeon R4/R5 Graphics] 
[103c:81e5]
  MachineType: HP HP 245 G5 Notebook PC
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-80-generic 
root=UUID=e8820090-c9e5-4245-bcb4-92818bd91e34 ro quiet splash vt.handoff=7
  SourcePackage: mesa
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/21/2016
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.08
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: 81E5
  dmi.board.vendor: HP
  dmi.board.version: KBC Version 73.14
  dmi.chassis.asset.tag: Chassis Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnInsyde:bvrF.08:bd04/21/2016:svnHP:pnHP245G5NotebookPC:pvrType1ProductConfigId:rvnHP:rn81E5:rvrKBCVersion73.14:cvnHP:ct10:cvrChassisVersion:
  dmi.product.family: 103C_5336AN G=N L=SMB B=HP S=245
  dmi.product.name: HP 245 G5 Notebook PC
  dmi.product.sku: Y9Q66PC#ACJ
  dmi.product.version: Type1ProductConfigId
  dmi.sys.vendor: HP
  modified.conffile..etc.default.apport:
   # set this to 0 to disable apport, or to 1 to enable it
   # you can temporarily override this with
   # sudo service apport start force_start=1
   enabled=0
  mtime.conffile..etc.default.apport: 2020-08-12T15:11:08.785042
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.105-3~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.3-0ubuntu0.2~20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-1ubuntu1~20.04.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1939455/+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 1956039] [NEW] BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018)

2021-12-30 Thread Heinrich Schuchardt
Public bug reported:

Updating Jammy fails with:

Get:2 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB] 
Err:2 http://archive.ubuntu.com/ubuntu jammy InRelease
  The following signatures were invalid: BADSIG 871920D1991BC93C Ubuntu Archive 
Automatic Signing Key (2018) 

** Affects: apt (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018)
  

Status in apt package in Ubuntu:
  New

Bug description:
  Updating Jammy fails with:

  Get:2 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB] 
  Err:2 http://archive.ubuntu.com/ubuntu jammy InRelease
The following signatures were invalid: BADSIG 871920D1991BC93C Ubuntu 
Archive Automatic Signing Key (2018) 

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1956039/+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 1726856] Re: ufw does not start automatically at boot

2021-12-30 Thread Myron Szymanskyj
@jdstrand I've created a new bug report as you suggested:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029

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

Title:
  ufw does not start automatically at boot

Status in ufw:
  Invalid
Status in ufw package in Ubuntu:
  Fix Released
Status in ufw source package in Xenial:
  Invalid
Status in ufw source package in Bionic:
  Invalid
Status in ufw source package in Cosmic:
  Invalid
Status in ufw source package in Disco:
  Invalid

Bug description:
  Whenever I boot into 17.10 ufw is always inactive, even though
  /etc/ufw/ufw.conf has this:

  # Set to yes to start on boot. If setting this remotely, be sure to add a rule
  # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
  ENABLED=yes

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ufw 0.35-5
  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
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 13:56:40 2017
  InstallationDate: Installed on 2015-04-01 (936 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago)
  mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1726856/+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 1956029] Re: ufw remains inactive at boot time

2021-12-30 Thread Myron Szymanskyj
** Summary changed:

- ufw does not activate at boot time
+ ufw remains inactive at boot time

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

Title:
  ufw remains inactive at boot time

Status in ufw package in Ubuntu:
  New

Bug description:
  I was advised to start a bug report:
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/comments/38

  I "ufw enable" then several seconds later networking stops. I have get
  Ubuntu to gracefully power-down using the power-button and then
  gracefully power-up.

  Out of curiosity, is anyone here having this problem wish ufw starting
  up at boot time while also using having fail2ban installed?

  Here is my theory. It takes a while for fail2ban to issue all the
  iptable commands to configure the firewall. When ufw tries to
  initialise there may be a clash or lock held either by an iptables
  instance spawned by fail2ban or an iptables instance spawned by ufw.
  One of them will fail and will quite probably mess-up ufw's rules
  breaking network connectivity.

  This time I waited for fail2ban to finish establishing its iptables
  rules before issuing "ufw enable" and this time round network
  connectivity was not lost.

  How to I ensure that ufw is fully up and initialised BEFORE the
  fail2ban service starts?

  -
  root@loki:~# ./ufw-diag.sh
  Has python: pass (binary: python3, version: 3.8.10, py3)
  Has iptables: pass
  Has ip6tables: pass

  Has /proc/net/dev: pass
  Has /proc/net/if_inet6: pass

  This script will now attempt to create various rules using the iptables
  and ip6tables commands. This may result in module autoloading (eg, for
  IPv6).
  Proceed with checks (Y/n)?
  == IPv4 ==
  Creating 'ufw-check-requirements'... done
  Inserting RETURN at top of 'ufw-check-requirements'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  addrtype (LOCAL): pass
  addrtype (MULTICAST): pass
  addrtype (BROADCAST): pass
  icmp (destination-unreachable): pass
  icmp (source-quench): pass
  icmp (time-exceeded): pass
  icmp (parameter-problem): pass
  icmp (echo-request): pass

  == IPv6 ==
  Creating 'ufw-check-requirements6'... done
  Inserting RETURN at top of 'ufw-check-requirements6'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  icmpv6 (destination-unreachable): pass
  icmpv6 (packet-too-big): pass
  icmpv6 (time-exceeded): pass
  icmpv6 (parameter-problem): pass
  icmpv6 (echo-request): pass
  icmpv6 with hl (neighbor-solicitation): pass
  icmpv6 with hl (neighbor-advertisement): pass
  icmpv6 with hl (router-solicitation): pass
  icmpv6 with hl (router-advertisement): pass
  ipv6 rt: pass

  All tests passed
  -
  root@loki:/lib/systemd/system# cat ufw.service
  [Unit]
  Description=Uncomplicated firewall
  Documentation=man:ufw(8)
  DefaultDependencies=no
  Before=network.target
  After=NetworkManager.service

  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/lib/ufw/ufw-init start quiet
  # ExecStartPost=/bin/sleep 10
  ExecStop=/lib/ufw/ufw-init stop

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/lib/systemd/system# cat fail2ban.service
  [Unit]
  Description=Fail2Ban Service
  Documentation=man:fail2ban(1)
  After=network.target iptables.service firewalld.service ip6tables.service 
ipset.service nftables.service ufw.service
  PartOf=firewalld.service

  [Service]
  Type=simple
  ExecStartPre=/bin/mkdir -p /run/fail2ban
  ExecStart=/usr/bin/fail2ban-server -xf start
  # if should be logged in systemd journal, use following line or set logtarget 
to sysout in fail2ban.local
  # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start
  ExecStop=/usr/bin/fail2ban-client stop
  ExecReload=/usr/bin/fail2ban-client reload
  PIDFile=/run/fail2ban/fail2ban.pid
  Restart=on-failure
  RestartPreventExitStatus=0 255

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/etc/default# cat ufw
  # /etc/default/ufw
  #

  # Set to yes to apply rules to support IPv6 (no means only IPv6 on loopback
  # accepted). You will need to 'disable' and then 'enable' the firewall for
  # 

[Touch-packages] [Bug 1956029] [NEW] ufw does not activate at boot time

2021-12-30 Thread Myron Szymanskyj
Public bug reported:

I was advised to start a bug report:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/comments/38

I "ufw enable" then several seconds later networking stops. I have get
Ubuntu to gracefully power-down using the power-button and then
gracefully power-up.

Out of curiosity, is anyone here having this problem wish ufw starting
up at boot time while also using having fail2ban installed?

Here is my theory. It takes a while for fail2ban to issue all the
iptable commands to configure the firewall. When ufw tries to initialise
there may be a clash or lock held either by an iptables instance spawned
by fail2ban or an iptables instance spawned by ufw. One of them will
fail and will quite probably mess-up ufw's rules breaking network
connectivity.

This time I waited for fail2ban to finish establishing its iptables
rules before issuing "ufw enable" and this time round network
connectivity was not lost.

How to I ensure that ufw is fully up and initialised BEFORE the fail2ban
service starts?

-
root@loki:~# ./ufw-diag.sh
Has python: pass (binary: python3, version: 3.8.10, py3)
Has iptables: pass
Has ip6tables: pass

Has /proc/net/dev: pass
Has /proc/net/if_inet6: pass

This script will now attempt to create various rules using the iptables
and ip6tables commands. This may result in module autoloading (eg, for
IPv6).
Proceed with checks (Y/n)?
== IPv4 ==
Creating 'ufw-check-requirements'... done
Inserting RETURN at top of 'ufw-check-requirements'... done
TCP: pass
UDP: pass
destination port: pass
source port: pass
ACCEPT: pass
DROP: pass
REJECT: pass
LOG: pass
hashlimit: pass
limit: pass
ctstate (NEW): pass
ctstate (RELATED): pass
ctstate (ESTABLISHED): pass
ctstate (INVALID): pass
ctstate (new, recent set): pass
ctstate (new, recent update): pass
ctstate (new, limit): pass
interface (input): pass
interface (output): pass
multiport: pass
comment: pass
addrtype (LOCAL): pass
addrtype (MULTICAST): pass
addrtype (BROADCAST): pass
icmp (destination-unreachable): pass
icmp (source-quench): pass
icmp (time-exceeded): pass
icmp (parameter-problem): pass
icmp (echo-request): pass

== IPv6 ==
Creating 'ufw-check-requirements6'... done
Inserting RETURN at top of 'ufw-check-requirements6'... done
TCP: pass
UDP: pass
destination port: pass
source port: pass
ACCEPT: pass
DROP: pass
REJECT: pass
LOG: pass
hashlimit: pass
limit: pass
ctstate (NEW): pass
ctstate (RELATED): pass
ctstate (ESTABLISHED): pass
ctstate (INVALID): pass
ctstate (new, recent set): pass
ctstate (new, recent update): pass
ctstate (new, limit): pass
interface (input): pass
interface (output): pass
multiport: pass
comment: pass
icmpv6 (destination-unreachable): pass
icmpv6 (packet-too-big): pass
icmpv6 (time-exceeded): pass
icmpv6 (parameter-problem): pass
icmpv6 (echo-request): pass
icmpv6 with hl (neighbor-solicitation): pass
icmpv6 with hl (neighbor-advertisement): pass
icmpv6 with hl (router-solicitation): pass
icmpv6 with hl (router-advertisement): pass
ipv6 rt: pass

All tests passed
-
root@loki:/lib/systemd/system# cat ufw.service
[Unit]
Description=Uncomplicated firewall
Documentation=man:ufw(8)
DefaultDependencies=no
Before=network.target
After=NetworkManager.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/ufw/ufw-init start quiet
# ExecStartPost=/bin/sleep 10
ExecStop=/lib/ufw/ufw-init stop

[Install]
WantedBy=multi-user.target

-
root@loki:/lib/systemd/system# cat fail2ban.service
[Unit]
Description=Fail2Ban Service
Documentation=man:fail2ban(1)
After=network.target iptables.service firewalld.service ip6tables.service 
ipset.service nftables.service ufw.service
PartOf=firewalld.service

[Service]
Type=simple
ExecStartPre=/bin/mkdir -p /run/fail2ban
ExecStart=/usr/bin/fail2ban-server -xf start
# if should be logged in systemd journal, use following line or set logtarget 
to sysout in fail2ban.local
# ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start
ExecStop=/usr/bin/fail2ban-client stop
ExecReload=/usr/bin/fail2ban-client reload
PIDFile=/run/fail2ban/fail2ban.pid
Restart=on-failure
RestartPreventExitStatus=0 255

[Install]
WantedBy=multi-user.target

-
root@loki:/etc/default# cat ufw
# /etc/default/ufw
#

# Set to yes to apply rules to support IPv6 (no means only IPv6 on loopback
# accepted). You will need to 'disable' and then 'enable' the firewall for
# the changes to take affect.
IPV6=yes

# Set the default input policy to ACCEPT, DROP, or REJECT. Please note that if
# you change this you will most likely want to adjust your rules.
DEFAULT_INPUT_POLICY="DROP"

# Set the default output policy to ACCEPT, DROP, or REJECT. Please note that if
# you change this you will most likely want to adjust your rules.
DEFAULT_OUTPUT_POLICY="ACCEPT"

# Set the default forward policy to ACCEPT, DROP or REJECT.  Please note that
# if you change this you will most likely want to adjust your rules
DEFAULT_FORWARD_POLICY="DROP"

# Set the default application policy to ACCEPT, DROP, REJECT