[Touch-packages] [Bug 2052494] Re: There is an error in the recording of timezones for some cities

[Simon Chopin]

Hi!

Thank you for taking the time to report this. Could you confirm on which
version of Ubuntu you're seeing this issue?

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

Title:
  There is an error in the recording of timezones for some cities

Status in libtimezonemap package in Ubuntu:
  New

Bug description:
  There is an error in the recording of timezones for some cities.
  Cities such as Zhanjiang are located in Guangdong Province, which is in the 
East 8 time zone, which is in the Asia/Shanghai time zone.but in the file 
timezonemap/src/data/cities15000.txt the city is recorded as being in East 6, 
the Asia/Urumqi time zone.

  
  Here is the modifications：
  ==
  timezonemap/src/data/cities15000.txt
  3054c3054
  < 1784990 Zhanjiang   Zhanjiang   
Chan-chiang,Chan-chiang-shih,Chankiang,Chzhan'czjan,Fort 
Bayard,Hsi-ying,Kwangchow,Kwangchowan,Kwangchowwan,Tram Giang,Trạm 
Giang,Tsamkong,ZHA,Zhanjiang,Zhanjiang Shi,zhan jiang,zhan jiang 
shi,Чжаньцзян,جاڭجياڭ شەھىرى,湛江,湛江市21.28145110.34271   P
   PPLA2   CN  30  637790  29   
   Asia/Shanghai   2012-01-18
  ---
  > 1784990 Zhanjiang   Zhanjiang   
Chan-chiang,Chan-chiang-shih,Chankiang,Chzhan'czjan,Fort 
Bayard,Hsi-ying,Kwangchow,Kwangchowan,Kwangchowwan,Tram Giang,Trạm 
Giang,Tsamkong,ZHA,Zhanjiang,Zhanjiang Shi,zhan jiang,zhan jiang 
shi,Чжаньцзян,جاڭجياڭ شەھىرى,湛江,湛江市21.28145110.34271   P
   PPLA2   CN  30  637790  29   
   Asia/Urumqi 2012-01-18
  3108c3108
  < 1787837 Xucheng Xucheng 
Hsu-wen,Hsu-wen-hsien,Hsü-wen,Hsü-wen-hsien,Suwen,Suwenyun,Tsuimen,Xucheng,Xucheng
 Jiedao,Xucheng Zhen,Xuwen,xu cheng,xu cheng jie dao,xu cheng zhen,徐城,徐城街道,徐城镇  
  20.32917110.16712   P   PPLA3   CN  30
  83267   75  Asia/Shanghai   2013-10-05
  ---
  > 1787837 Xucheng Xucheng 
Hsu-wen,Hsu-wen-hsien,Hsü-wen,Hsü-wen-hsien,Suwen,Suwenyun,Tsuimen,Xucheng,Xucheng
 Jiedao,Xucheng Zhen,Xuwen,xu cheng,xu cheng jie dao,xu cheng zhen,徐城,徐城街道,徐城镇  
  20.32917110.16712   P   PPLA3   CN  30
  83267   75  Asia/Urumqi 2013-10-05
  3318c3318
  < 1800829 Wuchuan Wuchuan 
Hai-lu,Mei-lu-shih,Mei-mao,Meilu,Muiluk,Wuchuan,wu chuan,吴川 21.45713
110.76591   P   PPL CN  30  
104168  7   Asia/Shanghai   2012-01-18
  ---
  > 1800829 Wuchuan Wuchuan 
Hai-lu,Mei-lu-shih,Mei-mao,Meilu,Muiluk,Wuchuan,wu chuan,吴川 21.45713
110.76591   P   PPL CN  30  
104168  7   Asia/Urumqi 2012-01-18
  3364c3364
  < 1804120 Lianjiang   Lianjiang   
Lei-pei,Liancheng,Lianjiang,Lien-chiang,Lien-chiang-hsien,Limkong,Limkong-hsien,Lunkong,Shih-ch'eng,Shih-ch’eng,lian
 jiang,廉江   21.64673110.28172   P   PPL CN  30  
100341  46  Asia/Shanghai   2012-01-18
  ---
  > 1804120 Lianjiang   Lianjiang   
Lei-pei,Liancheng,Lianjiang,Lien-chiang,Lien-chiang-hsien,Limkong,Limkong-hsien,Lunkong,Shih-ch'eng,Shih-ch’eng,lian
 jiang,廉江   21.64673110.28172   P   PPL CN  30  
100341  46  Asia/Urumqi 2012-01-18
  3432c3432
  < 1806960 Huazhou Huazhou 
Fachow,Fahsien,Fu-ch'eng-chen,Fu-ch’eng-chen,Hau-hsien,Hua,Hua-chou,Hua-hsien,Huazhou
   21.6110.58333   P   PPL CN  30   
   91701   35  Asia/Shanghai   2012-01-18
  ---
  > 1806960 Huazhou Huazhou 
Fachow,Fahsien,Fu-ch'eng-chen,Fu-ch’eng-chen,Hau-hsien,Hua,Hua-chou,Hua-hsien,Huazhou
   21.6110.58333   P   PPL CN  30   
   91701   35  Asia/Urumqi 2012-01-18
  3484c3484
  < 1810295 Gaozhou Gaozhou 
Gaozhou,Kao-chou,Kaochow,Kochow,Kochowfu,Mao-ming,Mao-ming-hsien,Mowming,gao 
zhou,高州21.93924110.84607   P   PPL CN  30   
   166069  57  Asia/Shanghai   2012-01-18
  ---
  > 1810295 Gaozhou Gaozhou 
Gaozhou,Kao-chou,Kaochow,Kochow,Kochowfu,Mao-ming,Mao-ming-hsien,Mowming,gao 
zhou,高州21.93924110.84607   P   PPL CN  30   
   166069  57  Asia/Urumqi 2012-01-18
  3507c3507
  < 1812057 Xinyi   Xinyi   
Dongzhen,Hsin-i,Tung-chen,Tung-chen-chen,Tung-chen-hsu,Tung-chen-hsü,Xinyi,xin 
yi,信宜22.37303110.94746   P   PPL CN   

[Touch-packages] [Bug 2051512] Re: apport ftbfs with Python 3.12 as the default

[Simon Chopin]

** Also affects: python3.12 (Ubuntu)
   Importance: Undecided
   Status: New

** Description changed:

-debian/rules override_dh_auto_test
+ [Description]
+ 
+ Python 3.12 gzip.GZipFile.write() outputs truncated data in some cases
+ (maybe all?)
+ 
+ [Test Plan]
+ 
+ Run the following script:
+ 
+ import gzip
+ import io
+ out = io.BytesIO()
+ gzip.GzipFile("foo", mode="wb", fileobj=out, mtime=0).write(b"FooFoo")
+ # print(out.getvalue())
+ print(gzip.decompress(out.getvalue()))
+ 
+ Expected output (as on Python 3.11):
+ FooFoo
+ 
+ Buggy output (tail end of the stack trace):
+ EOFError: Compressed file ended before the end-of-stream marker was reached
+ 
+ [Original report]
+ 
+ debian/rules override_dh_auto_test
  make[1]: Entering directory '/<>'
  tests/run-linters --errors-only
  Skipping mypy tests, mypy is not installed
  Running pylint...
  * Module apport-retrace
  bin/apport-retrace:577:44: E0601: Using variable 'crashid' before assignment 
(used-before-assignment)
  make[1]: *** [debian/rules:23: override_dh_auto_test] Error 2
  make[1]: Leaving directory '/<>'
  make: *** [debian/rules:4: binary] Error 2

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

Title:
  apport ftbfs with Python 3.12 as the default

Status in apport package in Ubuntu:
  Confirmed
Status in python3-defaults package in Ubuntu:
  New
Status in python3.12 package in Ubuntu:
  New
Status in apport source package in Noble:
  Confirmed
Status in python3-defaults source package in Noble:
  New
Status in python3.12 source package in Noble:
  New

Bug description:
  [Description]

  Python 3.12 gzip.GZipFile.write() outputs truncated data in some cases
  (maybe all?)

  [Test Plan]

  Run the following script:

  import gzip
  import io
  out = io.BytesIO()
  gzip.GzipFile("foo", mode="wb", fileobj=out, mtime=0).write(b"FooFoo")
  # print(out.getvalue())
  print(gzip.decompress(out.getvalue()))

  Expected output (as on Python 3.11):
  FooFoo

  Buggy output (tail end of the stack trace):
  EOFError: Compressed file ended before the end-of-stream marker was reached

  [Original report]

  debian/rules override_dh_auto_test
  make[1]: Entering directory '/<>'
  tests/run-linters --errors-only
  Skipping mypy tests, mypy is not installed
  Running pylint...
  * Module apport-retrace
  bin/apport-retrace:577:44: E0601: Using variable 'crashid' before assignment 
(used-before-assignment)
  make[1]: *** [debian/rules:23: override_dh_auto_test] Error 2
  make[1]: Leaving directory '/<>'
  make: *** [debian/rules:4: binary] Error 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2051512/+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 2051512] Re: apport ftbfs with Python 3.12 as the default

[Simon Chopin]

After further investigations into the gzip issue in python 3.12, it
turns out there was an undocumented change: it is now a buffered writer.
So the fire&forget pattern used in the snippet above doesn't work
anymore, we now need to use it as a proper IO object instead.

I still think this should be reported upstream because of the
documentation issue, but I'll work on changing the apport code to Do The
Right Thing.

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

Title:
  apport ftbfs with Python 3.12 as the default

Status in apport package in Ubuntu:
  Confirmed
Status in python3-defaults package in Ubuntu:
  New
Status in python3.12 package in Ubuntu:
  New
Status in apport source package in Noble:
  Confirmed
Status in python3-defaults source package in Noble:
  New
Status in python3.12 source package in Noble:
  New

Bug description:
  [Description]

  Python 3.12 gzip.GZipFile.write() outputs truncated data in some cases
  (maybe all?)

  [Test Plan]

  Run the following script:

  import gzip
  import io
  out = io.BytesIO()
  gzip.GzipFile("foo", mode="wb", fileobj=out, mtime=0).write(b"FooFoo")
  # print(out.getvalue())
  print(gzip.decompress(out.getvalue()))

  Expected output (as on Python 3.11):
  FooFoo

  Buggy output (tail end of the stack trace):
  EOFError: Compressed file ended before the end-of-stream marker was reached

  [Original report]

  debian/rules override_dh_auto_test
  make[1]: Entering directory '/<>'
  tests/run-linters --errors-only
  Skipping mypy tests, mypy is not installed
  Running pylint...
  * Module apport-retrace
  bin/apport-retrace:577:44: E0601: Using variable 'crashid' before assignment 
(used-before-assignment)
  make[1]: *** [debian/rules:23: override_dh_auto_test] Error 2
  make[1]: Leaving directory '/<>'
  make: *** [debian/rules:4: binary] Error 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2051512/+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 2052930] [NEW] liblocale-gettext-perl autopkgtests fail against glibc 2.39

[Simon Chopin]

Public bug reported:

The autopkgtests for liblocale-gettext-perl fail against glibc 2.39 with
the following errors:

autopkgtest [15:27:03]: test autodep8-perl-build-deps: [---
243s t/bind.t ... 
243s 1..1
243s # Running under perl version 5.036000 for linux
243s # Current time local: Wed Feb  7 15:27:02 2024
243s # Current time GMT:   Wed Feb  7 15:27:02 2024
243s # Using Test.pm version 1.31
243s ok 1
243s ok
243s t/frconvert.t .. 
243s 1..1
243s # Running under perl version 5.036000 for linux
243s # Current time local: Wed Feb  7 15:27:02 2024
243s # Current time GMT:   Wed Feb  7 15:27:02 2024
243s # Using Test.pm version 1.31
243s not ok 1
243s # Failed test 1 in t/frconvert.t at line 22
243s #  t/frconvert.t line 22 is:   ok(0);
243s Failed 1/1 subtests 
243s t/jaconvert.t .. 
243s 1..1
243s # Running under perl version 5.036000 for linux
243s # Current time local: Wed Feb  7 15:27:03 2024
243s # Current time GMT:   Wed Feb  7 15:27:03 2024
243s # Using Test.pm version 1.31
243s test
243s not ok 1
243s # Failed test 1 in t/jaconvert.t at line 23
243s #  t/jaconvert.t line 23 is:   ok(0);
243s Failed 1/1 subtests 
243s t/raw.t  
243s 1..1
243s # Running under perl version 5.036000 for linux
243s # Current time local: Wed Feb  7 15:27:03 2024
243s # Current time GMT:   Wed Feb  7 15:27:03 2024
243s # Using Test.pm version 1.31
243s not ok 1
243s # Failed test 1 in t/raw.t at line 14
243s #  t/raw.t line 14 is: ok(0);
243s Failed 1/1 subtests 
243s t/use.t  
243s 1..1
243s # Running under perl version 5.036000 for linux
243s # Current time local: Wed Feb  7 15:27:03 2024
243s # Current time GMT:   Wed Feb  7 15:27:03 2024
243s # Using Test.pm version 1.31
243s ok 1
243s ok
243s 
243s Test Summary Report
243s ---
243s t/frconvert.t (Wstat: 0 Tests: 1 Failed: 1)
243s   Failed test:  1
243s t/jaconvert.t (Wstat: 0 Tests: 1 Failed: 1)
243s   Failed test:  1
243s t/raw.t  (Wstat: 0 Tests: 1 Failed: 1)
243s   Failed test:  1
243s Files=5, Tests=5,  1 wallclock secs ( 0.03 usr  0.01 sys +  0.09 cusr  
0.07 csys =  0.20 CPU)
243s Result: FAIL

** Affects: glibc (Ubuntu)
 Importance: Undecided
 Status: Triaged

** Affects: liblocale-gettext-perl (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: update-excuse

** Also affects: liblocale-gettext-perl (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  liblocale-gettext-perl autopkgtests fail against glibc 2.39

Status in glibc package in Ubuntu:
  Triaged
Status in liblocale-gettext-perl package in Ubuntu:
  New

Bug description:
  The autopkgtests for liblocale-gettext-perl fail against glibc 2.39
  with the following errors:

  autopkgtest [15:27:03]: test autodep8-perl-build-deps: 
[---
  243s t/bind.t ... 
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:02 2024
  243s # Current time GMT:   Wed Feb  7 15:27:02 2024
  243s # Using Test.pm version 1.31
  243s ok 1
  243s ok
  243s t/frconvert.t .. 
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:02 2024
  243s # Current time GMT:   Wed Feb  7 15:27:02 2024
  243s # Using Test.pm version 1.31
  243s not ok 1
  243s # Failed test 1 in t/frconvert.t at line 22
  243s #  t/frconvert.t line 22 is: ok(0);
  243s Failed 1/1 subtests 
  243s t/jaconvert.t .. 
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:03 2024
  243s # Current time GMT:   Wed Feb  7 15:27:03 2024
  243s # Using Test.pm version 1.31
  243s test
  243s not ok 1
  243s # Failed test 1 in t/jaconvert.t at line 23
  243s #  t/jaconvert.t line 23 is: ok(0);
  243s Failed 1/1 subtests 
  243s t/raw.t  
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:03 2024
  243s # Current time GMT:   Wed Feb  7 15:27:03 2024
  243s # Using Test.pm version 1.31
  243s not ok 1
  243s # Failed test 1 in t/raw.t at line 14
  243s #  t/raw.t line 14 is:   ok(0);
  243s Failed 1/1 subtests 
  243s t/use.t  
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:03 2024
  243s # Current time GMT:   Wed Feb  7 15:27:03 2024
  243s # Using Test.pm version 1.31
  243s ok 1
  243s ok
  243s 
  243s Test Summary Report
  243s ---
  243s t/frconvert.t (Wstat: 0 Tests: 1 Failed: 1)
  243s   Failed test:  1
  243s t/jaconvert.t (Wstat: 0 Tests: 1 Failed: 1)
  243s   Failed test:  1
  243s t/raw.t  (Wstat: 0 Tests: 1 Failed: 1)
  243s   Failed test:  1
  243s Files=5, Tests

[Touch-packages] [Bug 2052930] Re: liblocale-gettext-perl autopkgtests fail against glibc 2.39

[Simon Chopin]

** Tags added: foundations-todo

** Changed in: glibc (Ubuntu)
 Assignee: (unassigned) => Simon Chopin (schopin)

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

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

Title:
  liblocale-gettext-perl autopkgtests fail against glibc 2.39

Status in glibc package in Ubuntu:
  Triaged
Status in liblocale-gettext-perl package in Ubuntu:
  New

Bug description:
  The autopkgtests for liblocale-gettext-perl fail against glibc 2.39
  with the following errors:

  autopkgtest [15:27:03]: test autodep8-perl-build-deps: 
[---
  243s t/bind.t ... 
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:02 2024
  243s # Current time GMT:   Wed Feb  7 15:27:02 2024
  243s # Using Test.pm version 1.31
  243s ok 1
  243s ok
  243s t/frconvert.t .. 
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:02 2024
  243s # Current time GMT:   Wed Feb  7 15:27:02 2024
  243s # Using Test.pm version 1.31
  243s not ok 1
  243s # Failed test 1 in t/frconvert.t at line 22
  243s #  t/frconvert.t line 22 is: ok(0);
  243s Failed 1/1 subtests 
  243s t/jaconvert.t .. 
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:03 2024
  243s # Current time GMT:   Wed Feb  7 15:27:03 2024
  243s # Using Test.pm version 1.31
  243s test
  243s not ok 1
  243s # Failed test 1 in t/jaconvert.t at line 23
  243s #  t/jaconvert.t line 23 is: ok(0);
  243s Failed 1/1 subtests 
  243s t/raw.t  
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:03 2024
  243s # Current time GMT:   Wed Feb  7 15:27:03 2024
  243s # Using Test.pm version 1.31
  243s not ok 1
  243s # Failed test 1 in t/raw.t at line 14
  243s #  t/raw.t line 14 is:   ok(0);
  243s Failed 1/1 subtests 
  243s t/use.t  
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:03 2024
  243s # Current time GMT:   Wed Feb  7 15:27:03 2024
  243s # Using Test.pm version 1.31
  243s ok 1
  243s ok
  243s 
  243s Test Summary Report
  243s ---
  243s t/frconvert.t (Wstat: 0 Tests: 1 Failed: 1)
  243s   Failed test:  1
  243s t/jaconvert.t (Wstat: 0 Tests: 1 Failed: 1)
  243s   Failed test:  1
  243s t/raw.t  (Wstat: 0 Tests: 1 Failed: 1)
  243s   Failed test:  1
  243s Files=5, Tests=5,  1 wallclock secs ( 0.03 usr  0.01 sys +  0.09 cusr  
0.07 csys =  0.20 CPU)
  243s Result: FAIL

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2052930/+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 2046844] Re: AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP

[Simon Chopin]

We had a mitigation for this in glibc but the latest change from simply
denying the unshare() call to allowing it but then denying anything
requiring capabilities *presumably* broke the glibc test suite again.
I'm only basing this from looking at the test logs, as I'm temporarily
unable to run autopkgtests locally and am lacking the time to fix it.

2 classes of errors:

2770s FAIL: stdlib/tst-system
2770s original exit status 1
2770s error: test-container.c:1136: could not create a private mount namespace

That one is clearly userns-related, as it's due to a failing mount()
call right after unshare()

2770s FAIL: sunrpc/tst-svc_register
2770s original exit status 1
2770s error: xwrite.c:32: write of 12 bytes failed after 0: Operation not 
permitted
2770s error: 1 test failures

I can't tell for sure what this one is about since this is your basic
write() call and I don't have a stack trace at hand, but the EPERM would
suggest that it's related.

I think a first fix would be to amend the test script to disable the
userns restriction entirely for the duration of the tests (using 'needs-
sudo'), while I'll still need to patch the test suite eventually to
handle this new failure mode gracefully and simply ignore the tests,
akin to https://sourceware.org/pipermail/libc-
alpha/2024-February/154754.html

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

Title:
  AppArmor user namespace creation restrictions cause many applications
  to crash with SIGTRAP

Status in akonadiconsole package in Ubuntu:
  Fix Released
Status in akregator package in Ubuntu:
  Fix Released
Status in angelfish package in Ubuntu:
  In Progress
Status in apparmor package in Ubuntu:
  Fix Released
Status in bubblewrap package in Ubuntu:
  Confirmed
Status in cantor package in Ubuntu:
  Fix Released
Status in devhelp package in Ubuntu:
  Fix Released
Status in digikam package in Ubuntu:
  Fix Released
Status in epiphany-browser package in Ubuntu:
  Fix Released
Status in evolution package in Ubuntu:
  Fix Released
Status in falkon package in Ubuntu:
  Fix Released
Status in freecad package in Ubuntu:
  Confirmed
Status in ghostwriter package in Ubuntu:
  Fix Released
Status in gnome-packagekit package in Ubuntu:
  Confirmed
Status in goldendict-webengine package in Ubuntu:
  Confirmed
Status in kalgebra package in Ubuntu:
  Fix Released
Status in kchmviewer package in Ubuntu:
  Confirmed
Status in kdeplasma-addons package in Ubuntu:
  Confirmed
Status in kgeotag package in Ubuntu:
  Fix Released
Status in kiwix package in Ubuntu:
  Confirmed
Status in kmail package in Ubuntu:
  Fix Released
Status in konqueror package in Ubuntu:
  Fix Released
Status in kontact package in Ubuntu:
  Fix Released
Status in marble package in Ubuntu:
  Fix Released
Status in notepadqq package in Ubuntu:
  Confirmed
Status in opam package in Ubuntu:
  Fix Released
Status in pageedit package in Ubuntu:
  Confirmed
Status in plasma-desktop package in Ubuntu:
  Confirmed
Status in plasma-welcome package in Ubuntu:
  Fix Released
Status in privacybrowser package in Ubuntu:
  Confirmed
Status in qmapshack package in Ubuntu:
  Confirmed
Status in qutebrowser package in Ubuntu:
  Confirmed
Status in rssguard package in Ubuntu:
  Confirmed
Status in steam package in Ubuntu:
  Fix Committed
Status in supercollider package in Ubuntu:
  Confirmed
Status in tellico package in Ubuntu:
  Fix Released

Bug description:
  Hi, I run Ubuntu development branch 24.04 and I have a problem with
  Epiphany browser 45.1-1 (Gnome Web): program doesn't launch, and I get
  this error

  $ epiphany
  bwrap: Creating new namespace failed: Permission denied

  ** (epiphany:12085): ERROR **: 14:44:35.023: Failed to fully launch 
dbus-proxy: Le processus fils s’est terminé avec le code 1
  Trappe pour point d'arrêt et de trace (core dumped)

  $ epiphany
  bwrap: Creating new namespace failed: Permission denied

  ** (epiphany:30878): ERROR **: 22:22:26.926: Failed to fully launch 
dbus-proxy: Le processus fils s’est terminé avec le code 1
  Trappe pour point d'arrêt et de trace (core dumped)

  Thanks for your help!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/akonadiconsole/+bug/2046844/+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 2056151] [NEW] systemd should create empty /etc/$program.conf.d directories

[Simon Chopin]

Public bug reported:

As a header to all .conf files in systemd there's a comment saying

# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file (or a copy of it placed in
# /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
# the /etc/systemd/user.conf.d/ directory. The latter is generally recommended.

(with variations on the actual directory name, of course)

Since the .d method is the recommended way, the systemd package should
create the empty directory as a way to reduce friction and make it more
even more discoverable to the user.

** 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/2056151

Title:
  systemd should create empty /etc/$program.conf.d directories

Status in systemd package in Ubuntu:
  New

Bug description:
  As a header to all .conf files in systemd there's a comment saying

  # Entries in this file show the compile time defaults. Local configuration
  # should be created by either modifying this file (or a copy of it placed in
  # /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" 
in
  # the /etc/systemd/user.conf.d/ directory. The latter is generally 
recommended.

  (with variations on the actual directory name, of course)

  Since the .d method is the recommended way, the systemd package should
  create the empty directory as a way to reduce friction and make it
  more even more discoverable to the user.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2056151/+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 2056196] [NEW] BT headset is disconnected when remotely changing from A2DP to HSP

[Simon Chopin]

Public bug reported:

Release of Ubuntu: Noble
Package Version: 5.72-0ubuntu1

My headset changed profile from A2DP to HSP as I received a phone call on my 
phone (the headset can connect to multiple BT devices).
I'd expect the system to adapt to the new profile (add a new source, change the 
properties of the sink to signal that it's crappy now, etc...), but instead it 
completely disconnected the headset.

I'd assume this line in the logs is the reason:

mars 05 16:01:44 pug bluetoothd[2644]:
src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free
Voice gateway: getpeername: Transport endpoint is not connected (107)

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: bluez 5.72-0ubuntu1
ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4
Uname: Linux 6.8.0-11-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.28.0-0ubuntu1
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: GNOME
Date: Tue Mar  5 16:03:31 2024
InstallationDate: Installed on 2021-07-05 (974 days ago)
InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
InterestingModules: rfcomm bnep btusb bluetooth
MachineType: Dell Inc. XPS 13 9310
ProcEnviron:
 LANG=fr_FR.UTF-8
 PATH=(custom, no user)
 SHELL=/usr/bin/zsh
 TERM=xterm-256color
 XDG_RUNTIME_DIR=
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.8.0-11-generic 
root=UUID=6bfcd06c-aed1-4da7-949a-dffbf9878bda ro quiet splash 
i915.enable_psr=0 vt.handoff=7
SourcePackage: bluez
UpgradeStatus: Upgraded to noble on 2024-03-05 (0 days ago)
dmi.bios.date: 12/19/2023
dmi.bios.release: 3.20
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 3.20.0
dmi.board.name: 0DXP1F
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: 
dmi:bvnDellInc.:bvr3.20.0:bd12/19/2023:br3.20:svnDellInc.:pnXPS139310:pvr:rvnDellInc.:rn0DXP1F:rvrA00:cvnDellInc.:ct10:cvr:sku0991:
dmi.product.family: XPS
dmi.product.name: XPS 13 9310
dmi.product.sku: 0991
dmi.sys.vendor: Dell Inc.
hciconfig:
 hci0:  Type: Primary  Bus: USB
BD Address: 68:54:5A:94:85:F3  ACL MTU: 1021:4  SCO MTU: 96:6
UP RUNNING PSCAN 
RX bytes:20697414 acl:97 sco:328138 events:3546 errors:0
TX bytes:21468970 acl:107 sco:327713 commands:3406 errors:0

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


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

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

Title:
  BT headset is disconnected when remotely changing from A2DP to HSP

Status in bluez package in Ubuntu:
  New

Bug description:
  Release of Ubuntu: Noble
  Package Version: 5.72-0ubuntu1

  My headset changed profile from A2DP to HSP as I received a phone call on my 
phone (the headset can connect to multiple BT devices).
  I'd expect the system to adapt to the new profile (add a new source, change 
the properties of the sink to signal that it's crappy now, etc...), but instead 
it completely disconnected the headset.

  I'd assume this line in the logs is the reason:

  mars 05 16:01:44 pug bluetoothd[2644]:
  src/profile.c:ext_io_disconnected() Unable to get io data for Hands-
  Free Voice gateway: getpeername: Transport endpoint is not connected
  (107)

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: bluez 5.72-0ubuntu1
  ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4
  Uname: Linux 6.8.0-11-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.28.0-0ubuntu1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: GNOME
  Date: Tue Mar  5 16:03:31 2024
  InstallationDate: Installed on 2021-07-05 (974 days ago)
  InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  InterestingModules: rfcomm bnep btusb bluetooth
  MachineType: Dell Inc. XPS 13 9310
  ProcEnviron:
   LANG=fr_FR.UTF-8
   PATH=(custom, no user)
   SHELL=/usr/bin/zsh
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.8.0-11-generic 
root=UUID=6bfcd06c-aed1-4da7-949a-dffbf9878bda ro quiet splash 
i915.enable_psr=0 vt.handoff=7
  SourcePackage: bluez
  UpgradeStatus: Upgraded to noble on 2024-03-05 (0 days ago)
  dmi.bios.date: 12/19/2023
  dmi.bios.release: 3.20
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 3.20.0
  dmi.board.name: 0DXP1F
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr3.20.0:bd12/19/2023:br3.20:svnDellInc.:pnXPS139310:pvr:rvnDellInc.:rn0DXP1F:rvrA00:cvnDellInc.:ct10:cvr:sku0991:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9310
  dmi.product.sku: 0991
  dmi.sys.vendor: Dell Inc.
  hciconfig:
   hci0:Type: Primary  Bus: USB
BD Address: 68:54:5A:94:85:F3  ACL MTU: 1021:4  SCO MTU: 96:6
UP RUNNING PSCAN 
RX bytes:20697414 acl:97 sco:328138 even

[Touch-packages] [Bug 2056561] Re: Libc6 bug in gvfs-udisk

[Simon Chopin]

Unless I'm missing something, the issue you're linking is about glib,
not glibc. Reassigning the bug accordingly.

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

** Changed in: glibc (Ubuntu)
   Status: New => Invalid

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

Title:
  Libc6 bug in gvfs-udisk

Status in glib2.0 package in Ubuntu:
  New
Status in glibc package in Ubuntu:
  Invalid

Bug description:
  Hi,

  Please see https://gitlab.gnome.org/GNOME/glib/-/issues/3168, which is
  a result of https://gitlab.gnome.org/GNOME/glib/-/issues/3168, which
  is fixed but needs a backport or something.

  Thanks,

  tg

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: libc6 2.38-1ubuntu6.1
  ProcVersionSignature: Ubuntu 6.5.0-25.25-generic 6.5.13
  Uname: Linux 6.5.0-25-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.27.0-0ubuntu5
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: GNOME
  Date: Fri Mar  8 15:15:39 2024
  Dependencies:
   gcc-13-base 13.2.0-4ubuntu3
   libc6 2.38-1ubuntu6.1
   libgcc-s1 13.2.0-4ubuntu3
   libidn2-0 2.3.4-1
   libunistring2 1.0-2
  InstallationDate: Installed on 2022-12-08 (456 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221020)
  SourcePackage: glibc
  UpgradeStatus: Upgraded to mantic on 2023-10-01 (159 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2056561/+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 2052930] Re: liblocale-gettext-perl autopkgtests fail against glibc 2.39

[Simon Chopin]

It turns out the fix was already in the upstream repo as a PR for a
while (couple of years?). I've submitted a Salsa MR to proactively
address the issue before it shows up there:

https://salsa.debian.org/perl-team/modules/packages/liblocale-gettext-
perl/-/merge_requests/1

and I've uploaded the same changes in Ubuntu.

** Changed in: liblocale-gettext-perl (Ubuntu)
   Status: New => Fix Committed

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

Title:
  liblocale-gettext-perl autopkgtests fail against glibc 2.39

Status in glibc package in Ubuntu:
  Triaged
Status in liblocale-gettext-perl package in Ubuntu:
  Fix Committed

Bug description:
  The autopkgtests for liblocale-gettext-perl fail against glibc 2.39
  with the following errors:

  autopkgtest [15:27:03]: test autodep8-perl-build-deps: 
[---
  243s t/bind.t ... 
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:02 2024
  243s # Current time GMT:   Wed Feb  7 15:27:02 2024
  243s # Using Test.pm version 1.31
  243s ok 1
  243s ok
  243s t/frconvert.t .. 
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:02 2024
  243s # Current time GMT:   Wed Feb  7 15:27:02 2024
  243s # Using Test.pm version 1.31
  243s not ok 1
  243s # Failed test 1 in t/frconvert.t at line 22
  243s #  t/frconvert.t line 22 is: ok(0);
  243s Failed 1/1 subtests 
  243s t/jaconvert.t .. 
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:03 2024
  243s # Current time GMT:   Wed Feb  7 15:27:03 2024
  243s # Using Test.pm version 1.31
  243s test
  243s not ok 1
  243s # Failed test 1 in t/jaconvert.t at line 23
  243s #  t/jaconvert.t line 23 is: ok(0);
  243s Failed 1/1 subtests 
  243s t/raw.t  
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:03 2024
  243s # Current time GMT:   Wed Feb  7 15:27:03 2024
  243s # Using Test.pm version 1.31
  243s not ok 1
  243s # Failed test 1 in t/raw.t at line 14
  243s #  t/raw.t line 14 is:   ok(0);
  243s Failed 1/1 subtests 
  243s t/use.t  
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:03 2024
  243s # Current time GMT:   Wed Feb  7 15:27:03 2024
  243s # Using Test.pm version 1.31
  243s ok 1
  243s ok
  243s 
  243s Test Summary Report
  243s ---
  243s t/frconvert.t (Wstat: 0 Tests: 1 Failed: 1)
  243s   Failed test:  1
  243s t/jaconvert.t (Wstat: 0 Tests: 1 Failed: 1)
  243s   Failed test:  1
  243s t/raw.t  (Wstat: 0 Tests: 1 Failed: 1)
  243s   Failed test:  1
  243s Files=5, Tests=5,  1 wallclock secs ( 0.03 usr  0.01 sys +  0.09 cusr  
0.07 csys =  0.20 CPU)
  243s Result: FAIL

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2052930/+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 2052930] Re: liblocale-gettext-perl autopkgtests fail against glibc 2.39

[Simon Chopin]

** Changed in: glibc (Ubuntu)
   Status: Triaged => Invalid

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

Title:
  liblocale-gettext-perl autopkgtests fail against glibc 2.39

Status in glibc package in Ubuntu:
  Invalid
Status in liblocale-gettext-perl package in Ubuntu:
  Fix Committed

Bug description:
  The autopkgtests for liblocale-gettext-perl fail against glibc 2.39
  with the following errors:

  autopkgtest [15:27:03]: test autodep8-perl-build-deps: 
[---
  243s t/bind.t ... 
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:02 2024
  243s # Current time GMT:   Wed Feb  7 15:27:02 2024
  243s # Using Test.pm version 1.31
  243s ok 1
  243s ok
  243s t/frconvert.t .. 
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:02 2024
  243s # Current time GMT:   Wed Feb  7 15:27:02 2024
  243s # Using Test.pm version 1.31
  243s not ok 1
  243s # Failed test 1 in t/frconvert.t at line 22
  243s #  t/frconvert.t line 22 is: ok(0);
  243s Failed 1/1 subtests 
  243s t/jaconvert.t .. 
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:03 2024
  243s # Current time GMT:   Wed Feb  7 15:27:03 2024
  243s # Using Test.pm version 1.31
  243s test
  243s not ok 1
  243s # Failed test 1 in t/jaconvert.t at line 23
  243s #  t/jaconvert.t line 23 is: ok(0);
  243s Failed 1/1 subtests 
  243s t/raw.t  
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:03 2024
  243s # Current time GMT:   Wed Feb  7 15:27:03 2024
  243s # Using Test.pm version 1.31
  243s not ok 1
  243s # Failed test 1 in t/raw.t at line 14
  243s #  t/raw.t line 14 is:   ok(0);
  243s Failed 1/1 subtests 
  243s t/use.t  
  243s 1..1
  243s # Running under perl version 5.036000 for linux
  243s # Current time local: Wed Feb  7 15:27:03 2024
  243s # Current time GMT:   Wed Feb  7 15:27:03 2024
  243s # Using Test.pm version 1.31
  243s ok 1
  243s ok
  243s 
  243s Test Summary Report
  243s ---
  243s t/frconvert.t (Wstat: 0 Tests: 1 Failed: 1)
  243s   Failed test:  1
  243s t/jaconvert.t (Wstat: 0 Tests: 1 Failed: 1)
  243s   Failed test:  1
  243s t/raw.t  (Wstat: 0 Tests: 1 Failed: 1)
  243s   Failed test:  1
  243s Files=5, Tests=5,  1 wallclock secs ( 0.03 usr  0.01 sys +  0.09 cusr  
0.07 csys =  0.20 CPU)
  243s Result: FAIL

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2052930/+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 2059078] Re: proposed-migration for faketime 0.9.10-2.1ubuntu1

[Simon Chopin]

Oh, hang on. The bash build has apparently been uploaded just a day
after the t64 gcc, which means gcc was presumably still building when
the bash build started:

gcc-13 armhf 13.2.0-13ubuntu1 (from the bash build logs)

A bash rebuild should "fix" this somewhat. Well, at least a little bit.

** Also affects: bash (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  proposed-migration for faketime 0.9.10-2.1ubuntu1

Status in bash package in Ubuntu:
  New
Status in faketime package in Ubuntu:
  New

Bug description:
  faketime 0.9.10-2.1ubuntu1 is stuck in -proposed with build failures
  on armhf.

  On armhf, the testsuite confusingly fails with a stack smash error.
  But this error happens in bash, which isn't even meant to be the
  process under test.

  Minimal reproducer:
  # LD_PRELOAD=./src/libfaketime.so.1 bash -c 'exit 0'
  *** stack smashing detected ***: terminated
  Aborted (core dumped)
  #

  Confusingly, ltrace shows different results for the newly-built binary
  than from one built without 64-bit time_t.

  # LD_PRELOAD=./src/libfaketime.so.1 ltrace --library '*faketime*' bash -c 
'exit 0'
  bash->getrandom(0x1f3bf08, 1, 0x9683b0, 0)   = 0xc8202
  bash->getrandom(0xc8203, 0xf7fad53c, 1023, 0xf7eef801) = 0xc8202
  *** stack smashing detected ***: terminated
  --- SIGABRT (Aborted) ---
  +++ killed by SIGABRT +++
  # LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/faketime/libfaketime.so.1 ltrace 
--library '*faketime*' bash -c 'exit 0' 
  bash->gettimeofday(0x8b07a0, 0)  = 0
  bash->getpid()   = 819717
  bash->gettimeofday(0xffb88714, 0)= 0
  bash->getpid()   = 819717
  bash->gettimeofday(0xffb8871c, 0)= 0
  bash->getpid()   = 819717
  +++ exited (status 0) +++
  #

  Unsetting -DFAKE_RANDOM in debian/rules does not fix the problem
  however.

  So simply loading the LD_PRELOAD library without executing it seems to
  be enough to break bash.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/2059078/+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 2058769] Re: proposed-migration for click 0.5.2-2

[Simon Chopin]

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

** Description changed:

- click 0.5.2-2 is stuck in -proposed.  autopkgtest now fails on armhf,
- and possibly on all archs.
+ click 0.5.2-2 is stuck in -proposed.  autopkgtest now fails on ppc64el,
+ s390x.
  
- armhf binary will be removed from the release pocket.
+ In order to be able to run the tests without all-proposed=1, glib 2.0 is
+ needed, which is why I marked it as affected.
+ 
+ Excerpt of the test logs:
+ 
+ ERROR: test_list_simple 
(click_package.tests.integration.test_list.TestList.test_list_simple)
+ --
+ Traceback (most recent call last):
+   File 
"/tmp/autopkgtest.VczHPz/build.dRN/src/click_package/tests/integration/test_list.py",
 line 29, in test_list_simple
+ self.click_install(path_to_click, name, user)
+   File 
"/tmp/autopkgtest.VczHPz/build.dRN/src/click_package/tests/integration/helpers.py",
 line 99, in click_install
+ subprocess.check_call(cmd)
+   File "/usr/lib/python3.12/subprocess.py", line 413, in check_call
+ raise CalledProcessError(retcode, cmd)
+ subprocess.CalledProcessError: Command '['/usr/bin/click', 'install', 
'--user=root', '--allow-unauthenticated', 
'/tmp/tmpqhzp18eh/com.ubuntu.verify-ok_1.0_all.click']' returned non-zero exit 
status 1.
+ 
+ ==
+ ERROR: test_debsig_install_valid_signature 
(click_package.tests.integration.test_signatures.TestSignatureVerification.test_debsig_install_valid_signature)
+ --
+ Traceback (most recent call last):
+   File 
"/tmp/autopkgtest.VczHPz/build.dRN/src/click_package/tests/integration/test_signatures.py",
 line 207, in test_debsig_install_valid_signature
+ subprocess.check_call(
+   File "/usr/lib/python3.12/subprocess.py", line 413, in check_call
+ raise CalledProcessError(retcode, cmd)
+ subprocess.CalledProcessError: Command '['/usr/bin/click', 'install', 
'--user=root', '/tmp/tmpymtfsjg9/org.example.debsig-valid-sig_1.0_all.click']' 
returned non-zero exit status 1.
+ 
+ ==
+ ERROR: test_debsig_install_can_install_with_sig_override 
(click_package.tests.integration.test_signatures.TestSignatureVerificationNoSignature.test_debsig_install_can_install_with_sig_override)
+ --
+ Traceback (most recent call last):
+   File 
"/tmp/autopkgtest.VczHPz/build.dRN/src/click_package/tests/integration/test_signatures.py",
 line 164, in test_debsig_install_can_install_with_sig_override
+ subprocess.check_call(
+   File "/usr/lib/python3.12/subprocess.py", line 413, in check_call
+ raise CalledProcessError(retcode, cmd)
+ subprocess.CalledProcessError: Command '['/usr/bin/click', 'install', 
'--allow-unauthenticated', '--user=root', 
'/tmp/tmpheysy9ze/org.example.debsig-no-sig_1.0_all.click']' returned non-zero 
exit status 1.

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

Title:
  proposed-migration for click 0.5.2-2

Status in click package in Ubuntu:
  New
Status in glib2.0 package in Ubuntu:
  New

Bug description:
  click 0.5.2-2 is stuck in -proposed.  autopkgtest now fails on
  ppc64el, s390x.

  In order to be able to run the tests without all-proposed=1, glib 2.0
  is needed, which is why I marked it as affected.

  Excerpt of the test logs:

  ERROR: test_list_simple 
(click_package.tests.integration.test_list.TestList.test_list_simple)
  --
  Traceback (most recent call last):
File 
"/tmp/autopkgtest.VczHPz/build.dRN/src/click_package/tests/integration/test_list.py",
 line 29, in test_list_simple
  self.click_install(path_to_click, name, user)
File 
"/tmp/autopkgtest.VczHPz/build.dRN/src/click_package/tests/integration/helpers.py",
 line 99, in click_install
  subprocess.check_call(cmd)
File "/usr/lib/python3.12/subprocess.py", line 413, in check_call
  raise CalledProcessError(retcode, cmd)
  subprocess.CalledProcessError: Command '['/usr/bin/click', 'install', 
'--user=root', '--allow-unauthenticated', 
'/tmp/tmpqhzp18eh/com.ubuntu.verify-ok_1.0_all.click']' returned non-zero exit 
status 1.

  ==
  ERROR: test_debsig_install_valid_signature 
(click_package.tests.integration.test_signatures.TestSignatureVerification.test_debsig_install_valid_signature)
  --
  Traceback (most recent call last):
File 
"/tmp/autopkgtest.VczHPz/build.dRN/src/click_package/tests/integration/test_signatures.py",
 line 207, in test_debsig_install_

[Touch-packages] [Bug 2059078] Re: proposed-migration for faketime 0.9.10-2.1ubuntu1

[Simon Chopin]

What now remains to be done is to heavily patch faketime to, when on
armhf:

1/ use the proper symbols from glibc (e.g. __clock_gettime64 instead of 
__clock_gettime)
2/ expose those symbols instead of the legacy 32-bit ones.

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

Title:
  proposed-migration for faketime 0.9.10-2.1ubuntu1

Status in bash package in Ubuntu:
  New
Status in faketime package in Ubuntu:
  New

Bug description:
  faketime 0.9.10-2.1ubuntu1 is stuck in -proposed with build failures
  on armhf.

  On armhf, the testsuite confusingly fails with a stack smash error.
  But this error happens in bash, which isn't even meant to be the
  process under test.

  Minimal reproducer:
  # LD_PRELOAD=./src/libfaketime.so.1 bash -c 'exit 0'
  *** stack smashing detected ***: terminated
  Aborted (core dumped)
  #

  Confusingly, ltrace shows different results for the newly-built binary
  than from one built without 64-bit time_t.

  # LD_PRELOAD=./src/libfaketime.so.1 ltrace --library '*faketime*' bash -c 
'exit 0'
  bash->getrandom(0x1f3bf08, 1, 0x9683b0, 0)   = 0xc8202
  bash->getrandom(0xc8203, 0xf7fad53c, 1023, 0xf7eef801) = 0xc8202
  *** stack smashing detected ***: terminated
  --- SIGABRT (Aborted) ---
  +++ killed by SIGABRT +++
  # LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/faketime/libfaketime.so.1 ltrace 
--library '*faketime*' bash -c 'exit 0' 
  bash->gettimeofday(0x8b07a0, 0)  = 0
  bash->getpid()   = 819717
  bash->gettimeofday(0xffb88714, 0)= 0
  bash->getpid()   = 819717
  bash->gettimeofday(0xffb8871c, 0)= 0
  bash->getpid()   = 819717
  +++ exited (status 0) +++
  #

  Unsetting -DFAKE_RANDOM in debian/rules does not fix the problem
  however.

  So simply loading the LD_PRELOAD library without executing it seems to
  be enough to break bash.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/2059078/+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 2060962] Re: apport-bug: cli reports syntax warnings to user

[Simon Chopin]

** Also affects: apport-symptoms (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: apport (Ubuntu)
   Status: New => Invalid

** Description changed:

  Apport version: 2.28.0-0ubuntu1
  Ubuntu-Server 24.04 Beta amd64 (20240410.1)
  
- See attached screenshot for error.
+ /usr/share/apport/symptoms/_audio_data.py:123: SyntaxWarning: invalid escape 
sequence '\['
+   m = re.search('Pin Default 0x(.*?): \[(.*?)\] (.*?) at (.*?) (.*)', line)
+ /usr/share/apport/symptoms/_audio_data.py:148: SyntaxWarning: invalid escape 
sequence '\d'
+   m = re.search(' (\d+) \[(\w+)\s*\]: (.+)', card)
+ /usr/share/apport/symptoms/_audio_data.py:162: SyntaxWarning: invalid escape 
sequence '\w'
+   m = re.match('^(\w+) #(\d+)', line)
+ /usr/share/apport/symptoms/_audio_data.py:171: SyntaxWarning: invalid escape 
sequence '\w'
+   m = re.match('^\t(\w+.*?): (.*)', line)
+ /usr/share/apport/symptoms/_audio_data.py:177: SyntaxWarning: invalid escape 
sequence '\w'
+   m = re.match('^\t(\w+.*?):', line)
+ /usr/share/apport/symptoms/_audio_data.py:182: SyntaxWarning: invalid escape 
sequence '\w'
+   m = re.match('^\t\t(\w+.*?) = "(.*)"', line)
+ /usr/share/apport/symptoms/_audio_mixercontrol.py:29: SyntaxWarning: invalid 
escape sequence '\['
+   m = re.search("\[([\-0-9.]+)dB\]", s)
+ /usr/share/apport/symptoms/_audio_mixercontrol.py:34: SyntaxWarning: invalid 
escape sequence '\['
+   if re.search("\[on\]", s):
+ /usr/share/apport/symptoms/_audio_mixercontrol.py:36: SyntaxWarning: invalid 
escape sequence '\['
+   if re.search("\[off\]", s):
+ /usr/share/apport/symptoms/_audio_mixercontrol.py:38: SyntaxWarning: invalid 
escape sequence '\d'
+   m = re.search(" ?(\d+) ", s)
+ /usr/share/apport/symptoms/_audio_mixercontrol.py:41: SyntaxWarning: invalid 
escape sequence '\['
+   m = re.search("\[([\-0-9.]+)%\]", s)

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

Title:
  apport-bug: cli reports syntax warnings to user

Status in apport package in Ubuntu:
  Invalid
Status in apport-symptoms package in Ubuntu:
  New

Bug description:
  Apport version: 2.28.0-0ubuntu1
  Ubuntu-Server 24.04 Beta amd64 (20240410.1)

  /usr/share/apport/symptoms/_audio_data.py:123: SyntaxWarning: invalid escape 
sequence '\['
m = re.search('Pin Default 0x(.*?): \[(.*?)\] (.*?) at (.*?) (.*)', line)
  /usr/share/apport/symptoms/_audio_data.py:148: SyntaxWarning: invalid escape 
sequence '\d'
m = re.search(' (\d+) \[(\w+)\s*\]: (.+)', card)
  /usr/share/apport/symptoms/_audio_data.py:162: SyntaxWarning: invalid escape 
sequence '\w'
m = re.match('^(\w+) #(\d+)', line)
  /usr/share/apport/symptoms/_audio_data.py:171: SyntaxWarning: invalid escape 
sequence '\w'
m = re.match('^\t(\w+.*?): (.*)', line)
  /usr/share/apport/symptoms/_audio_data.py:177: SyntaxWarning: invalid escape 
sequence '\w'
m = re.match('^\t(\w+.*?):', line)
  /usr/share/apport/symptoms/_audio_data.py:182: SyntaxWarning: invalid escape 
sequence '\w'
m = re.match('^\t\t(\w+.*?) = "(.*)"', line)
  /usr/share/apport/symptoms/_audio_mixercontrol.py:29: SyntaxWarning: invalid 
escape sequence '\['
m = re.search("\[([\-0-9.]+)dB\]", s)
  /usr/share/apport/symptoms/_audio_mixercontrol.py:34: SyntaxWarning: invalid 
escape sequence '\['
if re.search("\[on\]", s):
  /usr/share/apport/symptoms/_audio_mixercontrol.py:36: SyntaxWarning: invalid 
escape sequence '\['
if re.search("\[off\]", s):
  /usr/share/apport/symptoms/_audio_mixercontrol.py:38: SyntaxWarning: invalid 
escape sequence '\d'
m = re.search(" ?(\d+) ", s)
  /usr/share/apport/symptoms/_audio_mixercontrol.py:41: SyntaxWarning: invalid 
escape sequence '\['
m = re.search("\[([\-0-9.]+)%\]", s)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2060962/+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 2063200] Re: useradd --extrausers --groups tries to lock /etc/group

[Simon Chopin]

** Changed in: shadow (Ubuntu)
 Assignee: (unassigned) => Simon Chopin (schopin)

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

Title:
  useradd --extrausers --groups tries to lock /etc/group

Status in shadow package in Ubuntu:
  New

Bug description:
  On Ubuntu Core 24 calling the command line

  useradd --extrausers --groups somegroup somenewuser

  ... fails with:

  useradd: cannot lock /etc/group; try again later.

  It worked on 22.04. /etc is not writable. It also fails if somegroup
  is a group in extrausers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2063200/+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 2063200] Re: useradd --extrausers --groups tries to lock /etc/group

[Simon Chopin]

Quick repro steps:

❯ lxc launch ubuntu-daily:noble shadow
Creating shadow
Starting shadow
❯ lxc exec shadow bash
root@shadow:~# mv /etc /etc_write
root@shadow:~# mkdir /etc
root@shadow:~# mount -o bind,ro /etc_write /etc
root@shadow:~# useradd --extrausers --groups somegroup somenewuser
useradd: cannot lock /etc/group; try again later.

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

Title:
  useradd --extrausers --groups tries to lock /etc/group

Status in shadow package in Ubuntu:
  New

Bug description:
  On Ubuntu Core 24 calling the command line

  useradd --extrausers --groups somegroup somenewuser

  ... fails with:

  useradd: cannot lock /etc/group; try again later.

  It worked on 22.04. /etc is not writable. It also fails if somegroup
  is a group in extrausers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2063200/+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 2063200] Re: useradd --extrausers --groups tries to lock /etc/group

[Simon Chopin]

** Tags added: foundations-todo

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

Title:
  useradd --extrausers --groups tries to lock /etc/group

Status in shadow package in Ubuntu:
  New

Bug description:
  On Ubuntu Core 24 calling the command line

  useradd --extrausers --groups somegroup somenewuser

  ... fails with:

  useradd: cannot lock /etc/group; try again later.

  It worked on 22.04. /etc is not writable. It also fails if somegroup
  is a group in extrausers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2063200/+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 2063200] Re: useradd --extrausers --groups tries to lock /etc/group

[Simon Chopin]

The issue was introduced with https://github.com/shadow-
maint/shadow/pull/237

Basically, the previous group validation was done using glibc's getgrid
directly, which was presumably coping well with the RO status of
/etc/group, but that poses consistency problems because you could add a
local user to a network group. That PR changed this to only check the
local /etc/group file contents manually instead.

Sadly, it doesn't cope well with our extrausers feature on multiple levels:
* The manual code fails hard if it can't lock the files
* We presumably have local groups defined in multiple places, which the code 
doesn't allow for.

A quickfix would be:
* Move the validation to until *after* parsing all of the options
* Revert back to the previous approach to validate groups if in extrausers mode

A more involved fix would be to replace that with an approach that would
check both /etc/group and the extrausers equivalent when validating
groups, while silently ignoring locking failures.

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

Title:
  useradd --extrausers --groups tries to lock /etc/group

Status in shadow package in Ubuntu:
  New

Bug description:
  On Ubuntu Core 24 calling the command line

  useradd --extrausers --groups somegroup somenewuser

  ... fails with:

  useradd: cannot lock /etc/group; try again later.

  It worked on 22.04. /etc is not writable. It also fails if somegroup
  is a group in extrausers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2063200/+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 1972056] Re: [openssl3] please sync openssl.cnf to ease changing security level

[Simon Chopin]

** Description changed:

- openssl.cnf as provided misses some directive, which make it a bit
- difficult to change security level, which since openssl 3 disables SHA1
- signatures.
+ [Impact]
+ 
+ The OpenSSL 3.0 lead to a lot of broken setups. Some of them are
+ regressions, but others are simply broken due to the use of outdated
+ algorithms, such as SHA-1 signature on certificates. Changing the
+ security level is a common action to identify and work around such
+ cases, and as such the user should be able to change it easily  in the
+ default config file.
+ 
+ The fix is to partially revert our delta that ignored a Debian patch:
+ instead of ignoring the patch entirely, we modify it to only affect the
+ default configuration file, and in a way that matches our patchset.
+ Using this approach will allow us to pick up on Debian's changes more
+ easily during subsequent merges.
+ 
+ [Test Plan]
+ 
+ To easily check that the setting is taken into account, one can use
+ 'openssl ciphers -s'
+ 
+ $ openssl ciphers -v -s | wc -l # Uses the default value
+ 30
+ $ openssl ciphers -v -s 'DEFAULT:@SECLEVEL=2' | wc -l
+ 30
+ $ openssl ciphers -v -s 'DEFAULT:@SECLEVEL=3' | wc -l
+ 24
+ $ vim /etc/ssl/openssl.cf # edit the config file to bump the seclevel to 3
+ $ openssl ciphers -v -s | wc -l # Uses the new value from the config file
+ 24
+ 
+ [Where problems could occur]
+ 
+ The changes could break the overall configuration of OpenSSL!
+ 
+ [Origin report]
+ openssl.cnf as provided misses some directive, which make it a bit difficult 
to change security level, which since openssl 3 disables SHA1 signatures.
  
  See also this Debian bug https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=1010360 and the committed fix:
  
https://salsa.debian.org/debian/openssl/-/commit/b507914c40270e32cde6afcc8af93707c225e7f4
  
  Can you please sync this change in Ubuntu openssl?
  
  This way one should just add a single directive to change the security
  level.
  
  Thanks.

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

Title:
  [openssl3] please sync openssl.cnf to ease changing security level

Status in openssl package in Ubuntu:
  Confirmed
Status in openssl source package in Jammy:
  Confirmed
Status in openssl source package in Kinetic:
  Confirmed
Status in openssl package in Debian:
  Fix Released

Bug description:
  [Impact]

  The OpenSSL 3.0 lead to a lot of broken setups. Some of them are
  regressions, but others are simply broken due to the use of outdated
  algorithms, such as SHA-1 signature on certificates. Changing the
  security level is a common action to identify and work around such
  cases, and as such the user should be able to change it easily  in the
  default config file.

  The fix is to partially revert our delta that ignored a Debian patch:
  instead of ignoring the patch entirely, we modify it to only affect
  the default configuration file, and in a way that matches our
  patchset. Using this approach will allow us to pick up on Debian's
  changes more easily during subsequent merges.

  [Test Plan]

  To easily check that the setting is taken into account, one can use
  'openssl ciphers -s'

  $ openssl ciphers -v -s | wc -l # Uses the default value
  30
  $ openssl ciphers -v -s 'DEFAULT:@SECLEVEL=2' | wc -l
  30
  $ openssl ciphers -v -s 'DEFAULT:@SECLEVEL=3' | wc -l
  24
  $ vim /etc/ssl/openssl.cf # edit the config file to bump the seclevel to 3
  $ openssl ciphers -v -s | wc -l # Uses the new value from the config file
  24

  [Where problems could occur]

  The changes could break the overall configuration of OpenSSL!

  [Origin report]
  openssl.cnf as provided misses some directive, which make it a bit difficult 
to change security level, which since openssl 3 disables SHA1 signatures.

  See also this Debian bug https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=1010360 and the committed fix:
  
https://salsa.debian.org/debian/openssl/-/commit/b507914c40270e32cde6afcc8af93707c225e7f4

  Can you please sync this change in Ubuntu openssl?

  This way one should just add a single directive to change the security
  level.

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1972056/+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 1947588] Re: Infinite Loop in OpenSSL s_server

[Simon Chopin]

** Description changed:

+ [Impact]
+ 
+ The TLS test server `openssl s_server` can very easily be led into an
+ infinite loop if configured with incompatible settings and used via
+ DTLS. This makes it harder to test one's TLS configuration.
+ 
+ [Test plan]
+ 
+ In one session:
+ $ openssl s_server -nocert -psk 01020304 -dtls1
+ In parallel:
+ $ openssl s_client -dtls1 -psk 01020304
+ 
+ The server session will enter an infinite loop:
+ Using default temp DH parameters
+ ACCEPT
+ ERROR
+ 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal 
error:../ssl/statem/statem_lib.c:109:
+ ERROR
+ 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal 
error:../ssl/statem/statem_lib.c:109:
+ ERROR
+ ... etc...
+ 
+ [Where problems could occur]
+ 
+ The patch is fairly self-contained, so regressions should only occur in
+ the `openssl s_server` application, and not in the libssl or libcrypto
+ libraries.
+ However, the patch could break said server, which might be used in e.g.
+ autopkgtests.
+ 
+ [Original report]
  Launching openssl s_server as follows:
  
  $ openssl s_server -nocert -psk 01020304 -dtls1
  
  And using openssl s_client to connect to it like this:
  
  $ openssl s_client -dtls1 -psk 01020304
  
  Results in s_server entering an infinite loop:
- 
  
  Using default temp DH parameters
  ACCEPT
  ERROR
  140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal 
error:../ssl/statem/statem_lib.c:109:
  ERROR
  140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal 
error:../ssl/statem/statem_lib.c:109:
  ERROR
  
  ...and so on...
  
  I have confirmed that upstream OpenSSL does not have this issue in a
  default build of 1.1.1j or 1.1.1k. Upstream 1.1.1l has a different bug
  with these commands (https://github.com/openssl/openssl/issues/16707)
  and it was while working on the fix for that issue
  (https://github.com/openssl/openssl/pull/16838) that I noticed this
  problem in the Ubuntu packages.
  
  $ lsb_release -rd
- Description:  Ubuntu 21.04
- Release:  21.04
+ Description: Ubuntu 21.04
+ Release: 21.04
  
  $ apt-cache policy openssl
  openssl:
Installed: 1.1.1j-1ubuntu3.5
Candidate: 1.1.1j-1ubuntu3.5
Version table:
   *** 1.1.1j-1ubuntu3.5 500
  500 http://gb.archive.ubuntu.com/ubuntu hirsute-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu hirsute-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1.1.1j-1ubuntu3 500
  500 http://gb.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages
  
  $ openssl version -a
- OpenSSL 1.1.1j  16 Feb 2021
+ OpenSSL 1.1.1j 16 Feb 2021
  built on: Mon Aug 23 17:02:39 2021 UTC
  platform: debian-amd64
- options:  bn(64,64) rc4(16x,int) des(int) blowfish(ptr) 
+ options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr)
  compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack 
-g -O2 -ffile-prefix-map=/build/openssl-5U8yxE/openssl-1.1.1j=. -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC 
-DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time 
-D_FORTIFY_SOURCE=2
  OPENSSLDIR: "/usr/lib/ssl"
  ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
  Seeding source: os-specific

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

Title:
  Infinite Loop in OpenSSL s_server

Status in openssl package in Ubuntu:
  Confirmed
Status in openssl source package in Focal:
  Confirmed
Status in openssl source package in Impish:
  Confirmed
Status in openssl source package in Jammy:
  Confirmed

Bug description:
  [Impact]

  The TLS test server `openssl s_server` can very easily be led into an
  infinite loop if configured with incompatible settings and used via
  DTLS. This makes it harder to test one's TLS configuration.

  [Test plan]

  In one session:
  $ openssl s_server -nocert -psk 01020304 -dtls1
  In parallel:
  $ openssl s_client -dtls1 -psk 01020304

  The server session will enter an infinite loop:
  Using default temp DH parameters
  ACCEPT
  ERROR
  140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal 
error:../ssl/statem/statem_lib.c:109:
  ERROR
  140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal 
error:../ssl/statem/statem_lib.c:109:
  ERROR
  ... etc...

  [Where problems could occur]

  The patch is fairly self-contained, so regressions should only occur in
  the `openssl s_server` application, and not in the libssl or libcrypto
  libraries.
  However, the patch could brea

[Touch-packages] [Bug 1978093] [NEW] openssl: FTBFS due to missing certificates

[Simon Chopin]

Public bug reported:

Some certificates in the openssl package expired on 2022-06-01, making
the test suite fail.

** Affects: openssl (Ubuntu)
 Importance: Critical
 Status: Confirmed

** Affects: openssl (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Affects: openssl (Ubuntu Focal)
 Importance: Undecided
 Status: New

** Affects: openssl (Ubuntu Impish)
 Importance: Undecided
 Status: New

** Affects: openssl (Ubuntu Jammy)
 Importance: Undecided
 Status: New

** Affects: openssl (Ubuntu Kinetic)
 Importance: Critical
 Status: Confirmed

** Also affects: openssl (Ubuntu Impish)
   Importance: Undecided
   Status: New

** Also affects: openssl (Ubuntu Kinetic)
   Importance: Critical
   Status: Confirmed

** Also affects: openssl (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: openssl (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: openssl (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

Title:
  openssl: FTBFS due to missing certificates

Status in openssl package in Ubuntu:
  Confirmed
Status in openssl source package in Bionic:
  New
Status in openssl source package in Focal:
  New
Status in openssl source package in Impish:
  New
Status in openssl source package in Jammy:
  New
Status in openssl source package in Kinetic:
  Confirmed

Bug description:
  Some certificates in the openssl package expired on 2022-06-01, making
  the test suite fail.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1978093/+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 1978093] Re: openssl: FTBFS due to expired certificates

[Simon Chopin]

** Summary changed:

- openssl: FTBFS due to missing certificates
+ openssl: FTBFS due to expired certificates

** Tags added: ftbfs

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

Title:
  openssl: FTBFS due to expired certificates

Status in openssl package in Ubuntu:
  Confirmed
Status in openssl source package in Bionic:
  New
Status in openssl source package in Focal:
  New
Status in openssl source package in Impish:
  New
Status in openssl source package in Jammy:
  New
Status in openssl source package in Kinetic:
  Confirmed

Bug description:
  [Impact]

  Some certificates in the openssl package expired on 2022-06-01, making
  the test suite fail. This needs to be fixed to facilitate future
  security updates.

  [Test Plan]

  Build the package. It currently fails with the following test summary:

  80-test_ssl_new.t(Wstat: 256 Tests: 30 Failed: 1)
Failed test:  12
Non-zero exit status: 1

  [Where problems could occur]

  I supposed this could break the build even worse.

  [Other Info]
   
  This currently prevents 3.0.2-0ubuntu1.3 in Jammy from publication.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1978093/+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 1978093] Re: openssl: FTBFS due to expired certificates

[Simon Chopin]

** Description changed:

+ [Impact]
+ 
  Some certificates in the openssl package expired on 2022-06-01, making
- the test suite fail.
+ the test suite fail. This needs to be fixed to facilitate future
+ security updates.
+ 
+ [Test Plan]
+ 
+ Build the package. It currently fails with the following test summary:
+ 
+ 80-test_ssl_new.t(Wstat: 256 Tests: 30 Failed: 1)
+   Failed test:  12
+   Non-zero exit status: 1
+ 
+ [Where problems could occur]
+ 
+ I supposed this could break the build even worse.
+ 
+ [Other Info]
+  
+ This currently prevents 3.0.2-0ubuntu1.3 in Jammy from publication.

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

Title:
  openssl: FTBFS due to expired certificates

Status in openssl package in Ubuntu:
  Confirmed
Status in openssl source package in Bionic:
  New
Status in openssl source package in Focal:
  New
Status in openssl source package in Impish:
  New
Status in openssl source package in Jammy:
  New
Status in openssl source package in Kinetic:
  Confirmed

Bug description:
  [Impact]

  Some certificates in the openssl package expired on 2022-06-01, making
  the test suite fail. This needs to be fixed to facilitate future
  security updates.

  [Test Plan]

  Build the package. It currently fails with the following test summary:

  80-test_ssl_new.t(Wstat: 256 Tests: 30 Failed: 1)
Failed test:  12
Non-zero exit status: 1

  [Where problems could occur]

  I supposed this could break the build even worse.

  [Other Info]
   
  This currently prevents 3.0.2-0ubuntu1.3 in Jammy from publication.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1978093/+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 1978093] Re: openssl: FTBFS due to expired certificates

[Simon Chopin]

** Tags added: block-proposed-bionic block-proposed-focal block-
proposed-impish

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

Title:
  openssl: FTBFS due to expired certificates

Status in openssl package in Ubuntu:
  Confirmed
Status in openssl source package in Bionic:
  New
Status in openssl source package in Focal:
  New
Status in openssl source package in Impish:
  New
Status in openssl source package in Jammy:
  Fix Committed
Status in openssl source package in Kinetic:
  Confirmed

Bug description:
  [Impact]

  Some certificates in the openssl package expired on 2022-06-01, making
  the test suite fail. This needs to be fixed to facilitate future
  security updates.

  [Test Plan]

  Build the package. It currently fails with the following test summary:

  80-test_ssl_new.t(Wstat: 256 Tests: 30 Failed: 1)
Failed test:  12
Non-zero exit status: 1

  [Where problems could occur]

  I supposed this could break the build even worse.

  [Other Info]
   
  This currently prevents 3.0.2-0ubuntu1.3 in Jammy from publication.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1978093/+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 1978129] Re: Incomplete support for DT_RELR relocations on Ubuntu 22.04

[Simon Chopin]

** Tags added: fr-2459

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

Title:
  Incomplete support for DT_RELR relocations on Ubuntu 22.04

Status in The Ubuntu-power-systems project:
  New
Status in binutils package in Ubuntu:
  New
Status in binutils source package in Jammy:
  New
Status in binutils source package in Kinetic:
  New

Bug description:
  == Comment: #0 - Matheus Salgueiro Castanho  - 2022-06-09 
09:32:29 ==
  ---Problem Description---
  Latest glibc uses DT_RELR relocations, but linker support is incomplete as of 
binutils-2.38-3ubuntu1 on Ubuntu 22.04. It lacks the following fix integrated 
into the upstream 2.38 branch:
   
  PowerPC64 DT_RELR relative reloc addresses
  
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e4a35c7319628045302d4c597cb27f1b0a08c858

  As mentioned in the binutils mailing list when this patch was discussed, this 
fixes several glibc regressions:
  https://sourceware.org/pipermail/binutils/2022-March/119921.html
   
  Contact Information = Matheus Castanho/mscasta...@ibm.com 
   
  ---uname output---
  N/A
   
  Machine Type = N/A 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   git clone git://sourceware.org/git/glibc.git
  mkdir build && cd build
  ../glibc/configure --prefix=/usr && make -j8 && make check
   
  Userspace tool common name: binutils 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace rpm: binutils

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Matheus Castanho/mscasta...@ibm.com:
  -Attach ltrace and strace of userspace application.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1978129/+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 1958267] Re: wpa can't connect to servers using TLS 1.1 or older

[Simon Chopin]

-6ubuntu2 is the version that will get to Jammy (22.04), 9ubuntu1 is the
version currently in the devel series (future Kinetic, 22.10).

In general it is preferable to use the version compiled for your current
series, even though using the one in -devel might make sense in a
testing context, as was the case here.

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

Title:
  wpa can't connect to servers using TLS 1.1 or older

Status in wpa package in Ubuntu:
  Fix Released
Status in wpa source package in Jammy:
  Fix Committed
Status in wpa package in Debian:
  New

Bug description:
  * Impact
  wpa built with in openssl3 fails to connect to TLS 1.1 or lower server

  * Test case
  try to connect to a TLS <= 1.1 access point

  * Regression potential
  the patch lowers the security level in some situation for compatibility, it 
shouldn't prevent connecting to newer hardware, still try to connect to 
different type of wifi with different security levels

  ---

  those uses MD5-SHA1 as digest in its signature algorithm which no
  longer meets OpenSSL default level of security of 80 bits

  http://lists.infradead.org/pipermail/hostap/2022-May/040563.html

  Workaround are described in #22 and #36 by basically using
  CipherString = DEFAULT@SECLEVEL=0

  which lowers the security level

  ---

  With the current jammy version of wpasupplicant (2:2.10-1), I cannot
  connect to the WPA Enterprise network eduroam, which is used by
  Universities worldwide. I get a "Connection failed" message or a
  request to re-enter the password.

  - I've re-tried the credentials: no fix ;-)

  - Tried a 21.10 live session on the same machine: works fine!

  - Manually downgraded wpasupplicant to the impish version
  (2:2.9.0-21build1): connected normally.

  - Upgraded wpasupplicant to the latest version: fails to connect
  again.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: wpasupplicant 2:2.10-1
  ProcVersionSignature: Ubuntu 5.15.0-17.17-generic 5.15.12
  Uname: Linux 5.15.0-17-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.11-0ubuntu75
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Jan 18 09:56:23 2022
  InstallationDate: Installed on 2021-11-30 (48 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20211130)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: wpa
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1958267/+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 1978093] Re: openssl: FTBFS due to expired certificates

[Simon Chopin]

https://launchpad.net/ubuntu/+source/openssl/3.0.2-0ubuntu1.4 builds
fine, marking it as jammy-verified.

** Tags removed: verification-needed-jammy
** Tags added: verification-done-jammy

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

Title:
  openssl: FTBFS due to expired certificates

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  New
Status in openssl source package in Focal:
  New
Status in openssl source package in Impish:
  New
Status in openssl source package in Jammy:
  Fix Committed
Status in openssl source package in Kinetic:
  Fix Released

Bug description:
  [Impact]

  Some certificates in the openssl package expired on 2022-06-01, making
  the test suite fail. This needs to be fixed to facilitate future
  security updates.

  [Test Plan]

  Build the package. It currently fails with the following test summary:

  80-test_ssl_new.t(Wstat: 256 Tests: 30 Failed: 1)
Failed test:  12
Non-zero exit status: 1

  [Where problems could occur]

  I supposed this could break the build even worse.

  [Other Info]
   
  This currently prevents 3.0.2-0ubuntu1.3 in Jammy from publication.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1978093/+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 1963834] Re: openssl 3.0 - SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED]

[Simon Chopin]

You'll need to contact your provider. I'm guessing their script isn't
compatible with OpenSSL 3.0, but without more information (such as the
stdout/stderr of the openssl CLI invocation here) there isn't much we
can do on this end.

Whatever the precise issue though, it's almost certainly NOT related to
the OP bug :).

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

Title:
  openssl 3.0 - SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED]

Status in openssl package in Ubuntu:
  Won't Fix

Bug description:
  Description:Ubuntu Jammy Jellyfish (development branch)
  Release:22.04

  openssl:
Installé : 3.0.1-0ubuntu1
Candidat : 3.0.1-0ubuntu1
   Table de version :
   *** 3.0.1-0ubuntu1 500
  500 http://ca.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  100 /var/lib/dpkg/status

  Using Ubuntu 22.04, I now get the following error message when
  attempting to connect to our office VPN using "gp-saml-gui
  (https://github.com/dlenski/gp-saml-gui)" :

  #
  dominique@Doombuntu:~$ .local/bin/gp-saml-gui  server_url
  Looking for SAML auth tags in response to 
https://server_url/global-protect/prelogin.esp...
  usage: gp-saml-gui [-h] [--no-verify] [-C COOKIES | -K] [-g | -p] [-c CERT] 
[--key KEY] [-v | -q] [-x | -P | -S] [-u] [--clientos {Windows,Linux,Mac}] [-f 
EXTRA] server [openconnect_extra ...]
  gp-saml-gui: error: SSL error: [SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED] 
unsafe legacy renegotiation disabled (_ssl.c:997)
  #
  #
  #

  gp-saml-gui uses python module requests.
  Using python ide, I can get the same results  :

  #
  >>> r = requests.get('https://server_url')
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 699, 
in urlopen
  httplib_response = self._make_request(
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 382, 
in _make_request
  self._validate_conn(conn)
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 1012, 
in _validate_conn
  conn.connect()
File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 411, in 
connect
  self.sock = ssl_wrap_socket(
File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 449, in 
ssl_wrap_socket
  ssl_sock = _ssl_wrap_socket_impl(
File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 493, in 
_ssl_wrap_socket_impl
  return ssl_context.wrap_socket(sock, server_hostname=server_hostname)
File "/usr/lib/python3.10/ssl.py", line 512, in wrap_socket
  return self.sslsocket_class._create(
File "/usr/lib/python3.10/ssl.py", line 1070, in _create
  self.do_handshake()
File "/usr/lib/python3.10/ssl.py", line 1341, in do_handshake
  self._sslobj.do_handshake()
  ssl.SSLError: [SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED] unsafe legacy 
renegotiation disabled (_ssl.c:997)

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 439, in 
send
  resp = conn.urlopen(
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 755, 
in urlopen
  retries = retries.increment(
File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 574, in 
increment
  raise MaxRetryError(_pool, url, error or ResponseError(cause))
  urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='server_url', 
port=443): Max retries exceeded with url: / (Caused by SSLError(SSLError(1, 
'[SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED] unsafe legacy renegotiation 
disabled (_ssl.c:997)')))

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python3/dist-packages/requests/api.py", line 76, in get
  return request('get', url, params=params, **kwargs)
File "/usr/lib/python3/dist-packages/requests/api.py", line 61, in request
  return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 514, in 
send
  raise SSLError(e, request=request)
  requests.exceptions.SSLError: HTTPSConnectionPool(host='server_url', 
port=443): Max retries exceeded with url: / (Caused by SSLError(SSLError(1, 
'[SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED] unsafe legacy renegotiation 
disabled (_ssl.c:997)')))
  #
  #
  #

  I believe in OpenSSL 3.0 that SSL_OP_LEGACY_SERVER_CONNECT is now
  disabled by default, as opposed to 

[Touch-packages] [Bug 1972056] Re: [openssl3] please sync openssl.cnf to ease changing security level

[Simon Chopin]

Just to confirm, on a fresh LXC Jammy container:

root@rational-polliwog:~# dpkg -l openssl | tail -n 1
ii  openssl3.0.2-0ubuntu1.4 amd64Secure Sockets Layer toolkit - 
cryptographic utility
root@rational-polliwog:~# grep SECLEVEL /etc/ssl/openssl.cnf
CipherString = DEFAULT:@SECLEVEL=2
root@rational-polliwog:~# openssl ciphers -v -s | wc -l
30
root@rational-polliwog:~# sed -i s/SECLEVEL=2/SECLEVEL=3/ /etc/ssl/openssl.cnf
root@rational-polliwog:~# openssl ciphers -v -s | wc -l
24

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

Title:
  [openssl3] please sync openssl.cnf to ease changing security level

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  Fix Committed
Status in openssl source package in Kinetic:
  Fix Released
Status in openssl package in Debian:
  Fix Released

Bug description:
  [Impact]

  The OpenSSL 3.0 lead to a lot of broken setups. Some of them are
  regressions, but others are simply broken due to the use of outdated
  algorithms, such as SHA-1 signature on certificates. Changing the
  security level is a common action to identify and work around such
  cases, and as such the user should be able to change it easily  in the
  default config file.

  The fix is to partially revert our delta that ignored a Debian patch:
  instead of ignoring the patch entirely, we modify it to only affect
  the default configuration file, and in a way that matches our
  patchset. Using this approach will allow us to pick up on Debian's
  changes more easily during subsequent merges.

  [Test Plan]

  To easily check that the setting is taken into account, one can use
  'openssl ciphers -s'

  $ openssl ciphers -v -s | wc -l # Uses the default value
  30
  $ openssl ciphers -v -s 'DEFAULT:@SECLEVEL=2' | wc -l
  30
  $ openssl ciphers -v -s 'DEFAULT:@SECLEVEL=3' | wc -l
  24
  $ vim /etc/ssl/openssl.cf # edit the config file to bump the seclevel to 3
  $ openssl ciphers -v -s | wc -l # Uses the new value from the config file
  24

  [Where problems could occur]

  The changes could break the overall configuration of OpenSSL!

  [Origin report]
  openssl.cnf as provided misses some directive, which make it a bit difficult 
to change security level, which since openssl 3 disables SHA1 signatures.

  See also this Debian bug https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=1010360 and the committed fix:
  
https://salsa.debian.org/debian/openssl/-/commit/b507914c40270e32cde6afcc8af93707c225e7f4

  Can you please sync this change in Ubuntu openssl?

  This way one should just add a single directive to change the security
  level.

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1972056/+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 1947588] Re: Infinite Loop in OpenSSL s_server

[Simon Chopin]

On a fresh Jammy LXC container:

root@rational-polliwog:~# dpkg -l openssl | tail -n 1
ii  openssl3.0.2-0ubuntu1.4 amd64Secure Sockets Layer toolkit - 
cryptographic utility
root@rational-polliwog:~# openssl s_server -nocert -psk 01020304 -dtls1
Using default temp DH parameters
ACCEPT
ERROR
40472C92B97F:error:0ABF:SSL routines:tls_setup_handshake:no protocols 
available:../ssl/statem/statem_lib.c:104:
shutting down SSL
CONNECTION CLOSED
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   0 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   0 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (128 allowed)


Marking as verified.

** Tags removed: verification-needed-jammy
** Tags added: verification-done-jammy

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

Title:
  Infinite Loop in OpenSSL s_server

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Focal:
  Confirmed
Status in openssl source package in Impish:
  Confirmed
Status in openssl source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

  The TLS test server `openssl s_server` can very easily be led into an
  infinite loop if configured with incompatible settings and used via
  DTLS. This makes it harder to test one's TLS configuration.

  [Test plan]

  In one session:
  $ openssl s_server -nocert -psk 01020304 -dtls1
  In parallel:
  $ openssl s_client -dtls1 -psk 01020304

  The server session will enter an infinite loop:
  Using default temp DH parameters
  ACCEPT
  ERROR
  140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal 
error:../ssl/statem/statem_lib.c:109:
  ERROR
  140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal 
error:../ssl/statem/statem_lib.c:109:
  ERROR
  ... etc...

  [Where problems could occur]

  The patch is fairly self-contained, so regressions should only occur in
  the `openssl s_server` application, and not in the libssl or libcrypto
  libraries.
  However, the patch could break said server, which might be used in e.g.
  autopkgtests.

  [Original report]
  Launching openssl s_server as follows:

  $ openssl s_server -nocert -psk 01020304 -dtls1

  And using openssl s_client to connect to it like this:

  $ openssl s_client -dtls1 -psk 01020304

  Results in s_server entering an infinite loop:

  Using default temp DH parameters
  ACCEPT
  ERROR
  140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal 
error:../ssl/statem/statem_lib.c:109:
  ERROR
  140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal 
error:../ssl/statem/statem_lib.c:109:
  ERROR

  ...and so on...

  I have confirmed that upstream OpenSSL does not have this issue in a
  default build of 1.1.1j or 1.1.1k. Upstream 1.1.1l has a different bug
  with these commands (https://github.com/openssl/openssl/issues/16707)
  and it was while working on the fix for that issue
  (https://github.com/openssl/openssl/pull/16838) that I noticed this
  problem in the Ubuntu packages.

  $ lsb_release -rd
  Description: Ubuntu 21.04
  Release: 21.04

  $ apt-cache policy openssl
  openssl:
Installed: 1.1.1j-1ubuntu3.5
Candidate: 1.1.1j-1ubuntu3.5
Version table:
   *** 1.1.1j-1ubuntu3.5 500
  500 http://gb.archive.ubuntu.com/ubuntu hirsute-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu hirsute-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1.1.1j-1ubuntu3 500
  500 http://gb.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages

  $ openssl version -a
  OpenSSL 1.1.1j 16 Feb 2021
  built on: Mon Aug 23 17:02:39 2021 UTC
  platform: debian-amd64
  options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr)
  compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack 
-g -O2 -ffile-prefix-map=/build/openssl-5U8yxE/openssl-1.1.1j=. -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC 
-DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time 
-D_FORTIFY_SOURCE=2
  OPENSSLDIR: "/usr/lib/ssl"
  ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
  Seeding source: os-specific

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


-- 
Mailing list: https://launchpad.net/~

[Touch-packages] [Bug 1974037] Re: openssl: EVP_EC_gen() segfault without init

[Simon Chopin]

On a fresh Jammy LXC container:

root@rational-polliwog:~# dpkg -l libssl-dev | tail -n 1
ii  libssl-dev:amd64 3.0.2-0ubuntu1.4 amd64Secure Sockets Layer toolkit 
- development files
root@rational-polliwog:~# cat < openssl_test.c
#include 
int main()
{
EVP_PKEY_Q_keygen(NULL, NULL, "EC", "P-256");
}
EOF
root@rational-polliwog:~# gcc openssl_test.c -lcrypto -lssl -o openssl_test
root@rational-polliwog:~# ./openssl_test
root@rational-polliwog:~# echo $?
0

Marking as verified.

** Tags removed: verification-needed verification-needed-jammy
** Tags added: verification-done verification-done-jammy

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

Title:
  openssl: EVP_EC_gen() segfault without init

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  Fix Committed
Status in openssl source package in Kinetic:
  Fix Released
Status in openssl package in Debian:
  Fix Released

Bug description:
  [Impact]

  The fix for
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1968997 has
  broken some code paths as the new string comparison functions now need
  initialization, triggering segafults.

  The provided debdiff fixes the immediate issue and also settles on a
  new implementation not requiring the initialization in the first
  place.

  [Test Plan]

  Since this is a regression fix, we first need to check that the
  original bug hasn't cropped up again:

  sudo locale-gen tr_TR.UTF-8
  LANG=C curl https://ubuntu.com/ > /dev/null # This work
  LANG=tr_TF.UTF-8 curl https://ubuntu.com/ > /dev/null # This should work as 
well

  For the regression itself:

  sudo apt install libssl-dev
  cat < openssl_test.c
  #include 
  int main()
  {
  EVP_PKEY_Q_keygen(NULL, NULL, "EC", "P-256");
  }
  EOF
  gcc openssl_test.c -lcrypto -lssl -o openssl_test
  ./openssl_test

  
  [Where problems could occur]

  This new patch set is relatively massive, on top of another massive one.
  Some new regressions could crop up of a similar kind. Furthermore, the
  homegrown string comparison function could be buggy, leading to algorithm 
name mismatches.

  [Other info]

  The patches all come from upstream and have been merged on their 3.0
  maintenance branch.

  [Original report]

  Source: sscg
  Version: 3.0.2-1
  Severity: serious
  Tags: ftbfs

  https://buildd.debian.org/status/logs.php?pkg=sscg&ver=3.0.2-1%2Bb1

  ...
   1/10 generate_rsa_key_test FAIL  0.01s   killed by signal 11 
SIGSEGV
  04:32:21 MALLOC_PERTURB_=87 
/<>/obj-x86_64-linux-gnu/generate_rsa_key_test
  ...

  Summary of Failures:

   1/10 generate_rsa_key_test FAIL  0.01s   killed by signal
  11 SIGSEGV

  Ok: 9
  Expected Fail:  0
  Fail:   1
  Unexpected Pass:0
  Skipped:0
  Timeout:0
  dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 
MESON_TESTTHREADS=4 ninja test returned exit code 1
  make: *** [debian/rules:6: binary-arch] Error 25

  This has also been reported on the openssl-users mailing list:

  https://www.mail-archive.com/openssl-users@openssl.org/msg90830.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1974037/+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 1895017] Re: openssl: backport TLSv1.3 compat fix

[Simon Chopin]

*** This bug is a duplicate of bug 1940141 ***
https://bugs.launchpad.net/bugs/1940141

** This bug has been marked a duplicate of bug 1940141
   OpenSSL servers can send a non-empty status_request in a CertificateRequest

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

Title:
  openssl: backport TLSv1.3 compat fix

Status in openssl package in Ubuntu:
  New
Status in openssl source package in Bionic:
  New

Bug description:
  https://github.com/openssl/openssl/pull/9780/files breaks golang, so
  would be useful to backport in bionic which ships openssl 1.1.1 now
  too.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1895017/+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

Re: [Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15

[Simon Chopin]

I'm just watching from the sidelines here, but why do we need to have
a transition for this? Is there an ABI break I'm not aware of? Or is zlib
usually statically linked in Debian packages?

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

Title:
  zlib: compressBound() returns an incorrect result on z15

Status in Ubuntu on IBM z Systems:
  In Progress
Status in bedtools package in Ubuntu:
  New
Status in htslib package in Ubuntu:
  Invalid
Status in zlib package in Ubuntu:
  In Progress
Status in bedtools source package in Focal:
  Invalid
Status in htslib source package in Focal:
  New
Status in zlib source package in Focal:
  New
Status in bedtools source package in Impish:
  New
Status in htslib source package in Impish:
  Invalid
Status in zlib source package in Impish:
  New
Status in bedtools source package in Jammy:
  New
Status in htslib source package in Jammy:
  Invalid
Status in zlib source package in Jammy:
  Incomplete

Bug description:
  SRU Justification:
  ==

  [Impact]

  * zlib: compressBound() returns an incorrect result on IBM z15
  hardware.

  * Passing the result of compressBound() to compress() results
    in an error code.

  * This is because compressBound() is not adjusted for DFLTCC.

  [Fix]

  * Adjust compressBound() for DFLTCC like it's already done
    for deflateBound().

  * Since zlib project does not accept patches at the moment,
    the fix has been integrated into the DFLTCC pull request:
    https://github.com/madler/zlib/pull/410
    The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.

  * The fix extracted out of the above is:
    
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff

  * On top of this actual zlib fix, there is another patch needed:
   'Remove compressBound assertions. (PR #1258)' for htslib.

  * But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).

  [Test Plan]

  * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
    with Ubuntu Server 21.10 (or 22.04).

  * A test can be done  based on the following C test program:
    #include 
    #include 
    #include 
    int main() {
    Bytef in_buf[128], out_buf[1024];
    for (size_t i = 0; i < sizeof(in_buf); i++)
    in_buf[i] = rand();
    uLongf dest_len = compressBound(sizeof(in_buf));
    assert(dest_len <= sizeof(out_buf));
    int ret = compress(out_buf, &dest_len,
   in_buf, sizeof(in_buf));
    assert(ret == Z_OK);
    }

  * The test needs to be done by IBM, due to the requirements
    for the special z15 hardware.

  * A successful test was just completed, based on the version in jammy-
  proposed, which is at the same code level that the impish version this
  SRU is targeted for.

  [Where problems could occur]

  * If the adjustment of compressBound() for DFLTCC is done
    erroneously the issue can still be present or in worst case
    even affect Z systems other than z15 only.

  * The compression can become errorneous with the new changes,
    e.g. in compressBound.

  * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
    (incl. the bit definitions), may cause various and unforseen defects.

  * Any build time issues that might have been introduced by this patch
    can be identified by a test build; this was done and is available here:
    https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427

  [Other Info]

  * Ubuntu jammy, impish and focal are affected by the zlib issue.

  * The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.

  * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.

  * Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427  

  __

  Description:   zlib: compressBound() returns an incorrect result on z15
  Symptom:   Passing the result of compressBound() to compress()
     results in an error code.
  Problem:   compressBound() is not adjusted for DFLTCC.
  Solution:  Adjust compressBound() for DFLTCC like it's already done
     for deflateBound(). Since zlib project does not accept
     patches at the moment, the fix has been integrated into
     the DFLTCC pull request:
     https://github.com/madler

[Touch-packages] [Bug 1979639] Re: openssl 3.0.3-7 needs port from sid to jammy

[Simon Chopin]

** Description changed:

+ [Impact] 
+ While the default configuration works fine for every package that uses the 
system libssl3, any software that uses libssl1.1, either separately packaged 
(e.g. as an upgrade leftover) or vendored in (as in nodejs in our own archive) 
will fail to load the configuration as they don't have any notion of providers.
+ 
+ If the provider section isn't present in the configuration, libssl3 will
+ load the default provider, which means that commenting out the section
+ won't impact the behavior of standard libssl3 users.
+ 
+ [Test Plan]
+ 
+ On a system with a pristine openssl configuration:
+ 
+ $ sudo apt install nodejs
+ $ nodejs -  const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { 
modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  Uncaught:
  Error: error:25066067:DSO support routines:dlfcn_load:could not load the 
shared library
- at Sign.sign (node:internal/crypto/sig:131:29) {
-   opensslErrorStack: [
- 'error:0E076071:configuration file routines:module_run:unknown module 
name',
- 'error:0E07506E:configuration file routines:module_load_dso:error loading 
dso',
- 'error:25070067:DSO support routines:DSO_load:could not load the shared 
library'
-   ],
-   library: 'DSO support routines',
-   function: 'dlfcn_load',
-   reason: 'could not load the shared library',
-   code: 'ERR_OSSL_DSO_COULD_NOT_LOAD_THE_SHARED_LIBRARY'
+ at Sign.sign (node:internal/crypto/sig:131:29) {
+   opensslErrorStack: [
+ 'error:0E076071:configuration file routines:module_run:unknown module 
name',
+ 'error:0E07506E:configuration file routines:module_load_dso:error loading 
dso',
+ 'error:25070067:DSO support routines:DSO_load:could not load the shared 
library'
+   ],
+   library: 'DSO support routines',
+   function: 'dlfcn_load',
+   reason: 'could not load the shared library',
+   code: 'ERR_OSSL_DSO_COULD_NOT_LOAD_THE_SHARED_LIBRARY'
  }
  
- 
- Removing the relevant provider section lines (the Debian patch doesn't apply 
cleanly, hence the use of sed) fixes it:
+ Removing the relevant provider section lines (the Debian patch doesn't
+ apply cleanly, hence the use of sed) fixes it:
  
  ~ $ sed -i '/_sect\b/s/^/# /' /etc/ssl/openssl.cnf
  ~ $ node
  Welcome to Node.js v16.15.0.
  Type ".help" for more information.
  > const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { 
modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  
  
- 
- I realize there is no libssl1.1 on jammy, but a statically linked OpenSSL is 
not uncommon (Node.js being a very prominent example).
+ I realize there is no libssl1.1 on jammy, but a statically linked
+ OpenSSL is not uncommon (Node.js being a very prominent example).
  
  Would it be possible to get this Debian sid change ported to jammy?

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

Title:
  openssl 3.0.3-7 needs port from sid to jammy

Status in nodejs package in Ubuntu:
  Confirmed
Status in openssl package in Ubuntu:
  Fix Released
Status in nodejs source package in Jammy:
  Confirmed
Status in openssl source package in Jammy:
  Confirmed
Status in nodejs source package in Kinetic:
  Confirmed
Status in openssl source package in Kinetic:
  Fix Released

Bug description:
  [Impact] 
  While the default configuration works fine for every package that uses the 
system libss

[Touch-packages] [Bug 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

[Simon Chopin]

** Tags added: fr-2537

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

Title:
  [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

Status in Ubuntu on IBM z Systems:
  New
Status in nettle package in Ubuntu:
  New

Bug description:
  Upgrade nettle to latest version >= 3.7.4 (crypto)

  Description

  Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for
  Crypto Libraries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+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 1979639] Re: Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail

[Simon Chopin]

Many thanks for raising this :)

I was prepared to argue for this change as (if working as intended) it
has basically no impact on our own applications and could help quite a
few unsuspecting users, but since you asked for evidence I did a little
digging, and was somewhat surprised by what I found. While it is true
that there are quite a bit of software out there that embeds older
versions of OpenSSL, NodeJS are the outliers in pointing to /etc/ssl as
their OPENSSLDIR. In fact, even our own package points to /usr/lib/ssl,
with symlinks to /etc for the config file and the certificates.

I erroneously thought that the OpenSSL upstream default was also
/etc/ssl, but as it turns out they're using the more sensible
/usr/local/ssl as a default.

This limits the impact to

1/ third-party packages depending on our old libssl1.1,
2/ our nodejs package
3/ upstream NodeJS builds

I'm not particularly keen on doing this SRU just for the sake of 1/, and
2/ can be fixed in that package, but do we want to break things for 3/ ?

I don't know much about the JS ecosystem. My first Google result for
`installing nodejs on Ubuntu` was pretty quick to point me towards `nvm`
to "easily install different versions of Node", and that tool seems to
download upstream binaries directly.

I'm OK either way, and I've already started working on extending the
test case as per your requests.

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

Title:
  Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail

Status in nodejs package in Ubuntu:
  Confirmed
Status in openssl package in Ubuntu:
  Fix Released
Status in nodejs source package in Jammy:
  Confirmed
Status in openssl source package in Jammy:
  Incomplete
Status in nodejs source package in Kinetic:
  Confirmed
Status in openssl source package in Kinetic:
  Fix Released

Bug description:
  [Impact] 
  While the default configuration works fine for every package that uses the 
system libssl3, any software that uses libssl1.1, either separately packaged 
(e.g. as an upgrade leftover) or vendored in (as in nodejs in our own archive) 
will fail to load the configuration as they don't have any notion of providers.

  If the provider section isn't present in the configuration, libssl3
  will load the default provider, which means that commenting out the
  section won't impact the behavior of standard libssl3 users.

  [Test Plan]

  On a system with a pristine openssl configuration:

  $ sudo apt install nodejs
  $ nodejs -  const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { 
modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  Uncaught:
  Error: error:25066067:DSO support routines:dlfcn_load:could not load the 
shared library
  at Sign.sign (node:internal/crypto/sig:131:29) {
    opensslErrorStack: [
  'error:0E076071:configuration file routines:module_run:unknown module 
name',
  'error:0E07506E:configuration file routines:module_load_dso:error loading 
dso',
  'error:25070067:DSO support routines:DSO_load:could not load the shared 
library'
    ],
    library: 'DSO support routines',
    function: 'dlfcn_load',
    reason: 'could not load the shared library',
    code: 'ERR_OSSL_DSO_COULD_NOT_LOAD_THE_SHARED_LIBRARY'
  }

  Removing the relevant provider section lines (the Debian patch doesn't
  apply cleanly, hence the use of sed) fixes it:

  ~ $ sed -i '/_sect\b/s/^/# /' /etc/ssl/openssl.cnf
  ~ $ node
  Welcome to Node.js v16.15.0.
  Type ".help" for more information.
  > const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { 
modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  

  I realize there is no libssl1.1 on jammy, 

[Touch-packages] [Bug 1979639] Re: Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail

[Simon Chopin]

** Description changed:

- [Impact] 
- While the default configuration works fine for every package that uses the 
system libssl3, any software that uses libssl1.1, either separately packaged 
(e.g. as an upgrade leftover) or vendored in (as in nodejs in our own archive) 
will fail to load the configuration as they don't have any notion of providers.
+ [Impact]
+ While the default configuration works fine for every package that uses the 
system libssl3, libssl1.1.1 (which implicitly loads the configuration on 
OPENSSL_crypto_init()) fails to parse it.
+ 
+ Our nodejs package vendors openssl 1.1.1, which means it will trigger this 
bug. In addition, upstream NodeJS explicitly points their statically-linked 
OpenSSL to this file as well, and ships 1.1.1 in their current LTS (branch 
16.x).
+ Finally, we can also expect breakage for third-party packages that still 
depends on libssl1.1.
  
  If the provider section isn't present in the configuration, libssl3 will
  load the default provider, which means that commenting out the section
  won't impact the behavior of standard libssl3 users.
  
  [Test Plan]
  
  On a system with a pristine openssl configuration:
  
  $ sudo apt install nodejs
  $ nodejs -  const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { 
modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  Uncaught:
  Error: error:25066067:DSO support routines:dlfcn_load:could not load the 
shared library
  at Sign.sign (node:internal/crypto/sig:131:29) {
    opensslErrorStack: [
  'error:0E076071:configuration file routines:module_run:unknown module 
name',
  'error:0E07506E:configuration file routines:module_load_dso:error loading 
dso',
  'error:25070067:DSO support routines:DSO_load:could not load the shared 
library'
    ],
    library: 'DSO support routines',
    function: 'dlfcn_load',
    reason: 'could not load the shared library',
    code: 'ERR_OSSL_DSO_COULD_NOT_LOAD_THE_SHARED_LIBRARY'
  }
  
  Removing the relevant provider section lines (the Debian patch doesn't
  apply cleanly, hence the use of sed) fixes it:
  
  ~ $ sed -i '/_sect\b/s/^/# /' /etc/ssl/openssl.cnf
  ~ $ node
  Welcome to Node.js v16.15.0.
  Type ".help" for more information.
  > const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { 
modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  
  
  I realize there is no libssl1.1 on jammy, but a statically linked
  OpenSSL is not uncommon (Node.js being a very prominent example).
  
  Would it be possible to get this Debian sid change ported to jammy?

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

Title:
  Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail

Status in nodejs package in Ubuntu:
  Confirmed
Status in openssl package in Ubuntu:
  Fix Released
Status in nodejs source package in Jammy:
  Confirmed
Status in openssl source package in Jammy:
  Incomplete
Status in nodejs source package in Kinetic:
  Confirmed
Status in openssl source package in Kinetic:
  Fix Released

Bug description:
  [Impact]
  While the default configuration works fine for every package that uses the 
system libssl3, libssl1.1.1 (which implicitly loads the configuration on 
OPENSSL_crypto_init()) fails to parse it.

  Our nodejs package vendors openssl 1.1.1, which means it will trigger this 
bug. In addition, upstream NodeJS explicitly points their statically-linked 
OpenSSL to this file as well, and ships 1.1.1 in their current LTS (branch 
16.x).
  Finally, we can also expect breakage for third-party packages that still 
depends on libssl1.1.

  If the provider section isn't present in the configuration, libssl3
  will l

[Touch-packages] [Bug 1983859] [NEW] tracker-extract crashes with SIGSYS when upgrading from 20.04 to 22.04

[Simon Chopin]

Public bug reported:

When upgrading Ubuntu Desktop from 20.04 to 22.04, there's often (pretty
much always) a crash from tracker-extract, as described in the following
error report:

https://errors.ubuntu.com/oops/d7866d85-14cc-11ed-a52b-fa163e55efd0

The crash occurs during the upgrade, which means it's fairly hard to
investigate exactly what's going on as apport fails to extract a stack
trace, the binaries being overwritten during the upgrade.

However, the crash occurs because of a unhandled SIGSYS, meaning a
seccomp filter issue. I've tried backporting this patch fixing a similar
issue:

https://gitlab.gnome.org/GNOME/tracker-
miners/-/commit/4cda983b02e49f6bd28b94a6b96c9fe7026887ef

but it doesn't apply, likely due to the code having diverged too much
since.

My proposal is thus to disable tracker-extract during upgrade, including
in all user sessions. I'm assuming that the new version will be enabled
automatically as its unit file changed name anyway.

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

** Affects: ubuntu-release-upgrader (Ubuntu)
 Importance: High
 Status: Confirmed


** Tags: fr-2595

** Also affects: ubuntu-release-upgrader (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: ubuntu-release-upgrader (Ubuntu)
   Status: New => Confirmed

** Changed in: ubuntu-release-upgrader (Ubuntu)
   Importance: Undecided => High

** Tags added: fr-2595

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

Title:
  tracker-extract crashes with SIGSYS when upgrading from 20.04 to 22.04

Status in tracker package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  Confirmed

Bug description:
  When upgrading Ubuntu Desktop from 20.04 to 22.04, there's often
  (pretty much always) a crash from tracker-extract, as described in the
  following error report:

  https://errors.ubuntu.com/oops/d7866d85-14cc-11ed-a52b-fa163e55efd0

  The crash occurs during the upgrade, which means it's fairly hard to
  investigate exactly what's going on as apport fails to extract a stack
  trace, the binaries being overwritten during the upgrade.

  However, the crash occurs because of a unhandled SIGSYS, meaning a
  seccomp filter issue. I've tried backporting this patch fixing a
  similar issue:

  https://gitlab.gnome.org/GNOME/tracker-
  miners/-/commit/4cda983b02e49f6bd28b94a6b96c9fe7026887ef

  but it doesn't apply, likely due to the code having diverged too much
  since.

  My proposal is thus to disable tracker-extract during upgrade,
  including in all user sessions. I'm assuming that the new version will
  be enabled automatically as its unit file changed name anyway.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/1983859/+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 1983859] Re: tracker-extract crashes with SIGSYS when upgrading from 20.04 to 22.04

[Simon Chopin]

** Package changed: tracker (Ubuntu) => tracker-miners (Ubuntu)

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

Title:
  tracker-extract crashes with SIGSYS when upgrading from 20.04 to 22.04

Status in tracker-miners package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  Confirmed

Bug description:
  When upgrading Ubuntu Desktop from 20.04 to 22.04, there's often
  (pretty much always) a crash from tracker-extract, as described in the
  following error report:

  https://errors.ubuntu.com/oops/d7866d85-14cc-11ed-a52b-fa163e55efd0

  The crash occurs during the upgrade, which means it's fairly hard to
  investigate exactly what's going on as apport fails to extract a stack
  trace, the binaries being overwritten during the upgrade.

  However, the crash occurs because of a unhandled SIGSYS, meaning a
  seccomp filter issue. I've tried backporting this patch fixing a
  similar issue:

  https://gitlab.gnome.org/GNOME/tracker-
  miners/-/commit/4cda983b02e49f6bd28b94a6b96c9fe7026887ef

  but it doesn't apply, likely due to the code having diverged too much
  since.

  My proposal is thus to disable tracker-extract during upgrade,
  including in all user sessions. I'm assuming that the new version will
  be enabled automatically as its unit file changed name anyway.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1983859/+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 1987047] [NEW] openssl: merge 3.0.5-2 from Debian unstable

[Simon Chopin]

Public bug reported:

We need to merge the new version from Debian, notably because of
CVE-2022-2097 (the other security issue already being fixed as a cherry-
picked patch)

** Affects: openssl (Ubuntu)
 Importance: High
 Assignee: Simon Chopin (schopin)
 Status: Confirmed

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

Title:
  openssl: merge 3.0.5-2 from Debian unstable

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  We need to merge the new version from Debian, notably because of
  CVE-2022-2097 (the other security issue already being fixed as a
  cherry-picked patch)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1987047/+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 1987047] Re: openssl: merge 3.0.5-2 from Debian unstable

[Simon Chopin]

** Changed in: openssl (Ubuntu)
   Status: Confirmed => In Progress

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

Title:
  openssl: merge 3.0.5-2 from Debian unstable

Status in openssl package in Ubuntu:
  In Progress

Bug description:
  We need to merge the new version from Debian, notably because of
  CVE-2022-2097 (the other security issue already being fixed as a
  cherry-picked patch)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1987047/+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 1987051] [NEW] libvpx: merge 1.12.0-1 from Debian unstable

[Simon Chopin]

Public bug reported:

Merge new upstream version into kinetic.

** Affects: libvpx (Ubuntu)
 Importance: High
 Assignee: Simon Chopin (schopin)
 Status: In Progress

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

Title:
  libvpx: merge 1.12.0-1 from Debian unstable

Status in libvpx package in Ubuntu:
  In Progress

Bug description:
  Merge new upstream version into kinetic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1987051/+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 1987051] Re: libvpx: merge 1.12.0-1 from Debian unstable

[Simon Chopin]

** Changed in: libvpx (Ubuntu)
   Status: In Progress => Fix Committed

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

Title:
  libvpx: merge 1.12.0-1 from Debian unstable

Status in libvpx package in Ubuntu:
  Fix Committed

Bug description:
  Merge new upstream version into kinetic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1987051/+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 1982841] Re: [22.10 FEAT] [SEC2210] p11-kit: add IBM specific mechanisms and attributes (crypto)

[Simon Chopin]

Uploaded, thanks :)

** Changed in: p11-kit (Ubuntu)
   Status: In Progress => Fix Committed

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

Title:
  [22.10 FEAT] [SEC2210] p11-kit: add IBM specific mechanisms and
  attributes (crypto)

Status in Ubuntu on IBM z Systems:
  In Progress
Status in p11-kit package in Ubuntu:
  Fix Committed

Bug description:
  Add support for IBM specific attributes and mechanis to the PKCS11 
client-server implementation of p11-kit to p11-kit.
  This enables customers to access IBM Z HSMs remotely via a PKCS #11 API.

  Upstream Target: p11-kit 0.25.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982841/+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 1987625] [NEW] lxc: FTBFS against glibc 2.36.0

[Simon Chopin]

Public bug reported:

Hi,

lxc currently fails to build against glibc 2.36, which also affects its
autopkgtests. Here's an excerpt of the failed build logs containing the
first error detected:

gcc -DHAVE_CONFIG_H -I. -I../../src   -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE 
-Wvla -std=gnu11 -fms-extensions -fdiagnostics-color -Wimplicit-fallthrough=5 
-Wcast-align -Wstrict-prototypes -fno-strict-aliasing -fstack-clash-protection 
-fstack-protector-strong --param=ssp-buffer-size=4 -g -fcf-protection 
-Werror=implicit-function-declaration -Wlogical-op -Wmissing-include-dirs 
-Wold-style-definition -Winit-self -Wunused-but-set-variable -Wfloat-equal 
-Wsuggest-attribute=noreturn -Werror=return-type 
-Werror=incompatible-pointer-types -Wformat=2 -Wshadow -Wendif-labels 
-Werror=overflow -fdiagnostics-show-option -Werror=shift-count-overflow 
-Werror=shift-overflow=2 -Wdate-time -Wnested-externs 
-fasynchronous-unwind-tables -pipe -fexceptions -Warray-bounds -Wrestrict 
-Wreturn-local-addr -Wstringop-overflow 
-DLXCROOTFSMOUNT=\"/usr/lib/x86_64-linux-gnu/lxc\" -DLXCPATH=\"/var/lib/lxc\" 
-DLXC_GLOBAL_CONF=\"/etc/lxc/lxc.conf\" 
-DLXCINITDIR=\"/usr/lib/x86_64-linux-gnu\" 
-DLIBEXECDIR=\"/usr/lib/x86_64-linux-gnu\" 
-DLXCTEMPLATEDIR=\"/usr/share/lxc/templates\" 
-DLXCTEMPLATECONFIG=\"/usr/share/lxc/config\" -DLOGPATH=\"/var/log/lxc\" 
-DLXC_DEFAULT_CONFIG=\"/etc/lxc/default.conf\" 
-DLXC_USERNIC_DB=\"/run/lxc/nics\" -DLXC_USERNIC_CONF=\"/etc/lxc/lxc-usernet\" 
-DDEFAULT_CGROUP_PATTERN=\"\" -DRUNTIME_PATH=\"/run\" -DSBINDIR=\"/usr/sbin\" 
-DAPPARMOR_CACHE_DIR=\"/var/cache/lxc/apparmor\" -I ../../src -I 
../../src/include -I ../../src/lxc -I ../../src/lxc/storage -I 
../../src/lxc/cgroups -DHAVE_APPARMOR  -DHAVE_SECCOMP  -DHAVE_SELINUX   -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-Wvla -std=gnu11 -fms-extensions -Werror -c -o conf.o conf.c
conf.c: In function ‘__lxc_idmapped_mounts_child’:
conf.c:2993:37: error: passing argument 4 of ‘mount_setattr’ from incompatible 
pointer type [-Werror=incompatible-pointer-types]
 2993 | &attr,
  | ^
  | |
  | struct lxc_mount_attr *
In file included from conf.c:22:
/usr/include/x86_64-linux-gnu/sys/mount.h:317:46: note: expected ‘struct 
mount_attr *’ but argument is of type ‘struct lxc_mount_attr *’
  317 |   struct mount_attr *__uattr, size_t __usize)
  |   ~~~^~~
conf.c:3016:41: error: passing argument 4 of ‘mount_setattr’ from incompatible 
pointer type [-Werror=incompatible-pointer-types]
 3016 | &attr,
  | ^
  | |
  | struct lxc_mount_attr *
/usr/include/x86_64-linux-gnu/sys/mount.h:317:46: note: expected ‘struct 
mount_attr *’ but argument is of type ‘struct lxc_mount_attr *’
  317 |   struct mount_attr *__uattr, size_t __usize)
  |   ~~~^~~
conf.c: In function ‘lxc_idmapped_mounts_parent’:
conf.c:4130:37: error: passing argument 4 of ‘mount_setattr’ from incompatible 
pointer type [-Werror=incompatible-pointer-types]
 4130 | &attr, sizeof(attr));
  | ^
  | |
  | struct lxc_mount_attr *
/usr/include/x86_64-linux-gnu/sys/mount.h:317:46: note: expected ‘struct 
mount_attr *’ but argument is of type ‘struct lxc_mount_attr *’
  317 |   struct mount_attr *__uattr, size_t __usize)
  |   ~~~^~~

I believe the following upstream PR should fix the issue:
https://github.com/lxc/lxc/pull/4181

I'll be testing a patched version shortly and will post a debdiff if it
pans out.

** Affects: lxc (Ubuntu)
 Importance: Undecided
 Status: Confirmed


** Tags: ftbfs update-excuse

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

Title:
  lxc: FTBFS against glibc 2.36.0

Status in lxc package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  lxc currently fails to build against glibc 2.36, which also affects
  its autopkgtests. Here's an excerpt of the failed build logs
  containing the first error detected:

  gcc -DHAVE_CONFIG_H -I. -I../../src   -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE 
-Wvla -std=gnu11 -fms-extensions -fdiagnostics-color -Wimplicit-fallthrough=5 
-Wcast-align -Wstrict-prototypes -fno-strict-aliasing -fstack-clash-protection 
-fstack-prot

Re: [Touch-packages] [Bug 1987625] Re: lxc: FTBFS against glibc 2.36.0

[Simon Chopin]

Yup, I cherry-picked the patches already, thanks for those :).

I'm tracking down a build failure on ppc64el that's presumably caused by
gcc-12 on -O3, and once I have a solve (other than forcing -O2) I'll
post it all here.

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

Title:
  lxc: FTBFS against glibc 2.36.0

Status in lxc package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  lxc currently fails to build against glibc 2.36, which also affects
  its autopkgtests. Here's an excerpt of the failed build logs
  containing the first error detected:

  gcc -DHAVE_CONFIG_H -I. -I../../src   -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE 
-Wvla -std=gnu11 -fms-extensions -fdiagnostics-color -Wimplicit-fallthrough=5 
-Wcast-align -Wstrict-prototypes -fno-strict-aliasing -fstack-clash-protection 
-fstack-protector-strong --param=ssp-buffer-size=4 -g -fcf-protection 
-Werror=implicit-function-declaration -Wlogical-op -Wmissing-include-dirs 
-Wold-style-definition -Winit-self -Wunused-but-set-variable -Wfloat-equal 
-Wsuggest-attribute=noreturn -Werror=return-type 
-Werror=incompatible-pointer-types -Wformat=2 -Wshadow -Wendif-labels 
-Werror=overflow -fdiagnostics-show-option -Werror=shift-count-overflow 
-Werror=shift-overflow=2 -Wdate-time -Wnested-externs 
-fasynchronous-unwind-tables -pipe -fexceptions -Warray-bounds -Wrestrict 
-Wreturn-local-addr -Wstringop-overflow 
-DLXCROOTFSMOUNT=\"/usr/lib/x86_64-linux-gnu/lxc\" -DLXCPATH=\"/var/lib/lxc\" 
-DLXC_GLOBAL_CONF=\"/etc/lxc/lxc.conf\" 
-DLXCINITDIR=\"/usr/lib/x86_64-linux-gnu\" 
-DLIBEXECDIR=\"/usr/lib/x86_64-linux-gnu\" 
-DLXCTEMPLATEDIR=\"/usr/share/lxc/templates\" 
-DLXCTEMPLATECONFIG=\"/usr/share/lxc/config\" -DLOGPATH=\"/var/log/lxc\" 
-DLXC_DEFAULT_CONFIG=\"/etc/lxc/default.conf\" 
-DLXC_USERNIC_DB=\"/run/lxc/nics\" -DLXC_USERNIC_CONF=\"/etc/lxc/lxc-usernet\" 
-DDEFAULT_CGROUP_PATTERN=\"\" -DRUNTIME_PATH=\"/run\" -DSBINDIR=\"/usr/sbin\" 
-DAPPARMOR_CACHE_DIR=\"/var/cache/lxc/apparmor\" -I ../../src -I 
../../src/include -I ../../src/lxc -I ../../src/lxc/storage -I 
../../src/lxc/cgroups -DHAVE_APPARMOR  -DHAVE_SECCOMP  -DHAVE_SELINUX   -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-Wvla -std=gnu11 -fms-extensions -Werror -c -o conf.o conf.c
  conf.c: In function ‘__lxc_idmapped_mounts_child’:
  conf.c:2993:37: error: passing argument 4 of ‘mount_setattr’ from 
incompatible pointer type [-Werror=incompatible-pointer-types]
   2993 | &attr,
| ^
| |
| struct lxc_mount_attr *
  In file included from conf.c:22:
  /usr/include/x86_64-linux-gnu/sys/mount.h:317:46: note: expected ‘struct 
mount_attr *’ but argument is of type ‘struct lxc_mount_attr *’
317 |   struct mount_attr *__uattr, size_t __usize)
|   ~~~^~~
  conf.c:3016:41: error: passing argument 4 of ‘mount_setattr’ from 
incompatible pointer type [-Werror=incompatible-pointer-types]
   3016 | &attr,
| ^
| |
| struct lxc_mount_attr *
  /usr/include/x86_64-linux-gnu/sys/mount.h:317:46: note: expected ‘struct 
mount_attr *’ but argument is of type ‘struct lxc_mount_attr *’
317 |   struct mount_attr *__uattr, size_t __usize)
|   ~~~^~~
  conf.c: In function ‘lxc_idmapped_mounts_parent’:
  conf.c:4130:37: error: passing argument 4 of ‘mount_setattr’ from 
incompatible pointer type [-Werror=incompatible-pointer-types]
   4130 | &attr, sizeof(attr));
| ^
| |
| struct lxc_mount_attr *
  /usr/include/x86_64-linux-gnu/sys/mount.h:317:46: note: expected ‘struct 
mount_attr *’ but argument is of type ‘struct lxc_mount_attr *’
317 |   struct mount_attr *__uattr, size_t __usize)
|   ~~~^~~

  I believe the following upstream PR should fix the issue:
  https://github.com/lxc/lxc/pull/4181

  I'll be testing a patched version shortly and will post a debdiff if
  it pans out.

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


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

[Touch-packages] [Bug 1986984] Re: [FFe] tzdata 2022c update

[Simon Chopin]

** Summary changed:

- Availability of tzdata 2022c for Ubuntu 20.04
+ [FFe] tzdata 2022c update

** Description changed:

- tzdata 2022b and 2022c were just released that includes some timezone
- changes for Chile. According to the tzdata lib listed for Ubuntu 20.04,
- the latest package is 2022a. Any idea when 2022b or 2022c will be
- available? Chile made a change to the start of their daylight savings
- and pushed it from Sept 4th to the 11th, so we really need our servers
- updated before the 4th.
+ New timezone data, with the following timezones impacted:
+ - Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
+ - Iran no longer observes DST (Asia/Tehran)
+ 
+ Verification is done with 'zdump'. The first timezone that gets changed
+ in the updated package is dumped with 'zdump -v
+ $region/$timezone_that_changed' (this needs to be greped for in
+ /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
+ compared to the same output after the updated package got installed. If
+ those are different the verification is considered done.
+ 
+ [Test Case for all releases]
+ 1) zdump -v America/Santiago | grep 'Sep.*2022'
+   -> should indicate Sep 11, not Sep 4
+ 2) zdump -v Asia/Tehran | tail
+   -> last dates should be in 2022, not in 2499
+ 
+ [Test Case for releases >= 20.04 LTS]
+ 
+ For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
+ 1) sudo apt-get install python3-icu
+ 2) Run the following python script:
+ 
+ from datetime import datetime
+ from icu import ICUtzinfo, TimeZone
+ tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
+ always_before = datetime(2022, 9, 1)
+ now_before = datetime(2022, 9, 8)
+ always_after = datetime(2022, 9, 12)
+ assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
+ assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
+ 
+ The assertions would crash on 2022a.
+ 
+ [Test Case for releases <= 20.04 LTS]
+ 
+ Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. Subsequently, these should be checked for using the following:
+ diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)
+ 
+ Nothing should be returned by the above command.
+ 
+ [Original report]
+ tzdata 2022b and 2022c were just released that includes some timezone changes 
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest 
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a 
change to the start of their daylight savings and pushed it from Sept 4th to 
the 11th, so we really need our servers updated before the 4th.
  
  Thanks
  
  Jason

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

Title:
  [FFe] tzdata 2022c update

Status in tzdata package in Ubuntu:
  Confirmed

Bug description:
  New timezone data, with the following timezones impacted:
  - Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
  - Iran no longer observes DST (Asia/Tehran)

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [Test Case for all releases]
  1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
  2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499

  [Test Case for releases >= 20.04 LTS]

  For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
  1) sudo apt-get install python3-icu
  2) Run the following python script:

  from datetime import datetime
  from icu import ICUtzinfo, TimeZone
  tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
  always_before = datetime(2022, 9, 1)
  now_before = datetime(2022, 9, 8)
  always_after = datetime(2022, 9, 12)
  assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
  assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))

  The assertions would crash on 2022a.

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. Subsequently, these should be checked for using the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  Nothing should be returned by the above command.

  [Original report]
  tzdata 2022b and 2022c were j

[Touch-packages] [Bug 1986984] Re: [FFe] tzdata 2022c update

[Simon Chopin]

This update has been prepared in the following PPA:
https://launchpad.net/~schopin/+archive/ubuntu/tzdata

The kinetic upload has been prepared as a full merge from Debian,
however I kept the other series' diff as small as possible by doing a
plain "upstream update". Notably, I didn't pick up the Debian changes
renaming Kiev to Kyiv in the older releases.

You'll note that the ICU data has only been updated 'til 2022b. That's
because they haven't picked up 2022c yet, and probably won't since that
last release is more of a bugfix release, with no data changes.

** Also affects: tzdata (Ubuntu Kinetic)
   Importance: Undecided
   Status: Confirmed

** Also affects: tzdata (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: tzdata (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: tzdata (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: tzdata (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

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

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

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

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

Title:
  [FFe] tzdata 2022c update

Status in tzdata package in Ubuntu:
  Confirmed
Status in tzdata source package in Xenial:
  Confirmed
Status in tzdata source package in Bionic:
  Confirmed
Status in tzdata source package in Focal:
  Confirmed
Status in tzdata source package in Jammy:
  Confirmed
Status in tzdata source package in Kinetic:
  Confirmed

Bug description:
  New timezone data, with the following timezones impacted:
  - Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
  - Iran no longer observes DST (Asia/Tehran)

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [Test Case for all releases]
  1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
  2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499

  [Test Case for releases >= 20.04 LTS]

  For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
  1) sudo apt-get install python3-icu
  2) Run the following python script:

  from datetime import datetime
  from icu import ICUtzinfo, TimeZone
  tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
  always_before = datetime(2022, 9, 1)
  now_before = datetime(2022, 9, 8)
  always_after = datetime(2022, 9, 12)
  assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
  assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))

  The assertions would crash on 2022a.

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. Subsequently, these should be checked for using the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  Nothing should be returned by the above command.

  [Original report]
  tzdata 2022b and 2022c were just released that includes some timezone changes 
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest 
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a 
change to the start of their daylight savings and pushed it from Sept 4th to 
the 11th, so we really need our servers updated before the 4th.

  Thanks

  Jason

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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 1986984] Re: [FFe] tzdata 2022c update

[Simon Chopin]

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

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

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

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

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

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

Title:
  [FFe] tzdata 2022c update

Status in tzdata package in Ubuntu:
  Triaged
Status in tzdata source package in Xenial:
  Confirmed
Status in tzdata source package in Bionic:
  Confirmed
Status in tzdata source package in Focal:
  Confirmed
Status in tzdata source package in Jammy:
  Confirmed
Status in tzdata source package in Kinetic:
  Triaged

Bug description:
  New timezone data, with the following timezones impacted:
  - Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
  - Iran no longer observes DST (Asia/Tehran)

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [Test Case for all releases]
  1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
  2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499

  [Test Case for releases >= 20.04 LTS]

  For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
  1) sudo apt-get install python3-icu
  2) Run the following python script:

  from datetime import datetime
  from icu import ICUtzinfo, TimeZone
  tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
  always_before = datetime(2022, 9, 1)
  now_before = datetime(2022, 9, 8)
  always_after = datetime(2022, 9, 12)
  assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
  assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))

  The assertions would crash on 2022a.

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. Subsequently, these should be checked for using the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  Nothing should be returned by the above command.

  [Original report]
  tzdata 2022b and 2022c were just released that includes some timezone changes 
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest 
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a 
change to the start of their daylight savings and pushed it from Sept 4th to 
the 11th, so we really need our servers updated before the 4th.

  Thanks

  Jason

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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 1988196] [NEW] presage: ftbfs with GCC-11

[Simon Chopin]

Public bug reported:

Imported from Debian bug http://bugs.debian.org/984297:

Package: src:presage
Version: 0.9.1-2.2
Severity: normal
Tags: sid bookworm
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-11

[This bug is not targeted to the upcoming bullseye release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
severity of this report will be raised before the bookworm release,
so nothing has to be done for the bullseye release.

The full build log can be found at:
http://people.debian.org/~doko/logs/20210228/filtered/gcc11/presage_0.9.1-2.2_unstable_gcc11.log
The last lines of the build log are at the end of this report.

To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t=experimental install g++

Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-11/porting_to.html

GCC 11 defaults to the GNU++17 standard.  If your package installs
header files in /usr/include, please don't work around C++17 issues
by choosing a lower C++ standard for the package build, but fix these
issues to build with the C++17 standard.

[...]
presage.h:199:33: error: ISO C++17 does not allow dynamic exception 
specifications
  199 | std::string context() const throw (PresageException);
  | ^
presage.h:206:33: error: ISO C++17 does not allow dynamic exception 
specifications
  206 | bool context_change() const throw (PresageException);
  | ^
presage.h:212:32: error: ISO C++17 does not allow dynamic exception 
specifications
  212 | std::string prefix() const throw (PresageException);
  |^
presage.h:221:58: error: ISO C++17 does not allow dynamic exception 
specifications
  221 | std::string config(const std::string variable) const throw 
(PresageException);
  |  ^
presage.h:230:76: error: ISO C++17 does not allow dynamic exception 
specifications
  230 | void config(const std::string variable, const std::string value) 
const throw (PresageException);
  | 
   ^
presage.h:239:30: error: ISO C++17 does not allow dynamic exception 
specifications
  239 | void save_config() const throw (PresageException);
  |  ^
presage.cpp:34:5: error: ISO C++17 does not allow dynamic exception 
specifications
   34 | throw (PresageException)
  | ^
presage.cpp:45:5: error: ISO C++17 does not allow dynamic exception 
specifications
   45 | throw (PresageException)
  | ^
presage.cpp:65:5: error: ISO C++17 does not allow dynamic exception 
specifications
   65 | throw (PresageException)
  | ^
presage.cpp:91:5: error: ISO C++17 does not allow dynamic exception 
specifications
   91 | throw (PresageException)
  | ^
presage.cpp:140:5: error: ISO C++17 does not allow dynamic exception 
specifications
  140 | throw (PresageException)
  | ^
presage.cpp:147:5: error: ISO C++17 does not allow dynamic exception 
specifications
  147 | throw (PresageException)
  | ^
presage.cpp:153:5: error: ISO C++17 does not allow dynamic exception 
specifications
  153 | throw (PresageException)
  | ^
presage.cpp:201:5: error: ISO C++17 does not allow dynamic exception 
specifications
  201 | throw (PresageException)
  | ^
presage.cpp:207:5: error: ISO C++17 does not allow dynamic exception 
specifications
  207 | throw (PresageException)
  | ^
presage.cpp:213:5: error: ISO C++17 does not allow dynamic exception 
specifications
  213 | throw (PresageException)
  | ^
presage.cpp:219:5: error: ISO C++17 does not allow dynamic exception 
specifications
  219 | throw (PresageException)
  | ^
presage.cpp:225:5: error: ISO C++17 does not allow dynamic exception 
specifications
  225 | throw (PresageException)
  | ^
presage.cpp:231:5: error: ISO C++17 does not allow dynamic exception 
specifications
  231 | throw (PresageException)
  | ^
make[5]: *** [Makefile:580: libpresage_la-presage.lo] Error 1
make[5]: Leaving directory '/<>/src/lib'
make[4]: *** [Makefile:616: all-recursive] Error 1
make[4]: Leaving directory '/<>/s

[Touch-packages] [Bug 1987642] Re: Chile is delaying the DST by one week for 2022

[Simon Chopin]

*** This bug is a duplicate of bug 1986984 ***
https://bugs.launchpad.net/bugs/1986984

** This bug has been marked a duplicate of bug 2022
   iso-codes is not available for breezy

** This bug is no longer a duplicate of bug 2022
   iso-codes is not available for breezy

** Description changed:

- Chile is delaying the start of Daylight Saving Time (DST) by one week
- this year [1],[2].
+ New timezone data, with the following timezones impacted:
+ - Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
+ - Iran no longer observes DST (Asia/Tehran)
+ 
+ Verification is done with 'zdump'. The first timezone that gets changed
+ in the updated package is dumped with 'zdump -v
+ $region/$timezone_that_changed' (this needs to be greped for in
+ /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
+ compared to the same output after the updated package got installed. If
+ those are different the verification is considered done.
+ 
+ [Test Case for all releases]
+ 1) zdump -v America/Santiago | grep 'Sep.*2022'
+   -> should indicate Sep 11, not Sep 4
+ 2) zdump -v Asia/Tehran | tail
+   -> last dates should be in 2022, not in 2499
+ 
+ [Test Case for releases >= 20.04 LTS]
+ 
+ For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
+ 1) sudo apt-get install python3-icu
+ 2) Run the following python script:
+ 
+ from datetime import datetime
+ from icu import ICUtzinfo, TimeZone
+ tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
+ always_before = datetime(2022, 9, 1)
+ now_before = datetime(2022, 9, 8)
+ always_after = datetime(2022, 9, 12)
+ assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
+ assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
+ 
+ The assertions would crash on 2022a.
+ 
+ [Test Case for releases <= 20.04 LTS]
+ 
+ Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. Subsequently, these should be checked for using the following:
+ diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)
+ 
+ Nothing should be returned by the above command.
+ 
+ [Original report]
+ Chile is delaying the start of Daylight Saving Time (DST) by one week this 
year [1],[2].
  
  DST timezone in Chile will start on midnight of September 11th; and will
  end on April 1st, 2023.
  
  Debian's 2022c-1 and 2022b-1 versions of tzdata contain the fix for
  this.
  
  Upstream commit :
  https://github.com/eggert/tz/commit/711b46f8fc4e8a3d5caf7d4820562d6cdfe9d769
  
  We need to fix this in all or releases back to Xenial.
  
- 
  [1] 
https://www.interior.gob.cl/noticias/2022/08/09/comunicado-el-proximo-sabado-10-de-septiembre-los-relojes-se-deben-adelantar-una-hora/
  [2] 
https://www.timeanddate.com/news/time/chile-dst-delay-2022.html#:~:text=Chile%20is%20delaying%20the%20start,financial%20district%20in%20Chile%27s%20capital.

** This bug has been marked a duplicate of bug 1986984
   [FFe] tzdata 2022c update

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

Title:
  Chile is delaying the DST by one week for 2022

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Xenial:
  Confirmed
Status in tzdata source package in Bionic:
  Confirmed
Status in tzdata source package in Focal:
  Confirmed
Status in tzdata source package in Jammy:
  Confirmed
Status in tzdata source package in Kinetic:
  Fix Released

Bug description:
  New timezone data, with the following timezones impacted:
  - Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
  - Iran no longer observes DST (Asia/Tehran)

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [Test Case for all releases]
  1) zdump -v America/Santiago | grep 'Sep.*2022'
    -> should indicate Sep 11, not Sep 4
  2) zdump -v Asia/Tehran | tail
    -> last dates should be in 2022, not in 2499

  [Test Case for releases >= 20.04 LTS]

  For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
  1) sudo apt-get install python3-icu
  2) Run the following python script:

  from datetime import datetime
  from icu import ICUtzinfo, TimeZone
  tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
  always_before = datetime(2022, 9, 1)
  now_before = datetime(2022, 9, 8)
  always_after = datetime(2022, 9, 12)
  assert(tz.utcoff

[Touch-packages] [Bug 1986984] Re: [FFe] tzdata 2022c update

[Simon Chopin]

Apologies for the metadata bug traffic, I hadn't realized there were
duplicates, and actually use different bug numbers in the SRU and devel
uploads. Marking this manually as released on Kinetic, as the SRU
uploads use this bug number.

** Changed in: tzdata (Ubuntu Kinetic)
   Status: Triaged => Fix Released

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

Title:
  [FFe] tzdata 2022c update

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Xenial:
  Confirmed
Status in tzdata source package in Bionic:
  Confirmed
Status in tzdata source package in Focal:
  Confirmed
Status in tzdata source package in Jammy:
  Confirmed
Status in tzdata source package in Kinetic:
  Fix Released

Bug description:
  New timezone data, with the following timezones impacted:
  - Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
  - Iran no longer observes DST (Asia/Tehran)

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [Test Case for all releases]
  1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
  2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499

  [Test Case for releases >= 20.04 LTS]

  For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
  1) sudo apt-get install python3-icu
  2) Run the following python script:

  from datetime import datetime
  from icu import ICUtzinfo, TimeZone
  tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
  always_before = datetime(2022, 9, 1)
  now_before = datetime(2022, 9, 8)
  always_after = datetime(2022, 9, 12)
  assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
  assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))

  The assertions would crash on 2022a.

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. Subsequently, these should be checked for using the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  Nothing should be returned by the above command.

  [Original report]
  tzdata 2022b and 2022c were just released that includes some timezone changes 
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest 
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a 
change to the start of their daylight savings and pushed it from Sept 4th to 
the 11th, so we really need our servers updated before the 4th.

  Thanks

  Jason

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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 1986984] Re: [FFe] tzdata 2022c update

[Simon Chopin]

I verified the upload on Jammy, Focal and Bionic via fresh LXC
containers, using the attached script.

For the ESM releases, it has been handled by sbeattie from the Security
Team. As I understand, the packages are already available in the ESM
security PPA (I don't have access to it).

** Attachment added: "validate.sh"
   
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+attachment/5612734/+files/validate.sh

** Tags removed: verification-needed verification-needed-bionic 
verification-needed-focal verification-needed-jammy
** Tags added: verification-done verification-done-bionic 
verification-done-focal verification-done-jammy

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

Title:
  [FFe] tzdata 2022c update

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Xenial:
  Confirmed
Status in tzdata source package in Bionic:
  Fix Committed
Status in tzdata source package in Focal:
  Fix Committed
Status in tzdata source package in Jammy:
  Fix Committed
Status in tzdata source package in Kinetic:
  Fix Released

Bug description:
  New timezone data, with the following timezones impacted:
  - Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
  - Iran no longer observes DST (Asia/Tehran)

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [Test Case for all releases]
  1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
  2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499

  [Test Case for releases >= 20.04 LTS]

  For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
  1) sudo apt-get install python3-icu
  2) Run the following python script:

  from datetime import datetime
  from icu import ICUtzinfo, TimeZone
  tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
  always_before = datetime(2022, 9, 1)
  now_before = datetime(2022, 9, 8)
  always_after = datetime(2022, 9, 12)
  assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
  assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))

  The assertions would crash on 2022a.

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. Subsequently, these should be checked for using the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  Nothing should be returned by the above command.

  [Original report]
  tzdata 2022b and 2022c were just released that includes some timezone changes 
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest 
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a 
change to the start of their daylight savings and pushed it from Sept 4th to 
the 11th, so we really need our servers updated before the 4th.

  Thanks

  Jason

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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

Re: [Touch-packages] [Bug 1979639] Re: Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail

[Simon Chopin]

Hi!

I apologize, I thought I'd sent here the gameplan for the issue, but it
must have only been discussed out of band within the team. As noted by
Robie, the consensus is not to change the default configuration, but
instead patching node.js on Jammy (patches welcome for that one though).

I've already reverted the change in kinetic in my last upload
(3.0.5-2ubuntu1)

Thanks for the follow-up, Robie!

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

Title:
  Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail

Status in nodejs package in Ubuntu:
  Confirmed
Status in openssl package in Ubuntu:
  Fix Released
Status in nodejs source package in Jammy:
  Confirmed
Status in openssl source package in Jammy:
  Won't Fix
Status in nodejs source package in Kinetic:
  Confirmed
Status in openssl source package in Kinetic:
  Fix Released

Bug description:
  [Impact]
  While the default configuration works fine for every package that uses the 
system libssl3, libssl1.1.1 (which implicitly loads the configuration on 
OPENSSL_crypto_init()) fails to parse it.

  Our nodejs package vendors openssl 1.1.1, which means it will trigger this 
bug. In addition, upstream NodeJS explicitly points their statically-linked 
OpenSSL to this file as well, and ships 1.1.1 in their current LTS (branch 
16.x).
  Finally, we can also expect breakage for third-party packages that still 
depends on libssl1.1.

  If the provider section isn't present in the configuration, libssl3
  will load the default provider, which means that commenting out the
  section won't impact the behavior of standard libssl3 users.

  [Test Plan]

  On a system with a pristine openssl configuration:

  $ sudo apt install nodejs
  $ nodejs -  const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { 
modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  Uncaught:
  Error: error:25066067:DSO support routines:dlfcn_load:could not load the 
shared library
  at Sign.sign (node:internal/crypto/sig:131:29) {
    opensslErrorStack: [
  'error:0E076071:configuration file routines:module_run:unknown module 
name',
  'error:0E07506E:configuration file routines:module_load_dso:error loading 
dso',
  'error:25070067:DSO support routines:DSO_load:could not load the shared 
library'
    ],
    library: 'DSO support routines',
    function: 'dlfcn_load',
    reason: 'could not load the shared library',
    code: 'ERR_OSSL_DSO_COULD_NOT_LOAD_THE_SHARED_LIBRARY'
  }

  Removing the relevant provider section lines (the Debian patch doesn't
  apply cleanly, hence the use of sed) fixes it:

  ~ $ sed -i '/_sect\b/s/^/# /' /etc/ssl/openssl.cnf
  ~ $ node
  Welcome to Node.js v16.15.0.
  Type ".help" for more information.
  > const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { 
modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  

  I realize there is no libssl1.1 on jammy, but a statically linked
  OpenSSL is not uncommon (Node.js being a very prominent example).

  Would it be possible to get this Debian sid change ported to jammy?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1979639/+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 1960268] Re: SSL handshake failed - VPN SSL broken in 22.04

[Simon Chopin]

@dragu-stelian, you do not have the same issue. Looking at your logs, it
seems your client cannot reach your server over the network. This is not
related to openssl. If it were, the issue would manifest no matter from
where you're attempting to connect.

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

Title:
  SSL handshake failed - VPN SSL broken in 22.04

Status in openssl package in Ubuntu:
  Expired

Bug description:
  I'm trying to connect with global protect VPN but fails at login with:

  SSL handshake failed
  Failed to load URL https://...
  QtNetwork Error 6

  Another VPN client does work but the rdp connection to a remote server fails 
with:

  transport_connect_tls:freerdp_set_last_error_ex ERRCONNECT_TLS_CONNECT_FAILED
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu76
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: KDE
  DistroRelease: Ubuntu 21.10
  InstallationDate: Installed on 2021-03-19 (325 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  Package: openssl 3.0.1-0ubuntu1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 5.15.0-18.18-generic 5.15.12
  Tags:  wayland-session impish
  Uname: Linux 5.15.0-18-generic x86_64
  UpgradeStatus: Upgraded to impish on 2022-02-04 (3 days ago)
  UserGroups: adm cdrom dialout dip docker input lpadmin lxd plugdev sambashare 
sudo uinput
  _MarkForUpload: True
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu76
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: KDE
  DistroRelease: Ubuntu 22.04
  InstallationDate: Installed on 2021-03-19 (325 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  Package: openssl 3.0.1-0ubuntu1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 5.15.0-18.18-generic 5.15.12
  Tags:  wayland-session jammy
  Uname: Linux 5.15.0-18-generic x86_64
  UpgradeStatus: Upgraded to jammy on 2022-02-04 (3 days ago)
  UserGroups: adm cdrom dialout dip docker input lpadmin lxd plugdev sambashare 
sudo uinput
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1960268/+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 1988657] Re: VLAN gets IP address assignment from parent device when using "match macaddress"

[Simon Chopin]

I just tried it on all releases up to Kinetic, they're all affected. I
suspect it's actually a bug in systemd-networkd, as the files generated
in /run/systemd/networkd/ look sane enough:

root@firm-mayfly:~# cat /run/systemd/network/10-netplan-eno1.network 
[Match]
MACAddress=00:16:3e:10:7a:c2
Type=!vlan bond bridge

[Network]
LinkLocalAddressing=ipv6
Address=192.168.2.1/24
VLAN=l2club

root@firm-mayfly:~# cat /run/systemd/network/10-netplan-l2club.netdev 
[NetDev]
Name=l2club
Kind=vlan

[VLAN]
Id=10

root@firm-mayfly:~# cat /run/systemd/network/10-netplan-l2club.network 
[Match]
Name=l2club

[Network]
LinkLocalAddressing=ipv6
Address=10.232.228.16/8
ConfigureWithoutCarrier=yes

There wasn't anything suspicious in the journald logs, either.

** Tags added: rls-kk-incoming

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: netplan
   Status: New => Confirmed

** Changed in: netplan.io (Ubuntu)
   Status: New => Confirmed

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

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

Title:
  VLAN gets IP address assignment from parent device when using "match
  macaddress"

Status in netplan:
  Confirmed
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  System is Ubuntu 18.04 with Netplan 0.99-0ubuntu3~18.04.5(amd64)

  When using the "match macaddress" mechanism to guarantee the
  assignment of the ethernet device name to a particular port, VLANs
  added to that device will not get the the IP addresses assigned to
  them but rather the IP address of the parent ethernet device.

  In the example below from my system, the 'l2club' VLAN would get the
  192.168.2.1 address, along with eno1 receiving it.  The address
  10.232.228.16 was not assigned to anything.  With the "match
  macaddress" section was removed, both interfaces would then get the IP
  addresses that were expected.

  network:
version: 2
renderer: networkd
ethernets:
  eno1:
match:
  macaddress: 00:24:e8:00:00:00
addresses:
  - 192.168.2.1/24
vlans:
  l2club:
id: 10
link: eno1
addresses:
  - 10.232.228.16/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1988657/+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 2068933] Re: all reports with LaunchpadPrivate in them are tagged need-$arch-retrace

[Simon Chopin]

** Changed in: apport
   Status: New => Fix Committed

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

Title:
  all reports with LaunchpadPrivate in them are tagged need-$arch-
  retrace

Status in Apport:
  Fix Committed
Status in apport package in Ubuntu:
  In Progress

Bug description:
  I was recently reviewing the crash reports which the Launchpad
  retracers handle and was surprised to see a bunch of ubuntu-advantage-
  tools reports that retracing was tried for even though they had a
  ProblemType of Bug. Looking at the ubuntu-advantage-tools apport
  package hook we can see that all the LaunchpadPrivate is set to 1,
  then looking at `apport/crashdb_impl/launchpad.py` there is:

  1083 if "DistroRelease" in report:
  1084 if a and (
  1085 "VmCore" in report
  1086 or "CoreDump" in report
  1087 or "LaunchpadPrivate" in report
  1088 ):
  1089 hdr["Private"] = "yes"
  1090 hdr["Subscribers"] = report.get(
  1091 "LaunchpadSubscribe",
  1092 self.options.get("initial_subscriber", "apport"),
  1093 )
  1094 hdr["Tags"] += f" need-{a}-retrace"

  Adding need-$arch-retrace is incorrect if the ProblemType is Bug.

  Here are some example bugs:

  https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2067076
  https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2066231

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/2068933/+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 2074212] [NEW] libdmapsharing doesn't have frame pointers enabled

[Simon Chopin]

Public bug reported:

Despite the distribution having enabled frame pointers globally, the
binaries shipped by libdmapsharing don't have frame pointers.

It is likely due to the build system being pretty screwed up: it builds
the library once using the CFLAGS, then rebuilds it with custom flags
for the test suite, and we ship the latter version.

** Affects: libdmapsharing (Ubuntu)
 Importance: Undecided
 Status: In Progress

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

Title:
  libdmapsharing doesn't have frame pointers enabled

Status in libdmapsharing package in Ubuntu:
  In Progress

Bug description:
  Despite the distribution having enabled frame pointers globally, the
  binaries shipped by libdmapsharing don't have frame pointers.

  It is likely due to the build system being pretty screwed up: it
  builds the library once using the CFLAGS, then rebuilds it with custom
  flags for the test suite, and we ship the latter version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libdmapsharing/+bug/2074212/+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 2073338] Re: Please merge shadow 1:4.15.3-2 into Oracular

[Simon Chopin]

** Merge proposal linked:
   
https://code.launchpad.net/~hectorcao/ubuntu/+source/shadow/+git/shadow/+merge/469556

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

Title:
  Please merge shadow 1:4.15.3-2 into Oracular

Status in shadow package in Ubuntu:
  In Progress

Bug description:
  Current debian version in Oracular: 1:4.13+dfsg1 (upstream version
  4.13)

  New version 1:4.15.3-2 has been released in Debian unstable (upstream
  version 4.15)

  4.15 is the current supported stable version of upstream

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2073338/+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 2075204] [NEW] gdb on s390x chokes on divide-by-zero from chaos-marmosets

[Simon Chopin]

Public bug reported:

To help in the development of apport we're using the chaos-marmosets set
of binaries, which triggers various crashes. In particular, we're using
/usr/bin/divide-by-zero which does as its name indicates, which
naturally triggers a native crash.

However, GDB fails on s390x. Note that for the following I have the
debugging symbols from ddebs.ubuntu.com installed:

ubuntu@glibc-proposed:/tmp$ gdb /usr/bin/divide-by-zero
[snip]
Reading symbols from /usr/bin/divide-by-zero...
Reading symbols from 
/usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug...
(gdb) run
Starting program: /usr/bin/divide-by-zero
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".

Program received signal SIGTRAP, Trace/breakpoint trap.
0x02aa0814 in ?? ()
(gdb) bt
#0  0x02aa0814 in ?? ()
#1  0x03fff7d2baac in __libc_start_call_main (main=0x2aa0690 , 
main@entry=, 
argc=argc@entry=1, argv=argv@entry=0x3ffa468)
at ../sysdeps/nptl/libc_start_call_main.h:58
#2  0x03fff7d2bbae in __libc_start_main_impl (main=, argc=1, 
argv=0x3ffa468, init=, fini=, 
rtld_fini=0x3fff7f85650 <_dl_fini>,
stack_end=0x3ffa3b0) at ../csu/libc-start.c:360
#3  0x02aa0720 in _start ()
(gdb) info address divide_by_zero
Symbol "divide_by_zero" is a function at address 0x2aa0810.
(gdb)

So at this point GDB isn't capable of identifying the various symbols on
the stack, which isn't ideal.

Now, if I try to step in:

ubuntu@glibc-proposed:/tmp$ gdb -q /usr/bin/divide-by-zero
Reading symbols from /usr/bin/divide-by-zero...
Reading symbols from 
/usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug...
(gdb) start
Temporary breakpoint 1 at 0x690: file divide-by-zero.c, line 29.
Starting program: /usr/bin/divide-by-zero
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x3ffa468) at divide-by-zero.c:29
warning: 29 divide-by-zero.c: No such file or directory
(gdb) s
34  in divide-by-zero.c
(gdb)
divide_by_zero () at divide-by-zero.c:25
25  in divide-by-zero.c
(gdb)
/build/gdb-nviNEX/gdb-15.1/gdb/infrun.c:2982: internal-error: resume_1: 
Assertion `pc_in_thread_step_range (pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
- Backtrace -
0x2aa100a247f ???
0x2aa104efce5 ???
0x2aa104eff7f ???
0x2aa10668c13 ???
0x2aa102553db ???
0x2aa10255bd1 ???
0x2aa10255f5f ???
0x2aa10259195 ???
0x2aa1025c315 ???
0x2aa1025e9a5 ???
0x2aa10260015 ???
0x2aa1066951b ???
0x2aa10669e6d ???
0x2aa102b01cd ???
0x2aa102b3607 ???
0x2aa0ffed839 ???
0x3ffb142baab __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x3ffb142bbad __libc_start_main_impl
../csu/libc-start.c:360
0x2aa0fff8f8f ???
0x ???
-
/build/gdb-nviNEX/gdb-15.1/gdb/infrun.c:2982: internal-error: resume_1: 
Assertion `pc_in_thread_step_range (pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

I can provide a core dump if you think that'd help, but it seems
trivially reproducible.

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

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

Title:
  gdb on s390x chokes on divide-by-zero from chaos-marmosets

Status in gdb package in Ubuntu:
  New

Bug description:
  To help in the development of apport we're using the chaos-marmosets
  set of binaries, which triggers various crashes. In particular, we're
  using /usr/bin/divide-by-zero which does as its name indicates, which
  naturally triggers a native crash.

  However, GDB fails on s390x. Note that for the following I have the
  debugging symbols from ddebs.ubuntu.com installed:

  ubuntu@glibc-proposed:/tmp$ gdb /usr/bin/divide-by-zero
  [snip]
  Reading symbols from /usr/bin/divide-by-zero...
  Reading symbols from 
/usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug...
  (gdb) run
  Starting program: /usr/bin/divide-by-zero
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".

  Program received signal SIGTRAP, Trace/breakpoint trap.
  0x02aa0814 in ?? ()
  (gdb) bt
  #0  0x02aa0814 in ?? ()
  #1  0x03fff7d2baac in __libc_start_call_main (main=0x2aa0690 , 
main@entry=, 
argc=argc@entry=1, argv=argv@entry=0x3ffa468)
  at ../sysdeps/nptl/libc_start_call_main.h:58
  #2  0x03fff7d2bbae in __libc_start_main_impl (main=, 
argc=1, argv=0x3ffa468, init=, fini=, 
rtld_fini=0x3fff7f85650 <_dl_fini>,
  stack_end=0x3ffa3b0) at ../csu/libc-start.c:360
  

[Touch-packages] [Bug 2075313] [NEW] zlib FTBFS on s390x due to 32-bit support removal

[Simon Chopin]

Public bug reported:

We have recently removed support for 32-bit binaries on s390x, which
makes zlib FTBFS:

native-architecture: s390x
report:
 -
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: s390x
  status: broken
  reasons:
   -
missing:
 pkg:
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: s390x
  unsat-dependency: gcc-multilib:s390x

** Affects: zlib (Ubuntu)
 Importance: High
 Assignee: Simon Chopin (schopin)
 Status: New


** Tags: foundations-todo

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

Title:
  zlib FTBFS on s390x due to 32-bit support removal

Status in zlib package in Ubuntu:
  New

Bug description:
  We have recently removed support for 32-bit binaries on s390x, which
  makes zlib FTBFS:

  native-architecture: s390x
  report:
   -
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: s390x
status: broken
reasons:
 -
  missing:
   pkg:
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: s390x
unsat-dependency: gcc-multilib:s390x

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/2075313/+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 2073787] Re: apport-retrace needs more than 1.5 GB memory (when using sandbox)

[Simon Chopin]

This feature should be postponed to the 2.31 version (i.e. the 25.04
cycle), as we don't fully understand the typical usage patterns of
apport-retrace. We're talking about a substantial change, and having it
targeted to 2.30 (which needs to be cut in the coming two weeks) would
be rushing it, even though we don't actually have reports of it being an
issue in production. It's only becoming a problem because we now have
apport-retrace system tests during autopkgtests, which is by definition
an artificial setting.

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

Title:
  apport-retrace needs more than 1.5 GB memory (when using sandbox)

Status in Apport:
  Triaged
Status in apport package in Ubuntu:
  Triaged

Bug description:
  The system tests test_retrace_system_sandbox and
  test_retrace_jammy_sandbox fail on arm64, ppc64el, s390x, because
  apport-retrace is killed by the OOM killer. Example:

  autopkgtest kernel: Out of memory: Killed process 3597 (apport-
  retrace) total-vm:1512420kB, anon-rss:1241460kB, file-rss:2592kB,
  shmem-rss:0kB, UID:0 pgtables:2554kB oom_score_adj:0

  Log: https://autopkgtest.ubuntu.com/results/autopkgtest-oracular-
  bdrung-apport/oracular/s390x/a/apport/20240722_145904_d3c2f@/log.gz

  apport-retrace should be able to retrace crashes without needing
  multiple gigabytes of memory.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/2073787/+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 2075567] Re: zlib fails to build on s390x on oracular with gcc 14

[Simon Chopin]

** Changed in: zlib (Ubuntu)
   Importance: Undecided => Critical

** Changed in: zlib (Ubuntu)
 Assignee: (unassigned) => Simon Chopin (schopin)

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

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

Title:
  zlib fails to build on s390x on oracular with gcc 14

Status in Ubuntu on IBM z Systems:
  New
Status in zlib package in Ubuntu:
  Triaged

Bug description:
  Rebuilding zlib for s390x on oracular fails to build, probably due to
  gcc 14 usage (since it became more strict).

  Full build log can be found here:
  
https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz

  erroneous lines are:

  D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13 
-mzarch  -c -o crc32-vx.o contrib/s390/crc32-vx.c
  contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’:
  contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
 91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1);
|^
||
|uv16qi {aka 
__vector(16) unsigned char}
  contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but 
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
  contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
 92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2);
|^
||
|uv16qi {aka 
__vector(16) unsigned char}
  contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but 
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
  contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
 93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3);
|^
||
|uv16qi {aka 
__vector(16) unsigned char}
  contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but 
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
  contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
 94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4);
|^
||
|uv16qi {aka 
__vector(16) unsigned char}
  contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but 
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
  contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
||
|__vector(16) unsigned 
char
  contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but 
argument is of type ‘__vector(16) unsigned char’
  contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3);
|^~
||
|__vector(16) unsigned 
char
  contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but 
argument is of type ‘__vector(16) unsigned char’
  contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4);
|^~
||
|__vector(16) unsigned 
char
  contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but 
argument is of type ‘__vector(16) unsigned char’
  contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (

[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14

[Simon Chopin]

Frank, can you confirm that you got in touch with the upstream author
about it?

I probably could "fix" it by sprinkling casts all over the place, which
could be wildly unsafe depending on the exact properties of __int128, or
by actually using a local __int128 variable and memcpy it or something
like that, which might destroy performance? (I recall something like
that being a problem in some glibc routines on ARM where moving data
from SIMD registers was *really* slow on the Pis)

As you see, I'm in much doubt so knowledge from the people who wrote the
patch (and own the hardware) would be greatly appreciated!

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

Title:
  zlib fails to build on s390x on oracular with gcc 14

Status in Ubuntu on IBM z Systems:
  Triaged
Status in zlib package in Ubuntu:
  Triaged

Bug description:
  Rebuilding zlib for s390x on oracular fails to build, probably due to
  gcc 14 usage (since it became more strict).

  Full build log can be found here:
  
https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz

  erroneous lines are:

  D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13 
-mzarch  -c -o crc32-vx.o contrib/s390/crc32-vx.c
  contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’:
  contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
 91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1);
|^
||
|uv16qi {aka 
__vector(16) unsigned char}
  contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but 
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
  contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
 92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2);
|^
||
|uv16qi {aka 
__vector(16) unsigned char}
  contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but 
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
  contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
 93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3);
|^
||
|uv16qi {aka 
__vector(16) unsigned char}
  contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but 
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
  contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
 94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4);
|^
||
|uv16qi {aka 
__vector(16) unsigned char}
  contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but 
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
  contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
||
|__vector(16) unsigned 
char
  contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but 
argument is of type ‘__vector(16) unsigned char’
  contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3);
|^~
||
|__vector(16) unsigned 
char
  contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but 
argument is of type ‘__vector(16) unsigned char’
  contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4);
|^~
||
|__vector(16) unsig

[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14

[Simon Chopin]

** Also affects: gcc-14 (Ubuntu)
   Importance: Undecided
   Status: New

** Tags added: ftbfs update-excuse

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

Title:
  zlib fails to build on s390x on oracular with gcc 14

Status in Ubuntu on IBM z Systems:
  Triaged
Status in gcc-14 package in Ubuntu:
  New
Status in zlib package in Ubuntu:
  Triaged

Bug description:
  Rebuilding zlib for s390x on oracular fails to build, probably due to
  gcc 14 usage (since it became more strict).

  Full build log can be found here:
  
https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz

  erroneous lines are:

  D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13 
-mzarch  -c -o crc32-vx.o contrib/s390/crc32-vx.c
  contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’:
  contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
 91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1);
|^
||
|uv16qi {aka 
__vector(16) unsigned char}
  contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but 
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
  contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
 92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2);
|^
||
|uv16qi {aka 
__vector(16) unsigned char}
  contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but 
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
  contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
 93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3);
|^
||
|uv16qi {aka 
__vector(16) unsigned char}
  contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but 
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
  contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
 94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4);
|^
||
|uv16qi {aka 
__vector(16) unsigned char}
  contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but 
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
  contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
||
|__vector(16) unsigned 
char
  contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but 
argument is of type ‘__vector(16) unsigned char’
  contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3);
|^~
||
|__vector(16) unsigned 
char
  contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but 
argument is of type ‘__vector(16) unsigned char’
  contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4);
|^~
||
|__vector(16) unsigned 
char
  contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but 
argument is of type ‘__vector(16) unsigned char’
  contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of 
‘__builtin_s390_vgfmag’
114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
||
|  

[Touch-packages] [Bug 2075313] Re: zlib FTBFS on s390x due to 32-bit support removal

[Simon Chopin]

This is fixed by doko in 1:1.3.dfsg-3.1ubuntu3 but it's currently stuck
in -proposed due to bug 2075567

** Changed in: zlib (Ubuntu)
   Status: New => Fix Committed

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

Title:
  zlib FTBFS on s390x due to 32-bit support removal

Status in zlib package in Ubuntu:
  Fix Committed

Bug description:
  We have recently removed support for 32-bit binaries on s390x, which
  makes zlib FTBFS:

  native-architecture: s390x
  report:
   -
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: s390x
status: broken
reasons:
 -
  missing:
   pkg:
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: s390x
unsat-dependency: gcc-multilib:s390x

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/2075313/+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 2073992] Re: Please merge zlib 1:1.3.dfsg+really1.3.1-1 into oracular

[Simon Chopin]

** Changed in: zlib (Ubuntu)
 Assignee: Ravi Kant Sharma (ravi-sharma) => Simon Chopin (schopin)

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

Title:
  Please merge zlib 1:1.3.dfsg+really1.3.1-1 into oracular

Status in zlib package in Ubuntu:
  New

Bug description:
  tracking bu

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/2073992/+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 2073992] Re: Please merge zlib 1:1.3.dfsg+really1.3.1-1 into oracular

[Simon Chopin]

** Changed in: zlib (Ubuntu)
   Status: New => Fix Committed

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

Title:
  Please merge zlib 1:1.3.dfsg+really1.3.1-1 into oracular

Status in zlib package in Ubuntu:
  Fix Committed

Bug description:
  tracking bu

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/2073992/+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 2076898] Re: Numeric name is accepted as valid username for useradd/groupadd

[Simon Chopin]

** Merge proposal linked:
   
https://code.launchpad.net/~hectorcao/ubuntu/+source/shadow/+git/shadow/+merge/471145

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

Title:
  Numeric name is accepted as valid username for useradd/groupadd

Status in shadow package in Ubuntu:
  In Progress

Bug description:
  Pure numeric names (example 0, 100) should be considered as invalid group and 
user names
  The command useradd and groupadd must refuse them

  This is not the case in the latest version of shadow :
  1:4.15.3-3ubuntu1

  When we issue:

  $ useradd 0

  The command succeeds instead of failing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2076898/+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 2077340] [NEW] systemd mkosi tests can fail to pull packages from -proposed

[Simon Chopin]

Public bug reported:

In particular, testing against a version of glibc in -proposed will fail
with the following error:

3784s  libc6-dbg : Depends: libc6 (= 2.39-0ubuntu9) but 2.40-1ubuntu1 is
to be installed

(2.39-0ubuntu9 is the version in the release pocket, 2.40-1ubuntu1 is
the one in -proposed).

Full logs there:

https://autopkgtest.ubuntu.com/results/autopkgtest-
oracular/oracular/amd64/s/systemd/20240815_155819_13661@/log.gz

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

** Summary changed:

- systemd mk-osi tests can fail to pull packages from -proposed
+ systemd mkosi tests can fail to pull packages from -proposed

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

Title:
  systemd mkosi tests can fail to pull packages from -proposed

Status in systemd package in Ubuntu:
  New

Bug description:
  In particular, testing against a version of glibc in -proposed will
  fail with the following error:

  3784s  libc6-dbg : Depends: libc6 (= 2.39-0ubuntu9) but 2.40-1ubuntu1
  is to be installed

  (2.39-0ubuntu9 is the version in the release pocket, 2.40-1ubuntu1 is
  the one in -proposed).

  Full logs there:

  https://autopkgtest.ubuntu.com/results/autopkgtest-
  oracular/oracular/amd64/s/systemd/20240815_155819_13661@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2077340/+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 2076898] Re: Numeric name is accepted as valid username for useradd/groupadd

[Simon Chopin]

** Changed in: shadow (Ubuntu)
   Status: In Progress => Fix Committed

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

Title:
  Numeric name is accepted as valid username for useradd/groupadd

Status in shadow package in Ubuntu:
  Fix Committed

Bug description:
  Pure numeric names (example 0, 100) should be considered as invalid group and 
user names
  The command useradd and groupadd must refuse them

  This is not the case in the latest version of shadow :
  1:4.15.3-3ubuntu1

  When we issue:

  $ useradd 0

  The command succeeds instead of failing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2076898/+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 2074191] Re: Binary RM of 32-bit binaries on s390x

[Simon Chopin]

I checked the gcc packages, and indeed the lib32z1-dev dependency has
been fixed, including in the oracular release pocket. I think we're
hitting a bug in reverse-depends, since it shows up even for riscv64:

❯ reverse-depends -b -a riscv64 lib32z1-dev
Reverse-Build-Depends
=
* gcc-11
* gcc-12
* gcc-13
* gcc-14
* gcc-snapshot

Britney is currently refusing the glibc transition because of this:

trying: glibc dsda-doom zzuf dpf-plugins dante libnss-db unscd
skipped: glibc dsda-doom zzuf dpf-plugins dante libnss-db unscd (229, 67, 0)
got: 20+0: a-6:a-2:a-2:i-0:p-2:r-2:s-6
* s390x: lib32z1, lib32z1-dev, libc6-s390

(most of the candidate packages in the bundle have strict versioned
dependencies on glibc)

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

Title:
  Binary RM of 32-bit binaries on s390x

Status in glibc package in Ubuntu:
  Incomplete
Status in zlib package in Ubuntu:
  In Progress

Bug description:
  Hi,

  Could you please do a binary removal of the following binary packages
  in the oracular release pocket?

  lib32z1
  lib32z1-dev
  libc6-s390
  libc6-dev-s390
  oaklisp

  
  We have removed the support for 32-bit binaries on s390x (see bug 2067350), 
and these leftovers are preventing glibc from migrating.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2074191/+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 2074191] Re: Binary RM of 32-bit binaries on s390x

[Simon Chopin]

zlib has just migrate to the release pocket (along with glibc), closing
this bug.

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

** Changed in: glibc (Ubuntu)
   Status: Incomplete => Invalid

** Tags removed: update-excuse

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

Title:
  Binary RM of 32-bit binaries on s390x

Status in glibc package in Ubuntu:
  Invalid
Status in zlib package in Ubuntu:
  Fix Released

Bug description:
  Hi,

  Could you please do a binary removal of the following binary packages
  in the oracular release pocket?

  lib32z1
  lib32z1-dev
  libc6-s390
  libc6-dev-s390
  oaklisp

  
  We have removed the support for 32-bit binaries on s390x (see bug 2067350), 
and these leftovers are preventing glibc from migrating.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2074191/+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 2076340] Re: SRU: no-change rebuild to pick up changed build flags on ppc64el and s390x

[Simon Chopin]

I looked at the s390-tools build logs and have verified that the -fno-
omit-frame-pointer flags that were present in the previous build are now
gone on both ppc64el and s390x but not on amd64. In addition,
-mbackchain is present on s390x.

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

Title:
  SRU: no-change rebuild to pick up changed build flags on ppc64el and
  s390x

Status in atlas package in Ubuntu:
  New
Status in bzip2 package in Ubuntu:
  Fix Released
Status in containerd-app package in Ubuntu:
  New
Status in curl package in Ubuntu:
  New
Status in cyrus-sasl2 package in Ubuntu:
  New
Status in dbus package in Ubuntu:
  Fix Released
Status in docker.io-app package in Ubuntu:
  New
Status in dotnet8 package in Ubuntu:
  New
Status in gnutls28 package in Ubuntu:
  New
Status in golang-1.22 package in Ubuntu:
  New
Status in icu package in Ubuntu:
  Fix Released
Status in lapack package in Ubuntu:
  Fix Released
Status in libdeflate package in Ubuntu:
  New
Status in libseccomp package in Ubuntu:
  Fix Released
Status in libzdnn package in Ubuntu:
  Fix Released
Status in libzstd package in Ubuntu:
  New
Status in lz4 package in Ubuntu:
  New
Status in mysql-8.0 package in Ubuntu:
  New
Status in nettle package in Ubuntu:
  New
Status in openssh package in Ubuntu:
  New
Status in openssl package in Ubuntu:
  New
Status in p11-kit package in Ubuntu:
  New
Status in postgresql-16 package in Ubuntu:
  New
Status in postgresql-common package in Ubuntu:
  New
Status in powerpc-utils package in Ubuntu:
  Fix Released
Status in python-greenlet package in Ubuntu:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in runc-app package in Ubuntu:
  Fix Released
Status in rustc package in Ubuntu:
  New
Status in s390-tools package in Ubuntu:
  New
Status in s390-tools-signed package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New
Status in util-linux package in Ubuntu:
  New
Status in xz-utils package in Ubuntu:
  New
Status in zlib package in Ubuntu:
  New
Status in atlas source package in Noble:
  Fix Committed
Status in bzip2 source package in Noble:
  Fix Released
Status in containerd-app source package in Noble:
  Fix Released
Status in curl source package in Noble:
  Fix Released
Status in cyrus-sasl2 source package in Noble:
  Fix Released
Status in dbus source package in Noble:
  Fix Released
Status in docker.io-app source package in Noble:
  Fix Released
Status in dotnet8 source package in Noble:
  Fix Committed
Status in gnutls28 source package in Noble:
  Fix Released
Status in golang-1.22 source package in Noble:
  Fix Released
Status in icu source package in Noble:
  Fix Released
Status in lapack source package in Noble:
  Fix Released
Status in libdeflate source package in Noble:
  Fix Released
Status in libseccomp source package in Noble:
  Fix Released
Status in libzdnn source package in Noble:
  Fix Released
Status in libzstd source package in Noble:
  Fix Released
Status in lz4 source package in Noble:
  Fix Released
Status in mysql-8.0 source package in Noble:
  Fix Released
Status in nettle source package in Noble:
  Fix Released
Status in openssh source package in Noble:
  Fix Released
Status in openssl source package in Noble:
  Fix Released
Status in p11-kit source package in Noble:
  Fix Released
Status in postgresql-16 source package in Noble:
  Fix Committed
Status in postgresql-common source package in Noble:
  Fix Released
Status in powerpc-utils source package in Noble:
  Fix Released
Status in python-greenlet source package in Noble:
  Fix Released
Status in qemu source package in Noble:
  Fix Committed
Status in runc-app source package in Noble:
  Fix Released
Status in rustc source package in Noble:
  Fix Released
Status in s390-tools source package in Noble:
  Fix Committed
Status in s390-tools-signed source package in Noble:
  Fix Committed
Status in systemd source package in Noble:
  Fix Released
Status in util-linux source package in Noble:
  Fix Committed
Status in xz-utils source package in Noble:
  Fix Released
Status in zlib source package in Noble:
  Fix Released

Bug description:
  SRU: no-change rebuild to pick up changed build flags on ppc64el and
  s390x

  This is batch of packages that we want to rebuild to pick up the
  changed build flags on ppc64el (LP: #2064539) and s390x (LP:
  #2064538).

  Impact: These are no change uploads on architectures other than
  ppc64el and s390x. All of those packages already built successful in
  oracular with the changed build flags.

  We will validate picking up the changed build flags by inspecting the
  log files on ppc64el and s390x.

  The packages are now all built, and passing autopkg tests (the failing
  software-properties test is unrelated).

  Packages, that are not yet ready:

   - atlas (ftbfs)
   - s390-tools, s390-tools-signed (not yet uploaded)
   - pos

[Touch-packages] [Bug 2077862] Re: adduser autopkgtests failed due to shadow 1:4.15.3-3ubuntu2 in 24.10 proposed

[Simon Chopin]

** Bug watch added: Debian Bug tracker #1077804
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077804

** Also affects: fink via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077804
   Importance: Unknown
   Status: Unknown

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

Title:
  adduser autopkgtests failed due to shadow 1:4.15.3-3ubuntu2 in 24.10
  proposed

Status in adduser package in Ubuntu:
  New
Status in shadow package in Ubuntu:
  New
Status in Fink:
  Unknown

Bug description:
  ADT of adduser fails due to the merge of shadow on 24.10 to the
  version 1:4.15.3-3ubuntu2 in 24.10

  Logs of the ADT :
  
https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest-
  oracular/oracular/amd64/a/adduser/20240814_214718_33c7b@/log.gz

  The failing tests:
  ---

  650s Test Summary Report
  650s ---
  650s debian/tests/f/valid_username.t (Wstat: 5120 (exited 20) Tests: 
669 Failed: 20)
  650s   Failed tests:  209-212, 214-217, 245-248, 250-253, 321-324
  650s   Non-zero exit status: 20
  650s Files=20, Tests=2631, 142 wallclock secs ( 0.44 usr  0.11 sys + 79.95 
cusr 41.69 csys = 122.19 CPU)
  650s Result: FAIL

  Logs:
  ---

  670s #   Failed test 'command success: /usr/sbin/adduser --quiet --ingroup 
nogroup --system --disabled-password --home '/home/\}' --allow-all-names '\}''
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 50.
  670s #  got: '82'
  670s # expected: '0'
  670s
  670s #   Failed test 'user exists: \}'
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 247.
  670s #  got: undef
  670s # expected: anything else
  670s
  670s #   Failed test 'path exists: /home/\}'
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 176.
  670s
  670s #   Failed test 'command success: /usr/sbin/deluser --quiet 
--remove-home '\}''
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 50.
  670s #  got: '12'
  670s # expected: '0'
  670s
  670s #   Failed test 'command success: /usr/sbin/adduser --quiet --ingroup 
nogroup --system --disabled-password --home '/home/\}' '\}''
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 50.
  670s #  got: '82'
  670s # expected: '0'
  670s
  670s #   Failed test 'user exists: \}'
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 247.
  670s #  got: undef
  670s # expected: anything else
  670s
  670s #   Failed test 'path exists: /home/\}'
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 176.
  670s
  670s #   Failed test 'command success: /usr/sbin/deluser --quiet 
--remove-home '\}''
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 50.
  670s #  got: '12'
  670s # expected: '0'
  670s
  670s #   Failed test 'command success: /usr/sbin/adduser --quiet --ingroup 
nogroup --system --disabled-password --home '/home/DOMAIN\user' 
--allow-all-names 'DOMAIN\user''
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 50.
  670s #  got: '82'
  670s # expected: '0'
  670s
  670s #   Failed test 'user exists: DOMAIN\user'
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 247.
  670s #  got: undef
  670s # expected: anything else
  670s
  670s #   Failed test 'path exists: /home/DOMAIN\user'
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 176.
  670s
  670s #   Failed test 'command success: /usr/sbin/deluser --quiet 
--remove-home 'DOMAIN\user''
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 50.
  670s #  got: '12'
  670s # expected: '0'
  670s
  670s #   Failed test 'command success: /usr/sbin/adduser --quiet --ingroup 
nogroup --system --disabled-password --home '/home/DOMAIN\user' 'DOMAIN\user''
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 50.
  670s #  got: '82'
  670s # expected: '0'
  670s
  670s #   Failed test 'user exists: DOMAIN\user'
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 247.
  670s #  got: undef
  670s # expected: anything else
  670s
  670s #   Failed test 'path exists: /home/DOMAIN\user'
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 176.
  670s
  670s #   Failed test 'command success: /usr/sbin/deluser --quiet 
--remove-home 'DOMAIN\user''
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 50.
  670s #  got: '12'
  670s # expected: '0'
  670s
  670s #   Failed test 'command success: /usr/sbin/adduser --quiet --ingroup 
nogroup --system --disabled-password --home "/home/'c4\$h\\M0n3y\"'==>@" 
--allow-all-names "'c4\$h\\M0n3y\"'==>@"'
  670s #   at debian/tests/lib/AdduserTestsCommon.pm line 50.
  670s #  got: '82'
  670s # expected: '0'
  670s
  670s #   Failed test 'user exists: 'c4$h\M0n3y"'==>@'
  670s #   at debian/tests/lib/AdduserTestsCommon.pm l

[Touch-packages] [Bug 2077883] Re: usermod silently fails modifying group membership for extrausers

[Simon Chopin]

FWIW, it's not a regression as the behaviour is the same in Focal.

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

Title:
  usermod silently fails modifying group membership for extrausers

Status in shadow package in Ubuntu:
  New

Bug description:
  Release
  Distributor ID: Ubuntu
  Description:Ubuntu 24.04 LTS
  Release:24.04
  Codename:   noble

  Package:
  passwd 1:4.13+dfsg1-4ubuntu3.2

  When using the libnss-extrausers package to store users in a seperate
  DB at /var/lib/extrausers, the usermod program is unable to edit group
  memberships (usermod -a -G  )

  Running group-modifying usermod command fails silently, no error is
  generated and the return code is 0, but there is no change at
  /var/lib/extrausers

  usermod DOES support some extrausers features, I can successfully
  change a user's GECOS.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2077883/+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 2078058] Re: Missing function implementations in libssl.so.3 and .a

[Simon Chopin]

Hi,

Thanks for taking the time to report this issue.

Presumably, your boost.asio was not built against the libssl-dev headers
provided in Ubuntu, since in that version those function names aren't
provided as symbols but rather as preprocessor aliases to the more
modern TLS_* alternatives (see
https://docs.openssl.org/3.0/man3/SSL_CTX_new/#notes).

In other words, OpenSSL 3.0 breaks the ABI, so binaries linking against
it need to be recompiled (and their code might need some tweaking). We
did so for all binaries within the Ubuntu archive. Given that the oldest
Boost version we shipped in Jammy is 1.74, the binaries at fault here
come from somewhere else, please contact that provider to ask them to
give you a version built against libssl3.

** Changed in: openssl (Ubuntu)
   Status: New => Invalid

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

Title:
  Missing function implementations in libssl.so.3 and .a

Status in openssl package in Ubuntu:
  Invalid

Bug description:
  Description:Ubuntu 22.04.2 LTS
  Release:22.04

  openssl:
Installed: 3.0.2-0ubuntu1.17
Candidate: 3.0.2-0ubuntu1.17
Version table:
   *** 3.0.2-0ubuntu1.17 500
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
  500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   3.0.2-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages

  Expected behavior:
  Building an app that uses boost.asio (1.28.0 or any >=1.10.9) with SSL 
support will succeed.

  Unexpected behavior:
  Building an app that uses boost.asio (1.28.0 or any >=1.10.9) with SSL 
support results in undefined symbols at link time.

  Ubuntu openssl 3.0.2 and 3.0.7 provide libssl.so.3 (and .a) that lacks
  6 function implementations:

  SSL_CTX_set_max_proto_version
  SSL_CTX_set_min_proto_version
  SSL_set_mode
  SSLv23_client_method
  SSLv23_method
  SSLv23_server_method

  although they are declared in the openssl ssl.h header file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2078058/+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 2077712] Re: lastlog does not capture all logins

[Simon Chopin]

See https://github.com/linux-pam/linux-pam/blob/master/NEWS -> release
1.5.3

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

Title:
  lastlog does not capture all logins

Status in shadow package in Ubuntu:
  Won't Fix

Bug description:
  My system does not capture all logins in lastlog.
  In particular ssh logins are not captured.
  Some users stay stuck at "**Never logged in**"

  
  It is very similar to bug #271049 , but that one is over 10 yrs old.

  Might be related to /etc/pam.d  and pam_lastlog.so, but I don't know
  enough about that.

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: login 1:4.13+dfsg1-4ubuntu3
  ProcVersionSignature: Ubuntu 6.8.0-38.38-generic 6.8.8
  Uname: Linux 6.8.0-38-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.28.1-0ubuntu3.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Fri Aug 23 10:32:33 2024
  InstallationDate: Installed on 2023-10-27 (301 days ago)
  InstallationMedia: Xubuntu 23.10 "Mantic Minotaur" - Release amd64 (20231010)
  RebootRequiredPkgs: Error: path contained symlinks.
  SourcePackage: shadow
  UpgradeStatus: Upgraded to noble on 2024-07-12 (42 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2077712/+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 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set

[Simon Chopin]

** Changed in: systemd (Ubuntu Oracular)
   Status: New => In Progress

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

Title:
  [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with
  zdev:early=0 set

Status in Ubuntu on IBM z Systems:
  New
Status in s390-tools package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  In Progress
Status in s390-tools source package in Oracular:
  Fix Released
Status in systemd source package in Oracular:
  In Progress

Bug description:
  Versions:
  Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x
  Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x

  When I configure a zfcp LUN persistently via chzdev, the initrd is
  being rebuilt even with parameter zdev:early=0

  root@a8315003:~# chzdev -e zfcp-lun 
0.0.1803:0x500507630910d430:0x40194092 zdev:early=0
  zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured
  Note: The initial RAM-disk must be updated for these changes to take effect:
 - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092
  update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic
  I: The initramfs will attempt to resume from /dev/dasdb1
  I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698)
  I: Set the RESUME variable to override this.
  Using config file '/etc/zipl.conf'
  Building bootmap in '/boot'
  Adding IPL section 'ubuntu' (default)
  Preparing boot device: dasda (c00a).
  Done.
  root@a8315003:~#

  == Comment: - Thorsten Diehl  - 2023-03-01 
06:55:47 ==
  @BOE-dev
  This behaviour is unexpected.
  https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says:
  Activating a device early during the boot process

  Use the zdev:early device attribute to activate a device early during
  the boot process and to override any existing auto-configuration with
  a persistent device configuration.

  zdev:early=1
  The device is activated during the initial RAM disc phase according to 
the persistent configuration.

  zdev:early=0
  The device is activated as usual during the boot process. This is the 
default. If auto-configuration data is present, the device is activated during 
the initial RAM disc phase according to the auto-configuration. 

  I can't interprete a SCSI LUN as a device with auto configuration
  data. (At least, if the zfcp device hasn't NPIV enabled)

  == Comment: #5 - Peter Oberparleiter  - 
2023-03-01 11:18:28 ==
  (In reply to comment #2)
  > @BOE-dev
  > This behaviour is unexpected.
  > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says:
  > Activating a device early during the boot process
  > 
  > Use the zdev:early device attribute to activate a device early during the
  > boot process and to override any existing auto-configuration with a
  > persistent device configuration.
  > 
  > zdev:early=1
  > The device is activated during the initial RAM disc phase according to
  > the persistent configuration.
  > 
  > zdev:early=0
  > The device is activated as usual during the boot process. This is the
  > default. If auto-configuration data is present, the device is activated
  > during the initial RAM disc phase according to the auto-configuration. 

  The documentation is incorrect for Ubuntu. Canonical specifically
  builds zdev in a way that every change to persistent device
  configuration causes an update to the initial RAM-disk. See also:

  https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35
  
https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8

  > I can't interprete a SCSI LUN as a device with auto configuration data. (At
  > least, if the zfcp device hasn't NPIV enabled)

  This is related to auto-configuration as implemented for DPM.

  == Comment: #6 - Thorsten Diehl  - 2023-03-03 
12:41:44 ==
  So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which 
make the parameter zdev:early=0 ineffective. Correct?
  If you confirm, you may also close this bug.

  Not nice - then we have to find an alternate solution.

  == Comment: #7 - Peter Oberparleiter  - 
2023-03-07 06:48:07 ==
  (In reply to comment #6)
  > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which
  > make the parameter zdev:early=0 ineffective. Correct?
  > If you confirm, you may also close this bug.
  > 
  > Not nice - then we have to find an alternate solution.

  chzdev -p on Ubuntu will by default rebuild the initrd. This is intended
  behavior by Canonical and controlled by the ZDEV_ALWAYS_UPDATE_INITRD 
build-time
  switch. You can suppress it by adding option --no-root-update to the command
  line.

  Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed 
to
  have: it tells zdev not to enable that device during initrd processing,
  resulting in the corresponding udev rule not be

[Touch-packages] [Bug 1983200] Re: package libc6 2.35-0ubuntu3 failed to install/upgrade: new libc6:amd64 package pre-installation script subprocess returned error exit status 255

[Simon Chopin]

Looking at the logs, this bug seems rather to be in
/usr/share/perl5/Debconf/Db.pm, which is in debconf. Reassigning it
there.

** Also affects: debconf (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: glibc (Ubuntu)
   Status: New => Invalid

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

Title:
  package libc6 2.35-0ubuntu3 failed to install/upgrade: new libc6:amd64
  package pre-installation script subprocess returned error exit status
  255

Status in debconf package in Ubuntu:
  New
Status in glibc package in Ubuntu:
  Invalid

Bug description:
  I have an error there.

  ProblemType: Package
  DistroRelease: Ubuntu 22.04
  Package: libc6 2.35-0ubuntu3
  ProcVersionSignature: Ubuntu 5.15.0-43.46-generic 5.15.39
  Uname: Linux 5.15.0-43-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Sun Jul 31 11:39:05 2022
  ErrorMessage: new libc6:amd64 package pre-installation script subprocess 
returned error exit status 255
  InstallationDate: Installed on 2022-07-29 (1 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 
(20220419)
  Python3Details: /usr/bin/python3.10, Python 3.10.4, python3-minimal, 
3.10.4-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.21.1ubuntu2.1
   apt  2.4.6
  SourcePackage: glibc
  Title: package libc6 2.35-0ubuntu3 failed to install/upgrade: new libc6:amd64 
package pre-installation script subprocess returned error exit status 255
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1983200/+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 2002355] Re: package libssl-dev 3.0.2-0ubuntu1.7 [modified: usr/include/openssl/aes.h usr/include/openssl/asn1.h usr/include/openssl/asn1_mac.h usr/include/openssl/asn1t.h usr/in

[Simon Chopin]

Hi!

Seeing this line:

Unpacking libssl-dev:i386 (3.0.2-0ubuntu1.7) over (1.0.1f-1ubuntu2.27)

makes me think you either are trying to upgrade directly from Trusty
(which would be weird given your install medium is Jammy), or have
third-party packages on your system, most likely installed through a
third-party repository (e.g. PPA), or manually. Either way, this is not
something we can support, so I'm closing this as Invalid.

Your best bet moving forward is to uninstall libssl-dev:amd64 and
libssl-dev:i386 temporarily, and then reinstall them from the official
archive.

** Changed in: openssl (Ubuntu)
   Status: New => Invalid

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

Title:
  package libssl-dev 3.0.2-0ubuntu1.7 [modified:
  usr/include/openssl/aes.h usr/include/openssl/asn1.h
  usr/include/openssl/asn1_mac.h usr/include/openssl/asn1t.h
  usr/include/openssl/bio.h usr/include/openssl/blowfish.h
  usr/include/openssl/bn.h usr/include/openssl/buffer.h
  usr/include/openssl/camellia.h usr/include/openssl/cast.h
  usr/include/openssl/cmac.h usr/include/openssl/cms.h
  usr/include/openssl/comp.h usr/include/openssl/conf.h
  usr/include/openssl/conf_api.h usr/include/openssl/crypto.h
  usr/include/openssl/des.h usr/include/openssl/dh.h
  usr/include/openssl/dsa.h usr/include/openssl/dtls1.h
  usr/include/openssl/e_os2.h usr/include/openssl/ebcdic.h
  usr/include/openssl/ec.h usr/include/openssl/ecdh.h
  usr/include/openssl/ecdsa.h usr/include/openssl/engine.h
  usr/include/openssl/err.h usr/include/openssl/evp.h
  usr/include/openssl/hmac.h usr/include/openssl/lhash.h
  usr/include/openssl/md4.h usr/include/openssl/md5.h
  usr/include/openssl/modes.h usr/include/openssl/obj_mac.h
  usr/include/openssl/objects.h usr/include/openssl/ocsp.h
  usr/include/openssl/opensslv.h usr/include/openssl/ossl_typ.h
  usr/include/openssl/pem.h usr/include/openssl/pem2.h
  usr/include/openssl/pkcs12.h usr/include/openssl/pkcs7.h
  usr/include/openssl/rand.h usr/include/openssl/rc2.h
  usr/include/openssl/rc4.h usr/include/openssl/ripemd.h
  usr/include/openssl/rsa.h usr/include/openssl/safestack.h
  usr/include/openssl/seed.h usr/include/openssl/sha.h
  usr/include/openssl/srp.h usr/include/openssl/srtp.h
  usr/include/openssl/ssl.h usr/include/openssl/ssl2.h
  usr/include/openssl/ssl3.h usr/include/openssl/stack.h
  usr/include/openssl/symhacks.h usr/include/openssl/tls1.h
  usr/include/openssl/ts.h usr/include/openssl/txt_db.h
  usr/include/openssl/ui.h usr/include/openssl/whrlpool.h
  usr/include/openssl/x509.h usr/include/openssl/x509_vfy.h
  usr/include/openssl/x509v3.h] failed to install/upgrade: trying to
  overwrite shared '/usr/include/openssl/aes.h', which is different from
  other instances of package libssl-dev:i386

Status in openssl package in Ubuntu:
  Invalid

Bug description:
  openssl lib

  ProblemType: Package
  DistroRelease: Ubuntu 22.04
  ProcVersionSignature: Ubuntu 5.15.0-57.63-generic 5.15.74
  Uname: Linux 5.15.0-57-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu82.3
  AptOrdering:
   libssl-dev:i386: Install
   NULL: ConfigurePending
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Tue Jan 10 00:43:30 2023
  DpkgTerminalLog:
   Preparing to unpack .../libssl-dev_3.0.2-0ubuntu1.7_i386.deb ...
   Unpacking libssl-dev:i386 (3.0.2-0ubuntu1.7) over (1.0.1f-1ubuntu2.27) ...
   dpkg: error processing archive 
/var/cache/apt/archives/libssl-dev_3.0.2-0ubuntu1.7_i386.deb (--unpack):
trying to overwrite shared '/usr/include/openssl/aes.h', which is different 
from other instances of package libssl-dev:i386
  ErrorMessage: trying to overwrite shared '/usr/include/openssl/aes.h', which 
is different from other instances of package libssl-dev:i386
  InstallationDate: Installed on 2023-01-03 (5 days ago)
  InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809.1)
  Python3Details: /usr/bin/python3.10, Python 3.10.6, python3-minimal, 
3.10.6-1~22.04
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.21.1ubuntu2.1
   apt  2.4.8
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2002355/+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 2002660] [NEW] networkx incompatible with numpy 1.24

[Simon Chopin]

Public bug reported:

The nipype autopkgtests have started failing with the following stack
trace:

 ERROR collecting pipeline/plugins/tests/test_tools.py _
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:992: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:992: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:1006: in _find_and_load_unlocked
???
:688: in _load_unlocked
???
:883: in exec_module
???
:241: in _call_with_frames_removed
???
nipype/pipeline/plugins/__init__.py:5: in 
from .debug import DebugPlugin
nipype/pipeline/plugins/debug.py:7: in 
import networkx as nx
/usr/lib/python3/dist-packages/networkx/__init__.py:115: in 
import networkx.readwrite
/usr/lib/python3/dist-packages/networkx/readwrite/__init__.py:15: in 
from networkx.readwrite.graphml import *
/usr/lib/python3/dist-packages/networkx/readwrite/graphml.py:314: in 
class GraphML(object):
/usr/lib/python3/dist-packages/networkx/readwrite/graphml.py:346: in GraphML
(np.int, "int"), (np.int8, "int"),
/usr/lib/python3/dist-packages/numpy/__init__.py:284: in __getattr__
raise AttributeError("module {!r} has no attribute "
E   AttributeError: module 'numpy' has no attribute 'int'

The problematic code is in the networkx package, and seems to have been
fixed in
https://github.com/networkx/networkx/commit/207147ee179554a33f10f25032054d3e01f96188
(which is in 2.5 onwards).

Debian currently ships with 2.8.8, we might want to merge?

This is currently blocking the python3-defaults transition.

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

** Affects: nipype (Ubuntu)
 Importance: Undecided
 Status: Invalid

** Affects: python3-defaults (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: update-excuse

** Tags added: update-excuse

** Also affects: nipype (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: nipype (Ubuntu)
   Status: New => Invalid

** Also affects: python3-defaults (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  networkx incompatible with numpy 1.24

Status in networkx package in Ubuntu:
  New
Status in nipype package in Ubuntu:
  Invalid
Status in python3-defaults package in Ubuntu:
  New

Bug description:
  The nipype autopkgtests have started failing with the following stack
  trace:

   ERROR collecting pipeline/plugins/tests/test_tools.py 
_
  /usr/lib/python3.10/importlib/__init__.py:126: in import_module
  return _bootstrap._gcd_import(name[level:], package, level)
  :1050: in _gcd_import
  ???
  :1027: in _find_and_load
  ???
  :992: in _find_and_load_unlocked
  ???
  :241: in _call_with_frames_removed
  ???
  :1050: in _gcd_import
  ???
  :1027: in _find_and_load
  ???
  :992: in _find_and_load_unlocked
  ???
  :241: in _call_with_frames_removed
  ???
  :1050: in _gcd_import
  ???
  :1027: in _find_and_load
  ???
  :1006: in _find_and_load_unlocked
  ???
  :688: in _load_unlocked
  ???
  :883: in exec_module
  ???
  :241: in _call_with_frames_removed
  ???
  nipype/pipeline/plugins/__init__.py:5: in 
  from .debug import DebugPlugin
  nipype/pipeline/plugins/debug.py:7: in 
  import networkx as nx
  /usr/lib/python3/dist-packages/networkx/__init__.py:115: in 
  import networkx.readwrite
  /usr/lib/python3/dist-packages/networkx/readwrite/__init__.py:15: in 
  from networkx.readwrite.graphml import *
  /usr/lib/python3/dist-packages/networkx/readwrite/graphml.py:314: in 
  class GraphML(object):
  /usr/lib/python3/dist-packages/networkx/readwrite/graphml.py:346: in GraphML
  (np.int, "int"), (np.int8, "int"),
  /usr/lib/python3/dist-packages/numpy/__init__.py:284: in __getattr__
  raise AttributeError("module {!r} has no attribute "
  E   AttributeError: module 'numpy' has no attribute 'int'

  The problematic code is in the networkx package, and seems to have
  been fixed in
  
https://github.com/networkx/networkx/commit/207147ee179554a33f10f25032054d3e01f96188
  (which is in 2.5 onwards).

  Debian currently ships with 2.8.8, we might want to merge?

  This is currently blocking the python3-defaults transition.

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Un

[Touch-packages] [Bug 2002819] [NEW] dh-python: Deps guarded by (python3 << 3.X) break python-3.(X-1) use

[Simon Chopin]

Public bug reported:

Imported from Debian bug http://bugs.debian.org/1028603:

Package: dh-python
Version: 5.20221001
Severity: normal
X-Debbugs-Cc: scho...@ubuntu.com

For instance, pylint has "tomli>=1.1.0;python_version<'3.11'" in its
pyproject.toml, which is translated as "python3-tomli (>= 1.1.0) |
python3 (>= 3.11)".

This means that if we have python == 3.11 but still have python3.10 in
the archive, any code that iterates over all supported archive risks
failing simply due to the tomli module missing.

This is currently happening in the distro-info autopkgtests for the
python3-defaults migration from unstable to testing (and also in
Ubuntu). I'll probably be adding tomli as a test dependency in Ubuntu as
a stopgap, but I figured someone might think of a better long-term
solution to the issue.

-- System Information:
Debian Release: bookworm/sid
  APT prefers kinetic-updates
  APT policy: (500, 'kinetic-updates'), (500, 'kinetic-security'), (500, 
'kinetic'), (400, 'kinetic-proposed'), (100, 'kinetic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-29-generic (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-python depends on:
ii  python33.10.6-1
ii  python3-distutils  3.10.7-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev   1.21.9ubuntu1
pn  flit   
ii  libdpkg-perl   1.21.9ubuntu1
pn  python3-build  
pn  python3-installer  
ii  python3-tomli  2.0.1-1

-- no debconf information

** Affects: dh-python (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: dh-python (Debian)
 Importance: Undecided
 Status: New

** Bug watch added: Debian Bug tracker #1028603
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028603

** Changed in: dh-python (Debian)
 Remote watch: None => Debian Bug tracker #1028603

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

Title:
  dh-python: Deps guarded by (python3 << 3.X) break python-3.(X-1) use

Status in dh-python package in Ubuntu:
  New
Status in dh-python package in Debian:
  New

Bug description:
  Imported from Debian bug http://bugs.debian.org/1028603:

  Package: dh-python
  Version: 5.20221001
  Severity: normal
  X-Debbugs-Cc: scho...@ubuntu.com

  For instance, pylint has "tomli>=1.1.0;python_version<'3.11'" in its
  pyproject.toml, which is translated as "python3-tomli (>= 1.1.0) |
  python3 (>= 3.11)".

  This means that if we have python == 3.11 but still have python3.10 in
  the archive, any code that iterates over all supported archive risks
  failing simply due to the tomli module missing.

  This is currently happening in the distro-info autopkgtests for the
  python3-defaults migration from unstable to testing (and also in
  Ubuntu). I'll probably be adding tomli as a test dependency in Ubuntu as
  a stopgap, but I figured someone might think of a better long-term
  solution to the issue.

  -- System Information:
  Debian Release: bookworm/sid
APT prefers kinetic-updates
APT policy: (500, 'kinetic-updates'), (500, 'kinetic-security'), (500, 
'kinetic'), (400, 'kinetic-proposed'), (100, 'kinetic-backports')
  Architecture: amd64 (x86_64)
  Foreign Architectures: i386

  Kernel: Linux 5.19.0-29-generic (SMP w/24 CPU threads; PREEMPT)
  Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
  Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
set
  Shell: /bin/sh linked to /usr/bin/dash
  Init: systemd (via /run/systemd/system)
  LSM: AppArmor: enabled

  Versions of packages dh-python depends on:
  ii  python33.10.6-1
  ii  python3-distutils  3.10.7-1

  dh-python recommends no packages.

  Versions of packages dh-python suggests:
  ii  dpkg-dev   1.21.9ubuntu1
  pn  flit   
  ii  libdpkg-perl   1.21.9ubuntu1
  pn  python3-build  
  pn  python3-installer  
  ii  python3-tomli  2.0.1-1

  -- no debconf information

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dh-python/+bug/2002819/+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 2003548] Re: Merge Debian unstable's p11-kit 0.24.1-2

[Simon Chopin]

Uploaded, thanks :)

** Changed in: p11-kit (Ubuntu)
   Status: New => Fix Committed

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

Title:
  Merge Debian unstable's p11-kit 0.24.1-2

Status in p11-kit package in Ubuntu:
  Fix Committed

Bug description:
  This is a merge of Debian unstable's 0.24.1-2 as 0.24.1-2ubuntu1.
  A PPA is available at 
https://launchpad.net/~adrien-n/+archive/ubuntu/p11-kit-merge-0.24.1-2 .

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/p11-kit/+bug/2003548/+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 2004264] [NEW] FTBFS against glibc 2.37

[Simon Chopin]

Public bug reported:

Hi,

During a mass rebuild of Lunar, the package libunistring failed to build
against a snapshot of the upcoming glibc 2.37, while building fine using
2.36 as present in the archive.

https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20221215-lunar-glibc-2.37-lunar.html
https://launchpadlibrarian.net/644139079/buildlog_ubuntu-lunar-amd64.libunistring_1.0-2_BUILDING.txt.gz

I was able to reproduce this when building against my latest snapshot
(done this morning), published in this PPA:

https://launchpad.net/~schopin/+archive/ubuntu/glibc-2.37-snapshot/+packages

The failing tests appear to be test-strncat and test-u8-strncat.

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

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

Title:
  FTBFS against glibc 2.37

Status in libunistring package in Ubuntu:
  New

Bug description:
  Hi,

  During a mass rebuild of Lunar, the package libunistring failed to
  build against a snapshot of the upcoming glibc 2.37, while building
  fine using 2.36 as present in the archive.

  
https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20221215-lunar-glibc-2.37-lunar.html
  
https://launchpadlibrarian.net/644139079/buildlog_ubuntu-lunar-amd64.libunistring_1.0-2_BUILDING.txt.gz

  I was able to reproduce this when building against my latest snapshot
  (done this morning), published in this PPA:

  https://launchpad.net/~schopin/+archive/ubuntu/glibc-2.37-snapshot/+packages

  The failing tests appear to be test-strncat and test-u8-strncat.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libunistring/+bug/2004264/+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 2004264] Re: FTBFS against glibc 2.37

[Simon Chopin]

The failure is in a gnulib test. I've bisected it to the following glibc
upstream commit:

https://sourceware.org/git/?p=glibc.git;a=commit;h=642933158e7cf072d873231b1a9bb03291f2b989

The issue has been reported upstream.

** Bug watch added: Sourceware.org Bugzilla #30065
   https://sourceware.org/bugzilla/show_bug.cgi?id=30065

** Also affects: libunistring via
   https://sourceware.org/bugzilla/show_bug.cgi?id=30065
   Importance: Unknown
   Status: Unknown

** Project changed: libunistring => glibc

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

Title:
  FTBFS against glibc 2.37

Status in GLibC:
  Unknown
Status in libunistring package in Ubuntu:
  New

Bug description:
  Hi,

  During a mass rebuild of Lunar, the package libunistring failed to
  build against a snapshot of the upcoming glibc 2.37, while building
  fine using 2.36 as present in the archive.

  
https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20221215-lunar-glibc-2.37-lunar.html
  
https://launchpadlibrarian.net/644139079/buildlog_ubuntu-lunar-amd64.libunistring_1.0-2_BUILDING.txt.gz

  I was able to reproduce this when building against my latest snapshot
  (done this morning), published in this PPA:

  https://launchpad.net/~schopin/+archive/ubuntu/glibc-2.37-snapshot/+packages

  The failing tests appear to be test-strncat and test-u8-strncat.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/2004264/+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 2004264] Re: FTBFS against glibc 2.37

[Simon Chopin]

The issue has been fixed upstream just before the final 2.37 release,
thus closing this.

** Changed in: libunistring (Ubuntu)
   Status: New => Fix Released

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

Title:
  FTBFS against glibc 2.37

Status in GLibC:
  Unknown
Status in libunistring package in Ubuntu:
  Fix Released

Bug description:
  Hi,

  During a mass rebuild of Lunar, the package libunistring failed to
  build against a snapshot of the upcoming glibc 2.37, while building
  fine using 2.36 as present in the archive.

  
https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20221215-lunar-glibc-2.37-lunar.html
  
https://launchpadlibrarian.net/644139079/buildlog_ubuntu-lunar-amd64.libunistring_1.0-2_BUILDING.txt.gz

  I was able to reproduce this when building against my latest snapshot
  (done this morning), published in this PPA:

  https://launchpad.net/~schopin/+archive/ubuntu/glibc-2.37-snapshot/+packages

  The failing tests appear to be test-strncat and test-u8-strncat.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/2004264/+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 2006954] Re: openssl: merge unstable's 3.0.8-1

[Simon Chopin]

Uploaded, thanks!

** Changed in: openssl (Ubuntu)
   Status: New => Fix Committed

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

Title:
  openssl: merge unstable's 3.0.8-1

Status in openssl package in Ubuntu:
  Fix Committed

Bug description:
  Openssl 3.0.8 has been released. Unstable now contains 3.0.8-1 which
  we can merge.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2006954/+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 2038650] Re: crash reports not sent to the Error Tracker

[Simon Chopin]

We've agreed with Benjamin that the current fix is probably the way to
go for the SRU, while we work on the overall design to make this less
fragile (which would probably be way too much invasive for an SRU).

** Description changed:

- From what I can tell when I click the send button to send a crash report
- to the Error Tracker the crash doesn't actually get sent. My testing
- process follows:
+ [ Impact ]
+ 
+ Crash reports aren't sent in when going through the UI, unless the user
+ looks at the crash details.
+ 
+ [ Test Plan ]
+ 
+ 0) Make sure that error reporting is set to manual in the system settings (in 
Privacy screen)
+ 1) Launch xeyes
+ 2) pkill -11 xeyes
+ 3) Click send in the apport dialog. DO NOT look at the details of the report.
+ 4) ls -lh /var/crash/*xeyes*
+ 
+ There should be 3 files:
+ 
+ -rw-r- 1 bdmurray whoopsie  3370567 Oct  6 11:53 _usr_bin_xeyes.1000.crash
+ -rw-rw-r-- 1 bdmurray bdmurray0 Oct  6 11:53 
_usr_bin_xeyes.1000.upload
+ -rw--- 1 whoopsie whoopsie   37 Oct  6 11:53 
_usr_bin_xeyes.1000.uploaded
+ 
+ [ Where problems could occur ]
+ 
+ If the patch is wrong, we actually see similar bugs for other UI paths,
+ e.g. ticking the "Remember this" box, etc. I tried to cover them during
+ manual testing but I might have missed some.
+ 
+ [ Other Info ]
+  
+ If possible I'd like for us not to wait too long for this to mature in 
-proposed, as this would affect crashes during the upgrade.
+ 
+ [ Original report ]
+ From what I can tell when I click the send button to send a crash report to 
the Error Tracker the crash doesn't actually get sent. My testing process 
follows:
  
  1) Launch xeyes
  2) pkill -11 xeyes
  3) Click send in the apport dialog
  4) ls -lh /var/crash
  
  I would expect there to be three files in /var/crash:
  
  -rw-r- 1 bdmurray whoopsie  3370567 Oct  6 11:53 _usr_bin_xeyes.1000.crash
  -rw-rw-r-- 1 bdmurray bdmurray0 Oct  6 11:53 
_usr_bin_xeyes.1000.upload
  -rw--- 1 whoopsie whoopsie   37 Oct  6 11:53 
_usr_bin_xeyes.1000.uploaded
  
  However, after step #4 I'm only seeing the .crash file and not a .upload
  or .uploaded.  I was able to get the .upload and .uploaded files created
  if I chose to "View Report" and then click "Send".
  
  It's worth noting though that I did notice the size of the .crash file
  increase after clicking "Send" so some post-processing was done.
  
- ProblemType: Bug
- DistroRelease: Ubuntu 23.10
+ ProblemType: BugDistroRelease: Ubuntu 23.10
  Package: apport 2.27.0-0ubuntu4
  ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0
  Uname: Linux 6.5.0-5-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.27.0-0ubuntu4
  Architecture: amd64
  CasperMD5CheckResult: pass
  CrashReports: 640:1000:123:20944237:2023-10-06 12:10:47.809248208 
+0100:2023-10-06 12:11:23.340030509 +0100:/var/crash/_usr_bin_mpv.1000.crash
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Oct  6 12:12:46 2023
  InstallationDate: Installed on 2022-01-07 (637 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
- PackageArchitecture: all
- SourcePackage: apport
+ PackageArchitecture: allSourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

** Changed in: apport (Ubuntu Lunar)
 Assignee: Benjamin Drung (bdrung) => Simon Chopin (schopin)

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

Title:
  crash reports not sent to the Error Tracker

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Lunar:
  Confirmed
Status in apport source package in Mantic:
  Fix Released

Bug description:
  [ Impact ]

  Crash reports aren't sent in when going through the UI, unless the
  user looks at the crash details.

  [ Test Plan ]

  0) Make sure that error reporting is set to manual in the system settings (in 
Privacy screen)
  1) Launch xeyes
  2) pkill -11 xeyes
  3) Click send in the apport dialog. DO NOT look at the details of the report.
  4) ls -lh /var/crash/*xeyes*

  There should be 3 files:

  -rw-r- 1 bdmurray whoopsie  3370567 Oct  6 11:53 _usr_bin_xeyes.1000.crash
  -rw-rw-r-- 1 bdmurray bdmurray0 Oct  6 11:53 
_usr_bin_xeyes.1000.upload
  -rw--- 1 whoopsie whoopsie   37 Oct  6 11:53 
_usr_bin_xeyes.1000.uploaded

  [ Where problems could occur ]

  If the patch is wrong, we actually see similar bugs for other UI
  paths, e.g. ticking the "Remember this" box, etc. I tried to cover
  them during manual testing but I might have missed some.

  [ Other Info ]
   
  If possible I'd like for us not to wait too long for this to mature in 
-proposed, as this would affect crashes during the upgrade.

  [ Original report ]
  From what I can tell when I click 

[Touch-packages] [Bug 2038650] Re: crash reports not sent to the Error Tracker

[Simon Chopin]

Verified in a fresh Lunar VM.

** Tags removed: verification-needed verification-needed-lunar
** Tags added: verification-done verification-done-lunar

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

Title:
  crash reports not sent to the Error Tracker

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Lunar:
  Fix Committed
Status in apport source package in Mantic:
  Fix Released

Bug description:
  [ Impact ]

  Crash reports aren't sent in when going through the UI, unless the
  user looks at the crash details.

  [ Test Plan ]

  0) Make sure that error reporting is set to manual in the system settings (in 
Privacy screen)
  1) Launch xeyes
  2) pkill -11 xeyes
  3) Click send in the apport dialog. DO NOT look at the details of the report.
  4) ls -lh /var/crash/*xeyes*

  There should be 3 files:

  -rw-r- 1 bdmurray whoopsie  3370567 Oct  6 11:53 _usr_bin_xeyes.1000.crash
  -rw-rw-r-- 1 bdmurray bdmurray0 Oct  6 11:53 
_usr_bin_xeyes.1000.upload
  -rw--- 1 whoopsie whoopsie   37 Oct  6 11:53 
_usr_bin_xeyes.1000.uploaded

  [ Where problems could occur ]

  If the patch is wrong, we actually see similar bugs for other UI
  paths, e.g. ticking the "Remember this" box, etc. I tried to cover
  them during manual testing but I might have missed some.

  [ Other Info ]
   
  If possible I'd like for us not to wait too long for this to mature in 
-proposed, as this would affect crashes during the upgrade.

  [ Original report ]
  From what I can tell when I click the send button to send a crash report to 
the Error Tracker the crash doesn't actually get sent. My testing process 
follows:

  1) Launch xeyes
  2) pkill -11 xeyes
  3) Click send in the apport dialog
  4) ls -lh /var/crash

  I would expect there to be three files in /var/crash:

  -rw-r- 1 bdmurray whoopsie  3370567 Oct  6 11:53 _usr_bin_xeyes.1000.crash
  -rw-rw-r-- 1 bdmurray bdmurray0 Oct  6 11:53 
_usr_bin_xeyes.1000.upload
  -rw--- 1 whoopsie whoopsie   37 Oct  6 11:53 
_usr_bin_xeyes.1000.uploaded

  However, after step #4 I'm only seeing the .crash file and not a
  .upload or .uploaded.  I was able to get the .upload and .uploaded
  files created if I chose to "View Report" and then click "Send".

  It's worth noting though that I did notice the size of the .crash file
  increase after clicking "Send" so some post-processing was done.

  ProblemType: BugDistroRelease: Ubuntu 23.10
  Package: apport 2.27.0-0ubuntu4
  ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0
  Uname: Linux 6.5.0-5-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.27.0-0ubuntu4
  Architecture: amd64
  CasperMD5CheckResult: pass
  CrashReports: 640:1000:123:20944237:2023-10-06 12:10:47.809248208 
+0100:2023-10-06 12:11:23.340030509 +0100:/var/crash/_usr_bin_mpv.1000.crash
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Oct  6 12:12:46 2023
  InstallationDate: Installed on 2022-01-07 (637 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  PackageArchitecture: allSourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2038650/+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 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

[Simon Chopin]

I am not going to upload this, because I'm widely uncomfortable with bug
1990216 (details there).

In addition, I have a few superficial suggestions for aesthetics:

* Use lpX subdirectories in d/patches rather than add a prefix to the 
patchname
* Add a Bug-Ubuntu field with a LP URL to each patch to make it even easier to 
go back to the relevant bug

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

Title:
  openssl: backport to jammy "clear method store / query cache
  confusion"

Status in openssl package in Ubuntu:
  New
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [ATTENTION]
  This SRU contains FOUR changes which are listed in the section below.

  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  This ( #2033422 ) is the "central" bug with the global information and 
debdiff.

  This SRU addresses four issues with Jammy's openssl version:
  - http://pad.lv/1990216: Blowfish OFB/CFB decryption
  - http://pad.lv/1994165: ignored SMIME signature errors
  - http://pad.lv/2023545: imbca engine dumps core
  - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections

  The SRU information has been added to the four bug reports and I am
  attaching the debdiff here only for all four.

  All the patches have been included in subsequent openssl 3.0.x
  releases which in turn have been included in subsequent Ubuntu
  releases. There has been no report of issues when updating to these
  Ubuntu releases.

  I have rebuilt the openssl versions and used abi-compliance-checker to
  compare the ABIs of the libraries in jammy and the one for the SRU.
  Both matched completely (FYI, mantic's matched completely too).

  The patch related to blowfish presents an annoying situation: jammy's openssl 
creates incompatible files and cannot read other files but fixing it will lead 
to files created on jammy so far to become unreadable. Fortunately, blowfish is 
long-deprecated and applications can be improved to handle this situation if 
the need arises in practice.
  This is stated in the SRU information in the bug and in d/changelog.
  The current situation in Jammy could be a security issue but due to the 
aforementioned deprecation, the low usage of blowfish and the fact that 
upstream didn't consider this worthy of a security notice, we (this includes 
the security team) chose not to pursue that path either.

  I have also pushed the code to git (without any attempt to make it
  git-ubuntu friendly).

  
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
  sru

  I asked Brian Murray about phasing speed and he concurs a slow roll-out is 
probably better for openssl. There is a small uncertainty because a security 
update could come before the phasing is over, effectively fast-forwarding the 
SRU. Still, unless there is already a current pre-advisory, this is probably 
better than a 10% phasing which is over after only a couple days anyway.
  NB: at the moment openssl doesn't phase slowly so this needs to be 
implemented.

  [Impact]
  Severely degraded performance for concurrent operations compared to openssl 
1.1. The performance is so degraded that some workloads fail due to timeouts or 
insufficient resources (noone magically has 5 times more machines). As a 
consequence, a number of people use openssl 1.1 instead and do not get security 
updates.

  [Test plan]
  Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
 .
  Using this, I get the following numbers on my laptop:

  3.0.2:
  real  2m5.567s
  user  4m3.948s
  sys   2m0.233s

  this SRU:
  real  0m23.966s
  user  2m35.687s
  sys   0m1.920s

  As can be easily seen, the speed-up is massive: system time is divided
  by 60 and overall wall clock time is roughly five times lower.

  In http://pad.lv/2009544 , Rafael also shared his performance numbers
  and they are relatable to these. He used slightly different versions
  (upstreams rather than patched with cherry-picks) but at least one of
  the version used does not include other performance change. He also
  used different hardware and this performance issue seems to depend on
  the number of CPUs available but also obtained a performance several
  times better. Results on a given machine vary also very little across
  runs (less than 2% variation on runs of size 10). They are also very
  similar on a Raspberry Pi 4 (8GB).

  The benchmark uses https://www.google.com/humans.txt which takes
  around 130ms to download on my machine but I modified the script to
  download something only 20ms away. Results are so close to the ones
  using humans.txt tha

[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy

[Simon Chopin]

I'm very much against uploading this fix as an SRU. While it is a shame
that we have interop problems with the rest of the world, fixing this in
Jammy right now means we *will* break production for anyone that stores
Blowfish-encrypted data.

Doing `apt upgrade` on a production server is supposed to be a fairly
routine affair, whereas running into the interop issue means someone
somewhere did a dist-upgrade, changed some configuration, wrote new
code, or installed a new system, all of which are actions where the user
*should* expect possible breakage.

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

Title:
  backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL
  1.1 with blowfish in OFB or CFB modes" to Jammy

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  Decryption for Blowfish with OFB and CFB modes fails due to using a key 
shorter than expected by default.
  Encryption will also use a key shorter than expected.
  Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead 
to decryption issues.

  [Test plan]
  On Focal, run the following and copy the output to your clipboard

  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do  echo "Test with ${cipher}" 
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
  tar c pouet.bf-* | xz | base64 -w 60

  You can also run this on Lunar or Mantic if you add "-provider legacy
  -provider default" to the "openssl enc" invocation.

  On Jammy, run the following and paste your clipboard

  base64 -d | xz -d | tar x
  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider 
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}"; 
done

  Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
  decrypted: the other two will result in garbage on screen.

  Here is the result of the enc + tar + xz + base64 on Focal (works with
  Lunar/Mantic too but you need to added ):

  /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
  8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
  hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
  m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
  D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
  ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
  GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
  AoBQAACjzq5WscRn+wIABFla

  Here is the same but from Jammy if you want to test encryption on
  Jammy and decryption on Lunar/Mantic:

  /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
  8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
  HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
  jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
  2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
  k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
  /5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
  1AABrQKAUAAABh3ynbHEZ/sCAARZWg==

  The contents are expected to be different due to the use of
  randomness. Don't try to compare the base64 outputs: I'm only using
  them to ease testing across containers.

  [Where problems could occur]
  This patch makes openssl match the documented default (see "man openssl-enc" 
and search for "Blowfish" for instance) and fixes decryption from an up-to-date 
Jammy to pretty much everything else, but it also create an issue for data 
encrypted on Jammy without this patch and Jammy with this patch.

  There are two possible cases: encrypted data being streamed across
  this boundary or data at rest being transferred or read later.

  Streaming is probably not an issue in practice because it's rather the
  current situation that has been an issue and it's easy to remedy by
  updating everything (which is relatively few machines since that's
  only Jammy and not any other OS or distribution).

  Data at rest is more annoying since updating Jammy will make it
  impossible to read the data again without updates to other pieces of
  software. That sounds like a really bad thing and it kind of is but at
  the same, the benefits are much larger than the issues. Indeed, there
  is already an incompatibility at the moment between Jammy and
  everything else and the more time passes by, the more such problematic
  files can be created. Luckily very few people are using blowfish
  nowadays and it's not even enabled by default anymore 

[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

[Simon Chopin]

In addition, could the test plan maybe be edited to answer the following
question?

"How can one validate that the package in -proposed addresses the
issue?"

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

Title:
  openssl: backport to jammy "clear method store / query cache
  confusion"

Status in openssl package in Ubuntu:
  New
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [ATTENTION]
  This SRU contains FOUR changes which are listed in the section below.

  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  This ( #2033422 ) is the "central" bug with the global information and 
debdiff.

  This SRU addresses four issues with Jammy's openssl version:
  - http://pad.lv/1990216: Blowfish OFB/CFB decryption
  - http://pad.lv/1994165: ignored SMIME signature errors
  - http://pad.lv/2023545: imbca engine dumps core
  - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections

  The SRU information has been added to the four bug reports and I am
  attaching the debdiff here only for all four.

  All the patches have been included in subsequent openssl 3.0.x
  releases which in turn have been included in subsequent Ubuntu
  releases. There has been no report of issues when updating to these
  Ubuntu releases.

  I have rebuilt the openssl versions and used abi-compliance-checker to
  compare the ABIs of the libraries in jammy and the one for the SRU.
  Both matched completely (FYI, mantic's matched completely too).

  The patch related to blowfish presents an annoying situation: jammy's openssl 
creates incompatible files and cannot read other files but fixing it will lead 
to files created on jammy so far to become unreadable. Fortunately, blowfish is 
long-deprecated and applications can be improved to handle this situation if 
the need arises in practice.
  This is stated in the SRU information in the bug and in d/changelog.
  The current situation in Jammy could be a security issue but due to the 
aforementioned deprecation, the low usage of blowfish and the fact that 
upstream didn't consider this worthy of a security notice, we (this includes 
the security team) chose not to pursue that path either.

  I have also pushed the code to git (without any attempt to make it
  git-ubuntu friendly).

  
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
  sru

  I asked Brian Murray about phasing speed and he concurs a slow roll-out is 
probably better for openssl. There is a small uncertainty because a security 
update could come before the phasing is over, effectively fast-forwarding the 
SRU. Still, unless there is already a current pre-advisory, this is probably 
better than a 10% phasing which is over after only a couple days anyway.
  NB: at the moment openssl doesn't phase slowly so this needs to be 
implemented.

  [Impact]
  Severely degraded performance for concurrent operations compared to openssl 
1.1. The performance is so degraded that some workloads fail due to timeouts or 
insufficient resources (noone magically has 5 times more machines). As a 
consequence, a number of people use openssl 1.1 instead and do not get security 
updates.

  [Test plan]
  Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
 .
  Using this, I get the following numbers on my laptop:

  3.0.2:
  real  2m5.567s
  user  4m3.948s
  sys   2m0.233s

  this SRU:
  real  0m23.966s
  user  2m35.687s
  sys   0m1.920s

  As can be easily seen, the speed-up is massive: system time is divided
  by 60 and overall wall clock time is roughly five times lower.

  In http://pad.lv/2009544 , Rafael also shared his performance numbers
  and they are relatable to these. He used slightly different versions
  (upstreams rather than patched with cherry-picks) but at least one of
  the version used does not include other performance change. He also
  used different hardware and this performance issue seems to depend on
  the number of CPUs available but also obtained a performance several
  times better. Results on a given machine vary also very little across
  runs (less than 2% variation on runs of size 10). They are also very
  similar on a Raspberry Pi 4 (8GB).

  The benchmark uses https://www.google.com/humans.txt which takes
  around 130ms to download on my machine but I modified the script to
  download something only 20ms away. Results are so close to the ones
  using humans.txt that they are within the error margin. This is
  consistent with the high-concurrency in the benchmark which both
  saturates CPU, and "hides" latencies that are relatively low.

  Finally, there are posi

[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

[Simon Chopin]

A version containing a fix for this has been uploaded to the Jammy queue
to be processed by the SRU team. Thanks, Adrien :)

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

Title:
  openssl: backport to jammy "clear method store / query cache
  confusion"

Status in openssl package in Ubuntu:
  New
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [ATTENTION]
  This SRU contains FOUR changes which are listed in the section below.

  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  This ( #2033422 ) is the "central" bug with the global information and 
debdiff.

  This SRU addresses four issues with Jammy's openssl version:
  - http://pad.lv/1994165: ignored SMIME signature errors
  - http://pad.lv/2023545: imbca engine dumps core
  - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections

  The SRU information has been added to the four bug reports and I am
  attaching the debdiff here only for all four.

  All the patches have been included in subsequent openssl 3.0.x
  releases which in turn have been included in subsequent Ubuntu
  releases. There has been no report of issues when updating to these
  Ubuntu releases.

  I have rebuilt the openssl versions and used abi-compliance-checker to
  compare the ABIs of the libraries in jammy and the one for the SRU.
  Both matched completely (FYI, mantic's matched completely too).

  I have also pushed the code to git (without any attempt to make it
  git-ubuntu friendly).

  
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
  sru

  I asked Brian Murray about phasing speed and he concurs a slow roll-out is 
probably better for openssl. There is a small uncertainty because a security 
update could come before the phasing is over, effectively fast-forwarding the 
SRU. Still, unless there is already a current pre-advisory, this is probably 
better than a 10% phasing which is over after only a couple days anyway.
  NB: at the moment openssl doesn't phase slowly so this needs to be 
implemented.

  [Impact]
  Severely degraded performance for concurrent operations compared to openssl 
1.1. The performance is so degraded that some workloads fail due to timeouts or 
insufficient resources (noone magically has 5 times more machines). As a 
consequence, a number of people use openssl 1.1 instead and do not get security 
updates.

  [Test plan]
  Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
 .

  To test, follow these steps:
  - run "time python3 main.py" # using the aforementioned main.py script
  - apt install -t jammy-proposed libssl3
  - run "time python3 main.py"
  - compare the runtimes for the two main.py runs

  You can run this on x86_64, Raspberry Pi 4 or any machine, and get a
  very large speed-up in all cases. The improvements are not
  architecture-dependant.

  Using this changeset, I get the following numbers for ten runs on my
  laptop:

  3.0.2:
  real  2m5.567s
  user  4m3.948s
  sys   2m0.233s

  this SRU:
  real  0m23.966s
  user  2m35.687s
  sys   0m1.920s

  As can be easily seen, the speed-up is massive: system time is divided
  by 60 and overall wall clock time is roughly five times lower.

  In http://pad.lv/2009544 , Rafael also shared his performance numbers
  and they are relatable to these. He used slightly different versions
  (upstreams rather than patched with cherry-picks) but at least one of
  the version used does not include other performance change. He also
  used different hardware and this performance issue seems to depend on
  the number of CPUs available but also obtained a performance several
  times better. Results on a given machine vary also very little across
  runs (less than 2% variation on runs of size 10). They are also very
  similar on a Raspberry Pi 4 (8GB).

  The benchmark uses https://www.google.com/humans.txt which takes
  around 130ms to download on my machine but I modified the script to
  download something only 20ms away. Results are so close to the ones
  using humans.txt that they are within the error margin. This is
  consistent with the high-concurrency in the benchmark which both
  saturates CPU, and "hides" latencies that are relatively low.

  Finally, there are positive reports on github. Unfortunately they are
  not always completely targeted at these patches only and therefore I
  will not link directly to them but they have also been encouraging.

  [Where problems could occur]
  The change is spread over several patches which touch the internals of 
openssl. As such, the engine and provider functionality could be broken by 
these chan

[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate

[Simon Chopin]

A version containing a fix for this has been uploaded to the Jammy queue
to be processed by the SRU team. Thanks, Adrien :)

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

Title:
  [UBUNTU 22.04] openssl with ibmca engine configured dumps core when
  creating a new certificate

Status in Ubuntu on IBM z Systems:
  In Progress
Status in openssl package in Ubuntu:
  In Progress
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  Openssl using an engine dumps core upon certificate creation; other 
operations are probably affected too. Overall, engines are likely mostly 
unusable.

  [Test plan]
  An engine is needed to test the fix and I don't think we have many in the 
archive. This complicates reproducing the issue. I have been relying on user 
reports which have been very detailled and helpful.
  The issue has also been reported independently and with another engine 
(devcrypto).
  The issue is fixed in openssl 3.0.8 which landed in lunar.

  [Where problems could occur]
  I don't pretend to understand the lifecycle of providers in openssl3 but the 
patch is simple and has been widely tested by now, including on ubuntu. Thus, I 
see little chance an unexpected problem would occur with it.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/issues/18578

  *
  
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-
  sru-0001-Release-the-drbg-in-the-global-default-context-
  befor.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem
  -keyout __key.pem --subj '/CN=US'

  ---Problem Description---
  OpenSSL with ibmca engine configured dumps core when creating a new 
certificate.

  # openssl engine
  (dynamic) Dynamic engine loading support
  (ibmca) Ibmca hardware engine support
  # openssl req  -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem 
-keyout __key.pem --subj '/CN=US'
  Segmentation fault (core dumped)

  # journalctl
  Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b 
ilc:2 in libc.so.6[3ffae08+1ca000]
  Jun 07 13:06:08 SYSTEM kernel: Failing address:  TEID: 
0800
  Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user 
ASCE.
  Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024
  Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded 
Not tainted 5.15.0-73-generic #80-Ubuntu
  Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0)
  Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708
  Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 
AS:0 CC:0 PM:0 RI:0 EA:3
  Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 
 02aa3289f9d0
  Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 
 02aa328a4300
  Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 
02aa03ff 
  Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 
03ffae437c22 03ffec2fe000
  Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2  
  lgr%r11,%r2
    03ffae11c700: 
4700bc0,0
   #03ffae11c704: 
b24f00a0ear%r10,%a0
   >03ffae11c708: 
58102018l%r1,24(%r2)
    03ffae11c70c: 
ebaa002dsllg%r10,%r10,32
    03ffae11c712: 
b24f00a1ear%r10,%a1
    03ffae11c716: 
5910a0d0c%r1,208(%r10)
    03ffae11c71a: 
a7840033brc8,03ffae11c780
  Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address:
  Jun 07 13:06:08 SYSTEM kernel:  [<03ffae33242c>] 0x3ffae33242c
  Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0).
  Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 
0 dumped core.

   

[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result

[Simon Chopin]

A version containing a fix for this has been uploaded to the Jammy queue
to be processed by the SRU team. Thanks, Adrien :)

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

Title:
  CMS_final: do not ignore CMS_dataFinal result

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Kinetic:
  Won't Fix
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  S/MIME signature can fail silently
  The commit by upstream propagates the return code of some functions rather 
than ignore it.

  [Test plan]
  This issue is not very simple to reproduce because "openssl cms" cannot be 
used to do so. This has to be done with the openssl API instead.
  At least the bug reportere here and the one on openssl's bug tracker have 
confirmed the patch solves the issue. Additionally, the bug reporter here has 
tested the PPA that contains the patche and validated it. Finally, I read 
through the patch attentively.

  [Where problems could occur]
  At this point it is unlikely an error would appear. The openssl bug tracker 
mentions nothing related to this patch which landed more than a year ago. The 
patch is simple and doesn't change the code logic.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/pull/18876

  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  https://github.com/openssl/openssl/pull/18876

  The CMS_dataFinal result is important as signature may fail, however, it
  is ignored while returning success from CMS_final.

  Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"

  Thanks

  Upstream commit:

  ```
  commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
  Author: Alon Bar-Lev 
  Date:   Tue Jul 26 15:17:06 2022 +0300

  Handle SMIME_crlf_copy return code

  Currently the SMIME_crlf_copy result is ignored in all usages. It does
  return failure when memory allocation fails.

  This patch handles the SMIME_crlf_copy return code in all
  occurrences.

  Signed-off-by: Alon Bar-Lev 

  Reviewed-by: Tomas Mraz 
  Reviewed-by: Paul Dale 
  Reviewed-by: Hugo Landau 
  (Merged from https://github.com/openssl/openssl/pull/18876)
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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

Re: [Touch-packages] [Bug 1962549] Re: openssl cms -decrypt doesn't work properly when using an engine

[Simon Chopin]

> I don't know why LP expired this bug since you commented after I changed
> the its status...

AFAIK, LP will not switch back the status to anything after a comment has been
left. That makes sense, as it wouldn't know what the new status is
supposed to be.

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

Title:
  openssl cms -decrypt doesn't work properly when using an engine

Status in openssl package in Ubuntu:
  New

Bug description:
  I'm using:

  bsci@ip-10-132-42-225:~/test$ lsb_release -rd
  Description:Ubuntu 20.04.3 LTS
  Release:20.04

  bsci@ip-10-132-42-225:~/test$ apt-cache policy openssl
  openssl:
Installed: 1.1.1f-1ubuntu2.10
Candidate: 1.1.1f-1ubuntu2.10
Version table:
   *** 1.1.1f-1ubuntu2.10 500
  500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
  100 /var/lib/dpkg/status
   1.1.1f-1ubuntu2.8 500
  500 http://archive.ubuntu.com/ubuntu focal-security/main amd64 
Packages
   1.1.1f-1ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

  
  I have a private EC key held in a TPM 2.0 platform hierarchy.  I'm encrypting 
a message like this:

  openssl cms -encrypt -in message.txt -out message.cipher transport.pem

  Here, transport.pem is the cert. for the EC key held in the TPM.  I'm
  attempting to decrypt like this:

  openssl cms -decrypt -in message.cipher -out /dev/stdout -inkey
  0x8181 -keyform engine -engine tpm2tss -recip transport.pem

  Instead of seeing the original message text, I'm getting the following error:
  engine "tpm2tss" set.
  Error decrypting CMS using private key
  139626757388096:error:1010107D:elliptic curve 
routines:ecdh_simple_compute_key:missing private 
key:../crypto/ec/ecdh_ossl.c:61:

  It seems that the code is expecting the actual private key instead of
  using the key held in the TPM?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1962549/+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

Re: [Touch-packages] [Bug 2041830] Re: /usr/bin/gdb:6:dump_core:internal_vproblem:internal_verror:internal_error_loc:objfile::text_section_offset

[Simon Chopin]

How about directly sending a SIGSEGV or a SIGABRT to a working
teamviewer process using kill(1) ? That's what I usually do when I test
apport crash reporting code, this might trigger the issue.

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

Title:
  
/usr/bin/gdb:6:dump_core:internal_vproblem:internal_verror:internal_error_loc:objfile::text_section_offset

Status in gdb package in Ubuntu:
  New

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
gdb.  This problem was most recently seen with package version 
14.0.50.20230907-0ubuntu1, the problem page at 
https://errors.ubuntu.com/problem/e052ff0ad61743594bf64a85ca1e18b6e353025d 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041830/+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 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set

[Simon Chopin]

Tagging this to discuss this during the Foundations weekly meeting

** Tags added: rls-ff-incoming rls-jj-incoming

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

Title:
  [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with
  zdev:early=0 set

Status in Ubuntu on IBM z Systems:
  New
Status in initramfs-tools package in Ubuntu:
  New
Status in s390-tools package in Ubuntu:
  New

Bug description:
  Versions:
  Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x
  Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x

  When I configure a zfcp LUN persistently via chzdev, the initrd is
  being rebuilt even with parameter zdev:early=0

  root@a8315003:~# chzdev -e zfcp-lun 
0.0.1803:0x500507630910d430:0x40194092 zdev:early=0
  zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured
  Note: The initial RAM-disk must be updated for these changes to take effect:
 - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092
  update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic
  I: The initramfs will attempt to resume from /dev/dasdb1
  I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698)
  I: Set the RESUME variable to override this.
  Using config file '/etc/zipl.conf'
  Building bootmap in '/boot'
  Adding IPL section 'ubuntu' (default)
  Preparing boot device: dasda (c00a).
  Done.
  root@a8315003:~#

  == Comment: - Thorsten Diehl  - 2023-03-01 
06:55:47 ==
  @BOE-dev
  This behaviour is unexpected.
  https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says:
  Activating a device early during the boot process

  Use the zdev:early device attribute to activate a device early during
  the boot process and to override any existing auto-configuration with
  a persistent device configuration.

  zdev:early=1
  The device is activated during the initial RAM disc phase according to 
the persistent configuration.

  zdev:early=0
  The device is activated as usual during the boot process. This is the 
default. If auto-configuration data is present, the device is activated during 
the initial RAM disc phase according to the auto-configuration. 

  I can't interprete a SCSI LUN as a device with auto configuration
  data. (At least, if the zfcp device hasn't NPIV enabled)

  == Comment: #5 - Peter Oberparleiter  - 
2023-03-01 11:18:28 ==
  (In reply to comment #2)
  > @BOE-dev
  > This behaviour is unexpected.
  > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says:
  > Activating a device early during the boot process
  > 
  > Use the zdev:early device attribute to activate a device early during the
  > boot process and to override any existing auto-configuration with a
  > persistent device configuration.
  > 
  > zdev:early=1
  > The device is activated during the initial RAM disc phase according to
  > the persistent configuration.
  > 
  > zdev:early=0
  > The device is activated as usual during the boot process. This is the
  > default. If auto-configuration data is present, the device is activated
  > during the initial RAM disc phase according to the auto-configuration. 

  The documentation is incorrect for Ubuntu. Canonical specifically
  builds zdev in a way that every change to persistent device
  configuration causes an update to the initial RAM-disk. See also:

  https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35
  
https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8

  > I can't interprete a SCSI LUN as a device with auto configuration data. (At
  > least, if the zfcp device hasn't NPIV enabled)

  This is related to auto-configuration as implemented for DPM.

  == Comment: #6 - Thorsten Diehl  - 2023-03-03 
12:41:44 ==
  So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which 
make the parameter zdev:early=0 ineffective. Correct?
  If you confirm, you may also close this bug.

  Not nice - then we have to find an alternate solution.

  == Comment: #7 - Peter Oberparleiter  - 
2023-03-07 06:48:07 ==
  (In reply to comment #6)
  > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which
  > make the parameter zdev:early=0 ineffective. Correct?
  > If you confirm, you may also close this bug.
  > 
  > Not nice - then we have to find an alternate solution.

  chzdev -p on Ubuntu will by default rebuild the initrd. This is intended
  behavior by Canonical and controlled by the ZDEV_ALWAYS_UPDATE_INITRD 
build-time
  switch. You can suppress it by adding option --no-root-update to the command
  line.

  Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed 
to
  have: it tells zdev not to enable that device during initrd processing,
  resulting in the corresponding udev rule not being copied to the initrd [1].

  Unfortunately there is another Ubuntu-initrd script