[SOLVED] Trying to build deb -> upstream tar error

[Chrisdb]

Hi,

I'm trying to build and experimental package: php7.4.
The problem is after running 'debchange' and 'debuild', I get the following error:

Code: Select all

no upstream tarball found at ../php7.4_7.4.0~bp10+1.orig.tar

The command I used for debchange under directory 'php7.4-7.4.0~rc6' was:

Code: Select all

debchange -b -v 7.4.0~bp10+1

The solution probably is to change the name of the tar, but shouldn't this be done automatically?

Thx

[Head_on_a_Stick]

Try

Code: Select all

debchange --bpo

[Chrisdb]

Try

Code: Select all

debchange --bpo

That worked, thx!

One more question. After my build is done, should I use the following commands tot remove the build dependencies?

Code: Select all

apt-get purge <packagename>-build-deps
apt-get autoremove

[Head_on_a_Stick]

Yes. Or use aptitude instead, that auto-autoremoves.

[Chrisdb]

Yes. Or use aptitude instead, that auto-autoremoves.

After reading your post I had a look at aptitude as I do not use it very often. Apparently aptitude does remove more thoroughly.

So if I replace

Code: Select all

apt-get purge <packagename>-build-deps
apt-get autoremove

With just

Code: Select all

aptitude purge package_name

It should be enough?

[Head_on_a_Stick]

Yes. Use the --simulate option to test things first.

[Soul Singin']

I'm trying to build and experimental package: php7.4.

Keep us posted. Let us know how it goes.

Good luck and have fun!
- Soul

[Chrisdb]

I'm trying to build and experimental package: php7.4.

Keep us posted. Let us know how it goes.

Good luck and have fun!
- Soul

apparently some errors:

Code: Select all

Now signing changes and any dsc files...
 signfile dsc php7.4_7.4.0~rc6-1~bpo10+1.dsc chris <chris@mydebian>
gpg: keybox '/home/chris/.gnupg/pubring.kbx' created
gpg: skipped "chris <chris@mydebian>": No secret key
gpg: /tmp/debsign.oiyl1dyo/php7.4_7.4.0~rc6-1~bpo10+1.dsc: clear-sign failed: No secret key
debsign: gpg error occurred!  Aborting....
debuild: fatal error at line 1112:
running debsign failed

[Head_on_a_Stick]

Try

Code: Select all

debuild -us -uc

[Chrisdb]

Try

Code: Select all

debuild -us -uc

Thx, will keep you posted

Btw after the build I do get a lot of .deb files like php7.4-sqlite etc. And when I try to install the php7.4 deb, I get dependency errors.

Is there a way to create a single .deb containing everything?

[Head_on_a_Stick]

after the build I do get a lot of .deb files like php7.4-sqlite etc. And when I try to install the php7.4 deb, I get dependency errors

You probably have to install the .debs in a certain order, they may depend on each other.

Or set up a local repository: https://packages.debian.org/buster/local-apt-repository

[Chrisdb]

after the build I do get a lot of .deb files like php7.4-sqlite etc. And when I try to install the php7.4 deb, I get dependency errors

You probably have to install the .debs in a certain order, they may depend on each other.

Or set up a local repository: https://packages.debian.org/buster/local-apt-repository

Thx, the local-apt solution worked
Is this the recommended way to handle this situation?

How should I have handled it manually?

[Head_on_a_Stick]

Is this the recommended way to handle this situation?

I would certainly recommend it, I didn't even know about it until you started this thread though. Isn't it brilliant?

I use SUSE's Open Build Service to host custom Debian packages so that they're available for several machines at once: https://build.opensuse.org

How should I have handled it manually?

Look at the output when you try to install the "main" .deb package, that should tell you which .debs are needed first.

EDIT: it's just like installing an AUR package in Arch (without a "helper") that depends on other AUR packages.

[stevepusser]

Yes, "debuild" just by itself will try to sign the packages, but it's not a fatal error, and you still could have used the packages from that build where the final signing step failed. Signing the packages provides extra security if you're going to upload the packages to an actual repository, but it's not necessary if the debs are for your own use.

[Chrisdb]

Is this the recommended way to handle this situation?

I would certainly recommend it, I didn't even know about it until you started this thread though. Isn't it brilliant?

I use SUSE's Open Build Service to host custom Debian packages so that they're available for several machines at once: https://build.opensuse.org

How should I have handled it manually?

Look at the output when you try to install the "main" .deb package, that should tell you which .debs are needed first.

EDIT: it's just like installing an AUR package in Arch (without a "helper") that depends on other AUR packages.

Thx, the first tests seem tot work (php version, phpinfo)

Speaking about tests, during the build process, several tests failed, should I be worried?

[Soul Singin']

Speaking about tests, during the build process, several tests failed, should I be worried?

I do not know enough about PHP to answer that question. What I can advise you to do -- if you still have the build log -- is to post the relevant section here, so that someone knowledgeable can examine it for you.

In the meantime, if you remember which tests failed, conduct your own tests with those features.

[Chrisdb]

Speaking about tests, during the build process, several tests failed, should I be worried?

I do not know enough about PHP to answer that question. What I can advise you to do -- if you still have the build log -- is to post the relevant section here, so that someone knowledgeable can examine it for you.

In the meantime, if you remember which tests failed, conduct your own tests with those features.

Is there a way to rerun the tests, without rebuilding the package?

Another question, tests run from debuild, are they executed in a fakeroot environment? I'm asking because 1 of the tests complained about a missing package (php-cgi), but I installed it, then performed a rebuild of the package and it still gave me the error...

[stevepusser]

I wouldn't worry too much about the tests, myself. Debian packagers have to disable some or all of them for certain packages, since they fail in the standard chroot or schroot build environments that they use.

[Head_on_a_Stick]

Make a sid chroot and see if the tests also fail when building the official Debian package.

[Chrisdb]

Make a sid chroot and see if the tests also fail when building the official Debian package.

You mean the stable package (php7.3 in this case?)