Re: Uploading of libjpeg-turbo 2.0.x to unstable

[Mike Gabriel]

Hi,

TL;DR; porters' help needed to fix libjpeg-turbo unit tests on sparc64  
and powerpc. Thanks!


On  Di 14 Jan 2020 08:35:34 CET, Mike Gabriel wrote:


Hi all,

(as an unregular reader of debian-devel, please Cc: me so that I  
don't miss your replies)


I have uploaded libjpeg-turbo 2.0.x to experimental several months  
ago (August 2019). I feel, it is time to get 2.0.x into  
testing/unstable now.


However, I have never really done a transition of such a core'ish  
shared library package and I'd love to receive some guidance with  
this before I do the actual upload.


First of all, I don't think that a classical transition is required  
as there has not been an SONAME change for the shared libs in  
libjpeg-turbo. Package names haven't changed, either.


Simply uploading and waiting for things to break (at runtime) is  
neither a good approach, I sense. I have done some usual smoke tests  
(running this and that desktop environment, viewing JPEG images,  
etc.), but that feels insufficient.


People experienced with transitions of core packages with libjpeg  
testings, how would you approach sanity checks of libjpeg-turbo  
2.0.x before uploading?

https://salsa.debian.org/debian/libjpeg-turbo

Thanks in advance for any kind of input,
Mike


I forgot to mention more aspects...

First of all, libjpeg-turbo has unit tests and they are being tested  
at buildtime. The packages does not have autopktests, though.


Regarding the unit tests...

The whole 2.0.x series failed on two non-official Debian archs during  
unit tests:

https://buildd.debian.org/status/package.php?p=libjpeg-turbo&suite=experimental

Tests have been failing on sparc64 [1] and powerpc [2] since the first  
2.0.x upload.


Weird FTBFS occuring since the last upload (2.0.4-1~exp1)...

The today uploaded libjpeg-turbo 2.0.4-1~exp1 upload fails on more  
architectures (arm64, armhf, so far, builds are still being  
executed/pending):


```
-- The C compiler identification is GNU 9.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- broken
CMake Error at  
/usr/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:60 (message):

  The C compiler

"/usr/bin/cc"

  is not able to compile a simple test program.

  It fails with the following output:

Change Dir: /<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/make cmTC_859bb/fast && make[2]:  
Entering directory  
'/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_859bb.dir/build.make  
CMakeFiles/cmTC_859bb.dir/build
make[3]: Entering directory  
'/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp'

Building C object CMakeFiles/cmTC_859bb.dir/testCCompiler.c.o
/usr/bin/cc   -g -O2 -fdebug-prefix-map=/<>=.  
-fstack-protector-strong -Wformat -Werror=format-security -Wall  
-pedantic -ffloat-store -Wdate-time -D_FORTIFY_SOURCE=2-o  
CMakeFiles/cmTC_859bb.dir/testCCompiler.c.o   -c  
/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp/testCCompiler.c

Linking C executable cmTC_859bb
/usr/bin/cmake -E cmake_link_script  
CMakeFiles/cmTC_859bb.dir/link.txt --verbose=1
/usr/bin/cc -g -O2 -fdebug-prefix-map=/<>=.  
-fstack-protector-strong -Wformat -Werror=format-security -Wall  
-pedantic -ffloat-store -Wdate-time -D_FORTIFY_SOURCE=2   -Wl,-z,relro  
-Wl,-z,now -Wl,--as-needed  -rdynamic  
CMakeFiles/cmTC_859bb.dir/testCCompiler.c.o  -o cmTC_859bb

collect2: fatal error: ld terminated with signal 4 [Illegal instruction]
compilation terminated.
make[3]: *** [CMakeFiles/cmTC_859bb.dir/build.make:87: cmTC_859bb] Error 1
make[3]: *** Deleting file 'cmTC_859bb'
make[3]: Leaving directory  
'/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp'

make[2]: *** [Makefile:121: cmTC_859bb/fast] Error 2
make[2]: Leaving directory  
'/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp'


```

-> this feels like an issue not related to libjpeg-turbo...

Greets,
Mike

[1] https://buildd.debian.org/status/logs.php?pkg=libjpeg-turbo&arch=sparc64
[2] https://buildd.debian.org/status/logs.php?pkg=libjpeg-turbo&arch=powerpc
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpHRIoAlMmfY.pgp
Description: Digitale PGP-Signatur

Re: Uploading of libjpeg-turbo 2.0.x to unstable

[Bas Couwenberg]

On 2020-01-14 09:00, Mike Gabriel wrote:
collect2: fatal error: ld terminated with signal 4 [Illegal 
instruction]


That's a known issue affecting more packages:

 https://bugs.debian.org/948803

Kind Regards,

Bas

Re: Uploading of libjpeg-turbo 2.0.x to unstable

[Graham Inggs]

Hi Mike

On Tue, 14 Jan 2020 at 09:44, Mike Gabriel  wrote:
> Simply uploading and waiting for things to break (at runtime) is
> neither a good approach, I sense. I have done some usual smoke tests
> (running this and that desktop environment, viewing JPEG images,
> etc.), but that feels insufficient.

Autopkgtests are now run for packages in experimental, see:
https://release.debian.org/britney/pseudo-excuses-experimental.html#libjpeg-turbo

This tells you what would break if libjpeg-turbo were uploaded to unstable.
It looks like only vtk6/vtk7 have a problem:

autopkgtest for vtk6/6.3.0+dfsg2-5: amd64: Regression
autopkgtest for vtk7/7.1.1+dfsg2-1: amd64: Regression

Regards
Graham

Re: Uploading of libjpeg-turbo 2.0.x to unstable

[Mike Gabriel]

Hi Graham,

On  Di 14 Jan 2020 08:59:59 CET, Graham Inggs wrote:


Hi Mike

On Tue, 14 Jan 2020 at 09:44, Mike Gabriel  wrote:

Simply uploading and waiting for things to break (at runtime) is
neither a good approach, I sense. I have done some usual smoke tests
(running this and that desktop environment, viewing JPEG images,
etc.), but that feels insufficient.


Autopkgtests are now run for packages in experimental, see:
https://release.debian.org/britney/pseudo-excuses-experimental.html#libjpeg-turbo


Ah, very cool. I wasn't aware of autopkgtest providing such an  
interface. Awesome!



This tells you what would break if libjpeg-turbo were uploaded to unstable.
It looks like only vtk6/vtk7 have a problem:

autopkgtest for vtk6/6.3.0+dfsg2-5: amd64: Regression


-> WARNING: package libvtk6-dev is not installed though it should be


autopkgtest for vtk7/7.1.1+dfsg2-1: amd64: Regression


-> WARNING: package libvtk7-dev is not installed though it should be

Both regressions [1,2] seem to be unrelated to libjpeg-turbo, it seems...

Mike

[1]  
https://ci.debian.net/data/autopkgtest/unstable/amd64/v/vtk6/3924854/log.gz
[2]  
https://ci.debian.net/data/autopkgtest/unstable/amd64/v/vtk7/3924855/log.gz

--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpFw_XPGpSQM.pgp
Description: Digitale PGP-Signatur

Re: Uploading of libjpeg-turbo 2.0.x to unstable

[Paul Wise]

On Tue, Jan 14, 2020 at 7:44 AM Mike Gabriel wrote:

> However, I have never really done a transition of such a core'ish
> shared library package and I'd love to receive some guidance with this
> before I do the actual upload.

You might want to use ratt (Rebuild All The Things) to determine if
any reverse build deps have their build broken by the update, and then
run autopkgtest against the rebuilt packages.

> First of all, I don't think that a classical transition is required as
> there has not been an SONAME change for the shared libs in
> libjpeg-turbo. Package names haven't changed, either.

In case you are interested in tools for detecting unplanned ABI breakage:

https://github.com/lvc/pkg-abidiff
https://sourceware.org/libabigail/manual/abipkgdiff.html
https://lists.debian.org/msgid-search/192731475679...@web2g.yandex.ru

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#948868: ITP: ocaml-fmt -- OCaml Format pretty-printer combinators

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 

* Package name: ocaml-fmt
  Version : 0.8.8
  Upstream Author : Daniel Bünzli
* URL : https://erratique.ch/software/fmt
* License : ISC
  Programming Lang: OCaml
  Description : OCaml Format pretty-printer combinators

Fmt exposes combinators to devise Format pretty-printing functions.

Fmt depends only on the OCaml standard library. The optional Fmt_tty
library that allows to setup formatters for terminal color output
depends on the Unix library.

This is a new (indirect) dependency of ocaml-ipaddr. It will be
maintained in the OCaml team.

Bug#948944: general: File Premissions broken, Group write access denied

[Travis Eddy]

Package: general
Severity: normal

Dear Maintainer,

Looks like something is broken with the file premissions.. Quick test to 
replicate the problem
Install Debian
Create 2 users
Create a folder /test
add user1 to user2's group
usermod -a -G user2 user1
make the Test folder writeable by that group
as root chown user2:user2 /test
 chmod 2775 /test

As user1 try to write in /test

user1:/test$ mkdir test2

you'll get a premission denied error, for a reason i can't figure out. I've 
tried many different
commands and goolged incase the useradd commands changed ( never know with 
linux any more )
I haven't used debian since version 8, i've been using Cent. But this should be 
a standard


-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#948944: general: File Premissions broken, Group write access denied

[Russ Allbery]

Travis Eddy  writes:

> Looks like something is broken with the file premissions.. Quick test to
> replicate the problem

> Install Debian
> Create 2 users
> Create a folder /test
> add user1 to user2's group
> usermod -a -G user2 user1
> make the Test folder writeable by that group
> as root chown user2:user2 /test
>  chmod 2775 /test

> As user1 try to write in /test

> user1:/test$ mkdir test2

> you'll get a premission denied error,

usermod doesn't change an open session.  I suspect user1 was logged on
before you ran the usermod command and you're trying the mkdir from that
open session.  Try newgrp user2 in user1's session after the usermod, or
log out and log back in to refresh your supplemental groups.

(This has always been Debian's, and indeed UNIX's, behavior so far as I
know.)

-- 
Russ Allbery (r...@debian.org)