[Touch-packages] [Bug 1843394] Re: FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1 / binutils 2.32.51.20190905-0ubuntu1

2019-09-12 Thread Christian Ehrhardt 
Quoting a post of a ipxe related developer that did a nice check
realizing that e.g. disassembly always lists pushq (and opcode stays the
same) - thanks to Valentine for these checks!:


AFAIU, segment registers
are 16-bit long, however, "pushl" and "pushq" should also be valid and
produce the same opcode.

Quite interesting that obdump -S always shows "pushq" even when
"push" or "pushl" is used in the original source.

Please, take a look at the following log:

user@ubuntu19.10:/tmp$ cat push.S
 push %gs
 push %fs
user@ubuntu19.10:/tmp$ as --64 push.S -o push.out
user@ubuntu19.10:/tmp$ objdump -S push.out

push.out: file format elf64-x86-64


Disassembly of section .text:

 <.text>:
   0:   0f a8   pushq  %gs
   2:   0f a0   pushq  %fs
user@ubuntu19.10:/tmp$ cat pushl.S
 pushl %gs
 pushl %fs
user@ubuntu19.10:/tmp$ as --64 pushl.S -o pushl.out
user@ubuntu19.10:/tmp$ objdump -S pushl.out

pushl.out: file format elf64-x86-64


Disassembly of section .text:

 <.text>:
   0:   0f a8   pushq  %gs
   2:   0f a0   pushq  %fs
user@ubuntu19.10:/tmp$ cat pushq.S
 pushq %gs
 pushq %fs
user@ubuntu19.10:/tmp$ as --64 pushq.S -o pushq.out
pushq.S: Assembler messages:
pushq.S:1: Error: operand type mismatch for `push'
pushq.S:2: Error: operand type mismatch for `push'

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

Title:
  FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1 /
  binutils 2.32.51.20190905-0ubuntu1

Status in binutils package in Ubuntu:
  New
Status in ipxe package in Ubuntu:
  New

Bug description:
  This might be due to new gcc-9 being more strict, but the build that
  worked before now fails with:

  arch/x86_64/core/gdbidt.S: Assembler messages:
  arch/x86_64/core/gdbidt.S:109: Error: operand type mismatch for `push'
  arch/x86_64/core/gdbidt.S:110: Error: operand type mismatch for `push'
  arch/x86_64/core/gdbidt.S:161: Error: operand type mismatch for `pop'
  arch/x86_64/core/gdbidt.S:162: Error: operand type mismatch for `pop'
  make[2]: *** [Makefile.housekeeping:937: bin-x86_64-efi/gdbidt.o] Error 1

  Full log at: https://launchpadlibrarian.net/441262285/buildlog_ubuntu-
  eoan-amd64.ipxe_1.0.0+git-20190109.133f4c4-0ubuntu2_BUILDING.txt.gz

  Now all of this is about push/pop of %fs and %gs.
  That needs to match the size of the registers which depend on the current 
running mode.

  In this particular case in ./src/arch/x86_64/core/gdbidt.S
  The failing file is in ".code64" mode.
  In that I'd expect %gs/%fs to be 64 bit.

  
  Usually we see push/pop "w" in .code16 (word), l in .code32 (long) but in 
that sense here q (quad word) seems right at first (should be what correctly 
matches the .code64).
  That matches what I see throughout the ipxe code but also throughout the 
archive 
https://codesearch.debian.net/search?q=pop%5Ba-z%5D.*%25fs=0=2

  Maybe I misread the mode it is in, or it is actually a false positives.
  Or the sizes of FS/GS do not change - haven't touched them in a lng time.
  Was it that segment registers didn't change size?
  I'll need to do a few checks to first see what the compiler would expect 
there and from there need to understand this.

  The command used also points to AS being in 64 bit mode when this happens:
  gcc -E  -DARCH=x86_64 -DPLATFORM=efi -DSECUREBOOT=0 -fstrength-reduce 
-fomit-frame-pointer -falign-jumps=1 -falign-loops=1 -falign-functions=1 -m64 
-mno-mmx -mno-sse -fshort-wchar -Ui386 -Ulinux -DNVALGRIND -fpie -mno-red-zone 
-Iinclude -I. -Iarch/x86/include -Iarch/x86_64/include 
-Iarch/x86_64/include/efi -Os -g -ffreestanding -Wall -W -Wformat-nonliteral  
-fno-stack-protector -fno-dwarf2-cfi-asm -fno-exceptions  -fno-unwind-tables 
-fno-asynchronous-unwind-tables -Wno-address -Wno-stringop-truncation   
-ffunction-sections -fdata-sections -include include/compiler.h -DASM_TCHAR='@' 
-DASM_TCHAR_OPS='@' -DASSEMBLY  -DOBJECT=gdbidt arch/x86_64/core/gdbidt.S | as  
--64-o bin-x86_64-efi/gdbidt.o

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1843394/+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 1843394] Re: FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1 / binutils 2.32.51.20190905-0ubuntu1

2019-09-12 Thread Christian Ehrhardt 
FYI: The comparison to Fedora (there it still works) uses binutils
2.31.1-29.fc30.x86_64 still.

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

Title:
  FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1 /
  binutils 2.32.51.20190905-0ubuntu1

Status in binutils package in Ubuntu:
  New
Status in ipxe package in Ubuntu:
  New

Bug description:
  This might be due to new gcc-9 being more strict, but the build that
  worked before now fails with:

  arch/x86_64/core/gdbidt.S: Assembler messages:
  arch/x86_64/core/gdbidt.S:109: Error: operand type mismatch for `push'
  arch/x86_64/core/gdbidt.S:110: Error: operand type mismatch for `push'
  arch/x86_64/core/gdbidt.S:161: Error: operand type mismatch for `pop'
  arch/x86_64/core/gdbidt.S:162: Error: operand type mismatch for `pop'
  make[2]: *** [Makefile.housekeeping:937: bin-x86_64-efi/gdbidt.o] Error 1

  Full log at: https://launchpadlibrarian.net/441262285/buildlog_ubuntu-
  eoan-amd64.ipxe_1.0.0+git-20190109.133f4c4-0ubuntu2_BUILDING.txt.gz

  Now all of this is about push/pop of %fs and %gs.
  That needs to match the size of the registers which depend on the current 
running mode.

  In this particular case in ./src/arch/x86_64/core/gdbidt.S
  The failing file is in ".code64" mode.
  In that I'd expect %gs/%fs to be 64 bit.

  
  Usually we see push/pop "w" in .code16 (word), l in .code32 (long) but in 
that sense here q (quad word) seems right at first (should be what correctly 
matches the .code64).
  That matches what I see throughout the ipxe code but also throughout the 
archive 
https://codesearch.debian.net/search?q=pop%5Ba-z%5D.*%25fs=0=2

  Maybe I misread the mode it is in, or it is actually a false positives.
  Or the sizes of FS/GS do not change - haven't touched them in a lng time.
  Was it that segment registers didn't change size?
  I'll need to do a few checks to first see what the compiler would expect 
there and from there need to understand this.

  The command used also points to AS being in 64 bit mode when this happens:
  gcc -E  -DARCH=x86_64 -DPLATFORM=efi -DSECUREBOOT=0 -fstrength-reduce 
-fomit-frame-pointer -falign-jumps=1 -falign-loops=1 -falign-functions=1 -m64 
-mno-mmx -mno-sse -fshort-wchar -Ui386 -Ulinux -DNVALGRIND -fpie -mno-red-zone 
-Iinclude -I. -Iarch/x86/include -Iarch/x86_64/include 
-Iarch/x86_64/include/efi -Os -g -ffreestanding -Wall -W -Wformat-nonliteral  
-fno-stack-protector -fno-dwarf2-cfi-asm -fno-exceptions  -fno-unwind-tables 
-fno-asynchronous-unwind-tables -Wno-address -Wno-stringop-truncation   
-ffunction-sections -fdata-sections -include include/compiler.h -DASM_TCHAR='@' 
-DASM_TCHAR_OPS='@' -DASSEMBLY  -DOBJECT=gdbidt arch/x86_64/core/gdbidt.S | as  
--64-o bin-x86_64-efi/gdbidt.o

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1843394/+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 1336274] Re: HDMI Audio and all other audio disappeared from input sources and output sources in the audio control panel and stereo system is looping between audio is coming and

2019-09-12 Thread Launchpad Bug Tracker
[Expired for pulseaudio (Ubuntu) because there has been no activity for
60 days.]

** Changed in: pulseaudio (Ubuntu)
   Status: Incomplete => Expired

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

Title:
  HDMI Audio and all other audio disappeared from input sources and
  output sources in the audio control panel and stereo system is looping
  between audio is coming and audio is not coming from the computer.

Status in pulseaudio package in Ubuntu:
  Expired

Bug description:
  After I did an update via system update, my system stopped working
  with audio. I then viewed the audio control panel and non of my
  output/input sources appear. I'm assuming that a component that Pulse
  Audio uses has been updated and ether Pulse Audio does not know how to
  communicate with it, or the component was not tested before being
  released. I have not changed any of my hardware configurations, so it
  cannot be a hardware issue. Also using XBMC and I'm guessing XBMC
  backed down to using ASLA, I am able to set HDMI out (which I had to
  change from previous configuration which I'm assuming is because Pulse
  Audio is unable to start) and it works fine until I stop using it for
  awhile. After I stop using it for awhile, I have to reboot the system
  to get XBMC working again.

  The way my stereo system (A Yamaha Receiver) is reacting to this is
  it's showing it has audio coming from the computer one second, then
  the other second it doesn't have audio. I'm assuming this is the
  daemon of Pulse Audio restarting over and over again after it cannot
  start.

  I ran pulse audio in verbose mode to show what module is causing it to
  fail to load, and it is module-systemd-login. The reason it is failing
  to load is "Failed to create session monitor: No space left on device"
  but none of my disks are anywhere near being used up, nor is my ram,
  so I have no idea as to what it could be referring to... Maybe it's
  referring to space in the audio hardware??? I do not know... I have
  attached the logs on here.

  Any help would be useful in getting my audio back, I'm a
  hacker/developer/all around geek who loves the terminal, so please ask
  any questions! Please do feel free to email me, I want my audio back!

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: pulseaudio 1:4.0-0ubuntu11
  ProcVersionSignature: Ubuntu 3.13.0-30.54-generic 3.13.11.2
  Uname: Linux 3.13.0-30-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.2
  Architecture: amd64
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', 
'/dev/snd/controlC1', '/dev/snd/hwC1D0', '/dev/snd/pcmC1D0c', 
'/dev/snd/pcmC1D0p', '/dev/snd/pcmC1D2c', '/dev/snd/controlC0', 
'/dev/snd/hwC0D0', '/dev/snd/pcmC0D3p', '/dev/snd/pcmC0D7p', 
'/dev/snd/pcmC0D8p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
  Date: Tue Jul  1 08:34:09 2014
  InstallationDate: Installed on 2014-05-18 (43 days ago)
  InstallationMedia: It
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  SourcePackage: pulseaudio
  Symptom: audio
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/02/2013
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: V2.4
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: B85-G41 PC Mate(MS-7850)
  dmi.board.vendor: MSI
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: To be filled by O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: MSI
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrV2.4:bd12/02/2013:svnMSI:pnMS-7850:pvr1.0:rvnMSI:rnB85-G41PCMate(MS-7850):rvr1.0:cvnMSI:ct3:cvr1.0:
  dmi.product.name: MS-7850
  dmi.product.version: 1.0
  dmi.sys.vendor: MSI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1336274/+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 1827417] Re: Ubuntu 16.04 - EMU10K1 / CT4832 lost ability to listen stereo on headphones - there is upmixed surround only.

2019-09-12 Thread Launchpad Bug Tracker
[Expired for linux (Ubuntu) because there has been no activity for 60
days.]

** Changed in: linux (Ubuntu)
   Status: Incomplete => Expired

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

Title:
  Ubuntu 16.04 -  EMU10K1 / CT4832 lost ability to listen stereo on
  headphones -  there is upmixed  surround only.

Status in linux package in Ubuntu:
  Expired
Status in pulseaudio package in Ubuntu:
  Expired

Bug description:
  Hello,

  I have a problem - after one of the updates (sorry for being not precise - I 
can only track it back to the time I have been surely listening something on 
headphones - it has to be beginning of this year because last time I have been 
listening more on my SB Live for sure was in last one-two weeks of February 
2019 - I have suddenly lost "stereo" on my headphones.
  I have speakers connected to on-board sound card and headphones connected to 
SB Live Value for few years, so I did not mess with outputs or something - one 
day I changed Audacious output to SbLive in pavucontrol (as usually) and that 
time the sound was weirdly filtered.
  I have found that this must be "surround upmix" which I do not need and tried 
to disable it,
  enable-remixing = no and the same for "LFE remixing" in 
/etc/pulse/daemon.conf did not work.
  It does not matter what configuration I choose in pavucontrol- analog stereo 
duplex, "analog stereo output", "Analog surround 5.1" or 4.1 - for all "Analog 
output" scenarios the output is the same except for "mono" (no sound at all).
  I have tried do "skip" pulseaudio choosing "ALSA" output in Audacious + the 
alsa configuration for stereo but the upmix is still present.

  I have followed the old thread in Launchpad Answers:
  https://answers.launchpad.net/ubuntu/+source/alsa-driver/+question/169428
  =
  Hello,

  i'm on ubuntu 16.04LTS (AMD64, with emu10k1 based soundcard) and since the 
last update I have similar problem - I have lost ability to listen stereo music 
on my Soundblaster Live Value (i use earphones).
  Even system sounds , web browser content and mp3 files are up-mixed.
  Few days ago it was no problem to choose "analag stereo output" in 
pavucontrol, now it seems that at this output have rear surround channel only 
(as I suppose, there is "stereo" but vocals are like heard from the other room 
and there is sometimes reverb as in the bathroom) :/.
  I had tried adding "set enable-remixing=no" in both /etc/pulse/daemon.conf 
and in the home directory configuration file without success.
  I have purged pulseaudio but with the ALSA there is the same problem, I have 
tried purging alsa and reinstalling without effect.
  So i thought that it can be emu10k1 driver specific, after digging in the 
network for solutions I have had tried adding 
"hint.emu10kx.0.multichannel_disabled " to the module configuration file 
without visible (or rather soundible ;) effect.
  I have tried to check EMU10K1 configuration with aweset, but it gives error 
message, so maybe the bad magic sits somewhere around?

  aweset
  /dev/sequencer: No such file or directory

  Once again - everything worked fine until the last update. I use
  xubuntu desktop as my machine is quite old, in despair I have
  installed unity to find the sound settings / speaker configuration etc
  and button to "disable all effects" as I have seen somewhere, but
  there were no such options.

  Help me Obi Wan Kenobi, you're my only hope...
  =

  I have next tried to follow the path from ubuntu sound troubleshooting
  guide, I have purged everything, installed back and now I'm  here
  again with this "upmix" on SBLive! Value.

  Thanks in advance for help :)
  Tom
  --- 
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  CurrentDesktop: XFCE
  DistroRelease: Ubuntu 16.04
  HibernationDevice: RESUME=UUID=654027ee-6ab0-41ba-8537-452da07cda0e
  InstallationDate: Installed on 2011-10-07 (2765 days ago)
  InstallationMedia: Ubuntu 10.04.3 LTS "Lucid Lynx" - Release amd64 
(20110720.1)
  IwConfig:
   lono wireless extensions.
   
   lxcbr0no wireless extensions.
   
   eth0  no wireless extensions.
  MachineType: Gigabyte Technology Co., Ltd. M68MT-S2
  Package: pulseaudio 1:8.0-0ubuntu3.10
  PackageArchitecture: amd64
  ProcFB: 0 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-146-generic 
root=UUID=4559c496-f083-41a2-ad7c-1e03334389fd ro plymouth 
usbcore.autosuspend=-1
  ProcVersionSignature: Ubuntu 4.4.0-146.172-generic 4.4.177
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-146-generic N/A
   linux-backports-modules-4.4.0-146-generic  N/A
   linux-firmware 1.157.21
  RfKill:
   
  Tags: xenial third-party-packages xenial
  Uname: Linux 4.4.0-146-generic x86_64
  

[Touch-packages] [Bug 1827417] Re: Ubuntu 16.04 - EMU10K1 / CT4832 lost ability to listen stereo on headphones - there is upmixed surround only.

2019-09-12 Thread Launchpad Bug Tracker
[Expired for pulseaudio (Ubuntu) because there has been no activity for
60 days.]

** Changed in: pulseaudio (Ubuntu)
   Status: Incomplete => Expired

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

Title:
  Ubuntu 16.04 -  EMU10K1 / CT4832 lost ability to listen stereo on
  headphones -  there is upmixed  surround only.

Status in linux package in Ubuntu:
  Expired
Status in pulseaudio package in Ubuntu:
  Expired

Bug description:
  Hello,

  I have a problem - after one of the updates (sorry for being not precise - I 
can only track it back to the time I have been surely listening something on 
headphones - it has to be beginning of this year because last time I have been 
listening more on my SB Live for sure was in last one-two weeks of February 
2019 - I have suddenly lost "stereo" on my headphones.
  I have speakers connected to on-board sound card and headphones connected to 
SB Live Value for few years, so I did not mess with outputs or something - one 
day I changed Audacious output to SbLive in pavucontrol (as usually) and that 
time the sound was weirdly filtered.
  I have found that this must be "surround upmix" which I do not need and tried 
to disable it,
  enable-remixing = no and the same for "LFE remixing" in 
/etc/pulse/daemon.conf did not work.
  It does not matter what configuration I choose in pavucontrol- analog stereo 
duplex, "analog stereo output", "Analog surround 5.1" or 4.1 - for all "Analog 
output" scenarios the output is the same except for "mono" (no sound at all).
  I have tried do "skip" pulseaudio choosing "ALSA" output in Audacious + the 
alsa configuration for stereo but the upmix is still present.

  I have followed the old thread in Launchpad Answers:
  https://answers.launchpad.net/ubuntu/+source/alsa-driver/+question/169428
  =
  Hello,

  i'm on ubuntu 16.04LTS (AMD64, with emu10k1 based soundcard) and since the 
last update I have similar problem - I have lost ability to listen stereo music 
on my Soundblaster Live Value (i use earphones).
  Even system sounds , web browser content and mp3 files are up-mixed.
  Few days ago it was no problem to choose "analag stereo output" in 
pavucontrol, now it seems that at this output have rear surround channel only 
(as I suppose, there is "stereo" but vocals are like heard from the other room 
and there is sometimes reverb as in the bathroom) :/.
  I had tried adding "set enable-remixing=no" in both /etc/pulse/daemon.conf 
and in the home directory configuration file without success.
  I have purged pulseaudio but with the ALSA there is the same problem, I have 
tried purging alsa and reinstalling without effect.
  So i thought that it can be emu10k1 driver specific, after digging in the 
network for solutions I have had tried adding 
"hint.emu10kx.0.multichannel_disabled " to the module configuration file 
without visible (or rather soundible ;) effect.
  I have tried to check EMU10K1 configuration with aweset, but it gives error 
message, so maybe the bad magic sits somewhere around?

  aweset
  /dev/sequencer: No such file or directory

  Once again - everything worked fine until the last update. I use
  xubuntu desktop as my machine is quite old, in despair I have
  installed unity to find the sound settings / speaker configuration etc
  and button to "disable all effects" as I have seen somewhere, but
  there were no such options.

  Help me Obi Wan Kenobi, you're my only hope...
  =

  I have next tried to follow the path from ubuntu sound troubleshooting
  guide, I have purged everything, installed back and now I'm  here
  again with this "upmix" on SBLive! Value.

  Thanks in advance for help :)
  Tom
  --- 
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  CurrentDesktop: XFCE
  DistroRelease: Ubuntu 16.04
  HibernationDevice: RESUME=UUID=654027ee-6ab0-41ba-8537-452da07cda0e
  InstallationDate: Installed on 2011-10-07 (2765 days ago)
  InstallationMedia: Ubuntu 10.04.3 LTS "Lucid Lynx" - Release amd64 
(20110720.1)
  IwConfig:
   lono wireless extensions.
   
   lxcbr0no wireless extensions.
   
   eth0  no wireless extensions.
  MachineType: Gigabyte Technology Co., Ltd. M68MT-S2
  Package: pulseaudio 1:8.0-0ubuntu3.10
  PackageArchitecture: amd64
  ProcFB: 0 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-146-generic 
root=UUID=4559c496-f083-41a2-ad7c-1e03334389fd ro plymouth 
usbcore.autosuspend=-1
  ProcVersionSignature: Ubuntu 4.4.0-146.172-generic 4.4.177
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-146-generic N/A
   linux-backports-modules-4.4.0-146-generic  N/A
   linux-firmware 1.157.21
  RfKill:
   
  Tags: xenial third-party-packages xenial
  Uname: Linux 4.4.0-146-generic x86_64
 

[Touch-packages] [Bug 1834795] Re: xubuntu ethernet does not reconnect unless computer restarted, after power off/on modem or manually off/on "enable networking"

2019-09-12 Thread Launchpad Bug Tracker
[Expired for network-manager (Ubuntu) because there has been no activity
for 60 days.]

** Changed in: network-manager (Ubuntu)
   Status: Incomplete => Expired

-- 
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/1834795

Title:
  xubuntu ethernet does not reconnect unless computer restarted, after
  power off/on modem or manually off/on "enable networking"

Status in network-manager package in Ubuntu:
  Expired

Bug description:
  Xubuntu 19.04, 64bit, encrypted drive, using a desktop computer with
  ethernet to connect. Connects fine. Use openvpn also (from terminal).
  When the modem is turned off and on, or when the modem remains on but
  the ethernet connection is disabled (by unticking) and then ticking
  again "enable networking" in the applet taskbar, the connection does
  not re-establish. This is irregardless of the vpn, which even if i
  turn off, will not affect the lack of reconnection.

  If i ping bing.com, after trying to reconnect, I get back one
  response, but no multiple responses.

  ping bing.com
  PING bing.com (204.79.197.200) 56(84) bytes of data.

  This is slightly different to no connection being present, as then I
  would not even get back a single ping:

  "ping: bing.com: Temporary failure in name resolution"

  The only way to get a connection back is by restarting the system. And
  then it works fine.

  This is not an issue for ubuntu mate 19.04. The reconnection works
  fine, with no restart required.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1834795/+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 1843857] [NEW] IPMasquerade=yes -> ignored on eoan

2019-09-12 Thread Harry Coin
Public bug reported:

I'm testing out eoan, I have a [Network] section with IPMasquerade=yes.
The system starts without complaint from systemd in the logs, but I see no 
evidence of source natting going on.
I'm not sure of sub-dependencies, but I think source natting depends on 
libiptc-dev, which I don't see among the listings in eoan.

I found Systemd-networkd updates 'iptables-legacy' with the source 
natting/masquerade detail -- which is disused by default.
  
So it has no effect and doesn't throw an error.

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

-- 
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/1843857

Title:
  IPMasquerade=yes -> ignored on eoan

Status in systemd package in Ubuntu:
  New

Bug description:
  I'm testing out eoan, I have a [Network] section with IPMasquerade=yes.
  The system starts without complaint from systemd in the logs, but I see no 
evidence of source natting going on.
  I'm not sure of sub-dependencies, but I think source natting depends on 
libiptc-dev, which I don't see among the listings in eoan.

  I found Systemd-networkd updates 'iptables-legacy' with the source 
natting/masquerade detail -- which is disused by default.

  So it has no effect and doesn't throw an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1843857/+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 1843854] Re: ibus-ui-gtk3 crashed with SIGSEGV in ibus_bus_get_engines_by_names()

2019-09-12 Thread Apport retracing service
*** This bug is a duplicate of bug 1842022 ***
https://bugs.launchpad.net/bugs/1842022

Thank you for taking the time to report this crash and helping to make
this software better.  This particular crash has already been reported
and is a duplicate of bug #1842022, so is being marked as such.  Please
look at the other bug report to see if there is any missing information
that you can provide, or to see if there is a workaround for the bug.
Additionally, any further discussion regarding the bug should occur in
the other report.  Please continue to report any other bugs you may
find.

** Attachment removed: "CoreDump.gz"
   
https://bugs.launchpad.net/bugs/1843854/+attachment/5288419/+files/CoreDump.gz

** Attachment removed: "Disassembly.txt"
   
https://bugs.launchpad.net/bugs/1843854/+attachment/5288421/+files/Disassembly.txt

** Attachment removed: "ProcMaps.txt"
   
https://bugs.launchpad.net/bugs/1843854/+attachment/5288425/+files/ProcMaps.txt

** Attachment removed: "ProcStatus.txt"
   
https://bugs.launchpad.net/bugs/1843854/+attachment/5288426/+files/ProcStatus.txt

** Attachment removed: "Registers.txt"
   
https://bugs.launchpad.net/bugs/1843854/+attachment/5288427/+files/Registers.txt

** Attachment removed: "Stacktrace.txt"
   
https://bugs.launchpad.net/bugs/1843854/+attachment/5288428/+files/Stacktrace.txt

** Attachment removed: "ThreadStacktrace.txt"
   
https://bugs.launchpad.net/bugs/1843854/+attachment/5288429/+files/ThreadStacktrace.txt

** This bug has been marked a duplicate of private bug 1842022

** Information type changed from Private to Public

** Tags removed: need-amd64-retrace

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

Title:
  ibus-ui-gtk3 crashed with SIGSEGV in ibus_bus_get_engines_by_names()

Status in ibus package in Ubuntu:
  New

Bug description:
  ...

  ProblemType: Crash
  DistroRelease: Ubuntu 19.10
  Package: ibus 1.5.19-4ubuntu2
  ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8
  Uname: Linux 5.3.0-10-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep 13 02:40:36 2019
  ExecutablePath: /usr/lib/ibus/ibus-ui-gtk3
  InstallationDate: Installed on 2019-09-13 (0 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190909)
  ProcCmdline: /usr/lib/ibus/ibus-ui-gtk3
  SegvAnalysis:
   Segfault happened at: 0x7fb50345becb : orq
$0x0,(%rsp)
   PC (0x7fb50345becb) ok
   source "$0x0" ok
   destination "(%rsp)" (0x7ffda1a7afc0) not located in a known VMA region 
(needed writable region)!
   Stack memory exhausted (SP below stack segment)
  SegvReason: writing unknown VMA
  Signal: 11
  SourcePackage: ibus
  StacktraceTop:
   ?? () from /lib/x86_64-linux-gnu/libibus-1.0.so.5
   ibus_bus_get_engines_by_names () from /lib/x86_64-linux-gnu/libibus-1.0.so.5
   ?? ()
   ?? ()
   g_cclosure_marshal_VOID__STRINGv () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  Title: ibus-ui-gtk3 crashed with SIGSEGV in ibus_bus_get_engines_by_names()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  separator:

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1843854/+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 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

2019-09-12 Thread Ubuntu Foundations Team Bug Bot
The attachment "eoan 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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1796501

Title:
  systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  In Progress

Bug description:
  I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't 
exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the 
following steps:
  1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size.
  2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit.
  3. Ask upstream for SOA of test.asdf. with EDNS0.
  4. Ask upstream for SOA of test.asdf. without EDNS0.
  5. Repeat 1-4 for DS of test.asdf.
  6. Repeat 1-5 for asdf.
  7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size.
  8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size.

  The upstream returns an unfragmented NXDOMAIN response for steps 1-6,
  an unfragmented NOERROR response for step 7 and a fragmented NOERROR
  response for step 8 which is the correct behaviour. DNSSEC records are
  included in the response if the DO-bit in the request was set.

  systemd-resolved should take the response from step 1 and start with
  validation instead of starting useless retries with reduced feture
  set. Step 3 and 4 are completely useless and probably lead to the
  SERVFAIL because I have configured it with DNSSEC=yes to prevent
  downgrade attacks.

  This regression seems to be caused by the patch resolved-Mitigate-
  DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic
  should only be executed if it is configured as DNSSEC=allow-downgrade
  or DNSSEC=no. See also
  https://github.com/systemd/systemd/pull/8608#issuecomment-396927885.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+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 1843627] Re: evolution-calendar-factory crashed with SIGSEGV in tcache_get()

2019-09-12 Thread Bug Watch Updater
** Changed in: evolution-data-server
   Status: New => Fix Released

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

Title:
  evolution-calendar-factory crashed with SIGSEGV in tcache_get()

Status in evolution-data-server:
  Fix Released
Status in evolution-data-server package in Ubuntu:
  New

Bug description:
  https://gitlab.gnome.org/GNOME/evolution/issues/616

  ---

  I don't know what happened.

  ProblemType: Crash
  DistroRelease: Ubuntu 19.10
  Package: evolution-data-server 3.33.91-3
  ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8
  Uname: Linux 5.3.0-10-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CrashCounter: 1
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Sep 11 13:41:26 2019
  ExecutablePath: /usr/libexec/evolution-calendar-factory
  InstallationDate: Installed on 2018-12-02 (282 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  ProcCmdline: /usr/libexec/evolution-calendar-factory
  ProcEnviron:
   LANG=es_CL.UTF-8
   LANGUAGE=es_CL:es
   PATH=(custom, no user)
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
  SegvAnalysis:
   Segfault happened at: 0x7f36355653ae <__GI___libc_malloc+286>:   mov
(%r8),%rsi
   PC (0x7f36355653ae) ok
   source "(%r8)" (0x7f36) not located in a known VMA region (needed 
readable region)!
   destination "%rsi" ok
   Stack memory exhausted (SP below stack segment)
  SegvReason: reading unknown VMA
  Signal: 11
  SourcePackage: evolution-data-server
  StacktraceTop:
   tcache_get (tc_idx=) at malloc.c:2937
   __GI___libc_malloc (bytes=32) at malloc.c:3051
   g_malloc () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
   g_datalist_id_set_data_full () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
   () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  Title: evolution-calendar-factory crashed with SIGSEGV in tcache_get()
  UpgradeStatus: Upgraded to eoan on 2018-12-02 (282 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  separator:

To manage notifications about this bug go to:
https://bugs.launchpad.net/evolution-data-server/+bug/1843627/+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 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

2019-09-12 Thread Bryan Quigley
Built a eoan package with xnox's updated patch in my ppa:
https://launchpad.net/~bryanquigley/+archive/ubuntu/1796501/+packages

1. Confirm failure with DNSSEC=yes, DNS server 1.1.1.1
$ resolvectl query people.com.cn
people.com.cn: resolve call failed: DNSSEC validation failed: failed-auxiliary

2. Add PPA and upgrade systemd to PPA version.

3. Confirm success:
resolvectl query people.com.cn
people.com.cn: 106.48.12.140   -- link: ens2
   106.48.12.141   -- link: ens2
   (hpcc-download-foreign.chinacache.net)

** Patch added: "eoan debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+attachment/5288416/+files/systemd_241-7ubuntu2.debdiff

-- 
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/1796501

Title:
  systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  In Progress

Bug description:
  I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't 
exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the 
following steps:
  1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size.
  2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit.
  3. Ask upstream for SOA of test.asdf. with EDNS0.
  4. Ask upstream for SOA of test.asdf. without EDNS0.
  5. Repeat 1-4 for DS of test.asdf.
  6. Repeat 1-5 for asdf.
  7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size.
  8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size.

  The upstream returns an unfragmented NXDOMAIN response for steps 1-6,
  an unfragmented NOERROR response for step 7 and a fragmented NOERROR
  response for step 8 which is the correct behaviour. DNSSEC records are
  included in the response if the DO-bit in the request was set.

  systemd-resolved should take the response from step 1 and start with
  validation instead of starting useless retries with reduced feture
  set. Step 3 and 4 are completely useless and probably lead to the
  SERVFAIL because I have configured it with DNSSEC=yes to prevent
  downgrade attacks.

  This regression seems to be caused by the patch resolved-Mitigate-
  DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic
  should only be executed if it is configured as DNSSEC=allow-downgrade
  or DNSSEC=no. See also
  https://github.com/systemd/systemd/pull/8608#issuecomment-396927885.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+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 1843755] Re: [FFe] Please accept systemd 242 to Eoan

2019-09-12 Thread Balint Reczey
@vorlon: You can check in the Bileto ticket that the autopkgtests for
242 are all green (except for a single ostree one).

-- 
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/1843755

Title:
  [FFe] Please accept systemd 242 to Eoan

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing 
moved to 242 last week.
  While version 241 is the safer choice for Eoan (from v241 and v242) since it 
is widely tested updating to v242 will allow us to carry fewer patches in Eoan 
and makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing (except 
for a few unrelated failures):
  https://bileto.ubuntu.com/#/ticket/3797

  The final version will be 242-6ubuntu1 and I'm tidying up the
  changelog, too.

  I plan merging 242-7, too, going forward but this will not need an
  FFe.

  CHANGES WITH 242:

  * In .link files, MACAddressPolicy=persistent (the default) is changed
    to cover more devices. For devices like bridges, tun, tap, bond, and
    similar interfaces that do not have other identifying information,
    the interface name is used as the basis for persistent seed for MAC
    and IPv4LL addresses. The way that devices that were handled
    previously is not changed, and this change is about covering more
    devices then previously by the "persistent" policy.

    MACAddressPolicy=random may be used to force randomized MACs and
    IPv4LL addresses for a device if desired.

    Hint: the log output from udev (at debug level) was enhanced to
    clarify what policy is followed and which attributes are used.
    `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/`
    may be used to view this.

    Hint: if a bridge interface is created without any slaves, and gains
    a slave later, then now the bridge does not inherit slave's MAC.
    To inherit slave's MAC, for example, create the following file:
    ```
    # /etc/systemd/network/98-bridge-inherit-mac.link
    [Match]
    Type=bridge

    [Link]
    MACAddressPolicy=none
    ```

  * The .device units generated by systemd-fstab-generator and other
    generators do not automatically pull in the corresponding .mount 
unit
    as a Wants= dependency. This means that simply plugging in the 
device
    will not cause the mount unit to be started automatically. But 
please
    note that the mount unit may be started for other reasons, in
    particular if it is part of local-fs.target, and any unit which
    (transitively) depends on local-fs.target is started.

  * networkctl list/status/lldp now accept globbing wildcards for 
network
    interface names to match against all existing interfaces.

  * The $PIDFILE environment variable is set to point the absolute path
    configured with PIDFile= for processes of that service.

  * The fallback DNS server list was augmented with Cloudflare public 
DNS
    servers. Use `-Ddns-servers=` to set a different fallback.

  * A new special target usb-gadget.target will be started automatically
    when a USB Device Controller is detected (which means that the 
system
    is a USB peripheral).

  * A new unit setting CPUQuotaPeriodSec= assigns the time period
    relatively to which the CPU time quota specified by CPUQuota= is
    measured.

  * A new unit setting ProtectHostname= may be used to prevent services
    from modifying hostname information (even if they otherwise would
    have privileges to do so).

  * A new unit setting NetworkNamespacePath= may be used to specify a
    namespace for service or socket units through a path referring to a
    Linux network namespace pseudo-file.

  * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now
    have an effect on .socket units: when used the listening socket is
    created within the configured network namespace instead of the host
    namespace.

  * ExecStart= command lines in unit files may now be prefixed with ':'
    in which case environment variable substitution is
    disabled. (Supported for the other ExecXYZ= settings, too.)

  * .timer units gained two new boolean settings OnClockChange= and
    OnTimezoneChange= which may be used to also trigger a unit when the
    system clock is changed or the local timezone is
    modified. systemd-run has been updated to make these options easily
  

[Touch-packages] [Bug 1843755] Re: [FFe] Please accept systemd 242 to Eoan

2019-09-12 Thread Balint Reczey
@vorlon: I got reports against v243 via IRC, too, but those were
expected since autopkgtests were also failing in releated areas.

-- 
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/1843755

Title:
  [FFe] Please accept systemd 242 to Eoan

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing 
moved to 242 last week.
  While version 241 is the safer choice for Eoan (from v241 and v242) since it 
is widely tested updating to v242 will allow us to carry fewer patches in Eoan 
and makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing (except 
for a few unrelated failures):
  https://bileto.ubuntu.com/#/ticket/3797

  The final version will be 242-6ubuntu1 and I'm tidying up the
  changelog, too.

  I plan merging 242-7, too, going forward but this will not need an
  FFe.

  CHANGES WITH 242:

  * In .link files, MACAddressPolicy=persistent (the default) is changed
    to cover more devices. For devices like bridges, tun, tap, bond, and
    similar interfaces that do not have other identifying information,
    the interface name is used as the basis for persistent seed for MAC
    and IPv4LL addresses. The way that devices that were handled
    previously is not changed, and this change is about covering more
    devices then previously by the "persistent" policy.

    MACAddressPolicy=random may be used to force randomized MACs and
    IPv4LL addresses for a device if desired.

    Hint: the log output from udev (at debug level) was enhanced to
    clarify what policy is followed and which attributes are used.
    `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/`
    may be used to view this.

    Hint: if a bridge interface is created without any slaves, and gains
    a slave later, then now the bridge does not inherit slave's MAC.
    To inherit slave's MAC, for example, create the following file:
    ```
    # /etc/systemd/network/98-bridge-inherit-mac.link
    [Match]
    Type=bridge

    [Link]
    MACAddressPolicy=none
    ```

  * The .device units generated by systemd-fstab-generator and other
    generators do not automatically pull in the corresponding .mount 
unit
    as a Wants= dependency. This means that simply plugging in the 
device
    will not cause the mount unit to be started automatically. But 
please
    note that the mount unit may be started for other reasons, in
    particular if it is part of local-fs.target, and any unit which
    (transitively) depends on local-fs.target is started.

  * networkctl list/status/lldp now accept globbing wildcards for 
network
    interface names to match against all existing interfaces.

  * The $PIDFILE environment variable is set to point the absolute path
    configured with PIDFile= for processes of that service.

  * The fallback DNS server list was augmented with Cloudflare public 
DNS
    servers. Use `-Ddns-servers=` to set a different fallback.

  * A new special target usb-gadget.target will be started automatically
    when a USB Device Controller is detected (which means that the 
system
    is a USB peripheral).

  * A new unit setting CPUQuotaPeriodSec= assigns the time period
    relatively to which the CPU time quota specified by CPUQuota= is
    measured.

  * A new unit setting ProtectHostname= may be used to prevent services
    from modifying hostname information (even if they otherwise would
    have privileges to do so).

  * A new unit setting NetworkNamespacePath= may be used to specify a
    namespace for service or socket units through a path referring to a
    Linux network namespace pseudo-file.

  * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now
    have an effect on .socket units: when used the listening socket is
    created within the configured network namespace instead of the host
    namespace.

  * ExecStart= command lines in unit files may now be prefixed with ':'
    in which case environment variable substitution is
    disabled. (Supported for the other ExecXYZ= settings, too.)

  * .timer units gained two new boolean settings OnClockChange= and
    OnTimezoneChange= which may be used to also trigger a unit when the
    system clock is changed or the local timezone is
    modified. systemd-run has been updated to make these options 

[Touch-packages] [Bug 1843755] Re: [FFe] Please accept systemd 242 to Eoan

2019-09-12 Thread Balint Reczey
@vorlon: Those regressions are found in 243 RC1, I'm now preparing 243
final which has new regressions compared to 243 RC1. Many regressions
introduced in 243 were reported to upstream and got fixed in 243 final,
but not all of them.

There were two regression identified in 242 (regressing network-manager
and netplan.io) and I made a minimal revert in 242-6ubuntu1 to avoid
those. So regression-wise 242 seems to be clean as far as we can tell
and I believe regressions introduced at upstream between v242 and v243
are not a factor in deciding on accepting 242, unless you propose going
right to v243, but I would advise against that as it is not ready.

-- 
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/1843755

Title:
  [FFe] Please accept systemd 242 to Eoan

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing 
moved to 242 last week.
  While version 241 is the safer choice for Eoan (from v241 and v242) since it 
is widely tested updating to v242 will allow us to carry fewer patches in Eoan 
and makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing (except 
for a few unrelated failures):
  https://bileto.ubuntu.com/#/ticket/3797

  The final version will be 242-6ubuntu1 and I'm tidying up the
  changelog, too.

  I plan merging 242-7, too, going forward but this will not need an
  FFe.

  CHANGES WITH 242:

  * In .link files, MACAddressPolicy=persistent (the default) is changed
    to cover more devices. For devices like bridges, tun, tap, bond, and
    similar interfaces that do not have other identifying information,
    the interface name is used as the basis for persistent seed for MAC
    and IPv4LL addresses. The way that devices that were handled
    previously is not changed, and this change is about covering more
    devices then previously by the "persistent" policy.

    MACAddressPolicy=random may be used to force randomized MACs and
    IPv4LL addresses for a device if desired.

    Hint: the log output from udev (at debug level) was enhanced to
    clarify what policy is followed and which attributes are used.
    `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/`
    may be used to view this.

    Hint: if a bridge interface is created without any slaves, and gains
    a slave later, then now the bridge does not inherit slave's MAC.
    To inherit slave's MAC, for example, create the following file:
    ```
    # /etc/systemd/network/98-bridge-inherit-mac.link
    [Match]
    Type=bridge

    [Link]
    MACAddressPolicy=none
    ```

  * The .device units generated by systemd-fstab-generator and other
    generators do not automatically pull in the corresponding .mount 
unit
    as a Wants= dependency. This means that simply plugging in the 
device
    will not cause the mount unit to be started automatically. But 
please
    note that the mount unit may be started for other reasons, in
    particular if it is part of local-fs.target, and any unit which
    (transitively) depends on local-fs.target is started.

  * networkctl list/status/lldp now accept globbing wildcards for 
network
    interface names to match against all existing interfaces.

  * The $PIDFILE environment variable is set to point the absolute path
    configured with PIDFile= for processes of that service.

  * The fallback DNS server list was augmented with Cloudflare public 
DNS
    servers. Use `-Ddns-servers=` to set a different fallback.

  * A new special target usb-gadget.target will be started automatically
    when a USB Device Controller is detected (which means that the 
system
    is a USB peripheral).

  * A new unit setting CPUQuotaPeriodSec= assigns the time period
    relatively to which the CPU time quota specified by CPUQuota= is
    measured.

  * A new unit setting ProtectHostname= may be used to prevent services
    from modifying hostname information (even if they otherwise would
    have privileges to do so).

  * A new unit setting NetworkNamespacePath= may be used to specify a
    namespace for service or socket units through a path referring to a
    Linux network namespace pseudo-file.

  * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now
    have an effect on .socket units: when used the listening socket is
    created within the configured network namespace instead of the host
     

[Touch-packages] [Bug 1843755] Re: [FFe] Please accept systemd 242 to Eoan

2019-09-12 Thread Steve Langasek
That bug specifically calls out that 243 was removed because it
introduced regressions upstream.

It is left unclear whether these regressions applied to 242.

Were all of the regressions in 243 identified by way of autopkgtests?

-- 
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/1843755

Title:
  [FFe] Please accept systemd 242 to Eoan

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing 
moved to 242 last week.
  While version 241 is the safer choice for Eoan (from v241 and v242) since it 
is widely tested updating to v242 will allow us to carry fewer patches in Eoan 
and makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing (except 
for a few unrelated failures):
  https://bileto.ubuntu.com/#/ticket/3797

  The final version will be 242-6ubuntu1 and I'm tidying up the
  changelog, too.

  I plan merging 242-7, too, going forward but this will not need an
  FFe.

  CHANGES WITH 242:

  * In .link files, MACAddressPolicy=persistent (the default) is changed
    to cover more devices. For devices like bridges, tun, tap, bond, and
    similar interfaces that do not have other identifying information,
    the interface name is used as the basis for persistent seed for MAC
    and IPv4LL addresses. The way that devices that were handled
    previously is not changed, and this change is about covering more
    devices then previously by the "persistent" policy.

    MACAddressPolicy=random may be used to force randomized MACs and
    IPv4LL addresses for a device if desired.

    Hint: the log output from udev (at debug level) was enhanced to
    clarify what policy is followed and which attributes are used.
    `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/`
    may be used to view this.

    Hint: if a bridge interface is created without any slaves, and gains
    a slave later, then now the bridge does not inherit slave's MAC.
    To inherit slave's MAC, for example, create the following file:
    ```
    # /etc/systemd/network/98-bridge-inherit-mac.link
    [Match]
    Type=bridge

    [Link]
    MACAddressPolicy=none
    ```

  * The .device units generated by systemd-fstab-generator and other
    generators do not automatically pull in the corresponding .mount 
unit
    as a Wants= dependency. This means that simply plugging in the 
device
    will not cause the mount unit to be started automatically. But 
please
    note that the mount unit may be started for other reasons, in
    particular if it is part of local-fs.target, and any unit which
    (transitively) depends on local-fs.target is started.

  * networkctl list/status/lldp now accept globbing wildcards for 
network
    interface names to match against all existing interfaces.

  * The $PIDFILE environment variable is set to point the absolute path
    configured with PIDFile= for processes of that service.

  * The fallback DNS server list was augmented with Cloudflare public 
DNS
    servers. Use `-Ddns-servers=` to set a different fallback.

  * A new special target usb-gadget.target will be started automatically
    when a USB Device Controller is detected (which means that the 
system
    is a USB peripheral).

  * A new unit setting CPUQuotaPeriodSec= assigns the time period
    relatively to which the CPU time quota specified by CPUQuota= is
    measured.

  * A new unit setting ProtectHostname= may be used to prevent services
    from modifying hostname information (even if they otherwise would
    have privileges to do so).

  * A new unit setting NetworkNamespacePath= may be used to specify a
    namespace for service or socket units through a path referring to a
    Linux network namespace pseudo-file.

  * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now
    have an effect on .socket units: when used the listening socket is
    created within the configured network namespace instead of the host
    namespace.

  * ExecStart= command lines in unit files may now be prefixed with ':'
    in which case environment variable substitution is
    disabled. (Supported for the other ExecXYZ= settings, too.)

  * .timer units gained two new boolean settings OnClockChange= and
    OnTimezoneChange= which may be used to also trigger a unit when the
    system clock is changed or 

[Touch-packages] [Bug 1843755] Re: [FFe] Please accept systemd 242 to Eoan

2019-09-12 Thread Balint Reczey
@vorlon: Please see the discussion in LP: #1841790.

-- 
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/1843755

Title:
  [FFe] Please accept systemd 242 to Eoan

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing 
moved to 242 last week.
  While version 241 is the safer choice for Eoan (from v241 and v242) since it 
is widely tested updating to v242 will allow us to carry fewer patches in Eoan 
and makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing (except 
for a few unrelated failures):
  https://bileto.ubuntu.com/#/ticket/3797

  The final version will be 242-6ubuntu1 and I'm tidying up the
  changelog, too.

  I plan merging 242-7, too, going forward but this will not need an
  FFe.

  CHANGES WITH 242:

  * In .link files, MACAddressPolicy=persistent (the default) is changed
    to cover more devices. For devices like bridges, tun, tap, bond, and
    similar interfaces that do not have other identifying information,
    the interface name is used as the basis for persistent seed for MAC
    and IPv4LL addresses. The way that devices that were handled
    previously is not changed, and this change is about covering more
    devices then previously by the "persistent" policy.

    MACAddressPolicy=random may be used to force randomized MACs and
    IPv4LL addresses for a device if desired.

    Hint: the log output from udev (at debug level) was enhanced to
    clarify what policy is followed and which attributes are used.
    `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/`
    may be used to view this.

    Hint: if a bridge interface is created without any slaves, and gains
    a slave later, then now the bridge does not inherit slave's MAC.
    To inherit slave's MAC, for example, create the following file:
    ```
    # /etc/systemd/network/98-bridge-inherit-mac.link
    [Match]
    Type=bridge

    [Link]
    MACAddressPolicy=none
    ```

  * The .device units generated by systemd-fstab-generator and other
    generators do not automatically pull in the corresponding .mount 
unit
    as a Wants= dependency. This means that simply plugging in the 
device
    will not cause the mount unit to be started automatically. But 
please
    note that the mount unit may be started for other reasons, in
    particular if it is part of local-fs.target, and any unit which
    (transitively) depends on local-fs.target is started.

  * networkctl list/status/lldp now accept globbing wildcards for 
network
    interface names to match against all existing interfaces.

  * The $PIDFILE environment variable is set to point the absolute path
    configured with PIDFile= for processes of that service.

  * The fallback DNS server list was augmented with Cloudflare public 
DNS
    servers. Use `-Ddns-servers=` to set a different fallback.

  * A new special target usb-gadget.target will be started automatically
    when a USB Device Controller is detected (which means that the 
system
    is a USB peripheral).

  * A new unit setting CPUQuotaPeriodSec= assigns the time period
    relatively to which the CPU time quota specified by CPUQuota= is
    measured.

  * A new unit setting ProtectHostname= may be used to prevent services
    from modifying hostname information (even if they otherwise would
    have privileges to do so).

  * A new unit setting NetworkNamespacePath= may be used to specify a
    namespace for service or socket units through a path referring to a
    Linux network namespace pseudo-file.

  * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now
    have an effect on .socket units: when used the listening socket is
    created within the configured network namespace instead of the host
    namespace.

  * ExecStart= command lines in unit files may now be prefixed with ':'
    in which case environment variable substitution is
    disabled. (Supported for the other ExecXYZ= settings, too.)

  * .timer units gained two new boolean settings OnClockChange= and
    OnTimezoneChange= which may be used to also trigger a unit when the
    system clock is changed or the local timezone is
    modified. systemd-run has been updated to make these options easily
    accessible from the command line for transient timers.

    

[Touch-packages] [Bug 1843755] Re: [FFe] Please accept systemd 242 to Eoan

2019-09-12 Thread Balint Reczey
@vorlon: If you don's see that convincing I don't know what you are looking 
for. 242 now is as well tested as 241 when it entered Eoan and it is still not 
too late in the cycle to fix/revert if something breaks.
Imo the most important aspect is preparing for 20.04 LTS and 242 in Eoan serves 
that better than 241.

-- 
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/1843755

Title:
  [FFe] Please accept systemd 242 to Eoan

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing 
moved to 242 last week.
  While version 241 is the safer choice for Eoan (from v241 and v242) since it 
is widely tested updating to v242 will allow us to carry fewer patches in Eoan 
and makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing (except 
for a few unrelated failures):
  https://bileto.ubuntu.com/#/ticket/3797

  The final version will be 242-6ubuntu1 and I'm tidying up the
  changelog, too.

  I plan merging 242-7, too, going forward but this will not need an
  FFe.

  CHANGES WITH 242:

  * In .link files, MACAddressPolicy=persistent (the default) is changed
    to cover more devices. For devices like bridges, tun, tap, bond, and
    similar interfaces that do not have other identifying information,
    the interface name is used as the basis for persistent seed for MAC
    and IPv4LL addresses. The way that devices that were handled
    previously is not changed, and this change is about covering more
    devices then previously by the "persistent" policy.

    MACAddressPolicy=random may be used to force randomized MACs and
    IPv4LL addresses for a device if desired.

    Hint: the log output from udev (at debug level) was enhanced to
    clarify what policy is followed and which attributes are used.
    `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/`
    may be used to view this.

    Hint: if a bridge interface is created without any slaves, and gains
    a slave later, then now the bridge does not inherit slave's MAC.
    To inherit slave's MAC, for example, create the following file:
    ```
    # /etc/systemd/network/98-bridge-inherit-mac.link
    [Match]
    Type=bridge

    [Link]
    MACAddressPolicy=none
    ```

  * The .device units generated by systemd-fstab-generator and other
    generators do not automatically pull in the corresponding .mount 
unit
    as a Wants= dependency. This means that simply plugging in the 
device
    will not cause the mount unit to be started automatically. But 
please
    note that the mount unit may be started for other reasons, in
    particular if it is part of local-fs.target, and any unit which
    (transitively) depends on local-fs.target is started.

  * networkctl list/status/lldp now accept globbing wildcards for 
network
    interface names to match against all existing interfaces.

  * The $PIDFILE environment variable is set to point the absolute path
    configured with PIDFile= for processes of that service.

  * The fallback DNS server list was augmented with Cloudflare public 
DNS
    servers. Use `-Ddns-servers=` to set a different fallback.

  * A new special target usb-gadget.target will be started automatically
    when a USB Device Controller is detected (which means that the 
system
    is a USB peripheral).

  * A new unit setting CPUQuotaPeriodSec= assigns the time period
    relatively to which the CPU time quota specified by CPUQuota= is
    measured.

  * A new unit setting ProtectHostname= may be used to prevent services
    from modifying hostname information (even if they otherwise would
    have privileges to do so).

  * A new unit setting NetworkNamespacePath= may be used to specify a
    namespace for service or socket units through a path referring to a
    Linux network namespace pseudo-file.

  * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now
    have an effect on .socket units: when used the listening socket is
    created within the configured network namespace instead of the host
    namespace.

  * ExecStart= command lines in unit files may now be prefixed with ':'
    in which case environment variable substitution is
    disabled. (Supported for the other ExecXYZ= settings, too.)

  * .timer units gained two new boolean settings OnClockChange= and
    OnTimezoneChange= 

[Touch-packages] [Bug 1843812] Re: apt info "please use the '-a' switch"

2019-09-12 Thread Julian Andres Klode
Thanks for your bug report. It seems I did not add all switches from the
show command to the info alias when adding it.

** Changed in: apt (Ubuntu)
   Status: New => Triaged

** Changed in: apt (Ubuntu)
 Assignee: (unassigned) => Julian Andres Klode (juliank)

** Changed in: apt (Ubuntu)
   Importance: Undecided => Low

-- 
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/1843812

Title:
  apt info "please use the '-a' switch"

Status in apt package in Ubuntu:
  Triaged

Bug description:
  When getting info about a package, I see a notice asking me to "Please
  use the '-a' switch", but the apt program does not accept an '-a'
  switch.

  Steps to reproduce:
  $ apt info docker.io
  ...
  N: There is 1 additional record. Please use the '-a' switch to see it
  $ apt -a info docker.io
  $ apt info -a docker.io
  $ apt info docker.io -a

  Expected outcome:
  same output as `apt info docker.io` but with the 1 additional record.

  Seen outcome:
  E: Command line option 'a' [from -a] is not understood in combination with 
the other options.

  Also seen:
  `apt info $pkg` gives the same output as `apt show $pkg` including the Notice 
message, but where `apt info -a $pkg` fails, `apt show -a $pkg` succeeds.

  Workaround:
  Use `apt show -a $pkg` instead.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: apt 1.8.1
  ProcVersionSignature: Ubuntu 5.0.0-23.24-generic 5.0.15
  Uname: Linux 5.0.0-23-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Thu Sep 12 14:16:09 2019
  InstallationDate: Installed on 2018-10-30 (316 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  SourcePackage: apt
  UpgradeStatus: Upgraded to disco on 2019-04-18 (147 days ago)
  modified.conffile..etc.logrotate.d.apport: [modified]
  modified.conffile..etc.logrotate.d.apt: [modified]
  mtime.conffile..etc.logrotate.d.apport: 2018-12-13T12:13:33.355709
  mtime.conffile..etc.logrotate.d.apt: 2018-12-13T12:13:41.355709

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1843812/+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 1843793] Re: wpasupplicant 2.9 on eoan breaks wifi connections on arm64, reversion to 2.6-21ubuntu3.2 fixes.

2019-09-12 Thread satmandu
Here is the wpa supplicant log, gathered as per:
https://gist.github.com/wch/8305204#gistcomment-2477237

https://paste.ubuntu.com/p/Nm7G6STc22/

Note there are 3 sections.
The first section starts with "wpa_supplicant v2.6"
When I upgrade to 2.9 you can see this start with "wpa_supplicant v2.9"
When I revert back to 2.6 you can see "wpa_supplicant v2.6" again.

The wifi disconnects immediately after upgrading to 2.9, and I am able
to reconnect to wifi immediately after downgrading to 2.6 using "sudo
nmcli con up Manhattan". (That's the name of my network manager
connection.)

As to bisecting the changes between 2.6 and 2.9 That might take a
while!

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

Title:
  wpasupplicant 2.9 on eoan breaks wifi connections on arm64, reversion
  to 2.6-21ubuntu3.2 fixes.

Status in wpa package in Ubuntu:
  Incomplete

Bug description:
  Summary: Connecting from a RPI4 running on arm64 eoan-server-
  preinstalled image with current "upstream" raspberry pi foundation
  kernel 4.19.71 to a WPA2 protected access point (Unifi nanoHD). The
  wifi connection drops out after ~ ten minutes. Reverting wpasupplicant
  to disco version keeps that from happening.

  Running on arm64 eoan build with kernel from raspberry pi folks ( 
4.19.71-v8-g6de367fd7 ) on a rpi4.
  lsb_release -rd
  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  With wpasupplicant 2.9, wifi comes up on boot, but then drops out
  shortly thereafter.

  Reverting wpasupplicant to 2.6-21ubuntu3.2 keeps the wifi connection
  from dropping out.

  wireless driver:
  [41385.982747] brcmfmac: brcmf_fw_alloc_request: using 
brcm/brcmfmac43455-sdio for chip BCM4345/6
  [41386.000633] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  
1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4

  Logs using journalctl -xe NM_CONNECTION=f7f9f91f-001a-46b5-9acc-
  038db489a0c8 + NM_DEVICE=wlan0

  This is what I get with wpasupplicant 2.9:

  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.2749] 
manager: (wlan0): new 802.11 Wi-Fi device 
(/org/freedesktop/NetworkManager/Devices/7)
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3032] device 
(wlan0): state change: unmanaged -> unavailable (reason 'managed', 
sys-iface-state: 'ex
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3937] 
sup-iface[0x55b0b8faf0,wlan0]: supports 5 scan SSIDs
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3957] device 
(wlan0): supplicant interface state: starting -> ready
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3974] device 
(wlan0): state change: unavailable -> disconnected (reason 
'supplicant-available', sys-
  Sep 12 12:09:55 rpi4 NetworkManager[25218]:   [1568304595.9790] device 
(wlan0): supplicant interface state: ready -> scanning
  Sep 12 12:09:58 rpi4 NetworkManager[25218]:   [1568304598.7770] device 
(wlan0): supplicant interface state: scanning -> inactive
  Sep 12 12:10:01 rpi4 NetworkManager[25218]:   [1568304601.9310] device 
(wlan0): supplicant interface state: inactive -> scanning
  Sep 12 12:10:04 rpi4 NetworkManager[25218]:   [1568304604.7332] device 
(wlan0): supplicant interface state: scanning -> inactive
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.5964] device 
(wlan0): Activation: starting connection 'Manhattan' 
(f7f9f91f-001a-46b5-9acc-038db489a
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.5975] device 
(wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 
'manage
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6018] device 
(wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6027] device 
(wlan0): Activation: (wifi) access point 'Manhattan' has security, but secrets 
are requ
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6028] device 
(wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6115] device 
(wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6126] device 
(wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6139] device 
(wlan0): Activation: (wifi) connection 'Manhattan' has security, and secrets 
exist.  No
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6690] device 
(wlan0): supplicant interface state: inactive -> scanning
  Sep 12 12:10:18 rpi4 NetworkManager[25218]:   [1568304618.4907] device 
(wlan0): supplicant interface state: scanning -> disconnected
  Sep 12 12:10:18 rpi4 NetworkManager[25218]:   

[Touch-packages] [Bug 1843819] [NEW] Volume scaling is incorrect for Logitech H600 (046d:0a29): alsamixer @ 0% where pulse volume @ 50%

2019-09-12 Thread Jacob Godserv
Public bug reported:

When the volume is set to around 50% in PulseAudio (using the Ubuntu
Sound preferences screen but cross-checked by simply viewing with
pavucontrol) the alsamixer volume is set to 0%. I can see the volume
rise quickly as the volume is raised past 50% in the Sound preferences
screen.

This occurs at least for the Logitech H600 USB device:
Bus 001 Device 011: ID 046d:0a29 Logitech, Inc. H600 [Wireless Headset]

The other audio devices behave "correctly" where 0% is silent and 100%
is maximum volume.

This confused me because the volume was set to 50% (I'll frequently
reset headset volume to 30-50% to protect my ears) and thought audio was
broken at first because I wasn't getting any sound at all.

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

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

Title:
  Volume scaling is incorrect for Logitech H600 (046d:0a29): alsamixer @
  0% where pulse volume @ 50%

Status in pulseaudio package in Ubuntu:
  New

Bug description:
  When the volume is set to around 50% in PulseAudio (using the Ubuntu
  Sound preferences screen but cross-checked by simply viewing with
  pavucontrol) the alsamixer volume is set to 0%. I can see the volume
  rise quickly as the volume is raised past 50% in the Sound preferences
  screen.

  This occurs at least for the Logitech H600 USB device:
  Bus 001 Device 011: ID 046d:0a29 Logitech, Inc. H600 [Wireless Headset]

  The other audio devices behave "correctly" where 0% is silent and 100%
  is maximum volume.

  This confused me because the volume was set to 50% (I'll frequently
  reset headset volume to 30-50% to protect my ears) and thought audio
  was broken at first because I wasn't getting any sound at all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1843819/+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 1548057] Re: rfkill state is not restored on reboot

2019-09-12 Thread Jamie Strandboge
This still seems to be a problem on Ubuntu 19.04. Ie, if I do:

$ sudo systemctl status systemd-rfkill
● systemd-rfkill.service - Load/Save RF Kill Switch Status
   Loaded: loaded (/lib/systemd/system/systemd-rfkill.service; static; vendor 
preset:
...

$ rfkill block bluetooth
$ rfkill
ID TYPE  DEVICE  SOFT  HARD
 0 wlan  phy0   unblocked unblocked
 1 bluetooth hci0 blocked unblocked
$ sudo reboot

Then I get:

$ rfkill
ID TYPE  DEVICE  SOFT  HARD
 0 wlan  phy0   unblocked unblocked
 1 bluetooth hci0   unblocked unblocked

and I can see that the state files in /var/lib/systemd/rfkill were not
updated as part of the reboot:

$ cat /var/lib/systemd/rfkill/*bluetooth
0

However, I can workaround this manually by running 'sudo /lib/systemd
/systemd-rfkill' prior to reboot myself:

$ rfkill block bluetooth
$ rfkill
ID TYPE  DEVICE  SOFT  HARD
 0 bluetooth hci0 blocked unblocked
 1 wlan  phy0   unblocked unblocked
$ sudo /lib/systemd/systemd-rfkill
$ cat /var/lib/systemd/rfkill/*bluetooth
1
$ reboot
$ rfkill
ID TYPE  DEVICE  SOFT  HARD
 0 bluetooth hci0 blocked unblocked
 1 wlan  phy0   unblocked unblocked
$ cat /var/lib/systemd/rfkill/*bluetooth
1

In this manner, I can at least have bluetooth in a predictable state.
However, the desirable behavior is likely to have the current state
preserved across reboots. Looking at /lib/systemd/system/systemd-
rfkill.service, it appears all that is missing is an
ExecStop=/lib/systemd/systemd-rfkill

-- 
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/1548057

Title:
  rfkill state is not restored on reboot

Status in systemd package in Ubuntu:
  New

Bug description:
  1. Disable bluetooth via applet.
  2. Reboot.
  3. Login.
  4. Observe bluetooth is re-enabled!

  For fun having

  rfkill block bluetooth

  in rc.local does not work either

  ProblemType: Bug
  DistroRelease: Ubuntu 15.10
  Package: rfkill 0.5-1ubuntu2
  ProcVersionSignature: Ubuntu 4.2.0-27.32-generic 4.2.8-ckt1
  Uname: Linux 4.2.0-27-generic x86_64
  NonfreeKernelModules: fglrx
  ApportVersion: 2.19.1-0ubuntu5
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Sun Feb 21 13:37:39 2016
  InstallationDate: Installed on 2013-05-17 (1010 days ago)
  InstallationMedia: Xubuntu 13.04 "Raring Ringtail" - Release amd64 
(20130423.1)
  SourcePackage: rfkill
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1548057/+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 1843812] [NEW] apt info "please use the '-a' switch"

2019-09-12 Thread Moses Moore
Public bug reported:

When getting info about a package, I see a notice asking me to "Please
use the '-a' switch", but the apt program does not accept an '-a'
switch.

Steps to reproduce:
$ apt info docker.io
...
N: There is 1 additional record. Please use the '-a' switch to see it
$ apt -a info docker.io
$ apt info -a docker.io
$ apt info docker.io -a

Expected outcome:
same output as `apt info docker.io` but with the 1 additional record.

Seen outcome:
E: Command line option 'a' [from -a] is not understood in combination with the 
other options.

Also seen:
`apt info $pkg` gives the same output as `apt show $pkg` including the Notice 
message, but where `apt info -a $pkg` fails, `apt show -a $pkg` succeeds.

Workaround:
Use `apt show -a $pkg` instead.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: apt 1.8.1
ProcVersionSignature: Ubuntu 5.0.0-23.24-generic 5.0.15
Uname: Linux 5.0.0-23-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.10-0ubuntu27.1
Architecture: amd64
CurrentDesktop: KDE
Date: Thu Sep 12 14:16:09 2019
InstallationDate: Installed on 2018-10-30 (316 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
SourcePackage: apt
UpgradeStatus: Upgraded to disco on 2019-04-18 (147 days ago)
modified.conffile..etc.logrotate.d.apport: [modified]
modified.conffile..etc.logrotate.d.apt: [modified]
mtime.conffile..etc.logrotate.d.apport: 2018-12-13T12:13:33.355709
mtime.conffile..etc.logrotate.d.apt: 2018-12-13T12:13:41.355709

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


** Tags: amd64 apport-bug disco

-- 
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/1843812

Title:
  apt info "please use the '-a' switch"

Status in apt package in Ubuntu:
  New

Bug description:
  When getting info about a package, I see a notice asking me to "Please
  use the '-a' switch", but the apt program does not accept an '-a'
  switch.

  Steps to reproduce:
  $ apt info docker.io
  ...
  N: There is 1 additional record. Please use the '-a' switch to see it
  $ apt -a info docker.io
  $ apt info -a docker.io
  $ apt info docker.io -a

  Expected outcome:
  same output as `apt info docker.io` but with the 1 additional record.

  Seen outcome:
  E: Command line option 'a' [from -a] is not understood in combination with 
the other options.

  Also seen:
  `apt info $pkg` gives the same output as `apt show $pkg` including the Notice 
message, but where `apt info -a $pkg` fails, `apt show -a $pkg` succeeds.

  Workaround:
  Use `apt show -a $pkg` instead.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: apt 1.8.1
  ProcVersionSignature: Ubuntu 5.0.0-23.24-generic 5.0.15
  Uname: Linux 5.0.0-23-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Thu Sep 12 14:16:09 2019
  InstallationDate: Installed on 2018-10-30 (316 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  SourcePackage: apt
  UpgradeStatus: Upgraded to disco on 2019-04-18 (147 days ago)
  modified.conffile..etc.logrotate.d.apport: [modified]
  modified.conffile..etc.logrotate.d.apt: [modified]
  mtime.conffile..etc.logrotate.d.apport: 2018-12-13T12:13:33.355709
  mtime.conffile..etc.logrotate.d.apt: 2018-12-13T12:13:41.355709

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1843812/+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 1843793] Re: wpasupplicant 2.9 on eoan breaks wifi connections on arm64, reversion to 2.6-21ubuntu3.2 fixes.

2019-09-12 Thread Julian Andres Klode
If we can find something in wpa's log (however one gets them) and an
upstream fix for that, that would be great. If you can, I suggest you
try to git bisect the upstream repository from 2.6 to 2.9 and see what
commit breaks it.

Please note that custom kernels are not supported, and we can't be sure
it's a kernel or a wpa issue, so we'll probably have to wait for
official rpi4 support if we can't figure out the cause and fix this way.

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

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

Title:
  wpasupplicant 2.9 on eoan breaks wifi connections on arm64, reversion
  to 2.6-21ubuntu3.2 fixes.

Status in wpa package in Ubuntu:
  Incomplete

Bug description:
  Summary: Connecting from a RPI4 running on arm64 eoan-server-
  preinstalled image with current "upstream" raspberry pi foundation
  kernel 4.19.71 to a WPA2 protected access point (Unifi nanoHD). The
  wifi connection drops out after ~ ten minutes. Reverting wpasupplicant
  to disco version keeps that from happening.

  Running on arm64 eoan build with kernel from raspberry pi folks ( 
4.19.71-v8-g6de367fd7 ) on a rpi4.
  lsb_release -rd
  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  With wpasupplicant 2.9, wifi comes up on boot, but then drops out
  shortly thereafter.

  Reverting wpasupplicant to 2.6-21ubuntu3.2 keeps the wifi connection
  from dropping out.

  wireless driver:
  [41385.982747] brcmfmac: brcmf_fw_alloc_request: using 
brcm/brcmfmac43455-sdio for chip BCM4345/6
  [41386.000633] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  
1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4

  Logs using journalctl -xe NM_CONNECTION=f7f9f91f-001a-46b5-9acc-
  038db489a0c8 + NM_DEVICE=wlan0

  This is what I get with wpasupplicant 2.9:

  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.2749] 
manager: (wlan0): new 802.11 Wi-Fi device 
(/org/freedesktop/NetworkManager/Devices/7)
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3032] device 
(wlan0): state change: unmanaged -> unavailable (reason 'managed', 
sys-iface-state: 'ex
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3937] 
sup-iface[0x55b0b8faf0,wlan0]: supports 5 scan SSIDs
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3957] device 
(wlan0): supplicant interface state: starting -> ready
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3974] device 
(wlan0): state change: unavailable -> disconnected (reason 
'supplicant-available', sys-
  Sep 12 12:09:55 rpi4 NetworkManager[25218]:   [1568304595.9790] device 
(wlan0): supplicant interface state: ready -> scanning
  Sep 12 12:09:58 rpi4 NetworkManager[25218]:   [1568304598.7770] device 
(wlan0): supplicant interface state: scanning -> inactive
  Sep 12 12:10:01 rpi4 NetworkManager[25218]:   [1568304601.9310] device 
(wlan0): supplicant interface state: inactive -> scanning
  Sep 12 12:10:04 rpi4 NetworkManager[25218]:   [1568304604.7332] device 
(wlan0): supplicant interface state: scanning -> inactive
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.5964] device 
(wlan0): Activation: starting connection 'Manhattan' 
(f7f9f91f-001a-46b5-9acc-038db489a
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.5975] device 
(wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 
'manage
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6018] device 
(wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6027] device 
(wlan0): Activation: (wifi) access point 'Manhattan' has security, but secrets 
are requ
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6028] device 
(wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6115] device 
(wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6126] device 
(wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6139] device 
(wlan0): Activation: (wifi) connection 'Manhattan' has security, and secrets 
exist.  No
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6690] device 
(wlan0): supplicant interface state: inactive -> scanning
  Sep 12 12:10:18 rpi4 NetworkManager[25218]:   [1568304618.4907] device 
(wlan0): supplicant interface state: scanning -> disconnected
  Sep 12 12:10:18 rpi4 NetworkManager[25218]:   [1568304618.6313] device 
(wlan0): supplicant interface state: disconnected -> scanning
  Sep 12 12:10:21 rpi4 NetworkManager[25218]:   [1568304621.4490] device 

[Touch-packages] [Bug 1843793] Re: wpasupplicant 2.9 on eoan breaks wifi connections on arm64, reversion to 2.6-21ubuntu3.2 fixes.

2019-09-12 Thread Julian Andres Klode
I'm not sure the NM log is very useful, a wpa supplicant log would
probably be helpful, but no idea on gathering that.

** No longer affects: wpasupplicant (Ubuntu)

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

Title:
  wpasupplicant 2.9 on eoan breaks wifi connections on arm64, reversion
  to 2.6-21ubuntu3.2 fixes.

Status in wpa package in Ubuntu:
  Incomplete

Bug description:
  Summary: Connecting from a RPI4 running on arm64 eoan-server-
  preinstalled image with current "upstream" raspberry pi foundation
  kernel 4.19.71 to a WPA2 protected access point (Unifi nanoHD). The
  wifi connection drops out after ~ ten minutes. Reverting wpasupplicant
  to disco version keeps that from happening.

  Running on arm64 eoan build with kernel from raspberry pi folks ( 
4.19.71-v8-g6de367fd7 ) on a rpi4.
  lsb_release -rd
  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  With wpasupplicant 2.9, wifi comes up on boot, but then drops out
  shortly thereafter.

  Reverting wpasupplicant to 2.6-21ubuntu3.2 keeps the wifi connection
  from dropping out.

  wireless driver:
  [41385.982747] brcmfmac: brcmf_fw_alloc_request: using 
brcm/brcmfmac43455-sdio for chip BCM4345/6
  [41386.000633] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  
1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4

  Logs using journalctl -xe NM_CONNECTION=f7f9f91f-001a-46b5-9acc-
  038db489a0c8 + NM_DEVICE=wlan0

  This is what I get with wpasupplicant 2.9:

  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.2749] 
manager: (wlan0): new 802.11 Wi-Fi device 
(/org/freedesktop/NetworkManager/Devices/7)
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3032] device 
(wlan0): state change: unmanaged -> unavailable (reason 'managed', 
sys-iface-state: 'ex
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3937] 
sup-iface[0x55b0b8faf0,wlan0]: supports 5 scan SSIDs
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3957] device 
(wlan0): supplicant interface state: starting -> ready
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3974] device 
(wlan0): state change: unavailable -> disconnected (reason 
'supplicant-available', sys-
  Sep 12 12:09:55 rpi4 NetworkManager[25218]:   [1568304595.9790] device 
(wlan0): supplicant interface state: ready -> scanning
  Sep 12 12:09:58 rpi4 NetworkManager[25218]:   [1568304598.7770] device 
(wlan0): supplicant interface state: scanning -> inactive
  Sep 12 12:10:01 rpi4 NetworkManager[25218]:   [1568304601.9310] device 
(wlan0): supplicant interface state: inactive -> scanning
  Sep 12 12:10:04 rpi4 NetworkManager[25218]:   [1568304604.7332] device 
(wlan0): supplicant interface state: scanning -> inactive
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.5964] device 
(wlan0): Activation: starting connection 'Manhattan' 
(f7f9f91f-001a-46b5-9acc-038db489a
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.5975] device 
(wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 
'manage
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6018] device 
(wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6027] device 
(wlan0): Activation: (wifi) access point 'Manhattan' has security, but secrets 
are requ
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6028] device 
(wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6115] device 
(wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6126] device 
(wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6139] device 
(wlan0): Activation: (wifi) connection 'Manhattan' has security, and secrets 
exist.  No
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6690] device 
(wlan0): supplicant interface state: inactive -> scanning
  Sep 12 12:10:18 rpi4 NetworkManager[25218]:   [1568304618.4907] device 
(wlan0): supplicant interface state: scanning -> disconnected
  Sep 12 12:10:18 rpi4 NetworkManager[25218]:   [1568304618.6313] device 
(wlan0): supplicant interface state: disconnected -> scanning
  Sep 12 12:10:21 rpi4 NetworkManager[25218]:   [1568304621.4490] device 
(wlan0): supplicant interface state: scanning -> disconnected
  Sep 12 12:10:21 rpi4 NetworkManager[25218]:   [1568304621.9910] device 
(wlan0): supplicant interface state: disconnected -> scanning
  Sep 12 12:10:24 rpi4 NetworkManager[25218]:   [1568304624.8102] device 
(wlan0): supplicant interface state: scanning -> disconnected
  

[Touch-packages] [Bug 1843430] Re: FTBFS in Eoan due to new glibc - error: ‘SIOCGSTAMP’ undeclared

2019-09-12 Thread Launchpad Bug Tracker
This bug was fixed in the package dnsmasq - 2.80-1ubuntu2

---
dnsmasq (2.80-1ubuntu2) eoan; urgency=medium

  * Fix FTBFS in eoan due to glibc 2.30 SIOCGSTAMP changes (LP:
#1843430)

 -- Christian Ehrhardt   Tue, 10 Sep
2019 15:00:04 +0200

** Changed in: dnsmasq (Ubuntu)
   Status: In Progress => Fix Released

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

Title:
  FTBFS in Eoan due to new glibc - error: ‘SIOCGSTAMP’ undeclared

Status in dnsmasq package in Ubuntu:
  Fix Released

Bug description:
  We hit this on a rebuild in Eoan
  dhcp.c: In function ‘dhcp_packet’:
  dhcp.c:182:17: error: ‘SIOCGSTAMP’ undeclared (first use in this function); 
did you mean ‘SIOCGARP’?
    182 |   if (ioctl(fd, SIOCGSTAMP, ) == 0)
    | ^~
    | SIOCGARP

  This seems much like the fix in the (not yet released) upstream repo:
  => 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3052ce208acf602f0163166dcefb7330d537cedb

  "Fix build after y2038 changes in glib.
  SIOCGSTAMP is defined in linux/sockios.h, not asm/sockios.h now."

  Failed build log: https://launchpadlibrarian.net/441262561
  /buildlog_ubuntu-eoan-amd64.dnsmasq_2.80-1ubuntu1_BUILDING.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1843430/+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 1843793] Re: wpasupplicant 2.29 breaks wifi connections, reversion to 2.6-21ubuntu3.2 fixes.

2019-09-12 Thread satmandu
** Description changed:

  Running on arm64 eoan build with kernel from raspberry pi folks ( 
4.19.71-v8-g6de367fd7 ) on a rpi4.
  lsb_release -rd
  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10
  
- 
- With wpasupplicant 2.29, wifi comes up on boot, but then drops out shortly 
thereafter.
+ With wpasupplicant 2.9, wifi comes up on boot, but then drops out
+ shortly thereafter.
  
  Reverting wpasupplicant to 2.6-21ubuntu3.2 keeps the wifi connection
  from dropping out.
  
  Have "wifi.scan-rand-mac-address=no" set in
  /etc/NetworkManager/NetworkManager.conf as per many troubleshooting
  threads.
  
  wireless driver:
  [41385.982747] brcmfmac: brcmf_fw_alloc_request: using 
brcm/brcmfmac43455-sdio for chip BCM4345/6
  [41386.000633] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  
1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
  
+ Logs using journalctl -xe NM_CONNECTION=f7f9f91f-001a-46b5-9acc-
+ 038db489a0c8 + NM_DEVICE=wlan0
  
- Logs using journalctl -xe NM_CONNECTION=f7f9f91f-001a-46b5-9acc-038db489a0c8 
+ NM_DEVICE=wlan0
- 
- This is what I get with wpasupplicant 2.29:
+ This is what I get with wpasupplicant 2.9:
  
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.2749] 
manager: (wlan0): new 802.11 Wi-Fi device 
(/org/freedesktop/NetworkManager/Devices/7)
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3032] device 
(wlan0): state change: unmanaged -> unavailable (reason 'managed', 
sys-iface-state: 'ex
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3937] 
sup-iface[0x55b0b8faf0,wlan0]: supports 5 scan SSIDs
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3957] device 
(wlan0): supplicant interface state: starting -> ready
  Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3974] device 
(wlan0): state change: unavailable -> disconnected (reason 
'supplicant-available', sys-
  Sep 12 12:09:55 rpi4 NetworkManager[25218]:   [1568304595.9790] device 
(wlan0): supplicant interface state: ready -> scanning
  Sep 12 12:09:58 rpi4 NetworkManager[25218]:   [1568304598.7770] device 
(wlan0): supplicant interface state: scanning -> inactive
  Sep 12 12:10:01 rpi4 NetworkManager[25218]:   [1568304601.9310] device 
(wlan0): supplicant interface state: inactive -> scanning
  Sep 12 12:10:04 rpi4 NetworkManager[25218]:   [1568304604.7332] device 
(wlan0): supplicant interface state: scanning -> inactive
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.5964] device 
(wlan0): Activation: starting connection 'Manhattan' 
(f7f9f91f-001a-46b5-9acc-038db489a
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.5975] device 
(wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 
'manage
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6018] device 
(wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6027] device 
(wlan0): Activation: (wifi) access point 'Manhattan' has security, but secrets 
are requ
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6028] device 
(wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6115] device 
(wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6126] device 
(wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6139] device 
(wlan0): Activation: (wifi) connection 'Manhattan' has security, and secrets 
exist.  No
  Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6690] device 
(wlan0): supplicant interface state: inactive -> scanning
  Sep 12 12:10:18 rpi4 NetworkManager[25218]:   [1568304618.4907] device 
(wlan0): supplicant interface state: scanning -> disconnected
  Sep 12 12:10:18 rpi4 NetworkManager[25218]:   [1568304618.6313] device 
(wlan0): supplicant interface state: disconnected -> scanning
  Sep 12 12:10:21 rpi4 NetworkManager[25218]:   [1568304621.4490] device 
(wlan0): supplicant interface state: scanning -> disconnected
  Sep 12 12:10:21 rpi4 NetworkManager[25218]:   [1568304621.9910] device 
(wlan0): supplicant interface state: disconnected -> scanning
  Sep 12 12:10:24 rpi4 NetworkManager[25218]:   [1568304624.8102] device 
(wlan0): supplicant interface state: scanning -> disconnected
  Sep 12 12:10:25 rpi4 NetworkManager[25218]:   [1568304625.8531] device 
(wlan0): supplicant interface state: disconnected -> scanning
  Sep 12 12:10:28 rpi4 NetworkManager[25218]:   [1568304628.6735] device 
(wlan0): supplicant interface state: scanning -> disconnected
  Sep 12 12:10:28 rpi4 NetworkManager[25218]:   [1568304628.9667] device 
(wlan0): supplicant interface state: disconnected -> scanning
  Sep 12 12:10:40 rpi4 

[Touch-packages] [Bug 1843755] Re: [FFe] Please accept systemd 242 to Eoan

2019-09-12 Thread Steve Langasek
cut'n'pasting the changelog (especially with bad word wrapping) does not
constitute 'analysis' and is not particularly consumable by the release
team.

-- 
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/1843755

Title:
  [FFe] Please accept systemd 242 to Eoan

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing 
moved to 242 last week.
  While version 241 is the safer choice for Eoan (from v241 and v242) since it 
is widely tested updating to v242 will allow us to carry fewer patches in Eoan 
and makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing (except 
for a few unrelated failures):
  https://bileto.ubuntu.com/#/ticket/3797

  The final version will be 242-6ubuntu1 and I'm tidying up the
  changelog, too.

  I plan merging 242-7, too, going forward but this will not need an
  FFe.

  CHANGES WITH 242:

  * In .link files, MACAddressPolicy=persistent (the default) is changed
    to cover more devices. For devices like bridges, tun, tap, bond, and
    similar interfaces that do not have other identifying information,
    the interface name is used as the basis for persistent seed for MAC
    and IPv4LL addresses. The way that devices that were handled
    previously is not changed, and this change is about covering more
    devices then previously by the "persistent" policy.

    MACAddressPolicy=random may be used to force randomized MACs and
    IPv4LL addresses for a device if desired.

    Hint: the log output from udev (at debug level) was enhanced to
    clarify what policy is followed and which attributes are used.
    `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/`
    may be used to view this.

    Hint: if a bridge interface is created without any slaves, and gains
    a slave later, then now the bridge does not inherit slave's MAC.
    To inherit slave's MAC, for example, create the following file:
    ```
    # /etc/systemd/network/98-bridge-inherit-mac.link
    [Match]
    Type=bridge

    [Link]
    MACAddressPolicy=none
    ```

  * The .device units generated by systemd-fstab-generator and other
    generators do not automatically pull in the corresponding .mount 
unit
    as a Wants= dependency. This means that simply plugging in the 
device
    will not cause the mount unit to be started automatically. But 
please
    note that the mount unit may be started for other reasons, in
    particular if it is part of local-fs.target, and any unit which
    (transitively) depends on local-fs.target is started.

  * networkctl list/status/lldp now accept globbing wildcards for 
network
    interface names to match against all existing interfaces.

  * The $PIDFILE environment variable is set to point the absolute path
    configured with PIDFile= for processes of that service.

  * The fallback DNS server list was augmented with Cloudflare public 
DNS
    servers. Use `-Ddns-servers=` to set a different fallback.

  * A new special target usb-gadget.target will be started automatically
    when a USB Device Controller is detected (which means that the 
system
    is a USB peripheral).

  * A new unit setting CPUQuotaPeriodSec= assigns the time period
    relatively to which the CPU time quota specified by CPUQuota= is
    measured.

  * A new unit setting ProtectHostname= may be used to prevent services
    from modifying hostname information (even if they otherwise would
    have privileges to do so).

  * A new unit setting NetworkNamespacePath= may be used to specify a
    namespace for service or socket units through a path referring to a
    Linux network namespace pseudo-file.

  * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now
    have an effect on .socket units: when used the listening socket is
    created within the configured network namespace instead of the host
    namespace.

  * ExecStart= command lines in unit files may now be prefixed with ':'
    in which case environment variable substitution is
    disabled. (Supported for the other ExecXYZ= settings, too.)

  * .timer units gained two new boolean settings OnClockChange= and
    OnTimezoneChange= which may be used to also trigger a unit when the
    system clock is changed or the local timezone is
    modified. systemd-run has been updated to 

[Touch-packages] [Bug 1843755] Re: [FFe] Please accept systemd 242 to Eoan

2019-09-12 Thread Gianfranco Costamagna
I added in the description, the changelog to know what has been introduced in 
this release, something I would personally appreciate to have in my dailyjob is:
* systemd.volatile=overlay
* systemd-networkd-wait-online gained a new setting --any for waiting
* networkctl list/status/lldp now accept globbing wildcards for network


** Description changed:

  Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing 
moved to 242 last week.
  While version 241 is the safer choice for Eoan (from v241 and v242) since it 
is widely tested updating to v242 will allow us to carry fewer patches in Eoan 
and makes moving to the next release easier.
  
  The proposed package is tested in Bileto and all tests are passing (except 
for a few unrelated failures):
  https://bileto.ubuntu.com/#/ticket/3797
  
  The final version will be 242-6ubuntu1 and I'm tidying up the changelog,
  too.
  
  I plan merging 242-7, too, going forward but this will not need an FFe.
+ 
+ 
+ CHANGES WITH 242:
+ 
+ * In .link files, MACAddressPolicy=persistent (the default) is changed
+   to cover more devices. For devices like bridges, tun, tap, bond, and
+   similar interfaces that do not have other identifying information,
+   the interface name is used as the basis for persistent seed for MAC
+   and IPv4LL addresses. The way that devices that were handled
+   previously is not changed, and this change is about covering more
+   devices then previously by the "persistent" policy.
+ 
+   MACAddressPolicy=random may be used to force randomized MACs and
+   IPv4LL addresses for a device if desired.
+ 
+   Hint: the log output from udev (at debug level) was enhanced to
+   clarify what policy is followed and which attributes are used.
+   `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/`
+   may be used to view this.
+ 
+   Hint: if a bridge interface is created without any slaves, and gains
+   a slave later, then now the bridge does not inherit slave's MAC.
+   To inherit slave's MAC, for example, create the following file:
+   ```
+   # /etc/systemd/network/98-bridge-inherit-mac.link
+   [Match]
+   Type=bridge
+ 
+   [Link]
+   MACAddressPolicy=none
+   ```
+ 
+ * The .device units generated by systemd-fstab-generator and other
+   generators do not automatically pull in the corresponding .mount 
unit
+   as a Wants= dependency. This means that simply plugging in the 
device
+   will not cause the mount unit to be started automatically. But 
please
+   note that the mount unit may be started for other reasons, in
+   particular if it is part of local-fs.target, and any unit which
+   (transitively) depends on local-fs.target is started.
+ 
+ * networkctl list/status/lldp now accept globbing wildcards for 
network
+   interface names to match against all existing interfaces.
+ 
+ * The $PIDFILE environment variable is set to point the absolute path
+   configured with PIDFile= for processes of that service.
+ 
+ * The fallback DNS server list was augmented with Cloudflare public 
DNS
+   servers. Use `-Ddns-servers=` to set a different fallback.
+ 
+ * A new special target usb-gadget.target will be started automatically
+   when a USB Device Controller is detected (which means that the 
system
+   is a USB peripheral).
+ 
+ * A new unit setting CPUQuotaPeriodSec= assigns the time period
+   relatively to which the CPU time quota specified by CPUQuota= is
+   measured.
+ 
+ * A new unit setting ProtectHostname= may be used to prevent services
+   from modifying hostname information (even if they otherwise would
+   have privileges to do so).
+ 
+ * A new unit setting NetworkNamespacePath= may be used to specify a
+   namespace for service or socket units through a path referring to a
+   Linux network namespace pseudo-file.
+ 
+ * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now
+   have an effect on .socket units: when used the listening socket is
+   created within the configured network namespace instead of the host
+   namespace.
+ 
+ * ExecStart= command lines in unit files may now be prefixed with ':'
+   in which case environment variable substitution is
+   disabled. (Supported for the other ExecXYZ= settings, too.)
+ 
+ * .timer units gained two new boolean settings OnClockChange= and
+   OnTimezoneChange= which may be used to also trigger a unit when the
+   system clock is changed or the local timezone is
+   modified. systemd-run has been updated to make these options easily
+   accessible from 

[Touch-packages] [Bug 1843793] [NEW] wpasupplicant 2.29 breaks wifi connections, reversion to 2.6-21ubuntu3.2 fixes.

2019-09-12 Thread satmandu
Public bug reported:

Running on arm64 eoan build with kernel from raspberry pi folks ( 
4.19.71-v8-g6de367fd7 ) on a rpi4.
lsb_release -rd
Description:Ubuntu Eoan Ermine (development branch)
Release:19.10


With wpasupplicant 2.29, wifi comes up on boot, but then drops out shortly 
thereafter.

Reverting wpasupplicant to 2.6-21ubuntu3.2 keeps the wifi connection
from dropping out.

Have "wifi.scan-rand-mac-address=no" set in
/etc/NetworkManager/NetworkManager.conf as per many troubleshooting
threads.

wireless driver:
[41385.982747] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio 
for chip BCM4345/6
[41386.000633] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  1 
2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4


Logs using journalctl -xe NM_CONNECTION=f7f9f91f-001a-46b5-9acc-038db489a0c8 + 
NM_DEVICE=wlan0

This is what I get with wpasupplicant 2.29:

Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.2749] manager: 
(wlan0): new 802.11 Wi-Fi device (/org/freedesktop/NetworkManager/Devices/7)
Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3032] device 
(wlan0): state change: unmanaged -> unavailable (reason 'managed', 
sys-iface-state: 'ex
Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3937] 
sup-iface[0x55b0b8faf0,wlan0]: supports 5 scan SSIDs
Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3957] device 
(wlan0): supplicant interface state: starting -> ready
Sep 12 12:09:49 rpi4 NetworkManager[25218]:   [1568304589.3974] device 
(wlan0): state change: unavailable -> disconnected (reason 
'supplicant-available', sys-
Sep 12 12:09:55 rpi4 NetworkManager[25218]:   [1568304595.9790] device 
(wlan0): supplicant interface state: ready -> scanning
Sep 12 12:09:58 rpi4 NetworkManager[25218]:   [1568304598.7770] device 
(wlan0): supplicant interface state: scanning -> inactive
Sep 12 12:10:01 rpi4 NetworkManager[25218]:   [1568304601.9310] device 
(wlan0): supplicant interface state: inactive -> scanning
Sep 12 12:10:04 rpi4 NetworkManager[25218]:   [1568304604.7332] device 
(wlan0): supplicant interface state: scanning -> inactive
Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.5964] device 
(wlan0): Activation: starting connection 'Manhattan' 
(f7f9f91f-001a-46b5-9acc-038db489a
Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.5975] device 
(wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 
'manage
Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6018] device 
(wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6027] device 
(wlan0): Activation: (wifi) access point 'Manhattan' has security, but secrets 
are requ
Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6028] device 
(wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 
'managed')
Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6115] device 
(wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 
'managed')
Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6126] device 
(wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6139] device 
(wlan0): Activation: (wifi) connection 'Manhattan' has security, and secrets 
exist.  No
Sep 12 12:10:15 rpi4 NetworkManager[25218]:   [1568304615.6690] device 
(wlan0): supplicant interface state: inactive -> scanning
Sep 12 12:10:18 rpi4 NetworkManager[25218]:   [1568304618.4907] device 
(wlan0): supplicant interface state: scanning -> disconnected
Sep 12 12:10:18 rpi4 NetworkManager[25218]:   [1568304618.6313] device 
(wlan0): supplicant interface state: disconnected -> scanning
Sep 12 12:10:21 rpi4 NetworkManager[25218]:   [1568304621.4490] device 
(wlan0): supplicant interface state: scanning -> disconnected
Sep 12 12:10:21 rpi4 NetworkManager[25218]:   [1568304621.9910] device 
(wlan0): supplicant interface state: disconnected -> scanning
Sep 12 12:10:24 rpi4 NetworkManager[25218]:   [1568304624.8102] device 
(wlan0): supplicant interface state: scanning -> disconnected
Sep 12 12:10:25 rpi4 NetworkManager[25218]:   [1568304625.8531] device 
(wlan0): supplicant interface state: disconnected -> scanning
Sep 12 12:10:28 rpi4 NetworkManager[25218]:   [1568304628.6735] device 
(wlan0): supplicant interface state: scanning -> disconnected
Sep 12 12:10:28 rpi4 NetworkManager[25218]:   [1568304628.9667] device 
(wlan0): supplicant interface state: disconnected -> scanning
Sep 12 12:10:40 rpi4 NetworkManager[25218]:   [1568304640.9264] device 
(wlan0): Activation: (wifi) association took too long, failing activation
Sep 12 12:10:40 rpi4 NetworkManager[25218]:   [1568304640.9266] device 
(wlan0): state change: config -> failed (reason 'ssid-not-found', 
sys-iface-state: 'man
Sep 12 12:10:40 rpi4 NetworkManager[25218]:   

[Touch-packages] [Bug 1843755] Re: [FFe] Please accept systemd 242 to Eoan

2019-09-12 Thread Steve Langasek
I do not think this FFe request provides sufficient rationale for why we
would want to make an exception.  (Neither Debian testing having a newer
version, nor "carrying fewer patches", are a compelling reason.)

It also does not include any in-depth analysis of the risks, beyond
saying that 241 is "safer".  If there is no more detailed analysis of
what has changed upstream in 242, then we should default to safer.

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

-- 
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/1843755

Title:
  [FFe] Please accept systemd 242 to Eoan

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing 
moved to 242 last week.
  While version 241 is the safer choice for Eoan (from v241 and v242) since it 
is widely tested updating to v242 will allow us to carry fewer patches in Eoan 
and makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing (except 
for a few unrelated failures):
  https://bileto.ubuntu.com/#/ticket/3797

  The final version will be 242-6ubuntu1 and I'm tidying up the
  changelog, too.

  I plan merging 242-7, too, going forward but this will not need an
  FFe.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1843755/+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 1843766] [NEW] ust ftbfs in eoan

2019-09-12 Thread Matthias Klose
Public bug reported:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include/lttng -I../include 
-I../include -Wdate-time -D_FORTIFY_SOURCE=2 -DUST_COMPONENT=libringbuffer 
-Wall -fno-strict-aliasing -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c 
ring_buffer_backend.c  -fPIC -DPIC -o 
.libs/libringbuffer_la-ring_buffer_backend.o
In file included from ../include/usterr-signal-safe.h:29,
 from frontend_types.h:38,
 from backend_internal.h:31,
 from backend.h:32,
 from ring_buffer_frontend.c:73:
../include/lttng/ust-tid.h:38:21: error: static declaration of ‘gettid’ follows 
non-static declaration
   38 | static inline pid_t gettid(void)
  | ^~
In file included from /usr/include/unistd.h:1170,
 from ring_buffer_frontend.c:59:
/usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note: previous 
declaration of ‘gettid’ was here
   34 | extern __pid_t gettid (void) __THROW;
  |^~
In file included from ../include/usterr-signal-safe.h:29,
 from frontend_types.h:38,
 from backend_internal.h:31,
 from backend.h:32,
 from ring_buffer_backend.c:29:
../include/lttng/ust-tid.h:38:21: error: static declaration of ‘gettid’ follows 
non-static declaration
   38 | static inline pid_t gettid(void)
  | ^~
In file included from /usr/include/unistd.h:1170,
 from ring_buffer_backend.c:23:
/usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note: previous 
declaration of ‘gettid’ was here
   34 | extern __pid_t gettid (void) __THROW;
  |^~
make[3]: *** [Makefile:490: libringbuffer_la-ring_buffer_frontend.lo] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: *** [Makefile:483: libringbuffer_la-ring_buffer_backend.lo] Error 1
make[3]: Leaving directory '/<>/libringbuffer'
make[2]: *** [Makefile:580: all-recursive] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [Makefile:456: all] Error 2

** Affects: ust (Ubuntu)
 Importance: High
 Status: Confirmed


** Tags: ftbfs rls-ee-incoming

** Changed in: ust (Ubuntu)
   Status: New => Confirmed

** Changed in: ust (Ubuntu)
   Importance: Undecided => High

** Tags added: ftbfs rls-ee-incoming

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

Title:
  ust ftbfs in eoan

Status in ust package in Ubuntu:
  Confirmed

Bug description:
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include/lttng 
-I../include -I../include -Wdate-time -D_FORTIFY_SOURCE=2 
-DUST_COMPONENT=libringbuffer -Wall -fno-strict-aliasing -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c ring_buffer_backend.c  -fPIC -DPIC -o 
.libs/libringbuffer_la-ring_buffer_backend.o
  In file included from ../include/usterr-signal-safe.h:29,
   from frontend_types.h:38,
   from backend_internal.h:31,
   from backend.h:32,
   from ring_buffer_frontend.c:73:
  ../include/lttng/ust-tid.h:38:21: error: static declaration of ‘gettid’ 
follows non-static declaration
 38 | static inline pid_t gettid(void)
| ^~
  In file included from /usr/include/unistd.h:1170,
   from ring_buffer_frontend.c:59:
  /usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note: previous 
declaration of ‘gettid’ was here
 34 | extern __pid_t gettid (void) __THROW;
|^~
  In file included from ../include/usterr-signal-safe.h:29,
   from frontend_types.h:38,
   from backend_internal.h:31,
   from backend.h:32,
   from ring_buffer_backend.c:29:
  ../include/lttng/ust-tid.h:38:21: error: static declaration of ‘gettid’ 
follows non-static declaration
 38 | static inline pid_t gettid(void)
| ^~
  In file included from /usr/include/unistd.h:1170,
   from ring_buffer_backend.c:23:
  /usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note: previous 
declaration of ‘gettid’ was here
 34 | extern __pid_t gettid (void) __THROW;
|^~
  make[3]: *** [Makefile:490: libringbuffer_la-ring_buffer_frontend.lo] Error 1
  make[3]: *** Waiting for unfinished jobs
  make[3]: *** [Makefile:483: libringbuffer_la-ring_buffer_backend.lo] Error 1
  make[3]: Leaving directory '/<>/libringbuffer'
  make[2]: *** [Makefile:580: all-recursive] Error 1
  make[2]: Leaving directory '/<>'
  make[1]: *** [Makefile:456: all] Error 2

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

-- 
Mailing list: 

[Touch-packages] [Bug 1812316] Re: systemd: lack of seat verification in PAM module permits spoofing active session to polkit

2019-09-12 Thread Zbigniew Jędrzejewski-Szmek
Upstream fix: https://github.com/systemd/systemd/commit/83d4ab5533 (in
systemd-242).

-- 
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/1812316

Title:
  systemd: lack of seat verification in PAM module permits spoofing
  active session to polkit

Status in systemd package in Ubuntu:
  New

Bug description:
  [I am sending this bug report to Ubuntu as requested by systemd at
  
.]

  As documented at
  , for
  any action, a polkit policy can specify separate levels of required
  authentication based on whether a client is:

   - in an active session on a local console
   - in an inactive session on a local console
   - or neither

  This is expressed in the policy using the elements "allow_any",
  "allow_inactive" and "allow_active". Very roughly speaking, the idea here is
  to give special privileges to processes owned by users that are sitting
  physically in front of the machine (or at least, a keyboard and a screen that
  are connected to a machine), and restrict processes that e.g. belong to users
  that are ssh'ing into a machine.

  For example, the ability to refresh the system's package index is restricted
  this way using a policy in
  /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy:


  [...]
  Refresh system repositories
  [...]
  Authentication is required to refresh the system 
repositories
  [...]
  
auth_admin
auth_admin
yes
  


  
  On systems that use systemd-logind, polkit determines whether a session is
  associated with a local console by checking whether systemd-logind is tracking
  the session as being associated with a "seat". This happens through
  polkit_backend_session_monitor_is_session_local() in
  polkitbackendsessionmonitor-systemd.c, which calls sd_session_get_seat().
  The check whether a session is active works similarly.

  systemd-logind is informed about the creation of new sessions by the PAM
  module pam_systemd through a systemd message bus call from
  pam_sm_open_session() to method_create_session(). The RPC method trusts the
  information supplied to it, apart from some consistency checks; that is not
  directly a problem, since this RPC method can only be invoked by root.
  This means that the PAM module needs to ensure that it doesn't pass incorrect
  data to systemd-logind.

  Looking at the code in the PAM module, however, you can see that the seat name
  of the session and the virtual terminal number come from environment
  variables:

  seat = getenv_harder(handle, "XDG_SEAT", NULL);
  cvtnr = getenv_harder(handle, "XDG_VTNR", NULL);
  type = getenv_harder(handle, "XDG_SESSION_TYPE", type_pam);
  class = getenv_harder(handle, "XDG_SESSION_CLASS", class_pam);
  desktop = getenv_harder(handle, "XDG_SESSION_DESKTOP", desktop_pam);

  This is actually documented at
  
.

  After some fixup logic that is irrelevant here, this data is then passed to
  the RPC method.

  
  One quirk of this issue is that a new session is only created if the calling
  process is not already part of a session (based on the cgroups it is in,
  parsed from procfs). This means that an attacker can't simply ssh into a
  machine, set some environment variables, and then invoke a setuid binary that
  uses PAM (such as "su") because ssh already triggers creation of a session via
  PAM. But as it turns out, the systemd PAM module is only invoked for
  interactive sessions:

  # cat /usr/share/pam-configs/systemd
  Name: Register user sessions in the systemd control group hierarchy
  Default: yes
  Priority: 0
  Session-Interactive-Only: yes
  Session-Type: Additional
  Session:
  optional pam_systemd.so

  So, under the following assumptions:

   - we can run commands on the remote machine, e.g. via SSH
   - our account can be used with "su" (it has a password and isn't disabled)
   - the machine has no X server running and is currently displaying tty1, with
 a login prompt

  we can have our actions checked against the "allow_active" policies instead of
  the "allow_any" policies as follows:

   - SSH into the machine
   - use "at" to schedule a job in one minute that does the following:
 * wipe the environment
 * set XDG_SEAT=seat0 and XDG_VTNR=1
 * use "expect" to run "su -c {...} {our_username}" and enter our user's
   password
 * in the shell invoked by "su", perform the action we want to run under the
   "allow_active" policy

  
  I tested this in a Debian 10 VM, as follows ("{{{...}}}" have been replaced),
  after ensuring that no sessions are active and the VM's screen is showing the
  

[Touch-packages] [Bug 1843757] [NEW] protobuf ftbfs in eoan (ppc64el)

2019-09-12 Thread Matthias Klose
Public bug reported:

https://launchpadlibrarian.net/441264543/buildlog_ubuntu-eoan-
ppc64el.protobuf_3.6.1.3-2_BUILDING.txt.gz

g++ -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -pthread 
-DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall -Wextra -Werror -Wno-unused-parameter -g 
-O3 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o google/protobuf/no_warning_test-any_test.pb.o 
`test -f 'google/protobuf/any_test.pb.cc' || echo 
'./'`google/protobuf/any_test.pb.cc
In file included from /usr/include/string.h:494,
 from ./google/protobuf/stubs/port.h:38,
 from ./google/protobuf/stubs/common.h:46,
 from ./google/protobuf/any_test.pb.h:9,
 from google/protobuf/any_test.pb.cc:4:
In function ‘void* memset(void*, int, size_t)’,
inlined from ‘void protobuf_unittest::TestAny::SharedCtor()’ at 
google/protobuf/any_test.pb.cc:163:11,
inlined from ‘protobuf_unittest::TestAny::TestAny()’ at 
google/protobuf/any_test.pb.cc:145:13,
inlined from ‘void 
protobuf_google_2fprotobuf_2fany_5ftest_2eproto::InitDefaultsTestAny()’ at 
google/protobuf/any_test.pb.cc:141:1:
/usr/include/powerpc64le-linux-gnu/bits/string_fortified.h:71:33: error: ‘void* 
__builtin_memset(void*, int, long unsigned int)’ offset [49, 52] from the 
object at ‘protobuf_unittest::_TestAny_default_instance_’ is out of the bounds 
of referenced subobject ‘protobuf_unittest::TestAny::any_value_’ with type 
‘google::protobuf::Any*’ at offset 40 [-Werror=array-bounds]
   71 |   return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
  |  ~~~^~
cc1plus: all warnings being treated as errors
make[4]: *** [Makefile:4468: google/protobuf/no_warning_test-any_test.pb.o] 
Error 1
make[4]: *** Waiting for unfinished jobs
In file included from /usr/include/string.h:494,
 from ./google/protobuf/stubs/port.h:38,
 from ./google/protobuf/stubs/common.h:46,
 from ./google/protobuf/unittest_lite.pb.h:9,
 from google/protobuf/unittest_lite.pb.cc:4:
In function ‘void* memset(void*, int, size_t)’,
inlined from ‘void 
protobuf_unittest::TestAllTypesLite_NestedMessage::SharedCtor()’ at 
google/protobuf/unittest_lite.pb.cc:792:11,
inlined from 
‘protobuf_unittest::TestAllTypesLite_NestedMessage::TestAllTypesLite_NestedMessage()’
 at google/protobuf/unittest_lite.pb.cc:777:13,
inlined from ‘void 
protobuf_google_2fprotobuf_2funittest_5flite_2eproto::InitDefaultsTestAllTypesLite_NestedMessage()’
 at google/protobuf/unittest_lite.pb.cc:773:1:
/usr/include/powerpc64le-linux-gnu/bits/string_fortified.h:71:33: error: ‘void* 
__builtin_memset(void*, int, long unsigned int)’ offset [33, 36] from the 
object at 
‘protobuf_unittest::_TestAllTypesLite_NestedMessage_default_instance_’ is out 
of the bounds of referenced subobject 
‘protobuf_unittest::TestAllTypesLite_NestedMessage::cc_’ with type ‘long int’ 
at offset 24 [-Werror=array-bounds]
   71 |   return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
  |  ~~~^~
cc1plus: all warnings being treated as errors
make[4]: *** [Makefile:4412: 
google/protobuf/no_warning_test-unittest_lite.pb.o] Error 1
In file included from /usr/include/string.h:494,
 from ./google/protobuf/stubs/port.h:38,
 from ./google/protobuf/stubs/common.h:46,
 from ./google/protobuf/map_lite_unittest.pb.h:9,
 from google/protobuf/map_lite_unittest.pb.cc:4:
In function ‘void* memset(void*, int, size_t)’,
inlined from ‘void protobuf_unittest::TestRequiredLite::SharedCtor()’ at 
google/protobuf/map_lite_unittest.pb.cc:6417:11,
inlined from ‘protobuf_unittest::TestRequiredLite::TestRequiredLite()’ at 
google/protobuf/map_lite_unittest.pb.cc:6394:13,
inlined from ‘void 
protobuf_google_2fprotobuf_2fmap_5flite_5funittest_2eproto::InitDefaultsTestRequiredLite()’
 at google/protobuf/map_lite_unittest.pb.cc:6390:1:
/usr/include/powerpc64le-linux-gnu/bits/string_fortified.h:71:33: error: ‘void* 
__builtin_memset(void*, int, long unsigned int)’ offset [29, 36] from the 
object at ‘protobuf_unittest::_TestRequiredLite_default_instance_’ is out of 
the bounds of referenced subobject ‘protobuf_unittest::TestRequiredLite::a_’ 
with type ‘int’ at offset 24 [-Werror=array-bounds]
   71 |   return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
  |  ~~~^~
cc1plus: all warnings being treated as errors
make[4]: *** [Makefile:4398: 
google/protobuf/no_warning_test-map_lite_unittest.pb.o] Error 1
make[4]: Leaving directory '/<>/src'

** Affects: protobuf (Ubuntu)
 Importance: High
 Status: Confirmed


** Tags: ftbfs rls-ee-incoming

** Changed in: protobuf (Ubuntu)
 

[Touch-packages] [Bug 1843754] [NEW] mir ftbfs in eoan (ppc64el)

2019-09-12 Thread Matthias Klose
Public bug reported:

https://launchpadlibrarian.net/441268300/buildlog_ubuntu-eoan-
ppc64el.mir_1.1.1-0ubuntu3_BUILDING.txt.gz

63% tests passed, 159 tests failed out of 424

Total Test time (real) = 603.12 sec

The following tests FAILED:
  5 - miral_wlcs_tests.BadBufferTest.* (Failed)
  7 - miral_wlcs_tests.CopyCutPaste.* (Failed)
  8 - miral_wlcs_tests.ClientSurfaceEventsTest.* (Failed)
  9 - miral_wlcs_tests.FrameSubmission.* (Failed)
 10 - miral_wlcs_tests.XdgSurfaceV6Test.* (Failed)
 11 - miral_wlcs_tests.XdgToplevelV6Test.* (Failed)
 12 - miral_wlcs_tests.XdgToplevelV6ConfigurationTest.* (Failed)
 13 - miral_wlcs_tests.XdgSurfaceStableTest.* (Failed)
 14 - miral_wlcs_tests.XdgToplevelStableTest.* (Failed)
 15 - miral_wlcs_tests.XdgToplevelStableConfigurationTest.* (Failed)
 16 - miral_wlcs_tests.SelfTest.* (Failed)
 17 - miral_wlcs_tests.TestServer.* (Failed)
 18 - 
miral_wlcs_tests.PointerCrossingSurfaceCorner/SurfacePointerMotionTest.* 
(Failed)
 19 - 
miral_wlcs_tests.PointerCrossingSurfaceEdge/SurfacePointerMotionTest.* (Failed)
 20 - miral_wlcs_tests.WlShellSurface/TouchTest.* (Failed)
 21 - miral_wlcs_tests.XdgShellV6Surface/TouchTest.* (Failed)
 22 - miral_wlcs_tests.XdgShellStableSurface/TouchTest.* (Failed)
 23 - miral_wlcs_tests.Subsurface/TouchTest.* (Failed)
 24 - miral_wlcs_tests.NormalRegion/SurfaceWithInputRegions.* (Failed)
 25 - miral_wlcs_tests.SmallerRegion/SurfaceWithInputRegions.* (Failed)
 26 - miral_wlcs_tests.ClippedLargerRegion/SurfaceWithInputRegions.* 
(Failed)
 27 - miral_wlcs_tests.MultiRectRegionEdges/SurfaceWithInputRegions.* 
(Failed)
 28 - miral_wlcs_tests.MultiRectRegionCorners/SurfaceWithInputRegions.* 
(Failed)
 29 - miral_wlcs_tests.WlShellSurface/SurfaceTypesWithInputRegion.* 
(Failed)
 30 - miral_wlcs_tests.XdgShellV6Surface/SurfaceTypesWithInputRegion.* 
(Failed)
 31 - 
miral_wlcs_tests.XdgShellStableSurface/SurfaceTypesWithInputRegion.* (Failed)
 32 - miral_wlcs_tests.Subsurface/SurfaceTypesWithInputRegion.* (Failed)
 33 - miral_wlcs_tests.WlShellSubsurfaces/SubsurfaceTest.* (Failed)
 34 - miral_wlcs_tests.XdgShellV6Subsurfaces/SubsurfaceTest.* (Failed)
 35 - miral_wlcs_tests.XdgShellStableSubsurfaces/SubsurfaceTest.* 
(Failed)
 36 - miral_wlcs_tests.TouchInputSubsurfaces/SubsurfaceTest.* (Failed)
 37 - miral_wlcs_tests.Default/XdgPopupV6Test.* (Failed)
 38 - miral_wlcs_tests.Anchor/XdgPopupV6Test.* (Failed)
 39 - miral_wlcs_tests.Gravity/XdgPopupV6Test.* (Failed)
 40 - miral_wlcs_tests.AnchorRect/XdgPopupV6Test.* (Failed)
 41 - miral_wlcs_tests.Default/XdgPopupStableTest.* (Failed)
 42 - miral_wlcs_tests.Anchor/XdgPopupStableTest.* (Failed)
 43 - miral_wlcs_tests.Gravity/XdgPopupStableTest.* (Failed)
 44 - miral_wlcs_tests.AnchorRect/XdgPopupStableTest.* (Failed)
 45 - miral_wlcs_tests.ZeroSizeAnchorRect/XdgPopupStableTest.* (Failed)
 46 - mir_acceptance_tests.ServerSignalDeathTest.* (Failed)
 47 - mir_acceptance_tests.ServerShutdownDeathTest.* (Failed)
 48 - mir_acceptance_tests.ServerDisconnectDeathTest.* (Failed)
 49 - mir_acceptance_tests.ClientLibraryErrorsDeathTest.* (Failed)
 50 - mir_acceptance_tests.ServerSignal/AbortDeathTest.* (Timeout)
 51 - mir_acceptance_tests.ServerShutdown/OnSignalDeathTest.* (Timeout)
 52 - mir_acceptance_tests.ClientMediatedUserGestures.* (Failed)
 53 - mir_acceptance_tests.DragAndDrop.* (Failed)
 54 - mir_acceptance_tests.ServerConfigurationWrapping.* (Failed)
 56 - mir_acceptance_tests.ServerSignal.* (Failed)
 57 - mir_acceptance_tests.ServerStopCallback.* (Failed)
 58 - mir_acceptance_tests.ApplicationNotRespondingDetection.* (Failed)
 60 - mir_acceptance_tests.TestClientInput.* (Failed)
 61 - mir_acceptance_tests.TestClientInputKeyRepeat.* (Failed)
 62 - mir_acceptance_tests.TestClientInputWithTwoScreens.* (Failed)
 63 - mir_acceptance_tests.ClientLibraryCallbacks.* (Failed)
 64 - mir_acceptance_tests.ClientLibraryThread.* (Failed)
 65 - mir_acceptance_tests.ClientSurfaceEvents.* (Failed)
 66 - mir_acceptance_tests.ClientSurfaceStartupEvents.* (Failed)
 67 - mir_acceptance_tests.ClientSurfaceCreationResizeEvent.* (Failed)
 68 - mir_acceptance_tests.SurfaceSwapBuffers.* (Failed)
 69 - mir_acceptance_tests.SwapBuffersDoesntBlockOnSubmission.* (Failed)
 71 - mir_acceptance_tests.PointerConfinement.* (Failed)
 72 - mir_acceptance_tests.ClientSurfaces.* (Failed)
 73 - mir_acceptance_tests.ClientLogging.* (Failed)
 74 - mir_acceptance_tests.CustomWindowManagement.* (Failed)
 75 - 

[Touch-packages] [Bug 1843755] [NEW] [FFe] Please accept systemd 242 to Eoan

2019-09-12 Thread Balint Reczey
Public bug reported:

Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing moved 
to 242 last week.
While version 241 is the safer choice for Eoan (from v241 and v242) since it is 
widely tested updating to v242 will allow us to carry fewer patches in Eoan and 
makes moving to the next release easier.

The proposed package is tested in Bileto and all tests are passing (except for 
a few unrelated failures):
https://bileto.ubuntu.com/#/ticket/3797

The final version will be 242-6ubuntu1 and I'm tidying up the changelog,
too.

I plan merging 242-7, too, going forward but this will not need an FFe.

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

-- 
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/1843755

Title:
  [FFe] Please accept systemd 242 to Eoan

Status in systemd package in Ubuntu:
  New

Bug description:
  Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing 
moved to 242 last week.
  While version 241 is the safer choice for Eoan (from v241 and v242) since it 
is widely tested updating to v242 will allow us to carry fewer patches in Eoan 
and makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing (except 
for a few unrelated failures):
  https://bileto.ubuntu.com/#/ticket/3797

  The final version will be 242-6ubuntu1 and I'm tidying up the
  changelog, too.

  I plan merging 242-7, too, going forward but this will not need an
  FFe.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1843755/+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 1843749] [NEW] libseccomp ftbfs in eoan

2019-09-12 Thread Matthias Klose
Public bug reported:

i386, ppc64el, s390x

https://launchpadlibrarian.net/441264120/buildlog_ubuntu-
eoan-i386.libseccomp_2.4.1-0ubuntu0.19.10.3_BUILDING.txt.gz

Regression Test Summary
 tests run: 15896
 tests skipped: 182
 tests passed: 15894
 tests failed: 2
 tests errored: 36

FAIL: regression
== 
1 of 1 test failed
==
make[3]: *** [Makefile:1288: check-TESTS] Error 1

** Affects: libseccomp (Ubuntu)
 Importance: High
 Status: Confirmed


** Tags: ftbfs rls-ee-incoming

** Changed in: libseccomp (Ubuntu)
   Status: New => Confirmed

** Changed in: libseccomp (Ubuntu)
   Importance: Undecided => High

** Tags added: ftbfs rls-ee-incoming

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

Title:
  libseccomp ftbfs in eoan

Status in libseccomp package in Ubuntu:
  Confirmed

Bug description:
  i386, ppc64el, s390x

  https://launchpadlibrarian.net/441264120/buildlog_ubuntu-
  eoan-i386.libseccomp_2.4.1-0ubuntu0.19.10.3_BUILDING.txt.gz

  Regression Test Summary
   tests run: 15896
   tests skipped: 182
   tests passed: 15894
   tests failed: 2
   tests errored: 36
  
  FAIL: regression
  == 
  1 of 1 test failed
  ==
  make[3]: *** [Makefile:1288: check-TESTS] Error 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1843749/+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 1843750] [NEW] libsecret ftbfs in eoan

2019-09-12 Thread Matthias Klose
Public bug reported:

https://launchpadlibrarian.net/441262252/buildlog_ubuntu-eoan-
amd64.libsecret_0.18.8-1_BUILDING.txt.gz


Testsuite summary for libsecret 0.18.8

# TOTAL: 198
# PASS:  13
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 185
==

** Affects: libsecret (Ubuntu)
 Importance: High
 Status: Confirmed


** Tags: ftbfs rls-ee-incoming

** Changed in: libsecret (Ubuntu)
   Status: New => Confirmed

** Changed in: libsecret (Ubuntu)
   Importance: Undecided => High

** Tags added: ftbfs rls-ee-incoming

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

Title:
  libsecret ftbfs in eoan

Status in libsecret package in Ubuntu:
  Confirmed

Bug description:
  https://launchpadlibrarian.net/441262252/buildlog_ubuntu-eoan-
  amd64.libsecret_0.18.8-1_BUILDING.txt.gz

  
  Testsuite summary for libsecret 0.18.8
  
  # TOTAL: 198
  # PASS:  13
  # SKIP:  0
  # XFAIL: 0
  # FAIL:  0
  # XPASS: 0
  # ERROR: 185
  ==

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libsecret/+bug/1843750/+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 1843748] [NEW] liblockfile ftbfs in eoan (i386 only)

2019-09-12 Thread Matthias Klose
Public bug reported:

https://launchpadlibrarian.net/441262641/buildlog_ubuntu-
eoan-i386.liblockfile_1.15-1_BUILDING.txt.gz

gcc -Wl,-Bsymbolic-functions -Wl,-z,relro -fPIC -shared 
-Wl,-soname,liblockfile.so.1 \
-o liblockfile.so lockfile.o -lc
gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -D_GNU_SOURCE -fPIC -D_REENTRANT -I. 
-Wdate-time -D_FORTIFY_SOURCE=2  -c -o dotlockfile.o dotlockfile.c
gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -D_GNU_SOURCE -fPIC -D_REENTRANT -I. -c 
lockfile.c -o xlockfile.o
lockfile.c: In function ‘lockfile_create_save_tmplock’:
lockfile.c:350:9: warning: ignoring return value of ‘link’, declared with 
attribute warn_unused_result [-Wunused-result]
  350 |   (void)link(tmplock, lockfile);
  | ^~~
gcc -Wl,-Bsymbolic-functions -Wl,-z,relro -o dotlockfile dotlockfile.o 
xlockfile.o
./run-tests.sh
lockfile still exists after unlock
make[1]: *** [Makefile:88: test-stamp] Error 1
make[1]: Leaving directory '/<>'
dh_auto_build: make -j1 returned exit code 2
make: *** [debian/rules:7: build-arch] Error 255

** Affects: liblockfile (Ubuntu)
 Importance: High
 Status: Confirmed


** Tags: ftbfs rls-ee-incoming

** Changed in: liblockfile (Ubuntu)
   Status: New => Confirmed

** Changed in: liblockfile (Ubuntu)
   Importance: Undecided => High

** Tags added: ftbfs rls-ee-incoming

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

Title:
  liblockfile ftbfs in eoan (i386 only)

Status in liblockfile package in Ubuntu:
  Confirmed

Bug description:
  https://launchpadlibrarian.net/441262641/buildlog_ubuntu-
  eoan-i386.liblockfile_1.15-1_BUILDING.txt.gz

  gcc -Wl,-Bsymbolic-functions -Wl,-z,relro -fPIC -shared 
-Wl,-soname,liblockfile.so.1 \
-o liblockfile.so lockfile.o -lc
  gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -D_GNU_SOURCE -fPIC -D_REENTRANT -I. 
-Wdate-time -D_FORTIFY_SOURCE=2  -c -o dotlockfile.o dotlockfile.c
  gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -D_GNU_SOURCE -fPIC -D_REENTRANT -I. -c 
lockfile.c -o xlockfile.o
  lockfile.c: In function ‘lockfile_create_save_tmplock’:
  lockfile.c:350:9: warning: ignoring return value of ‘link’, declared with 
attribute warn_unused_result [-Wunused-result]
350 |   (void)link(tmplock, lockfile);
| ^~~
  gcc -Wl,-Bsymbolic-functions -Wl,-z,relro -o dotlockfile dotlockfile.o 
xlockfile.o
  ./run-tests.sh
  lockfile still exists after unlock
  make[1]: *** [Makefile:88: test-stamp] Error 1
  make[1]: Leaving directory '/<>'
  dh_auto_build: make -j1 returned exit code 2
  make: *** [debian/rules:7: build-arch] Error 255

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/liblockfile/+bug/1843748/+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 1843394] Re: FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1 / binutils 2.32.51.20190905-0ubuntu1

2019-09-12 Thread Matthias Klose
** Tags added: ftbfs

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

Title:
  FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1 /
  binutils 2.32.51.20190905-0ubuntu1

Status in binutils package in Ubuntu:
  New
Status in ipxe package in Ubuntu:
  New

Bug description:
  This might be due to new gcc-9 being more strict, but the build that
  worked before now fails with:

  arch/x86_64/core/gdbidt.S: Assembler messages:
  arch/x86_64/core/gdbidt.S:109: Error: operand type mismatch for `push'
  arch/x86_64/core/gdbidt.S:110: Error: operand type mismatch for `push'
  arch/x86_64/core/gdbidt.S:161: Error: operand type mismatch for `pop'
  arch/x86_64/core/gdbidt.S:162: Error: operand type mismatch for `pop'
  make[2]: *** [Makefile.housekeeping:937: bin-x86_64-efi/gdbidt.o] Error 1

  Full log at: https://launchpadlibrarian.net/441262285/buildlog_ubuntu-
  eoan-amd64.ipxe_1.0.0+git-20190109.133f4c4-0ubuntu2_BUILDING.txt.gz

  Now all of this is about push/pop of %fs and %gs.
  That needs to match the size of the registers which depend on the current 
running mode.

  In this particular case in ./src/arch/x86_64/core/gdbidt.S
  The failing file is in ".code64" mode.
  In that I'd expect %gs/%fs to be 64 bit.

  
  Usually we see push/pop "w" in .code16 (word), l in .code32 (long) but in 
that sense here q (quad word) seems right at first (should be what correctly 
matches the .code64).
  That matches what I see throughout the ipxe code but also throughout the 
archive 
https://codesearch.debian.net/search?q=pop%5Ba-z%5D.*%25fs=0=2

  Maybe I misread the mode it is in, or it is actually a false positives.
  Or the sizes of FS/GS do not change - haven't touched them in a lng time.
  Was it that segment registers didn't change size?
  I'll need to do a few checks to first see what the compiler would expect 
there and from there need to understand this.

  The command used also points to AS being in 64 bit mode when this happens:
  gcc -E  -DARCH=x86_64 -DPLATFORM=efi -DSECUREBOOT=0 -fstrength-reduce 
-fomit-frame-pointer -falign-jumps=1 -falign-loops=1 -falign-functions=1 -m64 
-mno-mmx -mno-sse -fshort-wchar -Ui386 -Ulinux -DNVALGRIND -fpie -mno-red-zone 
-Iinclude -I. -Iarch/x86/include -Iarch/x86_64/include 
-Iarch/x86_64/include/efi -Os -g -ffreestanding -Wall -W -Wformat-nonliteral  
-fno-stack-protector -fno-dwarf2-cfi-asm -fno-exceptions  -fno-unwind-tables 
-fno-asynchronous-unwind-tables -Wno-address -Wno-stringop-truncation   
-ffunction-sections -fdata-sections -include include/compiler.h -DASM_TCHAR='@' 
-DASM_TCHAR_OPS='@' -DASSEMBLY  -DOBJECT=gdbidt arch/x86_64/core/gdbidt.S | as  
--64-o bin-x86_64-efi/gdbidt.o

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1843394/+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 1842643] Re: [ffe] Update to 1.44.6

2019-09-12 Thread Iain Lane
Feel free then, I'm just really unsure personally about us being able to
fix regressions, but if you think that is an OK risk then fine.

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

Title:
  [ffe] Update to 1.44.6

Status in pango1.0 package in Ubuntu:
  New

Bug description:
  There are a lot of changes in pango1.0 since the version we currently
  have in eoan. We held off updating because there was a test failure.
  This has been resolved in the latest release, so we'd like to go for
  the update now.

  Overview of changes in 1.44.6
  =
  - docs: Fix symbol indices
  - Fix Thai line breaking
  - Re-add symbols needed by some bindings
  - Don't insert hyphens for some languages
  - Fix a crash with hyphenation

  Overview of changes in 1.44.5
  =
  - Revert a broken change (causing crashes on OS X)

  Overview of changes in 1.44.4
  =
  - Add an insert-hyphens attribute
  - Reinstate the return type of pango_fc_font_lock_face
  - Fix a problem with ellipses getting the wrong font
  - fc: Improve filtering by font format
  - Re-add PangoFcFont to public headers
  - Install PangoFc and PangoOT introspection files
  - Fix ink rectangles to have positive height
  - Fix mark positioning
  - Switch to using harfbuzz for metrics

  Overview of changes in 1.44.3
  =
  - Install pango-ot headers
  - Make subpixel positioning optional
  - fc: Ignore fonts with unsupported formats

  Overview of changes in 1.44.2
  =
  - Disable ligatures when letterspacing
  - Set design coords on hb_font_t
  - Expose more font options in pango-view
  - OS X: Make 'system-ui' font work
  - Keep deprecated pango-fc apis in headers
  - Make hex boxes work, always
  - introspection: Various build fixes
  - introspection: Add PangoPT, PangoFT2 namespaces
  - layout: Make the new line-spacing opt-in

  Overview of changes in 1.44.1
  =
  - Fix a crash with allow_break attributes
  - Fix Emoji spacing
  - Fix up includes and pkg-config requires
  - Correct some cases for hyphen insertion

  Overview of changes in 1.44.0
  =
  - Use harfbuzz for shaping on all platforms
  - Stop using freetype for font loading; this
  drops support for type1 and bitmap fonts
  - Add a getter for hb_font_t
  - Make PangoCoverage a GObject
  - Add a pango_tailor_break api
  - font metrics: Add line height
  - layout: Support line spacing
  - layout: Draw hyphens for line breaks
  - Add an attribute to suppress line breaking
  - cairo: Don't render hex boxes for space
  - Add an attribute to show invisible characters
  - Stop quantizing glyph positions
  - Add tests for itemization and line breaking
  - Remove language and shape engine remnants
  - Rename meson options: gtk_doc, introspection
  - Require GLib 2.59.2
  - Require Harfbuzz 2.0

  Overview of changes in 1.43.0
  =
  - Drop autotools
  - Drop Visual Studio build
  - Build with meson everywhere
  - Update Emoji tables for Unicode 11
  - Update test data for Unicode 11
  - Fix a crash with Thai breaking
  - Fix a crash with font variations
  - Deprecate bidi apis in favor of fribidi
  - Add a variable font family api
  - Improve font fallback handling on win32

  And see posts from upstream

  https://blogs.gnome.org/mclasen/2019/07/19/pango-updates/
  https://blogs.gnome.org/mclasen/2019/07/27/more-text-rendering-updates/
  https://blogs.gnome.org/mclasen/2019/08/07/pango-1-44-wrap-up/

  for the new features.

  We'd like to update to it, if possible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/1842643/+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 1843743] [NEW] klibc ftbfs in eoan

2019-09-12 Thread Matthias Klose
Public bug reported:

https://launchpadlibrarian.net/441262209/buildlog_ubuntu-eoan-
amd64.klibc_2.0.6-1ubuntu1_BUILDING.txt.gz

gcc -Wp,-MD,usr/klibc/.sigsuspend.o.d  -nostdinc -iwithprefix include 
-I/<>/usr/include/arch/x86_64 -Iusr/include/arch/x86_64 
-I/<>/usr/include/bits64 -Iusr/include/bits64 
-I/<>/usr/klibc/../include -Iusr/klibc/../include 
-I/<>/usr/include -Iusr/include -I/<>/linux/include 
-Ilinux/include -D__KLIBC__=2 -D__KLIBC_MINOR__=0 -D_BITSIZE=64 
-fno-stack-protector -fwrapv -fno-PIE -ggdb -m64 -Os -fomit-frame-pointer 
-mno-sse -falign-functions=1 -falign-jumps=1 -falign-loops=1 
-fno-asynchronous-unwind-tables -W -Wall -Wno-sign-compare 
-Wno-unused-parameter -c -o usr/klibc/sigsuspend.o usr/klibc/sigsuspend.c
usr/klibc/sigsuspend.c:8:10: fatal error: klibc/havesyscall.h: No such file or 
directory
8 | #include 
  |  ^
compilation terminated.
make[4]: *** [/<>/scripts/Kbuild.klibc:252: 
usr/klibc/sigsuspend.o] Error 1
make[3]: *** [/<>/./Kbuild:9: all] Error 2
make[2]: *** [Makefile:118: klibc] Error 2

** Affects: klibc (Ubuntu)
 Importance: High
 Status: Confirmed


** Tags: ftbfs rls-ee-incoming

** Changed in: klibc (Ubuntu)
   Status: New => Confirmed

** Changed in: klibc (Ubuntu)
   Importance: Undecided => High

** Tags added: ftbfs rls-ee-incoming

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

Title:
  klibc ftbfs in eoan

Status in klibc package in Ubuntu:
  Confirmed

Bug description:
  https://launchpadlibrarian.net/441262209/buildlog_ubuntu-eoan-
  amd64.klibc_2.0.6-1ubuntu1_BUILDING.txt.gz

  gcc -Wp,-MD,usr/klibc/.sigsuspend.o.d  -nostdinc -iwithprefix include 
-I/<>/usr/include/arch/x86_64 -Iusr/include/arch/x86_64 
-I/<>/usr/include/bits64 -Iusr/include/bits64 
-I/<>/usr/klibc/../include -Iusr/klibc/../include 
-I/<>/usr/include -Iusr/include -I/<>/linux/include 
-Ilinux/include -D__KLIBC__=2 -D__KLIBC_MINOR__=0 -D_BITSIZE=64 
-fno-stack-protector -fwrapv -fno-PIE -ggdb -m64 -Os -fomit-frame-pointer 
-mno-sse -falign-functions=1 -falign-jumps=1 -falign-loops=1 
-fno-asynchronous-unwind-tables -W -Wall -Wno-sign-compare 
-Wno-unused-parameter -c -o usr/klibc/sigsuspend.o usr/klibc/sigsuspend.c
  usr/klibc/sigsuspend.c:8:10: fatal error: klibc/havesyscall.h: No such file 
or directory
  8 | #include 
|  ^
  compilation terminated.
  make[4]: *** [/<>/scripts/Kbuild.klibc:252: 
usr/klibc/sigsuspend.o] Error 1
  make[3]: *** [/<>/./Kbuild:9: all] Error 2
  make[2]: *** [Makefile:118: klibc] Error 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1843743/+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 1843733] [NEW] fftw3 ftbfs in eoan (armhf only)

2019-09-12 Thread Matthias Klose
Public bug reported:

fftw3 ftbfs in eoan (armhf only).

https://launchpadlibrarian.net/441265031/buildlog_ubuntu-eoan-
armhf.fftw3_3.3.8-2_BUILDING.txt.gz

( cd tests ; /usr/bin/make smallcheck )
make[1]: Entering directory '/<>/tests'
perl -w ./check.pl -r -c=1 -v `pwd`/bench
Executing "/<>/tests/bench --verbose=1   --verify 'ok7e10x12bv29' 
--verify 'ik7e10x12bv29' --verify '//obr2304' --verify '//ibr2304' --verify 
'//ofr2304' --verify '//ifr2304' --verify 'obr2304' --verify 'ibr2304' --verify 
'ofr2304' --verify 'ifr2304' --verify '//obc2304' --verify '//ibc2304' --verify 
'//ofc2304' --verify '//ifc2304' --verify 'obc2304' --verify 'ibc2304' --verify 
'ofc2304' --verify 'ifc2304'"
ok7e10x12bv29 1.71318e-07 1.44516e-06 2.00887e-07
ik7e10x12bv29 1.66737e-07 1.44901e-06 1.76717e-07
Segmentation fault (core dumped)
FAILED /<>/tests/bench:  --verify 'ok7e10x12bv29' --verify 
'ik7e10x12bv29' --verify '//obr2304' --verify '//ibr2304' --verify '//ofr2304' 
--verify '//ifr2304' --verify 'obr2304' --verify 'ibr2304' --verify 'ofr2304' 
--verify 'ifr2304' --verify '//obc2304' --verify '//ibc2304' --verify 
'//ofc2304' --verify '//ifc2304' --verify 'obc2304' --verify 'ibc2304' --verify 
'ofc2304' --verify 'ifc2304'
make[1]: *** [Makefile:723: smallcheck] Error 1
make[1]: Leaving directory '/<>/tests'

** Affects: fftw3 (Ubuntu)
 Importance: High
 Status: Confirmed


** Tags: ftbfs rls-ee-incoming

** Changed in: fftw3 (Ubuntu)
   Status: New => Confirmed

** Changed in: fftw3 (Ubuntu)
   Importance: Undecided => High

** Tags added: ftbfs rls-ee-incoming

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

Title:
  fftw3 ftbfs in eoan (armhf only)

Status in fftw3 package in Ubuntu:
  Confirmed

Bug description:
  fftw3 ftbfs in eoan (armhf only).

  https://launchpadlibrarian.net/441265031/buildlog_ubuntu-eoan-
  armhf.fftw3_3.3.8-2_BUILDING.txt.gz

  ( cd tests ; /usr/bin/make smallcheck )
  make[1]: Entering directory '/<>/tests'
  perl -w ./check.pl -r -c=1 -v `pwd`/bench
  Executing "/<>/tests/bench --verbose=1   --verify 
'ok7e10x12bv29' --verify 'ik7e10x12bv29' --verify '//obr2304' --verify 
'//ibr2304' --verify '//ofr2304' --verify '//ifr2304' --verify 'obr2304' 
--verify 'ibr2304' --verify 'ofr2304' --verify 'ifr2304' --verify '//obc2304' 
--verify '//ibc2304' --verify '//ofc2304' --verify '//ifc2304' --verify 
'obc2304' --verify 'ibc2304' --verify 'ofc2304' --verify 'ifc2304'"
  ok7e10x12bv29 1.71318e-07 1.44516e-06 2.00887e-07
  ik7e10x12bv29 1.66737e-07 1.44901e-06 1.76717e-07
  Segmentation fault (core dumped)
  FAILED /<>/tests/bench:  --verify 'ok7e10x12bv29' --verify 
'ik7e10x12bv29' --verify '//obr2304' --verify '//ibr2304' --verify '//ofr2304' 
--verify '//ifr2304' --verify 'obr2304' --verify 'ibr2304' --verify 'ofr2304' 
--verify 'ifr2304' --verify '//obc2304' --verify '//ibc2304' --verify 
'//ofc2304' --verify '//ifc2304' --verify 'obc2304' --verify 'ibc2304' --verify 
'ofc2304' --verify 'ifc2304'
  make[1]: *** [Makefile:723: smallcheck] Error 1
  make[1]: Leaving directory '/<>/tests'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fftw3/+bug/1843733/+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 1842643] Re: [ffe] Update to 1.44.6

2019-09-12 Thread Sebastien Bacher
I'm unsure we have someone in the team/around who knows enough about
font rendering to weigh in.  I would go forward now with the update
because I feel like it's a safer road for the LTS to land changes
earlier than later, that time we get one buffer nonLTS cycle to get
feedback sort out issues (also based on the fact that even if there are
bugs they aren't obvious on a default installation and we can still fix
special cases between now and release or in a SRU)

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

Title:
  [ffe] Update to 1.44.6

Status in pango1.0 package in Ubuntu:
  New

Bug description:
  There are a lot of changes in pango1.0 since the version we currently
  have in eoan. We held off updating because there was a test failure.
  This has been resolved in the latest release, so we'd like to go for
  the update now.

  Overview of changes in 1.44.6
  =
  - docs: Fix symbol indices
  - Fix Thai line breaking
  - Re-add symbols needed by some bindings
  - Don't insert hyphens for some languages
  - Fix a crash with hyphenation

  Overview of changes in 1.44.5
  =
  - Revert a broken change (causing crashes on OS X)

  Overview of changes in 1.44.4
  =
  - Add an insert-hyphens attribute
  - Reinstate the return type of pango_fc_font_lock_face
  - Fix a problem with ellipses getting the wrong font
  - fc: Improve filtering by font format
  - Re-add PangoFcFont to public headers
  - Install PangoFc and PangoOT introspection files
  - Fix ink rectangles to have positive height
  - Fix mark positioning
  - Switch to using harfbuzz for metrics

  Overview of changes in 1.44.3
  =
  - Install pango-ot headers
  - Make subpixel positioning optional
  - fc: Ignore fonts with unsupported formats

  Overview of changes in 1.44.2
  =
  - Disable ligatures when letterspacing
  - Set design coords on hb_font_t
  - Expose more font options in pango-view
  - OS X: Make 'system-ui' font work
  - Keep deprecated pango-fc apis in headers
  - Make hex boxes work, always
  - introspection: Various build fixes
  - introspection: Add PangoPT, PangoFT2 namespaces
  - layout: Make the new line-spacing opt-in

  Overview of changes in 1.44.1
  =
  - Fix a crash with allow_break attributes
  - Fix Emoji spacing
  - Fix up includes and pkg-config requires
  - Correct some cases for hyphen insertion

  Overview of changes in 1.44.0
  =
  - Use harfbuzz for shaping on all platforms
  - Stop using freetype for font loading; this
  drops support for type1 and bitmap fonts
  - Add a getter for hb_font_t
  - Make PangoCoverage a GObject
  - Add a pango_tailor_break api
  - font metrics: Add line height
  - layout: Support line spacing
  - layout: Draw hyphens for line breaks
  - Add an attribute to suppress line breaking
  - cairo: Don't render hex boxes for space
  - Add an attribute to show invisible characters
  - Stop quantizing glyph positions
  - Add tests for itemization and line breaking
  - Remove language and shape engine remnants
  - Rename meson options: gtk_doc, introspection
  - Require GLib 2.59.2
  - Require Harfbuzz 2.0

  Overview of changes in 1.43.0
  =
  - Drop autotools
  - Drop Visual Studio build
  - Build with meson everywhere
  - Update Emoji tables for Unicode 11
  - Update test data for Unicode 11
  - Fix a crash with Thai breaking
  - Fix a crash with font variations
  - Deprecate bidi apis in favor of fribidi
  - Add a variable font family api
  - Improve font fallback handling on win32

  And see posts from upstream

  https://blogs.gnome.org/mclasen/2019/07/19/pango-updates/
  https://blogs.gnome.org/mclasen/2019/07/27/more-text-rendering-updates/
  https://blogs.gnome.org/mclasen/2019/08/07/pango-1-44-wrap-up/

  for the new features.

  We'd like to update to it, if possible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/1842643/+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 1843430] Re: FTBFS in Eoan due to new glibc - error: ‘SIOCGSTAMP’ undeclared

2019-09-12 Thread Matthias Klose
** Tags added: ftbfs

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

Title:
  FTBFS in Eoan due to new glibc - error: ‘SIOCGSTAMP’ undeclared

Status in dnsmasq package in Ubuntu:
  In Progress

Bug description:
  We hit this on a rebuild in Eoan
  dhcp.c: In function ‘dhcp_packet’:
  dhcp.c:182:17: error: ‘SIOCGSTAMP’ undeclared (first use in this function); 
did you mean ‘SIOCGARP’?
    182 |   if (ioctl(fd, SIOCGSTAMP, ) == 0)
    | ^~
    | SIOCGARP

  This seems much like the fix in the (not yet released) upstream repo:
  => 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3052ce208acf602f0163166dcefb7330d537cedb

  "Fix build after y2038 changes in glib.
  SIOCGSTAMP is defined in linux/sockios.h, not asm/sockios.h now."

  Failed build log: https://launchpadlibrarian.net/441262561
  /buildlog_ubuntu-eoan-amd64.dnsmasq_2.80-1ubuntu1_BUILDING.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1843430/+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 1843730] [NEW] dee ftbfs in eoan (all architectures)

2019-09-12 Thread Matthias Klose
Public bug reported:

https://launchpadlibrarian.net/441262638/buildlog_ubuntu-eoan-
amd64.dee_1.2.7+17.10.20170616-4ubuntu1_BUILDING.txt.gz

deprecated glib/gtk symbols

** Affects: dee (Ubuntu)
 Importance: High
 Status: Confirmed


** Tags: ftbfs rls-ee-incoming

** Tags added: ftbfs rls-ee-incoming

** Changed in: dee (Ubuntu)
   Status: New => Confirmed

** Changed in: dee (Ubuntu)
   Importance: Undecided => High

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

Title:
  dee ftbfs in eoan (all architectures)

Status in dee package in Ubuntu:
  Confirmed

Bug description:
  https://launchpadlibrarian.net/441262638/buildlog_ubuntu-eoan-
  amd64.dee_1.2.7+17.10.20170616-4ubuntu1_BUILDING.txt.gz

  deprecated glib/gtk symbols

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dee/+bug/1843730/+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 1829860] Re: APT unlocks in same order as it locks

2019-09-12 Thread Launchpad Bug Tracker
This bug was fixed in the package apt - 1.8.3

---
apt (1.8.3) unstable; urgency=medium

  [ Simon Körner ]
  * http: Fix Host header in proxied https connections (LP: #1838771)

  [ Brian Murray ]
  * Do not include squashfs file systems in df output. (LP: #1756595)

apt (1.8.2) unstable; urgency=medium

  [ Alwin Henseler ]
  * Flip /: in documented default value of DPkg::Path (Closes: #917986)

  [ TilmanK ]
  * Fix typo in German manpage translation

  [ Américo Monteiro ]
  * Portuguese manpages translation update (Closes: #926614)

  [ Jean-Pierre Giraud ]
  * French manpages translation update (Closes: #929290)

  [ Michael Zhivich ]
  * methods: https: handle requests for TLS re-handshake (LP: #1829861)

  [ Julian Andres Klode ]
  * Unlock dpkg locks in reverse locking order (LP: #1829860)

 -- Julian Andres Klode   Fri, 09 Aug 2019 11:16:15
+0200

** Changed in: apt (Ubuntu Disco)
   Status: Fix Committed => Fix Released

-- 
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/1829860

Title:
  APT unlocks in same order as it locks

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Xenial:
  New
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released

Bug description:
  [Impact]
  APT releases the locks in the same order it acquires them, rather than 
reverse order. Given that we have no waiting for locks, this is not _super_ 
problematic, but it might be wrong: You'd get a lock failure on dpkg's lock, 
rather than lock-frontend.

  [Test case]
  Watch lock release with strace and see that it unlocks the right way.

  [Regression potential]
  Some other locking races or something?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829860/+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 1829861] Re: handle TLS session renegotiation

2019-09-12 Thread Launchpad Bug Tracker
This bug was fixed in the package apt - 1.8.3

---
apt (1.8.3) unstable; urgency=medium

  [ Simon Körner ]
  * http: Fix Host header in proxied https connections (LP: #1838771)

  [ Brian Murray ]
  * Do not include squashfs file systems in df output. (LP: #1756595)

apt (1.8.2) unstable; urgency=medium

  [ Alwin Henseler ]
  * Flip /: in documented default value of DPkg::Path (Closes: #917986)

  [ TilmanK ]
  * Fix typo in German manpage translation

  [ Américo Monteiro ]
  * Portuguese manpages translation update (Closes: #926614)

  [ Jean-Pierre Giraud ]
  * French manpages translation update (Closes: #929290)

  [ Michael Zhivich ]
  * methods: https: handle requests for TLS re-handshake (LP: #1829861)

  [ Julian Andres Klode ]
  * Unlock dpkg locks in reverse locking order (LP: #1829860)

 -- Julian Andres Klode   Fri, 09 Aug 2019 11:16:15
+0200

** Changed in: apt (Ubuntu Disco)
   Status: Fix Committed => Fix Released

-- 
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/1829861

Title:
  handle TLS session renegotiation

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released
Status in apt source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  TLS sessions can renegotiate keys, but APT does not support it; meaning their 
HTTPS connections stop working.

  [Test case]
  We don't really have a reproducer. You'd need a server that re-negotiates by 
path; e.g. because it requires a a certain client certificate for a certain 
path.

  We know it does not break other use cases, having run that for quite
  some time in eoan and Debian stretch, and the patch was tested by the
  patch submitter @ Akamai (see https://github.com/Debian/apt/pull/93).

  [Regression potential]
  - Could we get stuck on renegotiation?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829861/+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 1829860] Update Released

2019-09-12 Thread Łukasz Zemczak
The verification of the Stable Release Update for apt has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
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/1829860

Title:
  APT unlocks in same order as it locks

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Xenial:
  New
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released

Bug description:
  [Impact]
  APT releases the locks in the same order it acquires them, rather than 
reverse order. Given that we have no waiting for locks, this is not _super_ 
problematic, but it might be wrong: You'd get a lock failure on dpkg's lock, 
rather than lock-frontend.

  [Test case]
  Watch lock release with strace and see that it unlocks the right way.

  [Regression potential]
  Some other locking races or something?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829860/+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 1838771] Re: http:Fix Host header in proxied https connections

2019-09-12 Thread Launchpad Bug Tracker
This bug was fixed in the package apt - 1.8.3

---
apt (1.8.3) unstable; urgency=medium

  [ Simon Körner ]
  * http: Fix Host header in proxied https connections (LP: #1838771)

  [ Brian Murray ]
  * Do not include squashfs file systems in df output. (LP: #1756595)

apt (1.8.2) unstable; urgency=medium

  [ Alwin Henseler ]
  * Flip /: in documented default value of DPkg::Path (Closes: #917986)

  [ TilmanK ]
  * Fix typo in German manpage translation

  [ Américo Monteiro ]
  * Portuguese manpages translation update (Closes: #926614)

  [ Jean-Pierre Giraud ]
  * French manpages translation update (Closes: #929290)

  [ Michael Zhivich ]
  * methods: https: handle requests for TLS re-handshake (LP: #1829861)

  [ Julian Andres Klode ]
  * Unlock dpkg locks in reverse locking order (LP: #1829860)

 -- Julian Andres Klode   Fri, 09 Aug 2019 11:16:15
+0200

** Changed in: apt (Ubuntu Disco)
   Status: Fix Committed => Fix Released

-- 
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/1838771

Title:
  http:Fix Host header in proxied https connections

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released

Bug description:
  [Impact]

  Currently CONNECT requests use the name of the proxy as Host value,
  instead of the origin server's name.

  According to RFC 2616 "The Host field value MUST represent the naming
  authority of the origin server or gateway given by the original URL."

  The current implementation causes problems with some proxy vendors. This
  commit[0] fixes this.

  [0] - https://salsa.debian.org/apt-
  
team/apt/commit/86d4d98060f36c7e71c34af20a1193a75496ef72#54d3193c5d10a0032c80c3a6d3f069507265547f

  [Test Case]

  Here's one reproducer an impacted user brought to my attention:

  # /etc/environment
  http_proxy="http://internal:8080;
  https_proxy="http://interal:8080;

  To support application development activities in-house, I had to
  configure Azure CLI APT repository following the instructions from
  "https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view
  =azure-cli-latest":

  $ sudo apt-get update
  $ sudo apt-get install curl apt-transport-https lsb-release gnupg
  $ curl -sL https://packages.microsoft.com/keys/microsoft.asc | \
  $ gpg --dearmor | \
  $ sudo tee /etc/apt/trusted.gpg.d/microsoft.asc.gpg > /dev/null
  $ AZ_REPO=$(lsb_release -cs)
  $ echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $ $ 
AZ_REPO main" | \
  $ sudo tee /etc/apt/sources.list.d/azure-cli.list
  $ sudo apt update

  In the final "apt update" command, APT respects system-wide network
  proxy variables and successfully fetched Canonical repository data
  over HTTP.

  However, it was unable to fetch the newly added Microsoft packages
  repository served via HTTPS.

  By using Wireshark to examine the HTTPS request made by APT, the
  request body reveals as:

  CONNECT packages.microsoft.com:443 HTTP/1.1\r\n
  Host: internal:8080\r\n
  User-Agent: Debian APT-HTTP/1.3 (1.6.11)\r\n
  ...
  ...

  There also is an automated test case in the package that runs as part
  of autopkgtest that tests a scenario like this, see the commit.

  [Regression Potential]

  * Fix already in debian, and Eoan
  * Has been reviewed/approved by juliank
  * A test package (pre-sru) has been provided to an impacted user, and he 
confirms it solves the situation.

  [Other Info]

  # salsa
  $ git describe --contains 86d4d98060f36c7e71c34af20a1193a75496ef72
  1.9.0~8

  # rmadison apt
  => apt | 1.6.11 | bionic-updates | source, amd64, arm64, armhf, i386, 
ppc64el, s390x
  => apt | 1.8.1 | disco-updates | source, amd64, arm64, armhf, i386, ppc64el, 
s390x
  apt | 1.9.1 | eoan | source, amd64, arm64, armhf, i386, ppc64el, s390x

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1838771/+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 1756595] Update Released

2019-09-12 Thread Łukasz Zemczak
The verification of the Stable Release Update for apt has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
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/1756595

Title:
  disk space info inadvertently provides all installed snaps

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released
Status in apt source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  When apport is reporting a crash, it includes the output of the "df" utility, 
to list the free disk space information per mount point.

  That output nowadays will inadvertently include all snaps that the
  user may have installed, including their revision numbers.

  Here is a simple df output:
  andreas@nsn7:~$ df
  Filesystem  1K-blocksUsed Available Use% Mounted on
  udev  8119680   0   8119680   0% /dev
  tmpfs 16301561828   1628328   1% /run
  nsn7/ROOT/ubuntu433084288 2500608 430583680   1% /
  tmpfs 8150776   1   8131888   1% /dev/shm
  tmpfs5120   4  5116   1% /run/lock
  tmpfs 8150776   0   8150776   0% 
/sys/fs/cgroup
  nsn7/var/log430763136  179456 430583680   1% /var/log
  nsn7/var/tmp430583808 128 430583680   1% /var/tmp
  /dev/sda2 1032088  160336871752  16% /boot
  /dev/sda1  5232482720520528   1% /boot/efi
  nsn7/home   430651264   67584 430583680   1% /home
  nsn7/var/cache  430653312   69632 430583680   1% /var/cache
  nsn7/var/mail   430583808 128 430583680   1% /var/mail
  nsn7/var/spool  430583808 128 430583680   1% /var/spool
  tmpfs 1630152  16   1630136   1% /run/user/120
  tmpfs 100   0   100   0% 
/var/lib/lxd/shmounts
  tmpfs 100   0   100   0% 
/var/lib/lxd/devlxd
  tmpfs 1630152  36   1630116   1% 
/run/user/1000
  nsn7/lxd/containers/squid-ds216 431444096  860416 430583680   1% 
/var/lib/lxd/storage-pools/default/containers/squid-ds216
  /dev/loop0  83712   83712 0 100% 
/snap/core/4206
  /dev/loop1 102144  102144 0 100% 
/snap/git-ubuntu/402

  You can see I have the core snap at revision 4206, and git-ubuntu at
  revision 402.

  There are already many bug reports in launchpad where one can see this
  information.

  Granted, the user can review it, refuse to send this data, etc. This
  bug is about the unexpectedness of having that information in the disk
  space data.

  If the user sees a prompt like "Would you like to include disk free
  space information in your report?", or "Would you like to include the
  output of the df(1) command in your report?", that doesn't immediately
  translate to "Would you like to include disk free space information
  and a list of all installed snaps and their revision numbers in your
  report?".

  [Test case]
  Do something that triggers the apport hook and make sure you don't see snaps 
in there.

  For example, install xterm, then add exit 1 to the start of the prerm,
  then run apt remove xterm, and investigate /var/crash/xterm.0.crash
  after that (delete before running apt).

  [Regression potential]
  Fix consists of adding -x squashfs to df output, so might hide other non-snap 
squashfs images.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1756595/+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 1829861] Re: handle TLS session renegotiation

2019-09-12 Thread Launchpad Bug Tracker
This bug was fixed in the package apt - 1.6.12

---
apt (1.6.12) bionic; urgency=medium

  [ TilmanK ]
  * Fix typo in German manpage translation

  [ Michael Zhivich ]
  * methods: https: handle requests for TLS re-handshake (LP: #1829861)

  [ Julian Andres Klode ]
  * Unlock dpkg locks in reverse locking order (LP: #1829860)

  [ Simon Körner ]
  * http: Fix Host header in proxied https connections (LP: #1838771)

  [ Brian Murray ]
  * Do not include squashfs file systems in df output. (LP: #1756595)

 -- Julian Andres Klode   Tue, 03 Sep 2019 12:05:35
+0200

** Changed in: apt (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

-- 
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/1829861

Title:
  handle TLS session renegotiation

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released
Status in apt source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  TLS sessions can renegotiate keys, but APT does not support it; meaning their 
HTTPS connections stop working.

  [Test case]
  We don't really have a reproducer. You'd need a server that re-negotiates by 
path; e.g. because it requires a a certain client certificate for a certain 
path.

  We know it does not break other use cases, having run that for quite
  some time in eoan and Debian stretch, and the patch was tested by the
  patch submitter @ Akamai (see https://github.com/Debian/apt/pull/93).

  [Regression potential]
  - Could we get stuck on renegotiation?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829861/+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 1756595] Re: disk space info inadvertently provides all installed snaps

2019-09-12 Thread Launchpad Bug Tracker
This bug was fixed in the package apt - 1.8.3

---
apt (1.8.3) unstable; urgency=medium

  [ Simon Körner ]
  * http: Fix Host header in proxied https connections (LP: #1838771)

  [ Brian Murray ]
  * Do not include squashfs file systems in df output. (LP: #1756595)

apt (1.8.2) unstable; urgency=medium

  [ Alwin Henseler ]
  * Flip /: in documented default value of DPkg::Path (Closes: #917986)

  [ TilmanK ]
  * Fix typo in German manpage translation

  [ Américo Monteiro ]
  * Portuguese manpages translation update (Closes: #926614)

  [ Jean-Pierre Giraud ]
  * French manpages translation update (Closes: #929290)

  [ Michael Zhivich ]
  * methods: https: handle requests for TLS re-handshake (LP: #1829861)

  [ Julian Andres Klode ]
  * Unlock dpkg locks in reverse locking order (LP: #1829860)

 -- Julian Andres Klode   Fri, 09 Aug 2019 11:16:15
+0200

** Changed in: apt (Ubuntu Disco)
   Status: Fix Committed => Fix Released

-- 
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/1756595

Title:
  disk space info inadvertently provides all installed snaps

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released
Status in apt source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  When apport is reporting a crash, it includes the output of the "df" utility, 
to list the free disk space information per mount point.

  That output nowadays will inadvertently include all snaps that the
  user may have installed, including their revision numbers.

  Here is a simple df output:
  andreas@nsn7:~$ df
  Filesystem  1K-blocksUsed Available Use% Mounted on
  udev  8119680   0   8119680   0% /dev
  tmpfs 16301561828   1628328   1% /run
  nsn7/ROOT/ubuntu433084288 2500608 430583680   1% /
  tmpfs 8150776   1   8131888   1% /dev/shm
  tmpfs5120   4  5116   1% /run/lock
  tmpfs 8150776   0   8150776   0% 
/sys/fs/cgroup
  nsn7/var/log430763136  179456 430583680   1% /var/log
  nsn7/var/tmp430583808 128 430583680   1% /var/tmp
  /dev/sda2 1032088  160336871752  16% /boot
  /dev/sda1  5232482720520528   1% /boot/efi
  nsn7/home   430651264   67584 430583680   1% /home
  nsn7/var/cache  430653312   69632 430583680   1% /var/cache
  nsn7/var/mail   430583808 128 430583680   1% /var/mail
  nsn7/var/spool  430583808 128 430583680   1% /var/spool
  tmpfs 1630152  16   1630136   1% /run/user/120
  tmpfs 100   0   100   0% 
/var/lib/lxd/shmounts
  tmpfs 100   0   100   0% 
/var/lib/lxd/devlxd
  tmpfs 1630152  36   1630116   1% 
/run/user/1000
  nsn7/lxd/containers/squid-ds216 431444096  860416 430583680   1% 
/var/lib/lxd/storage-pools/default/containers/squid-ds216
  /dev/loop0  83712   83712 0 100% 
/snap/core/4206
  /dev/loop1 102144  102144 0 100% 
/snap/git-ubuntu/402

  You can see I have the core snap at revision 4206, and git-ubuntu at
  revision 402.

  There are already many bug reports in launchpad where one can see this
  information.

  Granted, the user can review it, refuse to send this data, etc. This
  bug is about the unexpectedness of having that information in the disk
  space data.

  If the user sees a prompt like "Would you like to include disk free
  space information in your report?", or "Would you like to include the
  output of the df(1) command in your report?", that doesn't immediately
  translate to "Would you like to include disk free space information
  and a list of all installed snaps and their revision numbers in your
  report?".

  [Test case]
  Do something that triggers the apport hook and make sure you don't see snaps 
in there.

  For example, install xterm, then add exit 1 to the start of the prerm,
  then run apt remove xterm, and investigate /var/crash/xterm.0.crash
  after that (delete before running apt).

  [Regression potential]
  Fix consists of adding -x squashfs to df output, so might hide other non-snap 
squashfs images.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1756595/+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 1829861] Update Released

2019-09-12 Thread Łukasz Zemczak
The verification of the Stable Release Update for apt has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
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/1829861

Title:
  handle TLS session renegotiation

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released
Status in apt source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  TLS sessions can renegotiate keys, but APT does not support it; meaning their 
HTTPS connections stop working.

  [Test case]
  We don't really have a reproducer. You'd need a server that re-negotiates by 
path; e.g. because it requires a a certain client certificate for a certain 
path.

  We know it does not break other use cases, having run that for quite
  some time in eoan and Debian stretch, and the patch was tested by the
  patch submitter @ Akamai (see https://github.com/Debian/apt/pull/93).

  [Regression potential]
  - Could we get stuck on renegotiation?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829861/+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 1838771] Update Released

2019-09-12 Thread Łukasz Zemczak
The verification of the Stable Release Update for apt has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
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/1838771

Title:
  http:Fix Host header in proxied https connections

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released

Bug description:
  [Impact]

  Currently CONNECT requests use the name of the proxy as Host value,
  instead of the origin server's name.

  According to RFC 2616 "The Host field value MUST represent the naming
  authority of the origin server or gateway given by the original URL."

  The current implementation causes problems with some proxy vendors. This
  commit[0] fixes this.

  [0] - https://salsa.debian.org/apt-
  
team/apt/commit/86d4d98060f36c7e71c34af20a1193a75496ef72#54d3193c5d10a0032c80c3a6d3f069507265547f

  [Test Case]

  Here's one reproducer an impacted user brought to my attention:

  # /etc/environment
  http_proxy="http://internal:8080;
  https_proxy="http://interal:8080;

  To support application development activities in-house, I had to
  configure Azure CLI APT repository following the instructions from
  "https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view
  =azure-cli-latest":

  $ sudo apt-get update
  $ sudo apt-get install curl apt-transport-https lsb-release gnupg
  $ curl -sL https://packages.microsoft.com/keys/microsoft.asc | \
  $ gpg --dearmor | \
  $ sudo tee /etc/apt/trusted.gpg.d/microsoft.asc.gpg > /dev/null
  $ AZ_REPO=$(lsb_release -cs)
  $ echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $ $ 
AZ_REPO main" | \
  $ sudo tee /etc/apt/sources.list.d/azure-cli.list
  $ sudo apt update

  In the final "apt update" command, APT respects system-wide network
  proxy variables and successfully fetched Canonical repository data
  over HTTP.

  However, it was unable to fetch the newly added Microsoft packages
  repository served via HTTPS.

  By using Wireshark to examine the HTTPS request made by APT, the
  request body reveals as:

  CONNECT packages.microsoft.com:443 HTTP/1.1\r\n
  Host: internal:8080\r\n
  User-Agent: Debian APT-HTTP/1.3 (1.6.11)\r\n
  ...
  ...

  There also is an automated test case in the package that runs as part
  of autopkgtest that tests a scenario like this, see the commit.

  [Regression Potential]

  * Fix already in debian, and Eoan
  * Has been reviewed/approved by juliank
  * A test package (pre-sru) has been provided to an impacted user, and he 
confirms it solves the situation.

  [Other Info]

  # salsa
  $ git describe --contains 86d4d98060f36c7e71c34af20a1193a75496ef72
  1.9.0~8

  # rmadison apt
  => apt | 1.6.11 | bionic-updates | source, amd64, arm64, armhf, i386, 
ppc64el, s390x
  => apt | 1.8.1 | disco-updates | source, amd64, arm64, armhf, i386, ppc64el, 
s390x
  apt | 1.9.1 | eoan | source, amd64, arm64, armhf, i386, ppc64el, s390x

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1838771/+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 1838771] Re: http:Fix Host header in proxied https connections

2019-09-12 Thread Launchpad Bug Tracker
This bug was fixed in the package apt - 1.6.12

---
apt (1.6.12) bionic; urgency=medium

  [ TilmanK ]
  * Fix typo in German manpage translation

  [ Michael Zhivich ]
  * methods: https: handle requests for TLS re-handshake (LP: #1829861)

  [ Julian Andres Klode ]
  * Unlock dpkg locks in reverse locking order (LP: #1829860)

  [ Simon Körner ]
  * http: Fix Host header in proxied https connections (LP: #1838771)

  [ Brian Murray ]
  * Do not include squashfs file systems in df output. (LP: #1756595)

 -- Julian Andres Klode   Tue, 03 Sep 2019 12:05:35
+0200

** Changed in: apt (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

-- 
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/1838771

Title:
  http:Fix Host header in proxied https connections

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released

Bug description:
  [Impact]

  Currently CONNECT requests use the name of the proxy as Host value,
  instead of the origin server's name.

  According to RFC 2616 "The Host field value MUST represent the naming
  authority of the origin server or gateway given by the original URL."

  The current implementation causes problems with some proxy vendors. This
  commit[0] fixes this.

  [0] - https://salsa.debian.org/apt-
  
team/apt/commit/86d4d98060f36c7e71c34af20a1193a75496ef72#54d3193c5d10a0032c80c3a6d3f069507265547f

  [Test Case]

  Here's one reproducer an impacted user brought to my attention:

  # /etc/environment
  http_proxy="http://internal:8080;
  https_proxy="http://interal:8080;

  To support application development activities in-house, I had to
  configure Azure CLI APT repository following the instructions from
  "https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view
  =azure-cli-latest":

  $ sudo apt-get update
  $ sudo apt-get install curl apt-transport-https lsb-release gnupg
  $ curl -sL https://packages.microsoft.com/keys/microsoft.asc | \
  $ gpg --dearmor | \
  $ sudo tee /etc/apt/trusted.gpg.d/microsoft.asc.gpg > /dev/null
  $ AZ_REPO=$(lsb_release -cs)
  $ echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $ $ 
AZ_REPO main" | \
  $ sudo tee /etc/apt/sources.list.d/azure-cli.list
  $ sudo apt update

  In the final "apt update" command, APT respects system-wide network
  proxy variables and successfully fetched Canonical repository data
  over HTTP.

  However, it was unable to fetch the newly added Microsoft packages
  repository served via HTTPS.

  By using Wireshark to examine the HTTPS request made by APT, the
  request body reveals as:

  CONNECT packages.microsoft.com:443 HTTP/1.1\r\n
  Host: internal:8080\r\n
  User-Agent: Debian APT-HTTP/1.3 (1.6.11)\r\n
  ...
  ...

  There also is an automated test case in the package that runs as part
  of autopkgtest that tests a scenario like this, see the commit.

  [Regression Potential]

  * Fix already in debian, and Eoan
  * Has been reviewed/approved by juliank
  * A test package (pre-sru) has been provided to an impacted user, and he 
confirms it solves the situation.

  [Other Info]

  # salsa
  $ git describe --contains 86d4d98060f36c7e71c34af20a1193a75496ef72
  1.9.0~8

  # rmadison apt
  => apt | 1.6.11 | bionic-updates | source, amd64, arm64, armhf, i386, 
ppc64el, s390x
  => apt | 1.8.1 | disco-updates | source, amd64, arm64, armhf, i386, ppc64el, 
s390x
  apt | 1.9.1 | eoan | source, amd64, arm64, armhf, i386, ppc64el, s390x

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1838771/+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 1756595] Re: disk space info inadvertently provides all installed snaps

2019-09-12 Thread Launchpad Bug Tracker
This bug was fixed in the package apt - 1.6.12

---
apt (1.6.12) bionic; urgency=medium

  [ TilmanK ]
  * Fix typo in German manpage translation

  [ Michael Zhivich ]
  * methods: https: handle requests for TLS re-handshake (LP: #1829861)

  [ Julian Andres Klode ]
  * Unlock dpkg locks in reverse locking order (LP: #1829860)

  [ Simon Körner ]
  * http: Fix Host header in proxied https connections (LP: #1838771)

  [ Brian Murray ]
  * Do not include squashfs file systems in df output. (LP: #1756595)

 -- Julian Andres Klode   Tue, 03 Sep 2019 12:05:35
+0200

** Changed in: apt (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

-- 
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/1756595

Title:
  disk space info inadvertently provides all installed snaps

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released
Status in apt source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  When apport is reporting a crash, it includes the output of the "df" utility, 
to list the free disk space information per mount point.

  That output nowadays will inadvertently include all snaps that the
  user may have installed, including their revision numbers.

  Here is a simple df output:
  andreas@nsn7:~$ df
  Filesystem  1K-blocksUsed Available Use% Mounted on
  udev  8119680   0   8119680   0% /dev
  tmpfs 16301561828   1628328   1% /run
  nsn7/ROOT/ubuntu433084288 2500608 430583680   1% /
  tmpfs 8150776   1   8131888   1% /dev/shm
  tmpfs5120   4  5116   1% /run/lock
  tmpfs 8150776   0   8150776   0% 
/sys/fs/cgroup
  nsn7/var/log430763136  179456 430583680   1% /var/log
  nsn7/var/tmp430583808 128 430583680   1% /var/tmp
  /dev/sda2 1032088  160336871752  16% /boot
  /dev/sda1  5232482720520528   1% /boot/efi
  nsn7/home   430651264   67584 430583680   1% /home
  nsn7/var/cache  430653312   69632 430583680   1% /var/cache
  nsn7/var/mail   430583808 128 430583680   1% /var/mail
  nsn7/var/spool  430583808 128 430583680   1% /var/spool
  tmpfs 1630152  16   1630136   1% /run/user/120
  tmpfs 100   0   100   0% 
/var/lib/lxd/shmounts
  tmpfs 100   0   100   0% 
/var/lib/lxd/devlxd
  tmpfs 1630152  36   1630116   1% 
/run/user/1000
  nsn7/lxd/containers/squid-ds216 431444096  860416 430583680   1% 
/var/lib/lxd/storage-pools/default/containers/squid-ds216
  /dev/loop0  83712   83712 0 100% 
/snap/core/4206
  /dev/loop1 102144  102144 0 100% 
/snap/git-ubuntu/402

  You can see I have the core snap at revision 4206, and git-ubuntu at
  revision 402.

  There are already many bug reports in launchpad where one can see this
  information.

  Granted, the user can review it, refuse to send this data, etc. This
  bug is about the unexpectedness of having that information in the disk
  space data.

  If the user sees a prompt like "Would you like to include disk free
  space information in your report?", or "Would you like to include the
  output of the df(1) command in your report?", that doesn't immediately
  translate to "Would you like to include disk free space information
  and a list of all installed snaps and their revision numbers in your
  report?".

  [Test case]
  Do something that triggers the apport hook and make sure you don't see snaps 
in there.

  For example, install xterm, then add exit 1 to the start of the prerm,
  then run apt remove xterm, and investigate /var/crash/xterm.0.crash
  after that (delete before running apt).

  [Regression potential]
  Fix consists of adding -x squashfs to df output, so might hide other non-snap 
squashfs images.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1756595/+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 1829860] Re: APT unlocks in same order as it locks

2019-09-12 Thread Launchpad Bug Tracker
This bug was fixed in the package apt - 1.6.12

---
apt (1.6.12) bionic; urgency=medium

  [ TilmanK ]
  * Fix typo in German manpage translation

  [ Michael Zhivich ]
  * methods: https: handle requests for TLS re-handshake (LP: #1829861)

  [ Julian Andres Klode ]
  * Unlock dpkg locks in reverse locking order (LP: #1829860)

  [ Simon Körner ]
  * http: Fix Host header in proxied https connections (LP: #1838771)

  [ Brian Murray ]
  * Do not include squashfs file systems in df output. (LP: #1756595)

 -- Julian Andres Klode   Tue, 03 Sep 2019 12:05:35
+0200

** Changed in: apt (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

-- 
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/1829860

Title:
  APT unlocks in same order as it locks

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Xenial:
  New
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released

Bug description:
  [Impact]
  APT releases the locks in the same order it acquires them, rather than 
reverse order. Given that we have no waiting for locks, this is not _super_ 
problematic, but it might be wrong: You'd get a lock failure on dpkg's lock, 
rather than lock-frontend.

  [Test case]
  Watch lock release with strace and see that it unlocks the right way.

  [Regression potential]
  Some other locking races or something?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829860/+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 1843706] [NEW] Privacy of information collected with apport in the gnome-shell package

2019-09-12 Thread El jinete sin cabeza
Public bug reported:

After using apport to report a problem in gnome-shell in the file
'ShellJournal.txt' private information appears, such as the name of the
Notebook.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: apport 2.20.11-0ubuntu7
ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8
Uname: Linux 5.3.0-10-generic x86_64
ApportVersion: 2.20.11-0ubuntu7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Sep 12 09:08:45 2019
InstallationDate: Installed on 2018-12-02 (283 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
PackageArchitecture: all
SourcePackage: apport
UpgradeStatus: Upgraded to eoan on 2018-12-02 (283 days ago)

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


** Tags: amd64 apport-bug eoan wayland-session

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

Title:
  Privacy of information collected with apport in the gnome-shell
  package

Status in apport package in Ubuntu:
  New

Bug description:
  After using apport to report a problem in gnome-shell in the file
  'ShellJournal.txt' private information appears, such as the name of
  the Notebook.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: apport 2.20.11-0ubuntu7
  ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8
  Uname: Linux 5.3.0-10-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Sep 12 09:08:45 2019
  InstallationDate: Installed on 2018-12-02 (283 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  PackageArchitecture: all
  SourcePackage: apport
  UpgradeStatus: Upgraded to eoan on 2018-12-02 (283 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1843706/+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 1838771] Re: http:Fix Host header in proxied https connections

2019-09-12 Thread Eric Desrochers
[VERIFICATION BIONIC]

It looks good to me testing with the above [Test Case].

# apt-get update
Hit:1 http://security.ubuntu.com/ubuntu bionic-security InRelease
==> Hit:2 https://packages.microsoft.com/repos/azure-cli bionic InRelease   
 
Hit:3 http://archive.ubuntu.com/ubuntu bionic InRelease 
   
Hit:4 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:5 http://archive.ubuntu.com/ubuntu bionic-backports InRelease   
Hit:6 http://archive.ubuntu.com/ubuntu bionic-proposed InRelease
Reading package lists... Done

-- 
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/1838771

Title:
  http:Fix Host header in proxied https connections

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Fix Committed
Status in apt source package in Disco:
  Fix Committed

Bug description:
  [Impact]

  Currently CONNECT requests use the name of the proxy as Host value,
  instead of the origin server's name.

  According to RFC 2616 "The Host field value MUST represent the naming
  authority of the origin server or gateway given by the original URL."

  The current implementation causes problems with some proxy vendors. This
  commit[0] fixes this.

  [0] - https://salsa.debian.org/apt-
  
team/apt/commit/86d4d98060f36c7e71c34af20a1193a75496ef72#54d3193c5d10a0032c80c3a6d3f069507265547f

  [Test Case]

  Here's one reproducer an impacted user brought to my attention:

  # /etc/environment
  http_proxy="http://internal:8080;
  https_proxy="http://interal:8080;

  To support application development activities in-house, I had to
  configure Azure CLI APT repository following the instructions from
  "https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view
  =azure-cli-latest":

  $ sudo apt-get update
  $ sudo apt-get install curl apt-transport-https lsb-release gnupg
  $ curl -sL https://packages.microsoft.com/keys/microsoft.asc | \
  $ gpg --dearmor | \
  $ sudo tee /etc/apt/trusted.gpg.d/microsoft.asc.gpg > /dev/null
  $ AZ_REPO=$(lsb_release -cs)
  $ echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $ $ 
AZ_REPO main" | \
  $ sudo tee /etc/apt/sources.list.d/azure-cli.list
  $ sudo apt update

  In the final "apt update" command, APT respects system-wide network
  proxy variables and successfully fetched Canonical repository data
  over HTTP.

  However, it was unable to fetch the newly added Microsoft packages
  repository served via HTTPS.

  By using Wireshark to examine the HTTPS request made by APT, the
  request body reveals as:

  CONNECT packages.microsoft.com:443 HTTP/1.1\r\n
  Host: internal:8080\r\n
  User-Agent: Debian APT-HTTP/1.3 (1.6.11)\r\n
  ...
  ...

  There also is an automated test case in the package that runs as part
  of autopkgtest that tests a scenario like this, see the commit.

  [Regression Potential]

  * Fix already in debian, and Eoan
  * Has been reviewed/approved by juliank
  * A test package (pre-sru) has been provided to an impacted user, and he 
confirms it solves the situation.

  [Other Info]

  # salsa
  $ git describe --contains 86d4d98060f36c7e71c34af20a1193a75496ef72
  1.9.0~8

  # rmadison apt
  => apt | 1.6.11 | bionic-updates | source, amd64, arm64, armhf, i386, 
ppc64el, s390x
  => apt | 1.8.1 | disco-updates | source, amd64, arm64, armhf, i386, ppc64el, 
s390x
  apt | 1.9.1 | eoan | source, amd64, arm64, armhf, i386, ppc64el, s390x

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1838771/+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 1715749] Re: Intermittent black screen on HP EliteBook 840 G1

2019-09-12 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: xorg (Ubuntu)
   Status: New => Confirmed

-- 
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/1715749

Title:
  Intermittent black screen on HP EliteBook 840 G1

Status in xorg package in Ubuntu:
  Confirmed

Bug description:
  Once every couple hours, the internal laptop display goes black for a
  few seconds.

  This was reproducible:
  + With the laptop connected to a port replicator and the external display 
connected into the port replicator DP port via DP-DVI adapter. The external 
display remains on during this time.
  + With the laptop not connected into a port replicator but connected to an 
external display. The external display remains on during this time.
  + With the laptop not connected to either a port replicator or an external 
display.

  The hard disk was originally installed with Ubuntu MATE 14.10 in a HP
  EliteBook 6930p, upgraded to 15.04, 15.10 and eventually 16.04 and
  finally moved to the EliteBook 840 G1. The problem started immediately
  after the drive move.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: xorg 1:7.7+13ubuntu3
  ProcVersionSignature: Ubuntu 4.4.0-93.116-generic 4.4.79
  Uname: Linux 4.4.0-93-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.10
  Architecture: amd64
  CurrentDesktop: MATE
  Date: Fri Sep  8 00:53:24 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2014-12-09 (1002 days ago)
  InstallationMedia: Ubuntu MATE 14.10 "Utopic Unicorn" - amd64 (20141023)
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  ---
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: MATE
  DistUpgraded: Fresh install
  DistroCodename: xenial
  DistroRelease: Ubuntu 16.04
  DistroVariant: ubuntu
  EcryptfsInUse: Yes
  ExtraDebuggingInterest: Yes, if not too technical
  GraphicsCard:
   Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] 
(rev 0b) (prog-if 00 [VGA controller])
     Subsystem: Hewlett-Packard Company Haswell-ULT Integrated Graphics 
Controller [103c:198f]
  InstallationDate: Installed on 2014-12-09 (1158 days ago)
  InstallationMedia: Ubuntu MATE 14.10 "Utopic Unicorn" - amd64 (20141023)
  MachineType: Hewlett-Packard HP EliteBook 840 G1
  Package: xorg 1:7.7+13ubuntu3
  PackageArchitecture: amd64
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-112-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 4.4.0-112.135-generic 4.4.98
  Tags:  xenial ubuntu
  Uname: Linux 4.4.0-112-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dialout dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 05/23/2016
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: L71 Ver. 01.37
  dmi.board.name: 198F
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: KBC Version 15.59
  dmi.chassis.asset.tag: CNU407CM0V
  dmi.chassis.type: 10
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrL71Ver.01.37:bd05/23/2016:svnHewlett-Packard:pnHPEliteBook840G1:pvrA3009DD10203:rvnHewlett-Packard:rn198F:rvrKBCVersion15.59:cvnHewlett-Packard:ct10:cvr:
  dmi.product.name: HP EliteBook 840 G1
  dmi.product.version: A3009DD10203
  dmi.sys.vendor: Hewlett-Packard
  version.compiz: compiz 1:0.9.12.2+16.04.20160823-0ubuntu1
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.83-1~16.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 17.2.4-0ubuntu1~16.04.4
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 17.2.4-0ubuntu1~16.04.4
  version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.7
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20160325-1ubuntu1.2
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.12-1build2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1715749/+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 1715749] Re: Intermittent black screen on HP EliteBook 840 G1

2019-09-12 Thread Wenjie Zheng
I have exactly the same problem described in the title since 2018-11-27,
when I bought this laptop.

My configuration:
HP Elitebook 840 G1
Ubuntu 18.04

The same issue does not hit Windows, which I dual boot with.

-- 
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/1715749

Title:
  Intermittent black screen on HP EliteBook 840 G1

Status in xorg package in Ubuntu:
  Confirmed

Bug description:
  Once every couple hours, the internal laptop display goes black for a
  few seconds.

  This was reproducible:
  + With the laptop connected to a port replicator and the external display 
connected into the port replicator DP port via DP-DVI adapter. The external 
display remains on during this time.
  + With the laptop not connected into a port replicator but connected to an 
external display. The external display remains on during this time.
  + With the laptop not connected to either a port replicator or an external 
display.

  The hard disk was originally installed with Ubuntu MATE 14.10 in a HP
  EliteBook 6930p, upgraded to 15.04, 15.10 and eventually 16.04 and
  finally moved to the EliteBook 840 G1. The problem started immediately
  after the drive move.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: xorg 1:7.7+13ubuntu3
  ProcVersionSignature: Ubuntu 4.4.0-93.116-generic 4.4.79
  Uname: Linux 4.4.0-93-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.10
  Architecture: amd64
  CurrentDesktop: MATE
  Date: Fri Sep  8 00:53:24 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2014-12-09 (1002 days ago)
  InstallationMedia: Ubuntu MATE 14.10 "Utopic Unicorn" - amd64 (20141023)
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  ---
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: MATE
  DistUpgraded: Fresh install
  DistroCodename: xenial
  DistroRelease: Ubuntu 16.04
  DistroVariant: ubuntu
  EcryptfsInUse: Yes
  ExtraDebuggingInterest: Yes, if not too technical
  GraphicsCard:
   Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] 
(rev 0b) (prog-if 00 [VGA controller])
     Subsystem: Hewlett-Packard Company Haswell-ULT Integrated Graphics 
Controller [103c:198f]
  InstallationDate: Installed on 2014-12-09 (1158 days ago)
  InstallationMedia: Ubuntu MATE 14.10 "Utopic Unicorn" - amd64 (20141023)
  MachineType: Hewlett-Packard HP EliteBook 840 G1
  Package: xorg 1:7.7+13ubuntu3
  PackageArchitecture: amd64
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-112-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 4.4.0-112.135-generic 4.4.98
  Tags:  xenial ubuntu
  Uname: Linux 4.4.0-112-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dialout dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 05/23/2016
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: L71 Ver. 01.37
  dmi.board.name: 198F
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: KBC Version 15.59
  dmi.chassis.asset.tag: CNU407CM0V
  dmi.chassis.type: 10
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrL71Ver.01.37:bd05/23/2016:svnHewlett-Packard:pnHPEliteBook840G1:pvrA3009DD10203:rvnHewlett-Packard:rn198F:rvrKBCVersion15.59:cvnHewlett-Packard:ct10:cvr:
  dmi.product.name: HP EliteBook 840 G1
  dmi.product.version: A3009DD10203
  dmi.sys.vendor: Hewlett-Packard
  version.compiz: compiz 1:0.9.12.2+16.04.20160823-0ubuntu1
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.83-1~16.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 17.2.4-0ubuntu1~16.04.4
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 17.2.4-0ubuntu1~16.04.4
  version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.7
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20160325-1ubuntu1.2
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.12-1build2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1715749/+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 1838771] Re: http:Fix Host header in proxied https connections

2019-09-12 Thread Łukasz Zemczak
Eric, could you check the package and make sure the fix works as
expected for you as well?

-- 
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/1838771

Title:
  http:Fix Host header in proxied https connections

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Fix Committed
Status in apt source package in Disco:
  Fix Committed

Bug description:
  [Impact]

  Currently CONNECT requests use the name of the proxy as Host value,
  instead of the origin server's name.

  According to RFC 2616 "The Host field value MUST represent the naming
  authority of the origin server or gateway given by the original URL."

  The current implementation causes problems with some proxy vendors. This
  commit[0] fixes this.

  [0] - https://salsa.debian.org/apt-
  
team/apt/commit/86d4d98060f36c7e71c34af20a1193a75496ef72#54d3193c5d10a0032c80c3a6d3f069507265547f

  [Test Case]

  Here's one reproducer an impacted user brought to my attention:

  # /etc/environment
  http_proxy="http://internal:8080;
  https_proxy="http://interal:8080;

  To support application development activities in-house, I had to
  configure Azure CLI APT repository following the instructions from
  "https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view
  =azure-cli-latest":

  $ sudo apt-get update
  $ sudo apt-get install curl apt-transport-https lsb-release gnupg
  $ curl -sL https://packages.microsoft.com/keys/microsoft.asc | \
  $ gpg --dearmor | \
  $ sudo tee /etc/apt/trusted.gpg.d/microsoft.asc.gpg > /dev/null
  $ AZ_REPO=$(lsb_release -cs)
  $ echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $ $ 
AZ_REPO main" | \
  $ sudo tee /etc/apt/sources.list.d/azure-cli.list
  $ sudo apt update

  In the final "apt update" command, APT respects system-wide network
  proxy variables and successfully fetched Canonical repository data
  over HTTP.

  However, it was unable to fetch the newly added Microsoft packages
  repository served via HTTPS.

  By using Wireshark to examine the HTTPS request made by APT, the
  request body reveals as:

  CONNECT packages.microsoft.com:443 HTTP/1.1\r\n
  Host: internal:8080\r\n
  User-Agent: Debian APT-HTTP/1.3 (1.6.11)\r\n
  ...
  ...

  There also is an automated test case in the package that runs as part
  of autopkgtest that tests a scenario like this, see the commit.

  [Regression Potential]

  * Fix already in debian, and Eoan
  * Has been reviewed/approved by juliank
  * A test package (pre-sru) has been provided to an impacted user, and he 
confirms it solves the situation.

  [Other Info]

  # salsa
  $ git describe --contains 86d4d98060f36c7e71c34af20a1193a75496ef72
  1.9.0~8

  # rmadison apt
  => apt | 1.6.11 | bionic-updates | source, amd64, arm64, armhf, i386, 
ppc64el, s390x
  => apt | 1.8.1 | disco-updates | source, amd64, arm64, armhf, i386, ppc64el, 
s390x
  apt | 1.9.1 | eoan | source, amd64, arm64, armhf, i386, ppc64el, s390x

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1838771/+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 1843623] Re: LVM volumes not activated during boot after upgrade to 18.04 LTS

2019-09-12 Thread Marius Gedminas
So, uh, I tried another reboot so I could debug the problem some more,
and ... well ... the machine booted.  No problems.   I've no idea what's
going on, feel free to close this bug.

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

Title:
  LVM volumes not activated during boot after upgrade to 18.04 LTS

Status in lvm2 package in Ubuntu:
  New

Bug description:
  I've upgraded a server from Ubuntu 16.04 LTS to 18.04 LTS and now it
  fails to activate LVM volumes during boot (which causes systemd to
  stop in the middle of the boot process and ask me to fix this on the
  console without starting up services like SSH).

  The root partition, which is also on LVM, gets activated (by the
  initramfs I assume), but none of the other ones are.

  Everything worked fine on xenial, so I don't think this is a duplicate
  of 1573982?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: lvm2 2.02.176-4.1ubuntu3.18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18
  Uname: Linux 4.15.0-62-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  Date: Wed Sep 11 19:34:53 2019
  ProcEnviron:
   LC_CTYPE=lt_LT.UTF-8
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: lvm2
  UpgradeStatus: Upgraded to bionic on 2019-09-11 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1843623/+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 1843394] Re: FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1

2019-09-12 Thread Christian Ehrhardt 
I have had another dev try this on fedora which also has gcc 9.2.1 and
it works there.

But since it fails in "as" which is actually binutils lets add that as a bug 
task.
Maybe binutils developers know something about this?

** Summary changed:

- FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1
+ FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1 / 
binutils 2.32.51.20190905-0ubuntu1

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

Title:
  FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1 /
  binutils 2.32.51.20190905-0ubuntu1

Status in binutils package in Ubuntu:
  New
Status in ipxe package in Ubuntu:
  New

Bug description:
  This might be due to new gcc-9 being more strict, but the build that
  worked before now fails with:

  arch/x86_64/core/gdbidt.S: Assembler messages:
  arch/x86_64/core/gdbidt.S:109: Error: operand type mismatch for `push'
  arch/x86_64/core/gdbidt.S:110: Error: operand type mismatch for `push'
  arch/x86_64/core/gdbidt.S:161: Error: operand type mismatch for `pop'
  arch/x86_64/core/gdbidt.S:162: Error: operand type mismatch for `pop'
  make[2]: *** [Makefile.housekeeping:937: bin-x86_64-efi/gdbidt.o] Error 1

  Full log at: https://launchpadlibrarian.net/441262285/buildlog_ubuntu-
  eoan-amd64.ipxe_1.0.0+git-20190109.133f4c4-0ubuntu2_BUILDING.txt.gz

  Now all of this is about push/pop of %fs and %gs.
  That needs to match the size of the registers which depend on the current 
running mode.

  In this particular case in ./src/arch/x86_64/core/gdbidt.S
  The failing file is in ".code64" mode.
  In that I'd expect %gs/%fs to be 64 bit.

  
  Usually we see push/pop "w" in .code16 (word), l in .code32 (long) but in 
that sense here q (quad word) seems right at first (should be what correctly 
matches the .code64).
  That matches what I see throughout the ipxe code but also throughout the 
archive 
https://codesearch.debian.net/search?q=pop%5Ba-z%5D.*%25fs=0=2

  Maybe I misread the mode it is in, or it is actually a false positives.
  Or the sizes of FS/GS do not change - haven't touched them in a lng time.
  Was it that segment registers didn't change size?
  I'll need to do a few checks to first see what the compiler would expect 
there and from there need to understand this.

  The command used also points to AS being in 64 bit mode when this happens:
  gcc -E  -DARCH=x86_64 -DPLATFORM=efi -DSECUREBOOT=0 -fstrength-reduce 
-fomit-frame-pointer -falign-jumps=1 -falign-loops=1 -falign-functions=1 -m64 
-mno-mmx -mno-sse -fshort-wchar -Ui386 -Ulinux -DNVALGRIND -fpie -mno-red-zone 
-Iinclude -I. -Iarch/x86/include -Iarch/x86_64/include 
-Iarch/x86_64/include/efi -Os -g -ffreestanding -Wall -W -Wformat-nonliteral  
-fno-stack-protector -fno-dwarf2-cfi-asm -fno-exceptions  -fno-unwind-tables 
-fno-asynchronous-unwind-tables -Wno-address -Wno-stringop-truncation   
-ffunction-sections -fdata-sections -include include/compiler.h -DASM_TCHAR='@' 
-DASM_TCHAR_OPS='@' -DASSEMBLY  -DOBJECT=gdbidt arch/x86_64/core/gdbidt.S | as  
--64-o bin-x86_64-efi/gdbidt.o

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1843394/+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 1843430] Re: FTBFS in Eoan due to new glibc - error: ‘SIOCGSTAMP’ undeclared

2019-09-12 Thread Christian Ehrhardt 
** Changed in: dnsmasq (Ubuntu)
   Status: New => In Progress

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

Title:
  FTBFS in Eoan due to new glibc - error: ‘SIOCGSTAMP’ undeclared

Status in dnsmasq package in Ubuntu:
  In Progress

Bug description:
  We hit this on a rebuild in Eoan
  dhcp.c: In function ‘dhcp_packet’:
  dhcp.c:182:17: error: ‘SIOCGSTAMP’ undeclared (first use in this function); 
did you mean ‘SIOCGARP’?
    182 |   if (ioctl(fd, SIOCGSTAMP, ) == 0)
    | ^~
    | SIOCGARP

  This seems much like the fix in the (not yet released) upstream repo:
  => 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3052ce208acf602f0163166dcefb7330d537cedb

  "Fix build after y2038 changes in glib.
  SIOCGSTAMP is defined in linux/sockios.h, not asm/sockios.h now."

  Failed build log: https://launchpadlibrarian.net/441262561
  /buildlog_ubuntu-eoan-amd64.dnsmasq_2.80-1ubuntu1_BUILDING.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1843430/+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 1843554] Re: apt update is trying to use IPv6 for some reason, which does not work

2019-09-12 Thread Marius Gedminas
Oops, I didn't read the error messages closely enough, sorry!

(Also the mirror came back up right when I applied the
Acquire::ForceIPv4 "true"; workaround, making me think my initial
analysis was right.  What a coincidence!)

-- 
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/1843554

Title:
  apt update is trying to use IPv6 for some reason, which does not work

Status in apt package in Ubuntu:
  Invalid

Bug description:
  Today I've discovered that I cannot use apt-get any more:

  apt update
  Hit:1 http://ppa.launchpad.net/mgedmin/ppa/ubuntu disco InRelease
  Ign:2 http://ddebs.ubuntu.com disco InRelease
  Ign:3 http://ddebs.ubuntu.com disco-updates InRelease
  Hit:4 http://ppa.launchpad.net/pov/ppa/ubuntu disco InRelease
  Hit:5 http://ddebs.ubuntu.com disco Release
  Hit:6 http://security.ubuntu.com/ubuntu disco-security InRelease
  Hit:7 http://ddebs.ubuntu.com disco-updates Release
  0% [Connecting to lt.archive.ubuntu.com (2001:778:1::d)]

  and there it stalls for about 30 seconds, after which

  Err:10 http://lt.archive.ubuntu.com/ubuntu disco InRelease
Cannot initiate the connection to lt.archive.ubuntu.com:80 
(2001:778:1::d). - connect (101: Network is unreachable) Could not connect to 
lt.archive.ubuntu.com:80 (83.171.20.4), connection timed out
  Err:11 http://lt.archive.ubuntu.com/ubuntu disco-updates InRelease
Cannot initiate the connection to lt.archive.ubuntu.com:80 
(2001:778:1::d). - connect (101: Network is unreachable)
  Err:12 http://lt.archive.ubuntu.com/ubuntu disco-backports InRelease
Cannot initiate the connection to lt.archive.ubuntu.com:80 
(2001:778:1::d). - connect (101: Network is unreachable)
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  16 packages can be upgraded. Run 'apt list --upgradable' to see them.
  W: Failed to fetch 
http://lt.archive.ubuntu.com/ubuntu/dists/disco/InRelease  Cannot initiate the 
connection to lt.archive.ubuntu.com:80 (2001:778:1::d). - connect (101: Network 
is unreachable) Could not connect to lt.archive.ubuntu.com:80 (83.171.20.4), 
connection timed out
  W: Failed to fetch 
http://lt.archive.ubuntu.com/ubuntu/dists/disco-updates/InRelease  Cannot 
initiate the connection to lt.archive.ubuntu.com:80 (2001:778:1::d). - connect 
(101: Network is unreachable)
  W: Failed to fetch 
http://lt.archive.ubuntu.com/ubuntu/dists/disco-backports/InRelease  Cannot 
initiate the connection to lt.archive.ubuntu.com:80 (2001:778:1::d). - connect 
(101: Network is unreachable)
  W: Some index files failed to download. They have been ignored, or old 
ones used instead.

  I don't know why it's trying to connect to my Ubuntu mirror over IPv6.
  There's no IPv6 in Lithuania (I'm exaggerating a bit, but my ISP --
  the largest ISP in the country -- does not support IPv6).  I've never
  had working IPv6 connectivity in my life.  apt-get used to work before
  today.  I've no idea what changed.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: apt 1.8.1
  ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21
  Uname: Linux 5.0.0-27-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Sep 11 11:46:28 2019
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2019-06-12 (90 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  SourcePackage: apt
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1843554/+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 1843394] Re: FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1

2019-09-12 Thread Christian Ehrhardt 
** Also affects: binutils (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1

Status in binutils package in Ubuntu:
  New
Status in ipxe package in Ubuntu:
  New

Bug description:
  This might be due to new gcc-9 being more strict, but the build that
  worked before now fails with:

  arch/x86_64/core/gdbidt.S: Assembler messages:
  arch/x86_64/core/gdbidt.S:109: Error: operand type mismatch for `push'
  arch/x86_64/core/gdbidt.S:110: Error: operand type mismatch for `push'
  arch/x86_64/core/gdbidt.S:161: Error: operand type mismatch for `pop'
  arch/x86_64/core/gdbidt.S:162: Error: operand type mismatch for `pop'
  make[2]: *** [Makefile.housekeeping:937: bin-x86_64-efi/gdbidt.o] Error 1

  Full log at: https://launchpadlibrarian.net/441262285/buildlog_ubuntu-
  eoan-amd64.ipxe_1.0.0+git-20190109.133f4c4-0ubuntu2_BUILDING.txt.gz

  Now all of this is about push/pop of %fs and %gs.
  That needs to match the size of the registers which depend on the current 
running mode.

  In this particular case in ./src/arch/x86_64/core/gdbidt.S
  The failing file is in ".code64" mode.
  In that I'd expect %gs/%fs to be 64 bit.

  
  Usually we see push/pop "w" in .code16 (word), l in .code32 (long) but in 
that sense here q (quad word) seems right at first (should be what correctly 
matches the .code64).
  That matches what I see throughout the ipxe code but also throughout the 
archive 
https://codesearch.debian.net/search?q=pop%5Ba-z%5D.*%25fs=0=2

  Maybe I misread the mode it is in, or it is actually a false positives.
  Or the sizes of FS/GS do not change - haven't touched them in a lng time.
  Was it that segment registers didn't change size?
  I'll need to do a few checks to first see what the compiler would expect 
there and from there need to understand this.

  The command used also points to AS being in 64 bit mode when this happens:
  gcc -E  -DARCH=x86_64 -DPLATFORM=efi -DSECUREBOOT=0 -fstrength-reduce 
-fomit-frame-pointer -falign-jumps=1 -falign-loops=1 -falign-functions=1 -m64 
-mno-mmx -mno-sse -fshort-wchar -Ui386 -Ulinux -DNVALGRIND -fpie -mno-red-zone 
-Iinclude -I. -Iarch/x86/include -Iarch/x86_64/include 
-Iarch/x86_64/include/efi -Os -g -ffreestanding -Wall -W -Wformat-nonliteral  
-fno-stack-protector -fno-dwarf2-cfi-asm -fno-exceptions  -fno-unwind-tables 
-fno-asynchronous-unwind-tables -Wno-address -Wno-stringop-truncation   
-ffunction-sections -fdata-sections -include include/compiler.h -DASM_TCHAR='@' 
-DASM_TCHAR_OPS='@' -DASSEMBLY  -DOBJECT=gdbidt arch/x86_64/core/gdbidt.S | as  
--64-o bin-x86_64-efi/gdbidt.o

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1843394/+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