Closed nolange closed 2 years ago
It makes sense to use the proper package building procedure. I'm not familiar with it and couldn't figure it out really. But from what I've seen in other packages, I understand that these debian packaging instructions are not in the original repos, they have their own repos. Anyway, I'm all for using the standard tools over a custom script.
It makes sense to use the proper package building procedure. I'm not familiar with it and couldn't figure it out really. But from what I've seen in other packages, I understand that these debian packaging instructions are not in the original repos, they have their own repos.
Yes, that's more flexible and recommended, since debian (and derivates) often adds patches or has differences between distribution releases. Would be overkill for now, as you will need release archives for the project.
Technically there is little difference, other than the content of source/format
file.
I think gdb is a requirement rather than a recommendation.
I think it fits the definition of debian's recommends nicely:
Recommends
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found together with this one in all but unusual installations.
theres gdb
, and gdb-minimal
and gdb-multiarch
as alternatives in the repos and you could use some custom gdb builds as well. Note that a recommended package will be installed as dependency unless explicitly disabled.
Normally you only set used libraries and services as absolute dependency.
I see. I'm not familiar with debian conventions, so I don't have a well formed opinion on this. I always install with "--no-install-recommends" but I don't consider myself a typical user. I feel like at least one of these gdb packages should be installed, otherwise seer would be useless, but you are much more knowledgeable on the subject than me.
Thanks you guys for improving this part of Seer! I will accept the pull request.
I've tried building the deb package for seer 1.7. It worked alright but the version number is still 1.0. I guess something needs to be updated with every release and the only mention of the version number under the debian directory is the changelog file.
I've tried building the deb package for seer 1.7. It worked alright but the version number is still 1.0. I guess something needs to be updated with every release and the only mention of the version number under the debian directory is the changelog file.
Yeah, should be the only thing necessary?
seer (1.7) UNRELEASED; urgency=medium
This only sets the version from the package of course, the compiled binary takes the version from elsewhere.
Hi,
Is there something I can improve on my end?
Currently, the version number is hardcoded in SeerUtl.cpp. It's shown in the About box.
Perhaps I can put the version number in some file that still works for Seer and it available for the the Debian build process? (Or any other distro build process?)
I'm open to ideas.
Not sure what issue @uyar is encountering, the debian version is separate by design. if anything you could patch the changelog when building release archives
The generated deb package has the version number 1.0 in the file name. Shouldn't that match the version number of seer itself? Won't it be confusing otherwise?
The generated deb package has the version number 1.0 in the file name. Shouldn't that match the version number of seer itself? Won't it be confusing otherwise?
So you did not update the changelog? That wasnt clear to me. You'd need to update it, like below
seer (1.7) UNRELEASED; urgency=medium
(I picked up the previous version number from the PROJECT entry in CMakeList.txt file, thats why its 1.0)
No, I've just extracted the tar.gz source for 1.7 and run dpkg-buildpackage. I think either @epasveer could update the changelog with every new release, or the readme could include an instruction for updating it.
Hi All,
It's a little clearer to me now. When I prepare for a release, I need to update 3 files with the version number.
seer/src/CMakeLists.txt
seer/debian/changelog
seer/src/SeerUtl.cpp
I'll fix up the 2 files that are currently wrong.
BTW, what else is needed in "debian/changelog"? Is it a growing list of changes, from version to version? Or just the changes since the previous version?
Is there an example from another project that is a good example of a well-formed debian changelog?
Thanks.
This one looks like a viable example of a "changelog".
https://github.com/romlok/python-debian/blob/master/debian/changelog
I don't think you need that detailed a changelog here. I guess this is a changelog for the packaging, not for seer. So, just a simple version update message could suffice. But then again, I'm not sure.
just sed out the numbers before a release. The changelog is primary for packaging.
Technically it's supposed to grow, but no one cares unless it's properly added to debian/Ubuntu.
You could go an extra step and update the date (date -R
format)
Got it. Many thanks!
sorry i didn't see this, while creating the package, but if anyone wants to be co-maintainer/maintainer of it, feel welcome. here's my packaging that you can dget urlto.dsc
and debuild
then install and try/test:
Hi @alexmyczko , I'll try to build from your package. (I should learn how to do it anyway :^)
I have a Debian11 machine. Let me see how it goes.
Hi Alex,
It failed.
erniep@wildfire:~/Development/debian/seer$ dget https://sid.ethz.ch/debian/seer/seer-gdb_1.8%2Bds-1.dsc
dget: retrieving https://sid.ethz.ch/debian/seer/seer-gdb_1.8%2Bds-1.dsc
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 873 100 873 0 0 1233 0 --:--:-- --:--:-- --:--:-- 1233
dget: retrieving https://sid.ethz.ch/debian/seer/seer-gdb_1.8+ds.orig.tar.xz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 574k 100 574k 0 0 528k 0 0:00:01 0:00:01 --:--:-- 528k
dget: retrieving https://sid.ethz.ch/debian/seer/seer-gdb_1.8+ds-1.debian.tar.xz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1852 100 1852 0 0 4473 0 --:--:-- --:--:-- --:--:-- 4484
seer-gdb_1.8%2Bds-1.dsc:
dscverify: seer-gdb_1.8%2Bds-1.dsc failed signature check:
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: no valid OpenPGP data found.
gpg: processing message failed: Unknown system error
Validation FAILED!!
Actually, it left files in the directory. I was able to run 'dpkg-source' and 'debuild'.
However, it did everything (compiled and linked) but failed with this at the end.
dpkg-deb: building package 'seer-gdb-dbgsym' in '../seer-gdb-dbgsym_1.8+ds-1_amd64.deb'.
dpkg-deb: building package 'seer-gdb' in '../seer-gdb_1.8+ds-1_amd64.deb'.
dpkg-genbuildinfo
dpkg-genchanges >../seer-gdb_1.8+ds-1_amd64.changes
dpkg-genchanges: info: including full source code in upload
dpkg-source --after-build .
dpkg-buildpackage: info: full upload (original source is included)
Now running lintian seer-gdb_1.8+ds-1_amd64.changes ...
E: seer-gdb source: source-is-missing tests/helloname/core.helloname.3961
W: seer-gdb source: debian-watch-not-mangling-version opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%$1.tar.gz%" https://github.com/epasveer/seer/tags (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
W: seer-gdb: improbable-bug-number-in-closes 1017914
W: seer-gdb source: newer-standards-version 4.6.1 (current is 4.5.1)
W: seer-gdb: no-manual-page usr/bin/seer
Finished running lintian.
Now signing changes and any dsc files...
signfile dsc seer-gdb_1.8+ds-1.dsc Gürkan Myczko <tar@debian.org>
gpg: directory '/home/erniep/.gnupg' created
gpg: keybox '/home/erniep/.gnupg/pubring.kbx' created
gpg: skipped "Gürkan Myczko <tar@debian.org>": No secret key
gpg: /tmp/debsign.f2cIANqe/seer-gdb_1.8+ds-1.dsc: clear-sign failed: No secret key
debsign: gpg error occurred! Aborting....
debuild: fatal error at line 1112:
running debsign failed
Errors with gpg and things in the "tests" directories.
I've officially released v1.9. This is the trimmed release. I think we should work from it.
well the only failed thing is, you can't file with my private key, since you don't have my private key, and you're not me. so just ignore the failure that you're not me, thus can't have my private key to sign the built package ;)
Hello,
planning to test this gui, so far I only fixed up the packaging.
Using the normal debian tools ensures good compatibility and gives you alot stuff for free like automatically generating package dependencies. Ideally you will only have to adjust the
changelog
for the correct version number.I had to remove EXCLUDE_FROM_ALL, not sure what the idea there was, but this means you cant just use
make
to build the app.