Need advice on coordinating libkdumpfile update and introducing pykdumpfile

[Michel Lind]

Dear all,

libkdumpfile has recently released version 0.5.5, which despite the
version number, actually contains an soname bump from 0.5.4

https://github.com/ptesarik/libkdumpfile/releases/tag/v0.5.5

See e.g. the relevant Fedora packaging change
https://src.fedoraproject.org/rpms/libkdumpfile/c/c0097ea1c69462b6bb151d186ff4856663c5b7e4?branch=rawhide

The soname bump is fine in itself - I'll change the name of the binary
subpackage containing the shared library files, and the upload will need
to be done by a full Debian Developer and subject to FTP master review
(IIRC, please correct me if I'm wrong).

*But* upstream also decided to drop the legacy Python bindings right
after 0.5.5 is out, and instead recommending the separate pykdumpfile
(which they also maintain)

https://github.com/ptesarik/pykdumpfile
https://src.fedoraproject.org/rpms/python-pykdumpfile

So rather than keeping the Python bindings in 0.5.5 I figured might as
well drop the Python bindings immediately and package the new one.

This needs to be built against the correct libkdumpfile, so I'm a bit
unsure about the sequencing - in Fedora my sequence was:

- package the new libkdumpfile, make it obsolete the old Python
subpackage so upgrades work but result in the Python subpackage being
removed
- then package pykdumpfile

I could have done both in a side tag and avoided having a time where the
Python bindings are not available, but the way Python packages are
generated in Fedora, if the package name changes the virtual provides
they generate change anyway, so pykdumpfile won't be a drop in
replacement even though it ships exactly the same Python module names.

For Debian - since we already require FTP master review for the soname
bump, it seems to make even more sense to also drop the old Python
bindings and avoid requiring a re-review when 0.5.6 comes out.

The question is - is it OK to have unstable temporarily miss the Python
bindings? And should I preserve the upgrade path or let people keep the
old Python bindings? (so apt-upgrade will skip updating libkdumpfile)?

Or is there a way, say build the new libkdumpfile in experimental with
the Python bindings disabled, get the new pykdumpfile reviewed and also
built in experimental, then get them both promoted to unstable?

Thanks in advance,

[Michel Lind]

Post by Michel Lind
Dear all,
libkdumpfile has recently released version 0.5.5, which despite the
version number, actually contains an soname bump from 0.5.4
https://github.com/ptesarik/libkdumpfile/releases/tag/v0.5.5
See e.g. the relevant Fedora packaging change
https://src.fedoraproject.org/rpms/libkdumpfile/c/c0097ea1c69462b6bb151d186ff4856663c5b7e4?branch=rawhide
The soname bump is fine in itself - I'll change the name of the binary
subpackage containing the shared library files, and the upload will need
to be done by a full Debian Developer and subject to FTP master review
(IIRC, please correct me if I'm wrong).
*But* upstream also decided to drop the legacy Python bindings right
after 0.5.5 is out, and instead recommending the separate pykdumpfile
(which they also maintain)
https://github.com/ptesarik/pykdumpfile
https://src.fedoraproject.org/rpms/python-pykdumpfile
So rather than keeping the Python bindings in 0.5.5 I figured might as
well drop the Python bindings immediately and package the new one.
This needs to be built against the correct libkdumpfile, so I'm a bit
- package the new libkdumpfile, make it obsolete the old Python
subpackage so upgrades work but result in the Python subpackage being
removed
- then package pykdumpfile
I could have done both in a side tag and avoided having a time where the
Python bindings are not available, but the way Python packages are
generated in Fedora, if the package name changes the virtual provides
they generate change anyway, so pykdumpfile won't be a drop in
replacement even though it ships exactly the same Python module names.
For Debian - since we already require FTP master review for the soname
bump, it seems to make even more sense to also drop the old Python
bindings and avoid requiring a re-review when 0.5.6 comes out.
The question is - is it OK to have unstable temporarily miss the Python
bindings? And should I preserve the upgrade path or let people keep the
old Python bindings? (so apt-upgrade will skip updating libkdumpfile)?
Or is there a way, say build the new libkdumpfile in experimental with
the Python bindings disabled, get the new pykdumpfile reviewed and also
built in experimental, then get them both promoted to unstable?

That is exactly how you should do it.
- upload the new libkdumpfile with python bindings to experimental
- once it clears new, upload to unstable (beware of the transition, so maybe
request a transition slot by doing `reportbug release.debian.org')
- upload libkdumpfile again to experimental without python bindings
- upload pykdumpfile to experimental
- once pykdumpfile clears NEW, upload both to unstable

Ah, OK, so these uploads all require FTP master review right?

- soname bump to 0.5.5 in experimental
- initial upload of the new pykdumpfile in experimental
- dropping python bindings in experimental
- 0.5.5 without python in unstable (or can I as a DM do this myself?)
- pykdumpfile in unstable

If a package that's been cleared for experimental can be uploaded to
unstable without FTP master review, even if it has binary subpackage
name changes, that would simplify this quite a bit (but if it requires
re-review, that's fine too, I just have to know how much to coordinate
with the DD sponsoring the upload)

Thanks Emilio!

[Michel Lind]

Michel,

Post by Michel Lind
Ah, OK, so these uploads all require FTP master review right?
- soname bump to 0.5.5 in experimental
- initial upload of the new pykdumpfile in experimental
- dropping python bindings in experimental
- 0.5.5 without python in unstable (or can I as a DM do this myself?)
- pykdumpfile in unstable
If a package that's been cleared for experimental can be uploaded to
unstable without FTP master review, even if it has binary subpackage
name changes, that would simplify this quite a bit (but if it requires
re-review, that's fine too, I just have to know how much to coordinate
with the DD sponsoring the upload)

FTP master review is only required when the name of a binary package changes. Any
other change inside the binary package does not require their review.
Because FTP master review can take an unpredictable amount of time, usually the best
course of action in this case would be to make all such changes in experimental (because
it is OK for packages in experimental to not be coinstallable or otherwise introduce
breakage with other packages). Once everything is settled, you can upload a version of
these experimental packages that only changes the target to unstable and they will all
drop in immediately.

Ah, great, thank you!

Best regards,

[Michel Lind]

Hi all,

Post by Michel Lind

Michel,

Post by Michel Lind
Ah, OK, so these uploads all require FTP master review right?
- soname bump to 0.5.5 in experimental
- initial upload of the new pykdumpfile in experimental
- dropping python bindings in experimental
- 0.5.5 without python in unstable (or can I as a DM do this myself?)
- pykdumpfile in unstable
If a package that's been cleared for experimental can be uploaded to
unstable without FTP master review, even if it has binary subpackage
name changes, that would simplify this quite a bit (but if it requires
re-review, that's fine too, I just have to know how much to coordinate
with the DD sponsoring the upload)

FTP master review is only required when the name of a binary package changes. Any
other change inside the binary package does not require their review.
Because FTP master review can take an unpredictable amount of time, usually the best
course of action in this case would be to make all such changes in experimental (because
it is OK for packages in experimental to not be coinstallable or otherwise introduce
breakage with other packages). Once everything is settled, you can upload a version of
these experimental packages that only changes the target to unstable and they will all
drop in immediately.

Ah, great, thank you!

Thanks to everyone's feedbacks. I have uploaded this to
mentors.debian.net

https://mentors.debian.net/package/libkdumpfile/

Git repo: https://mentors.debian.net/package/libkdumpfile/

Changes requiring FTP master re-review:
- drop Python subpackage (I was initially going to do this later, but
there are already a lot of other changes - see below - that need
re-review anyway just to make the transition works)
- libkdumpfile10 -> libkdumpfile12
- stop bundling libaddrxlat.so.3 with libkdumpfile10 - it did not get a
soname bump, so having it bundled means you can't have libkdumpfile10
and libkdumpfile12 installed at the same time. Followed https://wiki.debian.org/PackageTransition
for instructions on how to split libkdumpfile10 -> libkdumpfile12
*and* libaddrxlat3
- ship out kdumpid in a new utils subpackage

After this is in experimental I'll package the new Python bindings
(pykdumpfile) and ask for that to be sponsored, then get those both into
unstable.

Thanks,

[Breno Leitao]

Hello Michel,

Post by Michel Lind
Hi all,

Post by Michel Lind

Michel,

Post by Michel Lind
Ah, OK, so these uploads all require FTP master review right?
- soname bump to 0.5.5 in experimental
- initial upload of the new pykdumpfile in experimental
- dropping python bindings in experimental
- 0.5.5 without python in unstable (or can I as a DM do this myself?)
- pykdumpfile in unstable
If a package that's been cleared for experimental can be uploaded to
unstable without FTP master review, even if it has binary subpackage
name changes, that would simplify this quite a bit (but if it requires
re-review, that's fine too, I just have to know how much to coordinate
with the DD sponsoring the upload)

FTP master review is only required when the name of a binary package changes. Any
other change inside the binary package does not require their review.
Because FTP master review can take an unpredictable amount of time, usually the best
course of action in this case would be to make all such changes in experimental (because
it is OK for packages in experimental to not be coinstallable or otherwise introduce
breakage with other packages). Once everything is settled, you can upload a version of
these experimental packages that only changes the target to unstable and they will all
drop in immediately.

Ah, great, thank you!

Thanks to everyone's feedbacks. I have uploaded this to
mentors.debian.net
https://mentors.debian.net/package/libkdumpfile/

I had a look at the package above, but I got the following message when
build. After the test passes, it shows:

dh_missing: error: missing files, aborting

Have you seen anything similar?

Here is the rest of the log, afte the tests passed.

============================================================================
Testsuite summary for libkdumpfile 0.5.5
============================================================================
# TOTAL: 209
# PASS: 209
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
make[4]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tests'
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tests'
make[2]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tests'
Making check in tools
make[2]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/tools'
Making check in kdumpid
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/tools/kdumpid'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tools/kdumpid'
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/tools'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tools'
make[2]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tools'
Making check in examples
make[2]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/examples'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/examples'
Making check in python
make[2]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/python'
/usr/bin/python ./setup.py build
make _test_addrxlat.la \
test_addrxlat.py
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/python'
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/python3.11 -I/usr/include/python3.11 -Wsign-compare -g -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -DNDEBUG -g -fwrapv -O2 -Wall -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/leitao/source/libkdumpfile-0.5.5=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c -o test_addrxlat.lo test_addrxlat.c
make[3]: Nothing to be done for 'test_addrxlat.py'.
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/python3.11 -I/usr/include/python3.11 -Wsign-compare -g -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -DNDEBUG -g -fwrapv -O2 -Wall -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/leitao/source/libkdumpfile-0.5.5=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c test_addrxlat.c -fPIC -DPIC -o .libs/test_addrxlat.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/python3.11 -I/usr/include/python3.11 -Wsign-compare -g -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -DNDEBUG -g -fwrapv -O2 -Wall -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/leitao/source/libkdumpfile-0.5.5=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c test_addrxlat.c -o test_addrxlat.o >/dev/null 2>&1
/bin/bash ../libtool --tag=CC --mode=link gcc -I/usr/include/python3.11 -I/usr/include/python3.11 -Wsign-compare -g -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -DNDEBUG -g -fwrapv -O2 -Wall -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/leitao/source/libkdumpfile-0.5.5=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -module -avoid-version -export-symbols ./test_addrxlat.sym -rpath /home/leitao/source/libkdumpfile-0.5.5/python -Wl,-z,relro -Wl,-z,now -o _test_addrxlat.la test_addrxlat.lo -ldl -lm ../src/addrxlat/libaddrxlat.la
libtool: link: echo "{ global:" > .libs/_test_addrxlat.ver
libtool: link: cat ./test_addrxlat.sym | /usr/bin/sed -e "s/\(.*\)/\1;/" >> .libs/_test_addrxlat.ver
libtool: link: echo "local: *; };" >> .libs/_test_addrxlat.ver
libtool: link: gcc -shared -fPIC -DPIC .libs/test_addrxlat.o -Wl,-rpath -Wl,/home/leitao/source/libkdumpfile-0.5.5/src/addrxlat/.libs -ldl -lm ../src/addrxlat/.libs/libaddrxlat.so -g -fstack-protector-strong -g -O2 -g -O2 -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-soname -Wl,_test_addrxlat.so -Wl,-version-script -Wl,.libs/_test_addrxlat.ver -o .libs/_test_addrxlat.so
libtool: link: ar cr .libs/_test_addrxlat.a test_addrxlat.o
libtool: link: ranlib .libs/_test_addrxlat.a
libtool: link: ( cd ".libs" && rm -f "_test_addrxlat.la" && ln -s "../_test_addrxlat.la" "_test_addrxlat.la" )
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/python'
make check-TESTS
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/python'
make[4]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/python'
PASS: test_addrxlat.py
============================================================================
Testsuite summary for libkdumpfile 0.5.5
============================================================================
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
make[4]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/python'
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/python'
make[2]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/python'
make[2]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5'
make[2]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5'
make[1]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5'
create-stamp debian/debhelper-build-stamp
dh_prep
dh_installdirs
dh_auto_install
make -j1 install DESTDIR=/home/leitao/source/libkdumpfile-0.5.5/debian/tmp AM_UPDATE_INFO_DIR=no
make[1]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5'
Making install in include
make[2]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/include'
Making install in libkdumpfile
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/include/libkdumpfile'
make[4]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/include/libkdumpfile'
make[4]: Nothing to be done for 'install-exec-am'.
/usr/bin/mkdir -p '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/include/libkdumpfile'
/usr/bin/install -c -m 644 addrxlat.h kdumpfile.h '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/include/libkdumpfile'
make[4]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/include/libkdumpfile'
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/include/libkdumpfile'
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/include'
make[4]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/include'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/include'
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/include'
make[2]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/include'
Making install in src
make[2]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/src'
Making install in addrxlat
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/src/addrxlat'
make[4]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/src/addrxlat'
/usr/bin/mkdir -p '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu'
/bin/bash ../../libtool --mode=install /usr/bin/install -c libaddrxlat.la '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu'
libtool: install: /usr/bin/install -c .libs/libaddrxlat.so.3.1.4 /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu/libaddrxlat.so.3.1.4
libtool: install: (cd /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu && { ln -s -f libaddrxlat.so.3.1.4 libaddrxlat.so.3 || { rm -f libaddrxlat.so.3 && ln -s libaddrxlat.so.3.1.4 libaddrxlat.so.3; }; })
libtool: install: (cd /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu && { ln -s -f libaddrxlat.so.3.1.4 libaddrxlat.so || { rm -f libaddrxlat.so && ln -s libaddrxlat.so.3.1.4 libaddrxlat.so; }; })
libtool: install: /usr/bin/install -c .libs/libaddrxlat.lai /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu/libaddrxlat.la
libtool: install: /usr/bin/install -c .libs/libaddrxlat.a /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu/libaddrxlat.a
libtool: install: chmod 644 /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu/libaddrxlat.a
libtool: install: ranlib /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu/libaddrxlat.a
libtool: warning: remember to run 'libtool --finish /usr/lib/x86_64-linux-gnu'
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/src/addrxlat'
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/src/addrxlat'
Making install in kdumpfile
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/src/kdumpfile'
make[4]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/src/kdumpfile'
/usr/bin/mkdir -p '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu'
/bin/bash ../../libtool --mode=install /usr/bin/install -c libkdumpfile.la '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu'
libtool: warning: relinking 'libkdumpfile.la'
libtool: install: (cd /home/leitao/source/libkdumpfile-0.5.5/src/kdumpfile; /bin/bash "/home/leitao/source/libkdumpfile-0.5.5/libtool" --tag CC --mode=relink gcc -fvisibility=hidden -I/usr/include/lzo -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/leitao/source/libkdumpfile-0.5.5=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -version-info 12:0:0 -Wl,--version-script=./libkdumpfile.map -Wl,-z,relro -Wl,-z,now -o libkdumpfile.la -rpath /usr/lib/x86_64-linux-gnu aarch64.lo arm.lo attr.lo bitmap.lo blob.lo cache.lo context.lo devmem.lo diskdump.lo elfdump.lo fcache.lo flatmap.lo ia32.lo lkcd.lo notes.lo open.lo pfn.lo read.lo riscv64.lo sadump.lo s390x.lo s390dump.lo todo.lo util.lo vmcoreinfo.lo vtop.lo ppc64.lo x86_64.lo ../../src/addrxlat/libaddrxlat.la -lz -llzo2 -lsnappy -lzstd -inst-prefix-dir /home/leitao/source/libkdumpfile-0.5.5/debian/tmp)
libtool: relink: gcc -shared -fPIC -DPIC .libs/aarch64.o .libs/arm.o .libs/attr.o .libs/bitmap.o .libs/blob.o .libs/cache.o .libs/context.o .libs/devmem.o .libs/diskdump.o .libs/elfdump.o .libs/fcache.o .libs/flatmap.o .libs/ia32.o .libs/lkcd.o .libs/notes.o .libs/open.o .libs/pfn.o .libs/read.o .libs/riscv64.o .libs/sadump.o .libs/s390x.o .libs/s390dump.o .libs/todo.o .libs/util.o .libs/vmcoreinfo.o .libs/vtop.o .libs/ppc64.o .libs/x86_64.o -L/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu -laddrxlat -lz -llzo2 -lsnappy -lzstd -g -O2 -fstack-protector-strong -Wl,--version-script=./libkdumpfile.map -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-soname -Wl,libkdumpfile.so.12 -o .libs/libkdumpfile.so.12.0.0
libtool: install: /usr/bin/install -c .libs/libkdumpfile.so.12.0.0T /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu/libkdumpfile.so.12.0.0
libtool: install: (cd /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu && { ln -s -f libkdumpfile.so.12.0.0 libkdumpfile.so.12 || { rm -f libkdumpfile.so.12 && ln -s libkdumpfile.so.12.0.0 libkdumpfile.so.12; }; })
libtool: install: (cd /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu && { ln -s -f libkdumpfile.so.12.0.0 libkdumpfile.so || { rm -f libkdumpfile.so && ln -s libkdumpfile.so.12.0.0 libkdumpfile.so; }; })
libtool: install: /usr/bin/install -c .libs/libkdumpfile.lai /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu/libkdumpfile.la
libtool: install: /usr/bin/install -c .libs/libkdumpfile.a /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu/libkdumpfile.a
libtool: install: chmod 644 /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu/libkdumpfile.a
libtool: install: ranlib /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu/libkdumpfile.a
libtool: warning: remember to run 'libtool --finish /usr/lib/x86_64-linux-gnu'
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/src/kdumpfile'
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/src/kdumpfile'
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/src'
make[4]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/src'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/src'
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/src'
make[2]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/src'
Making install in tests
make[2]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/tests'
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/tests'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tests'
make[2]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tests'
Making install in tools
make[2]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/tools'
Making install in kdumpid
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/tools/kdumpid'
make[4]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/tools/kdumpid'
/usr/bin/mkdir -p '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/bin'
/bin/bash ../../libtool --mode=install /usr/bin/install -c kdumpid '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/bin'
libtool: warning: '../../src/kdumpfile/libkdumpfile.la' has not been installed in '/usr/lib/x86_64-linux-gnu'
libtool: warning: '../../src/addrxlat/libaddrxlat.la' has not been installed in '/usr/lib/x86_64-linux-gnu'
libtool: install: /usr/bin/install -c .libs/kdumpid /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/bin/kdumpid
/usr/bin/mkdir -p '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/share/man/man1'
/usr/bin/install -c -m 644 kdumpid.1 '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/share/man/man1'
make[4]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tools/kdumpid'
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tools/kdumpid'
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/tools'
make[4]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/tools'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tools'
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tools'
make[2]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/tools'
Making install in examples
make[2]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/examples'
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/examples'
/usr/bin/mkdir -p '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/bin'
/bin/bash ../libtool --mode=install /usr/bin/install -c dumpattr listxendoms showxlat '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/bin'
libtool: warning: '../src/kdumpfile/libkdumpfile.la' has not been installed in '/usr/lib/x86_64-linux-gnu'
libtool: warning: '../src/addrxlat/libaddrxlat.la' has not been installed in '/usr/lib/x86_64-linux-gnu'
libtool: install: /usr/bin/install -c .libs/dumpattr /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/bin/dumpattr
libtool: warning: '../src/kdumpfile/libkdumpfile.la' has not been installed in '/usr/lib/x86_64-linux-gnu'
libtool: warning: '../src/addrxlat/libaddrxlat.la' has not been installed in '/usr/lib/x86_64-linux-gnu'
libtool: install: /usr/bin/install -c .libs/listxendoms /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/bin/listxendoms
libtool: warning: '../src/kdumpfile/libkdumpfile.la' has not been installed in '/usr/lib/x86_64-linux-gnu'
libtool: warning: '../src/addrxlat/libaddrxlat.la' has not been installed in '/usr/lib/x86_64-linux-gnu'
libtool: install: /usr/bin/install -c .libs/showxlat /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/bin/showxlat
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/examples'
make[2]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/examples'
Making install in python
make[2]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/python'
/usr/bin/python ./setup.py build
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5/python'
/usr/bin/python ./setup.py install \
--root "/home/leitao/source/libkdumpfile-0.5.5/debian/tmp"/ \
--install-purelib /usr/lib/python3.11/site-packages \
--install-platlib /usr/lib/python3.11/site-packages \
--record installed.list
/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py:66: SetuptoolsDeprecationWarning: setup.py install is deprecated.
!!

********************************************************************************
Please avoid running ``setup.py`` directly.
Instead, use pypa/build, pypa/installer or other
standards-based tools.

See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html for details.
********************************************************************************

!!
self.initialize_options()
libtool: warning: relinking 'build/lib.linux-x86_64-cpython-311/_addrxlat.cpython-311-x86_64-linux-gnu.la'
libtool: install: (cd /home/leitao/source/libkdumpfile-0.5.5/python; /bin/bash "/home/leitao/source/libkdumpfile-0.5.5/libtool" --mode=relink x86_64-linux-gnu-gcc -module -avoid-version -export-symbols-regex "init.*|PyInit_.*" -rpath /usr/lib/python3.11/site-packages -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/leitao/source/libkdumpfile-0.5.5=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-cpython-311/./addrxlat.lo ../src/addrxlat/libaddrxlat.la -L/usr/lib/x86_64-linux-gnu -o build/lib.linux-x86_64-cpython-311/_addrxlat.cpython-311-x86_64-linux-gnu.la -inst-prefix-dir /home/leitao/source/libkdumpfile-0.5.5/debian/tmp)
libtool: relink: /usr/bin/nm -B build/temp.linux-x86_64-cpython-311/./.libs/addrxlat.o | /usr/bin/sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | /usr/bin/sed '/ __gnu_lto/d' | /usr/bin/sed 's/.* //' | sort | uniq > build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.exp
libtool: relink: /usr/bin/grep -E -e "init.*|PyInit_.*" "build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.exp" > "build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.expT"
libtool: relink: mv -f "build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.expT" "build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.exp"
libtool: relink: echo "{ global:" > build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.ver
libtool: relink: cat build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.exp | /usr/bin/sed -e "s/\(.*\)/\1;/" >> build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.ver
libtool: relink: echo "local: *; };" >> build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.ver
libtool: relink: gcc -shared -fPIC -DPIC build/temp.linux-x86_64-cpython-311/./.libs/addrxlat.o -L/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu -laddrxlat -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z -Wl,relro -Wl,-z -Wl,now -g -O2 -fstack-protector-strong -Wl,-soname -Wl,_addrxlat.cpython-311-x86_64-linux-gnu.so -Wl,-version-script -Wl,build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.ver -o build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.so
libtool: install: /usr/bin/install -c build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.soT /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/python3.11/site-packages/_addrxlat.cpython-311-x86_64-linux-gnu.so
libtool: install: /usr/bin/install -c build/lib.linux-x86_64-cpython-311/.libs/_addrxlat.cpython-311-x86_64-linux-gnu.lai /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/python3.11/site-packages/_addrxlat.cpython-311-x86_64-linux-gnu.la
libtool: warning: remember to run 'libtool --finish /usr/lib/python3.11/site-packages'
libtool: warning: relinking 'build/lib.linux-x86_64-cpython-311/_kdumpfile.cpython-311-x86_64-linux-gnu.la'
libtool: install: (cd /home/leitao/source/libkdumpfile-0.5.5/python; /bin/bash "/home/leitao/source/libkdumpfile-0.5.5/libtool" --mode=relink x86_64-linux-gnu-gcc -module -avoid-version -export-symbols-regex "init.*|PyInit_.*" -rpath /usr/lib/python3.11/site-packages -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/leitao/source/libkdumpfile-0.5.5=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-cpython-311/./kdumpfile.lo ../src/kdumpfile/libkdumpfile.la -L/usr/lib/x86_64-linux-gnu -o build/lib.linux-x86_64-cpython-311/_kdumpfile.cpython-311-x86_64-linux-gnu.la -inst-prefix-dir /home/leitao/source/libkdumpfile-0.5.5/debian/tmp)
libtool: relink: /usr/bin/nm -B build/temp.linux-x86_64-cpython-311/./.libs/kdumpfile.o | /usr/bin/sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | /usr/bin/sed '/ __gnu_lto/d' | /usr/bin/sed 's/.* //' | sort | uniq > build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.exp
libtool: relink: /usr/bin/grep -E -e "init.*|PyInit_.*" "build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.exp" > "build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.expT"
libtool: relink: mv -f "build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.expT" "build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.exp"
libtool: relink: echo "{ global:" > build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.ver
libtool: relink: cat build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.exp | /usr/bin/sed -e "s/\(.*\)/\1;/" >> build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.ver
libtool: relink: echo "local: *; };" >> build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.ver
libtool: relink: gcc -shared -fPIC -DPIC build/temp.linux-x86_64-cpython-311/./.libs/kdumpfile.o -L/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu -lkdumpfile -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z -Wl,relro -Wl,-z -Wl,now -g -O2 -fstack-protector-strong -Wl,-soname -Wl,_kdumpfile.cpython-311-x86_64-linux-gnu.so -Wl,-version-script -Wl,build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.ver -o build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.so
libtool: install: /usr/bin/install -c build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.soT /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/python3.11/site-packages/_kdumpfile.cpython-311-x86_64-linux-gnu.so
libtool: install: /usr/bin/install -c build/lib.linux-x86_64-cpython-311/.libs/_kdumpfile.cpython-311-x86_64-linux-gnu.lai /home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/python3.11/site-packages/_kdumpfile.cpython-311-x86_64-linux-gnu.la
libtool: warning: remember to run 'libtool --finish /usr/lib/python3.11/site-packages'
[03/09/25 19:26:22] ERROR listing git files failed - pretending git.py:24
there aren't any
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/python'
make[2]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5/python'
make[2]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5'
make[3]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5'
make[3]: Nothing to be done for 'install-exec-am'.
/usr/bin/mkdir -p '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig'
/usr/bin/install -c -m 644 libaddrxlat.pc libkdumpfile.pc '/home/leitao/source/libkdumpfile-0.5.5/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig'
make[3]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5'
make[2]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5'
make[1]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5'
dh_install
debian/rules execute_after_dh_install
make[1]: Entering directory '/home/leitao/source/libkdumpfile-0.5.5'
# remove examples. While we want to make sure they compile,
# the binaries should not be shipped
# list individually so we don't accidentally remove an actual
# binary in the future
rm debian/tmp/usr/bin/dumpattr
rm debian/tmp/usr/bin/listxendoms
rm debian/tmp/usr/bin/showxlat
# we can't just pass `--disable-static` to dh_auto_configure
# as those are needed to compile tests
rm debian/tmp/usr/lib/*/lib*.a
rm debian/tmp/usr/lib/*/lib*.la
make[1]: Leaving directory '/home/leitao/source/libkdumpfile-0.5.5'
dh_installdocs
dh_installchangelogs
dh_installexamples
dh_installman
dh_perl
dh_link
dh_strip_nondeterminism
dh_compress
dh_fixperms
dh_missing
dh_missing: warning: usr/lib/python3.11/site-packages/_addrxlat.cpython-311-x86_64-linux-gnu.la exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/_addrxlat.cpython-311-x86_64-linux-gnu.so exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/_kdumpfile.cpython-311-x86_64-linux-gnu.la exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/_kdumpfile.cpython-311-x86_64-linux-gnu.so exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/addrxlat/__init__.py exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/addrxlat/__pycache__/__init__.cpython-311.pyc exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/addrxlat/__pycache__/exceptions.cpython-311.pyc exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/addrxlat/exceptions.py exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/kdumpfile/__init__.py exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/kdumpfile/__pycache__/__init__.cpython-311.pyc exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/kdumpfile/__pycache__/exceptions.cpython-311.pyc exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/kdumpfile/__pycache__/views.cpython-311.pyc exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/kdumpfile/exceptions.py exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/kdumpfile/views.py exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/libkdumpfile-0.5.5.egg-info/PKG-INFO exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/libkdumpfile-0.5.5.egg-info/SOURCES.txt exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/libkdumpfile-0.5.5.egg-info/dependency_links.txt exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/python3.11/site-packages/libkdumpfile-0.5.5.egg-info/top_level.txt exists in debian/tmp but is not installed to anywhere
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed (with files per package)
* dh_install: libaddrxlat3 (2), libkdumpfile-dev (5), libkdumpfile-doc (0), libkdumpfile-utils (2), libkdumpfile12 (2)
* dh_installdocs: libaddrxlat3 (0), libkdumpfile-dev (0), libkdumpfile-doc (1), libkdumpfile-utils (0), libkdumpfile12 (1)
* dh_installexamples: libaddrxlat3 (0), libkdumpfile-dev (3), libkdumpfile-doc (0), libkdumpfile-utils (0), libkdumpfile12 (0)
* dh_installman: libaddrxlat3 (0), libkdumpfile-dev (0), libkdumpfile-doc (0), libkdumpfile-utils (0), libkdumpfile12 (0)
If the missing files are installed by another tool, please file a bug against it.
When filing the report, if the tool is not part of debhelper itself, please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+).
(in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.md.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built
If the omission is intentional or no other helper can take care of this consider adding the
paths to debian/not-installed.

Remember to be careful with paths containing "x86_64-linux-gnu", where you might need to
use a wildcard or (assuming compat 13+) e.g. ${DEB_HOST_MULTIARCH} in debian/not-installed
to ensure it works on all architectures (see #961104).
make: *** [debian/rules:6: binary] Error 255
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
debuild: fatal error at line 1184:
dpkg-buildpackage -us -uc -ui failed

[Matthias Urlichs]

It should not fail in sbuilder or pbuilder, but just in case I can explicitly disable Python bindings from being built so it’s easier to do a test build

Please do. Packages shouldn't build differently (or not at all)
depending on whether some random not-mentioned-in-d-control package is
installed.

Policy doesn't seem to explicitly state that (I just took an
admittedly-cursory look), but maybe it should.

--
-- regards
--
-- Matthias Urlichs

[Breno Leitao]

Hello Michel,

Hi Breno,

Post by Breno Leitao
Hello Michel,

Post by Michel Lind
Hi all,

Post by Michel Lind

Michel,

Post by Michel Lind
Ah, OK, so these uploads all require FTP master review right?
- soname bump to 0.5.5 in experimental
- initial upload of the new pykdumpfile in experimental
- dropping python bindings in experimental
- 0.5.5 without python in unstable (or can I as a DM do
this myself?)
- pykdumpfile in unstable
If a package that's been cleared for experimental can be
uploaded to
unstable without FTP master review, even if it has binary
subpackage
name changes, that would simplify this quite a bit (but if
it requires
re-review, that's fine too, I just have to know how much to
coordinate
with the DD sponsoring the upload)

FTP master review is only required when the name of a binary
package changes.  Any
other change inside the binary package does not require their review.
Because FTP master review can take an unpredictable amount of
time, usually the best
course of action in this case would be to make all such
changes in experimental (because
it is OK for packages in experimental to not be coinstallable
or otherwise introduce
breakage with other packages).  Once everything is settled,
you can upload a version of
these experimental packages that only changes the target to
unstable and they will all
drop in immediately.

Ah, great, thank you!

Thanks to everyone's feedbacks. I have uploaded this to
mentors.debian.net
https://mentors.debian.net/package/libkdumpfile/

I had a look at the package above, but I got the following message when
dh_missing: error: missing files, aborting
Have you seen anything similar?
Here is the rest of the log, afte the tests passed.

Looks like you ran the build on a system with Python headers
installed so it built the Python bindings, then it failed because
there are unpackaged files
It should not fail in sbuilder or pbuilder, but just in case I can
explicitly disable Python bindings from being built so it’s easier to
do a test build

Hi Breno,
The hypothesis is correct; by explicitly passing `--with-python=no` my
test build succeeded even when I added python3-dev and python3-
setuptools in debian/control

This new version worked now, and I've just uploaded it.

Thanks for working on it,
--breno

[Soren Stoutner]

Michel,

Post by Michel Lind
Ah, OK, so these uploads all require FTP master review right?
- soname bump to 0.5.5 in experimental
- initial upload of the new pykdumpfile in experimental
- dropping python bindings in experimental
- 0.5.5 without python in unstable (or can I as a DM do this myself?)
- pykdumpfile in unstable
If a package that's been cleared for experimental can be uploaded to
unstable without FTP master review, even if it has binary subpackage
name changes, that would simplify this quite a bit (but if it requires
re-review, that's fine too, I just have to know how much to coordinate
with the DD sponsoring the upload)

FTP master review is only required when the name of a binary package changes. Any
other change inside the binary package does not require their review.

Because FTP master review can take an unpredictable amount of time, usually the best
course of action in this case would be to make all such changes in experimental (because
it is OK for packages in experimental to not be coinstallable or otherwise introduce
breakage with other packages). Once everything is settled, you can upload a version of
these experimental packages that only changes the target to unstable and they will all
drop in immediately.