Re: Update of packages by non-maintainer
Am 29.05.2020 um 00:34 schrieb Yasuhiro KIMURA: In my case following line should be put as override.hint. Right? -- curr: 0.4-1 -- You would probably also need a "replace-versions:" line. I'd tend to use the "version:" line to override the upstream version number to something that sorts correctly with the previous version number in this case, though. Something as simple as "deb+0.4" might already do that. -- Achim. (on the road :-)
Re: git repositories for cygwin packaging - please test
04.08.2019 21:08, Jon Turney пишет:
>
> While a number of maintainers keep their cygwin packaging under some
> sort of version control, there is currently no central collection of
> these repositories.
>
> 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:
>
> git push cyg...@cygwin.com:/git/cygwin-packages/
>
> where is a package name you are listed as a maintainer for
> in http://cygwin.com/cygwin-pkg-maint.
>
> These repositories are lazily created on the first push.
>
> Since it's intended that these repositories will only contain cygport
> scripts, patches, and other packaging files, and to prevent the
> accidental committing of upstream archives, pushes containing large
> binary files will be rejected.
>
> These repositories are viewable via gitweb at
> https://cygwin.com/git-cygwin-packages/ (URL may be subject to change),
> and should be cloneable via anonymous git/http with the URLs shown there.
>
> Please give this a test, if possible, and report any problems here.
I've tried to push the playground branch to
cygwin.com:/git/cygwin-packages/znc and the output was full of this:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "",
LC_ALL = (unset),
LANG = "ru_RU.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "",
LC_ALL = (unset),
LANG = "ru_RU.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Re: Help needed with gobject-introspection
On 27/05/2020 21:32, Ken Brown via Cygwin-apps wrote: On 5/24/2020 11:56 AM, Jon Turney wrote: So, yeah, this is a meson bug, which I will work on (if this command ends up in the build.ninja, it's executed by ninja with 'sh -c', but if it ends up in a pickle, it's executed by meson with execve()) It looks like I've bumped into a variation of this bug. While attempting to build the documentation for the latest glib2.0 release, I got the following: FAILED: docs/reference/gobject/gobject-decl.txt /usr/bin/meson --internal exe --unpickle /home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin/meson-private/meson_exe_meson_1ed2fbe217cac49ae4affd274e0d4a729085a002.dat ['/usr/bin/meson', '--internal', 'gtkdoc', '--sourcedir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3', '--builddir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin', '--subdir=docs/reference/gobject', '--headerdirs=gobject', '--mainfile=gobject-docs.xml', '--modulename=gobject', '-- [...] /docs/reference/gobject/tut_tools.xml', '--cc=gcc', '--ld=gcc', '--cflags=-I@BUILD_ROOT@/gobject -I../gobject -pthread -I@BUILD_ROOT@/. -I../. -I@BUILD_ROOT@/glib -I../glib -I@BUILD_ROOT@/docs/reference/gobject/. -I../docs [...] So @BUILD_ROOT@ didn't get replaced by the build root after pickling and unpickling. Needless to say, this produced errors like: cc1: error: @BUILD_ROOT@/glib: No such file or directory [-Werror=missing-include-dirs] I can give you a precise recipe for reproducing this bug if it would help your debugging. Definitely a bug. I'll see if I can take a look at it this weekend.
Re: Help needed with gobject-introspection
On 25/05/2020 16:04, Ken Brown via Cygwin-apps wrote: On 5/24/2020 1:00 PM, Ken Brown via Cygwin-apps wrote: On 5/24/2020 12:45 PM, Ken Brown via Cygwin-apps wrote: On 5/24/2020 11:56 AM, Jon Turney wrote: On 21/05/2020 18:07, Ken Brown via Cygwin-apps wrote: On 5/21/2020 11:48 AM, Jon Turney wrote: On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote: On 5/21/2020 9:24 AM, Jon Turney wrote: On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote: On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote: [...] This does indeed shed some light. If I remove all the commas but leave the single quotes, the command fails with the same error message as before: cp: target 'docs/index.html.tmp' is not a directory If I also remove the single quotes, the command succeeds. I think the problem is the quotes around the double ampersands, so they are treated as arguments to the cp command instead of being interpreted by the shell executing the command. So, yeah, this is a meson bug, which I will work on (if this command ends up in the build.ninja, it's executed by ninja with 'sh -c', but if it ends up in a pickle, it's executed by meson with execve()) Yes, that does seem like a meson bug. But is it also a babl bug to some extent? When babl puts '&&' in a command argument, it's assuming that the command will be executed by 'sh -c'. I have very little experience with meson. Have you ever seen this issue in other projects that use meson? I just noticed this, at https://mesonbuild.com/Custom-build-targets.html : Meson only permits you to specify one command to run. This is by design as writing shell pipelines into build definition files leads to code that is very hard to maintain. If your compilation requires multiple steps you need to write a wrapper script that does all the necessary work. We're not talking about a shell pipeline here, but it's similar. So I'm thinking this really is a babl bug. Yeah. Ideally meson would stop people from writing custom targets which use shell operators. Unfortunately, it doesn't and there are probably many other existing instances of this usage. Additionally, meson is perhaps a bit schizophrenic on this topic and (I think) actually has code to make sure this works as expected when the command ends up being put directly into build.ninja (which is what will usually happen on linux etc.) Regardless of whose bug it is, I've got a simple but ugly workaround (attached), now that you've explained to me what's going on. Good stuff.
