[ITA] unifont 14.0.02
I'd like to adopt Unifont which I use as a low resolution fallback for X and MS Windows. Cygwin builds: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=unifont=succeeded=Brian+Inglis=3925 GNU just released the latest Unifont with utilities and Truetype fonts providing full coverage of the Unicode 14 Basic Multilingual Plane (Unicode Plane 0), plus over 12,600 glyphs for scripts in the Unicode 14 Supplementary Multilingual Plane (Unicode Plane 1), and some ConScript Unicode Registry (CSUR) and Under CSUR (UCSUR) glyphs in Private Use Areas (PUA). Unifont 14.0.02 Released https://lists.gnu.org/archive/html/info-gnu/2022-03/msg2.html -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
[PATCH cygport] autotools.cygclass: correctly detect Autoconf 2.70+
The latest version of Autoconf is 2.71, but the version detection
incorrectly considers 2.70 and higher as being the same as 2.59 and
lower for the purposes of specifying documentation directories. Correct
that, and make the version detection a bit more future-proof by parsing
out the actual version parts and performing numeric comparison.
While we're at it, add a bit more commentary explaining the intent of
the different behaviour over the different Autoconf versions.
---
cygclass/autotools.cygclass | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index cce9be0..2ab5626 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -619,6 +619,8 @@ cygconf() {
local confdir;
local configure;
local confver;
+ local confver_maj;
+ local confver_min;
local f;
local foo_config;
local prefix;
@@ -651,6 +653,8 @@ cygconf() {
configure="${confdir}/configure"
confver=$(grep -m 1 'GNU Autoconf' ${configure} | cut -d ' ' -f 6)
+ confver_maj=${confver%%.*}
+ confver_min=${confver##*.}
# AC_CONFIG_FILES should not be dist'ed, but it sometimes happens anyway
eval $(grep -h '^ac_config_files=' ${configure})
@@ -678,18 +682,26 @@ cygconf() {
confargs+=" --libdir=${prefix}/${MULTILIB_LIBDIR}"
fi
- case "x${confver}" in
- x2.6[0-9]*)
- confargs+=" --docdir=/usr/share/doc/${PN}
--htmldir=/usr/share/doc/${PN}/html"
- ;;
- *)
- confargs+=" --infodir=${prefix}/share/info
--mandir=${prefix}/share/man"
- ;;
- esac
+ if [ $confver_maj -ge 2 -a $confver_min -ge 60 ] || [ $confver_maj -ge
3 ]
+ then
+ # Autoconf version supports --docdir and --htmldir, which will
+ # need to be specified manually. It also supports --infodir
+ # and --mandir, but the defaults for those match the FHS.
+ confargs+=" --docdir=/usr/share/doc/${PN}
--htmldir=/usr/share/doc/${PN}/html"
+ else
+ # Autoconf version does not support --docdir or --htmldir, so
+ # don't specify those. Set --infodir and --mandir, as those
+ # have defaults that don't match the FHS.
+ confargs+=" --infodir=${prefix}/share/info
--mandir=${prefix}/share/man"
+ fi
- case "x${confver}" in
- x2.[5-9]*) confargs+=" -C" ;;
- esac
+
+ if [ $confver_maj -ge 2 -a $confver_min -ge 50 ] || [ $confver_maj -ge
3 ]
+ then
+ # Always use a cache file; prior to 2.50, this was the default,
+ # thereafter it needs to be requested explicitly.
+ confargs+=" -C"
+ fi
if cross_compiling || inherited toolchain
then
--
2.35.1
Re: [ITP] git-filter-repo 2.34.0
On Tue, Mar 08, 2022 at 03:42:13PM -0500, James Morris wrote: > Hi Adam, > > Thanks for the feedback! > > > - You've patched the shebang from `/usr/bin/env python3` to > > `/usr/bin/python3`. To what end? /usr/bin/env is part of coreutils > > for Cygwin, so there shouldn't be any risk that it won't be installed. > > If someone has their own compiled python3 in /usr/local/bin, they'd > > probably expect that to be used, so I don't think I'd change the > > shebang unless there's some clear and specific reason for doing so. > > I am trying to prevent exactly what you described. git-filter-repo > needs Python >=3.5 to function and we know that `/usr/bin/python3` is > the correct version. Suppose a user installed Python 3.3 at > `/usr/local/bin/python3`, now git-filter-repo will run with the wrong > Python version and most likely break. This is what other distributions > do when they distribute Python scripts and I'm fairly sure Debian > explicitly calls this out in its policy. I just went and did an entirely unscientific check of the scripts I have installed in my Cygwin /bin/ directory. It looks like there's no great consistency, but the majority of scripts there (20 to 9) are calling the relevant Python interpreter directly rather than relying on env. Personally, I'd probably not bother changing things from the upstream package, but if you'd rather do things this way I'm not going to argue :) > > - You're changing the shebang with both a patch file and with a line in > > src_compile; you don't need to do both! I suspect this is an artefact > > of how Cygport packages the source files, but AIUI the canonical way > > to do this sort of patching with Cygport is to drop the sed line from > > your .cygport file and just keep the patch file that gets generated. > > Yeah the patch file was automatically generated when I ran `cygport > all` and I wasn't sure what to do with it. To me it seems silly to > have a patch just to change the shebang line when `sed` works fine. > I'll try removing `sed` to see what happens. Cygport automatically generates patches when it detects a difference between the "src" and "origsrc" directories. You're changing something in "src", so the patch gets generated. The idea is that you can adjust things in the src directory by hand, then when you run cygport it'll automatically store the diffs so you never need to make the same changes again. I suspect the best solution here would be to either (a) drop the sed line and just use a patch file, or (b) make the change in the inst directory as part of the `src_install` function in the .cygport file, i.e. fixing it up as part of doing the "installation" step rather than the "compilation" step. But the sed command is idempotent, so while having both is redundant and a bit odd, I don't think it does any harm. > > - You've set the category as both Devel and Python. IMO (I've not > > checked what the general consensus on this is) this shouldn't be in > > Python: it's a tool that happens to use Python, but I'd expect the > > Python category to be for things that are specifically useful to > > people doing Python dev, so things like libraries that can be usefully > > imported in a Python module, or tools for debugging Python scripts. I > > think this should only be in the Devel category. > > Yeah I initially didn't have it in the Python category, but then I > thought about how other tools like bzr and mercurial are there so it > seemed appropriate. Granted I didn't check if they also provided > Python libraries, but I thought it made sense to put git-filter-repo > in the Python category to maybe warn users that installing it would > pull in Python. I've just checked both bzr and mercurial, and they definitely do provide Python packages. I don't think it's necessary to warn users about dependencies by using categories; setup provides those warnings already when it does dependency resolution. > > - That said, I think ideally you'd also be packaging git_filter_repo.py, > > which does provide a Python library that users can import. At that > > point, this would unambiguously belong in both categories. > > I wasn't sure how to go about this since I didn't know if that would > mean making a bunch of 'python3*-git-filter-repo' packages. > Do you think I should make it importable, remove it from the Python > category, or just leave it as is? My preference here would be to make it importable. That's not going to be something many people are interested in, but there's no reason not to. It can still be a single package -- as bzr and mercurial are -- providing both the main executable and the Python libraries. There's obviously a balance here: monolith packages that add a bunch of dependencies or eat a bunch of disk space / bandwidth, to provide functions many users won't care about, are clearly a bad idea. But the cost of having both the Python module and the executable in this package is going to
scallywag cygport fails to detect perl script runtime dependencies
Does cygport require perl modules to be installed as build dependencies in order to enable their detection as runtime dependencies for perl scripts in packages? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Re: [ITP] git-filter-repo 2.34.0
On 10/03/2022 20:52, Marco Atzeri wrote: On 08.03.2022 01:11, James Morris wrote: Hello, I'd like to maintain the package for git-filter-repo, a Python script to quickly edit git history. It's MIT licensed, available in both Debian and Fedora, and I've also just recently packaged git-filter-repo up for MSYS2. Cygport package files can be found here: https://drive.google.com/drive/folders/12RXG0804TmR9ZF2STpV7LXqpJMucYAfx?usp=sharing Thanks, James added to the package list. As soon you and Adam are aligned, you can upload. https://cygwin.com/packaging-contributors-guide.html Please also provide a SSH key as explained here: https://cygwin.com/packaging/key.html
Re: Cygport configure script argument handling
On Fri, Mar 11, 2022 at 12:38:47AM -0500, Yaakov Selkowitz wrote:
> On Thu, 2022-03-10 at 16:41 +, Adam Dinwoodie wrote:
> > I've fallen down a slight rabbit hole looking at the cygconf function in
> > Cygport's autotools.cygclass. The specific bit of code that's causing
> > me consternation is thus:
> >
> > case "x${confver}" in
> > x2.6[0-9]*)
> > confargs+=" --docdir=/usr/share/doc/${PN}
> > --htmldir=/usr/share/doc/${PN}/html"
> > ;;
> > *)
> > confargs+=" --infodir=${prefix}/share/info
> > --mandir=${prefix}/share/man"
> > ;;
> > esac
> >
> > Firstly, I think the glob is incorrect: it looks like it was intended to
> > match files that came from Autoconf versions 2.60 and up -- 2.60 is when
> > Autoconf added the docdir and htmldir arguments -- but it has stopped
> > working as expected: Autoconf released 2.70 in December 2020, and is now
> > up to 2.71. The above code won't match those versions.
>
> Yes, this likely needs to be updated for 2.70+.
Grand, I'll see if I can offer a patch shortly :)
> > Secondly -- and I'm not sure if this is intended or not -- I don't
> > understand why --infodir and --mandir are only defined for versions
> > prior to 2.60 (and, apparently unintentionally, 2.70 onwards). Those
> > are valid both before and after 2.60. My best guess is that the intent
> > was for the first option to fall through to the second, so for 2.60+ all
> > four options would be defined, but that would have required `;&` or
> > `;;&` rather than `;;`.
>
> No. 2.60 included changes for these (and other) directory values:
>
> https://lists.gnu.org/archive/html/autotools-announce/2006-06/msg2.html
>
> docdir and htmldir were added in 2.60, hence we don't want to pass them when
> <=2.59 is detected. infodir and mandir were changed in 2.60, from
> $prefix/{info,man} (which cygport needed to override for FHS compliance) to
> $datarootdir/{info,man}, where the new datarootdir is $prefix/share, meaning
> they no longer needed to be overriden by cygport.
Ah! Yes, that makes sense. Thank you for the explanation!
Adam
