I already tried to generate well formatted libraries for Deken (but not to upload them) and I had a problem with the parentheses in the names of the Deken libraries that are not supported by Travis (and Appveyor I guess) because they are used inside the URL. I don't find where I spoke about it (on GitHub or on this list). So if you find a solution I'll be pleased to know it :)
Cheers, Pierre
Hi,
back on this more than 2 months later...
so I setup travis to upload ossia package to deken on tagged commit.
here is the script : https://github.com/OSSIA/lib
ossia/blob/feature/deken/ci/push_deken.sh
The deken configuration and GPG key are encrypted with travis command line
tool.
I'm not using deken tool on travis because I had too much headache.
But it should be possible,
At least I can upload some non signed package.
I have an issue with GPG signing from Python :
https://github.com/pure-data/deken/issues/166 (which might be fixed now).
Then the command line tool was broken :
https://github.com/pure-data/deken/issues/169 (which should be fixed now).
Moreover I have a lot of issue on Appveyor to run deken.
PATH variable is a nightmare to configure and deken fails because it can't
find make
...
Those issues discouraged me to use the command line tool and I'm using
curl
to create directory and upload file.
gpg sign the package and sha256-sum compute the checksum.
This setup is working on Travis, Appveyor is on the road.
Concerning the parenthese issue, you should use at least single quotes around your file name. I'm using double ones to expand ${VERSION} variable *before* making the upload URL.
cheers
Antoine
-- do it yourself http://antoine.villeret.free.fr
2017-07-19 11:24 GMT+02:00 Pierre Guillot guillotpierre6@gmail.com:
I already tried to generate well formatted libraries for Deken (but not to upload them) and I had a problem with the parentheses in the names of the Deken libraries that are not supported by Travis (and Appveyor I guess) because they are used inside the URL. I don't find where I spoke about it (on GitHub or on this list). So if you find a solution I'll be pleased to know it :)
Cheers, Pierre
On 2017-10-18 22:49, Antoine Villeret wrote:
back on this more than 2 months later... so I setup travis to upload ossia package to deken on tagged commit.
i noticed that the ossia packages lack a license.
also the source packages are just huge (175MB), and they contain
luckily the source package does *not* include the source code (and full git history) of all dependencies (like libc++ and gcc) ;-/
it seems that the source archive is a pristine recursive checkout of the git repository (which is good enough).
but: would it be possible to trim down the size of the source package?
e.g. something like git archive
(possibly plus an addition of which
revisions of the various 3rd party submodules were used).
this should trim down the source package to <9MB (less than 5% of the current sources).
fg amsdr IOhannes
2017-10-19 11:10 GMT+02:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2017-10-18 22:49, Antoine Villeret wrote:
back on this more than 2 months later... so I setup travis to upload ossia package to deken on tagged commit.
i noticed that the ossia packages lack a license.
this should be fixed
also the source packages are just huge (175MB), and they contain
- the entire (git) history of libossia
- twenty-one (21) 3rd party modules
- the entire (git) history of each 3rd party module
luckily the source package does *not* include the source code (and full git history) of all dependencies (like libc++ and gcc) ;-/
it seems that the source archive is a pristine recursive checkout of the git repository (which is good enough).
but: would it be possible to trim down the size of the source package? e.g. something like
git archive
(possibly plus an addition of which revisions of the various 3rd party submodules were used).this should trim down the source package to <9MB (less than 5% of the current sources).
yes I noticed that and I'm sorry for disturbing the huge package were part of upload test and have been deleted. But I'm not found of releasing source package that are not ready to build. So I find a way to strip down source package to about 15Mo with all 3rd party source and without git history. Thus people who can't find a suitable binary package can easily build it from the tarball. (well 'easily' is relative...)
Moreover, they were a lot of upload in the pasts few week because I was testing the deployment system. They should be more sporadic in the future.
Hopefully windows package will be available on the next release with GPG signature and SHA sum.
I hope this is fine for you.
Best
Antoine
fg amsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list