Re: git repositories for cygwin packaging - please test
On 8/6/2020 4:20 PM, Jon Turney wrote: On 27/05/2020 23:27, Jon Turney wrote: On 04/08/2019 21:08, Jon Turney wrote: To remedy this lack, using the same ssh key you use for sftp package upload, package maintainers can now also push to git repositories, like so: Package maintainers may have noticed that the output from pushing to these git repositories now includes a line like: "remote: scallywag: build nnn queued" This is a *prototype* of a system to automatically build the packages, where the results appear (some time later) at [1] (URL subject to change) [1] https://cygwin.com/cgi-bin2/jobs.cgi Currently, many packages will fail to build correctly due to: One problem I have noticed is that some packages have test suites (which are getting run via 'cygport test' invoking src_test()) which: - require lots of extra dependencies to run, or - don't succeed on Cygwin, or - take an inordinate amount of time to run (exceeding the resource limits) So I'm wondering if .cygport files need: - an annotation to indicate tests shouldn't be run by this system (in RESTRICT? or somewhere new?) - a separate TEST_REQUIRES to list packages which depended on for running tests? I like both ideas. For the first one (don't run 'cygport test'), I have a slight preference for putting the annotation somewhere new, since it's pretty different from the current uses of RESTRICT. It doesn't affect what cygport does, but rather it tells the automated system not to run a certain cygport command. Ken
Re: git repositories for cygwin packaging - please test
On 27/05/2020 23:27, Jon Turney wrote: On 04/08/2019 21:08, Jon Turney wrote: To remedy this lack, using the same ssh key you use for sftp package upload, package maintainers can now also push to git repositories, like so: Package maintainers may have noticed that the output from pushing to these git repositories now includes a line like: "remote: scallywag: build nnn queued" This is a *prototype* of a system to automatically build the packages, where the results appear (some time later) at [1] (URL subject to change) [1] https://cygwin.com/cgi-bin2/jobs.cgi Currently, many packages will fail to build correctly due to: One problem I have noticed is that some packages have test suites (which are getting run via 'cygport test' invoking src_test()) which: - require lots of extra dependencies to run, or - don't succeed on Cygwin, or - take an inordinate amount of time to run (exceeding the resource limits) So I'm wondering if .cygport files need: - an annotation to indicate tests shouldn't be run by this system (in RESTRICT? or somewhere new?) - a separate TEST_REQUIRES to list packages which depended on for running tests?
Re: cygport: Request a new feature in order to set owner/group names in packaged tarballs.
Lemures Lemniscati via Cygwin-apps writes: > Do you mean controlling with '-I' or '--use-compress-program='? > (And I didn't know these options of tar... oh.) No, I was talking about things like XZ_OPT or ZSTD_CLEVEL. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: cygport: Request a new feature in order to set owner/group names in packaged tarballs.
On 05/08/2020 22:50, Lemures Lemniscati via Cygwin-apps wrote: On Wed, 5 Aug 2020 20:34:24 +0100, Jon Turney However, I think there is a consistency problem here, as other variables which should only produce a single line in the .hint file (e.g. REQUIRES, etc.) don't get whitespace canonicalized (as least, that's how it seemed to me when I briefly looked at this). Thanks for the patch. Thank you for reviewing. It would be easy to canonicalize through a functiion like __single_line_list () in the commit https://github.com/cygwin-lem/cygport/commit/7607782d3d1972aef6b88ee32f5211f21abbbcfb I'll check later for 'category:', 'requires:', 'obsoletes:', 'provides:', and 'conflicts:'. Any other field to be checked for canonicalization? Although it's not very clearly specified in [1], the only keys in a .hint file for which multiline values are currently permitted are ldesc: and message: [1] https://cygwin.com/packaging-hint-files.html
Re: [ITA] fontforge-{nopy,py38,py37,py36}-20200314p64-1 for review
On Thu, Aug 6, 2020 at 1:05 PM Lemures Lemniscati via Cygwin-apps wrote: > > On Fri, 31 Jul 2020 06:23:36 +0200, Marco Atzeri via Cygwin-apps > > On 30.07.2020 22:39, Lemures Lemniscati via Cygwin-apps wrote: > > > I'm trying to build fontforge packages with latest upstream > > >https://github.com/fontforge/fontforge/ > > Packages related to fontforge 20190801 or 20200314 in Ubuntu, Debian and > Fedora are linked to python 3.8. > > https://packages.ubuntu.com/focal/python3-fontforge > https://packages.debian.org/bullseye/python3-fontforge > https://fedora.pkgs.org/32/fedora-x86_64/fontforge-20200314-3.fc32.x86_64.rpm.html > > So, I'll retry to make fontforge.cygport in order to link it python3.8 only, > later. that was also my finding. I agree on your proposal In addition it seems sphinx is "needed" for 3.8 so I put it on my TODO list. > -- > Lem unfortunately I have problem with python-gi, so other things are dragging on... Regards Marco
Re: [ITA] fontforge-{nopy,py38,py37,py36}-20200314p64-1 for review
On Fri, 31 Jul 2020 06:23:36 +0200, Marco Atzeri via Cygwin-apps > On 30.07.2020 22:39, Lemures Lemniscati via Cygwin-apps wrote: > > I'm trying to build fontforge packages with latest upstream > >https://github.com/fontforge/fontforge/ > > > > ( forked for cygwin build to > > > > https://github.com/cygwin-lem/fontforge/tree/n_20200314p64_maybe-nonbreaking > > ) > > > > And, some of Yaakov's patches are now in the upstream: > > > > https://github.com/fontforge/fontforge/commit/c0a27e4bdc436e73901b7a6cd7e4b6910fcee408 > > > > > > * Cygport files are forked here: > >https://github.com/cygwin-lem/fontforge-cygport/tree/n_20200314p64-1 > > from > >https://cygwin.com/git/cygwin-packages/fontforge.git . > > > > > > * New test package files are here: > >https://cygwin-lem.github.io/fontforge-cygport/ . > > > > > > > > * Note: > > > > To build test packages: > > > > (1) prepare cmake-3.17.3-1 (test) > > > > (2) invoke build.sh under > >https://github.com/cygwin-lem/fontforge-cygport/tree/n_20200314p64-1 > >as follows: > > > > ./build.sh --generate-cygport --download --test > > > >(or for short: "./build.sh -s -d -t" ). > > > >This generates cygport files, downloads a source tarball, and > > test-tagged builds. > > > > > > When we build fontforge, it can be linked to only one specific > > version of python3. > > So, I've prepared four cygport files by a script ./build.sh > > > >fontforge-nopy.cygport > >fontforge-py38.cygport > >fontforge-py37.cygport > >fontforge-py36.cygport > > > > > > * Need help > > > > Please give me any advice on building and packaging such cases... > > > > > > > > * Need help more > > > > Any advice on how to adapt it to the CI system. > > Is it enough just putting the generated cygport files in a repository? > > > > > > > > Regards, > > > > Lem > > > Thanks Lem > > on my TODO list for the weekend, assuming no oneelse do it before > Packages related to fontforge 20190801 or 20200314 in Ubuntu, Debian and Fedora are linked to python 3.8. https://packages.ubuntu.com/focal/python3-fontforge https://packages.debian.org/bullseye/python3-fontforge https://fedora.pkgs.org/32/fedora-x86_64/fontforge-20200314-3.fc32.x86_64.rpm.html So, I'll retry to make fontforge.cygport in order to link it python3.8 only, later. -- Lem
