Re: [PATCH cygport] bin/cygport.in: Allow `-fdebug-prefix-map` to be selected instead of `-ffile-prefix-map`
The issue about debug_counter.h was resolved by merging the pull request upstream. https://github.com/ruby/ruby/pull/10895 Therefore, this patch is no longer needed and will be withdrawn. On Tue, May 28, 2024 at 11:07 PM Jon Turney wrote: > > On 25/05/2024 08:25, Daisuke Fujimura via Cygwin-apps wrote: > > Having seen this commit ( > > https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=commit;h=9e82685e32f6717675e9f6bf55dd1336e3fc3831 > > ), > > I understand that this is problematic from a reproducibility point of > > view, but I would like to be able to specify a `-fdebug-prefix-map` > > because C sources with code like `#include __FILE__` cannot be > > compiled. > > > > https://github.com/cygwin/scallywag/actions/runs/9002845391/job/24732313857#step:6:1302 > > > > ``` > > /cygdrive/d/a/scallywag/ruby/ruby-3.3.1-1.x86_64/src/ruby-3.3.1/debug_counter.h:359:10: > > fatal error: /usr/src/debug/ruby-3.3.1-1/debug_counter.h: No such file > > or directory > > 359 | #include __FILE__ > > | ^~~~ > > compilation terminated. > > ``` > > > > The patch is as follows. > > Thanks very much for the patch. > > Yeah, I tripped over this when I was testing your previous patch. > > This seems like a generic problem which everyone is going to have with > ruby, though. And from a brief look at the debug_counter.h header, it > does seem like a case of excessive cleverness - on first glance, it > looks like this could just be written using a separate header, rather > than recursively including itself with some define set... > > (and I guess it's actually a gcc bug, or at least misfeature, that you > can make '#include __FILE__' do something other than it's plain meaning) > > Nevertheless, I guess this is needed. > > > Shell variable names in the patch should be changed to appropriate ones. > > Yeah, not sure what a good name for this is. Something like > 'DEBUGINFO_ONLY_DEBUG_PREFIX_MAP', maybe? > > It needs to be mentioned in the documentation somewhere, as well. >
[PATCH cygport] bin/cygport.in: Allow `-fdebug-prefix-map` to be selected instead of `-ffile-prefix-map`
Having seen this commit ( https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=commit;h=9e82685e32f6717675e9f6bf55dd1336e3fc3831 ), I understand that this is problematic from a reproducibility point of view, but I would like to be able to specify a `-fdebug-prefix-map` because C sources with code like `#include __FILE__` cannot be compiled. https://github.com/cygwin/scallywag/actions/runs/9002845391/job/24732313857#step:6:1302 ``` /cygdrive/d/a/scallywag/ruby/ruby-3.3.1-1.x86_64/src/ruby-3.3.1/debug_counter.h:359:10: fatal error: /usr/src/debug/ruby-3.3.1-1/debug_counter.h: No such file or directory 359 | #include __FILE__ | ^~~~ compilation terminated. ``` The patch is as follows. Shell variable names in the patch should be changed to appropriate ones. force-debug-prefix-map.diff Description: Binary data
Re: [PATCH cygport] pkg_info.cygpart: Do not detect dependencies on itself in ruby package
Using cygport-0.36.9-1 with this patch merged in, it was confirmed
that a ruby-3.3.1 package could be created in the local development
environment.
Thank you for merging.
On Mon, May 6, 2024 at 11:12 PM Jon Turney wrote:
>
> On 03/04/2024 15:18, Daisuke Fujimura via Cygwin-apps wrote:
> > Thank you for reviewing this.
> >
> >> Can you clarify what the "failure" is here?
> >
> [...]
> >
> > /usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
> > -- rbconfig (LoadError)
> >
> [...]
>
> Thanks very much for the detailed explanation.
>
> So this is an error (or warning?) generated by invoking the
> not-yet-properly installed, just-built ruby in ${D}.
>
> I applied your patch.
>
> > On Sun, Mar 10, 2024 at 10:34 PM Jon Turney
> > wrote:
> >>
> >> On 16/02/2024 12:51, Daisuke Fujimura via Cygwin-apps wrote:
> >>> Attempting to create a package for ruby-3.3, but it fails when trying
> >>> to detect a dependency on itself.
> >>
> >> Thanks for this patch.
> >>
> >> Can you clarify what the "failure" is here?
> >>
> >>> To avoid this, skip them if the target is `ruby`.
> >>
> >> The second hunk seems like a removes the dependency on ruby_xy for the
> >> ruby package, which also provides ruby_xy.
> >>
> >> Historically, we've allowed self-dependencies like this, because they
> >> seem to be benign, although it seems like we could do with some generic
> >> code to suppress them
>
> ... except I added something to generically prevent a packages provides:
> appearing it it's requires:
>
Re: [PATCH cygport] pkg_info.cygpart: Do not detect dependencies on itself in ruby package
Thank you for reviewing this.
> Can you clarify what the "failure" is here?
ruby.cygport and its CI results are as follows.
-
https://cygwin.com/cgit/cygwin-packages/ruby/commit/?id=65af41c137b45d09614ea99f78d7a4818b1bdfb1
-
https://github.com/cygwin/scallywag/actions/runs/7580195232/job/20645744555#step:6:22939
```
>>> Creating source package
ruby-3.3.0-1.src/
ruby-3.3.0-1.src/2.0.0-cygwin-configure.patch
ruby-3.3.0-1.src/2.0.0-cygwin-rubygems.patch
ruby-3.3.0-1.src/2.5.1-win32-resolv.patch
ruby-3.3.0-1.src/9357.patch
ruby-3.3.0-1.src/ruby-2.1.0-always-use-i386.patch
ruby-3.3.0-1.src/ruby-2.1.0-custom-rubygems-location.patch
ruby-3.3.0-1.src/ruby-2.1.0-Enable-configuration-of-archlibdir.patch
ruby-3.3.0-1.src/ruby-2.1.0-Prevent-duplicated-paths-when-empty-version-string-i.patch
ruby-3.3.0-1.src/ruby-2.3.0-ruby_version.patch
ruby-3.3.0-1.src/ruby-3.3.0-Disable-syntax-suggest-test-case.patch
ruby-3.3.0-1.src/ruby-3.3.0.tar.gz
ruby-3.3.0-1.src/ruby-3.4.0-ruby-net-http-Renew-test-certificates.patch
ruby-3.3.0-1.src/ruby.cygport
/usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
-- rbconfig (LoadError)
from /usr/share/rubygems/rubygems.rb:8:in `'
from :2:in `require'
from :2:in `'
/usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
-- rbconfig (LoadError)
from /usr/share/rubygems/rubygems.rb:8:in `'
from :2:in `require'
from :2:in `'
/usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
-- rbconfig (LoadError)
from /usr/share/rubygems/rubygems.rb:8:in `'
from :2:in `require'
from :2:in `'
>>> ruby requires: cygwin libcrypt2 libffi8 libgcc1 libgmp10 libssl3 libyaml0_2
>>> ruby_33 zlib0 ca-certificates
/usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
-- rbconfig (LoadError)
from /usr/share/rubygems/rubygems.rb:8:in `'
from :2:in `require'
from :2:in `'
/usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
-- rbconfig (LoadError)
from /usr/share/rubygems/rubygems.rb:8:in `'
from :2:in `require'
from :2:in `'
/usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
-- rbconfig (LoadError)
from /usr/share/rubygems/rubygems.rb:8:in `'
from :2:in `require'
from :2:in `'
>>> ruby-devel requires: pkg-config ruby ruby_33 libcrypt-devel libgmp-devel
/usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
-- rbconfig (LoadError)
from /usr/share/rubygems/rubygems.rb:8:in `'
from :2:in `require'
from :2:in `'
/usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
-- rbconfig (LoadError)
from /usr/share/rubygems/rubygems.rb:8:in `'
from :2:in `require'
from :2:in `'
/usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
-- rbconfig (LoadError)
from /usr/share/rubygems/rubygems.rb:8:in `'
from :2:in `require'
from :2:in `'
>>> ruby-doc requires:
>>> ruby-tcltk requires: ruby-tk
>>> Testing ruby-3.3.0-1.x86_64
:
:
```
LoadError is occurring three times because the ruby.exe used to detect
dependencies in the ruby package is not /usr/bin/ruby.exe but
${D}/usr/bin/ruby.exe.
- https://github.com/cygwin/cygport/blob/0.36.8/lib/pkg_info.cygpart#L562
- https://github.com/cygwin/cygport/blob/0.36.8/lib/pkg_info.cygpart#L564
- https://github.com/cygwin/cygport/blob/0.36.8/lib/pkg_info.cygpart#L565
${D}/usr/bin/ruby.exe is used because ${D} is added to the PATH.
- https://github.com/cygwin/cygport/blob/0.36.8/lib/pkg_info.cygpart#L137
As the ruby package itself does not depend on ruby-* other than its
own sub-packages, we considered that lines 560~600 did not need to be
executed.
- https://github.com/cygwin/cygport/blob/0.36.8/lib/pkg_info.cygpart#L560-L600
As for `ruby_xy`, as pointed out, there should be no diff.
On Sun, Mar 10, 2024 at 10:34 PM Jon Turney wrote:
>
> On 16/02/2024 12:51, Daisuke Fujimura via Cygwin-apps wrote:
> > Attempting to create a package for ruby-3.3, but it fails when trying
> > to detect a dependency on itself.
>
> Thanks for this patch.
>
> Can you clarify what the "failure" is here?
>
> > To avoid this, skip them if the target is `ruby`.
>
> The second hunk seems like a removes the dependency on ruby_xy for the
> ruby package, which also provides ruby_xy.
>
> Historically, we've allowed self-dependencies like this, because they
> seem to be benign, although it seems like we could do with some generic
> code to suppress them
>
> (e.g. cygport also ends up generating cygwin-debuginfo with a dependency
> on itself, which is harmless but could be suppressed)
>
[PATCH cygport] pkg_info.cygpart: Do not detect dependencies on itself in ruby package
Attempting to create a package for ruby-3.3, but it fails when trying to detect a dependency on itself. To avoid this, skip them if the target is `ruby`. pkg_info-for-ruby.diff Description: Binary data
Re: [PATCH cygport] git.cygclass: Suppress the depth option
Thank you for merging.
I have confirmed that this modification has resulted in the intended behaviour.
```
$ cygport --version
cygport 0.36.8
Copyright (C) 2020 Cygport authors
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program under the terms of
the GNU General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any
later version.
For more information about these matters, see the file named COPYING.
Written for the Cygwin project <https://cygwin.com/>.
$ head -3 agbsum-15-1bl1.cygport
HOMEPAGE="https://mandelbrot.dk/${PN}";
GIT_URI="https://mandelbrot.dk/${PN}";
GIT_TAG="${PV}"
$ cygport agbsum-15-1bl1.cygport fetch
*** Info: Trying to enable case sensitivity on /tmp/agbsum/agbsum-15-1bl1.x86_64
git clone --depth 1 --branch 15 --no-checkout
https://mandelbrot.dk/agbsum agbsum
Cloning into 'agbsum'...
fatal: dumb http transport does not support shallow capabilities
*** Warning: git clone failed, retrying without --depth option
git clone --branch 15 --no-checkout https://mandelbrot.dk/agbsum agbsum
Cloning into 'agbsum'...
Fetching objects: 251, done.
git checkout tags/15
HEAD is now at bef1780 Rename source directory: 'src' => 'source';
Update naming convention; Update copyright holder name; Update code
style;
```
On Mon, Feb 12, 2024 at 2:09 AM Jon Turney via Cygwin-apps
wrote:
>
> On 03/12/2023 21:53, Brian Inglis via Cygwin-apps wrote:
> > On 2023-12-03 13:34, Jon Turney via Cygwin-apps wrote:
> >> On 30/11/2023 12:17, Daisuke Fujimura via Cygwin-apps wrote:
> >>> Implementations that conditionally branch on variables are simple.
> >>>
> >>> The proposed retry implementation complicates git.cygclass, but I
> >>> think it reduces the maintainer's effort.
> >>>
> >>> I have created a patch for a retry implementation.
> >>> Could you review it?
> >>
>
> Thanks very much to Fujimura-san for all his work on this.
>
> >> Attached is the patch after my edits.
>
> I've applied a reheated version of this patch. Hopefully that works well
> enough, but obviously can be further refined if needed.
>
> > Looks like straight curl HEAD -I tells you about smart transport if you
> > want a quick check rather than a dry run:
> >
> > $ time curl -ILSs
> > https://repo.or.cz/r/git.git/info/refs?service=git-upload-pack | grep
> > -qi '^content-type:\sapplication/x-git-upload-pack'; echo $?
> >
> > real0m0.630s
> > user0m0.077s
> > sys 0m0.123s
> > 0
> > $ time curl -ILSs
> > https://github.com/BrianInglis/apt-cyg.git/info/refs?service=git-upload-pack
> > | grep -qi '^content-type:\sapplication/x-git-upload-pack'; echo $?
> >
> > real0m0.440s
> > user0m0.061s
> > sys 0m0.184s
> > 1
>
> Thanks for this.
>
> Uh, but it seems like 'git clone --depth 1' works with both of these
> URLs, so... um... I'm not sure what's going on.
>
[PATCH cygport] cmake.cygclass: Add src_test
See https://cygwin.com/pipermail/cygwin-apps/2023-October/043227.html
> src_test is not redefined in cmake.cygclass (and ninja.cygclass) in
> cygport-0.36.3. Therefore, I defined src_test in json-c.cygport.
>
> - https://github.com/cygwin/cygport/blob/0.36.6/cygclass/cmake.cygclass
> - https://github.com/cygwin/cygport/blob/0.36.6/cygclass/ninja.cygclass
>
> I agree that it would be preferable to have src_test defined in one of these
> cygclasses.
The test is executed with or without CYGCMAKE_GENERATOR=Ninja.
diff --git a/cygclass/cmake.cygclass b/cygclass/cmake.cygclass
index cab75cf3..d2a7ef09 100644
--- a/cygclass/cmake.cygclass
+++ b/cygclass/cmake.cygclass
@@ -215,6 +215,14 @@ src_compile() {
}
#
+#o* cmake.cygclass/src_test (cmake)
+# DEFINITION
+src_test() {
+ cd ${B}
+ ctest
+}
+#
+
#o* cmake.cygclass/src_install (cmake)
# DEFINITION
src_install() {
Re: [PATCH cygport] git.cygclass: Suppress the depth option
I have implemented a curl-based smart transport check. How about this one?
diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
index e53a7985..f3ed343e 100644
--- a/cygclass/git.cygclass
+++ b/cygclass/git.cygclass
@@ -67,6 +67,7 @@ SRC_DIR="${GIT_MODULE}${GIT_SUBDIR+/}${GIT_SUBDIR}"
git_fetch() {
local _depth
+ local _branch
check_prog_req git
@@ -78,17 +79,21 @@ git_fetch() {
_depth="--depth 1"
if defined GIT_TAG
then
- _depth+=" --branch ${GIT_TAG}"
+ _branch="--branch ${GIT_TAG}"
elif defined GIT_BRANCH
then
- _depth+=" --branch ${GIT_BRANCH}"
+ _branch="--branch ${GIT_BRANCH}"
fi
fi
+ check_prog_req curl
+ curl -is ${GIT_URI}/info/refs?service=git-upload-pack | grep
--binary-files=text -i '^content-type:\sapplication/x-git-upload-pack'
>& /dev/null && _branch="${_depth} ${_branch}"
+
# T likely doesn't exist at this point, so create it first
mkdir -p ${T}
cd ${T}
- verbose git clone ${_depth} --no-checkout ${GIT_URI} ${GIT_MODULE}
|| error "git clone failed"
+ verbose git clone ${_branch} --no-checkout ${GIT_URI} ${GIT_MODULE}
|| error "git clone failed"
+
cd ${T}/${GIT_MODULE}
#v* git.cygclass/GIT_BRANCH
On Mon, Dec 4, 2023 at 6:53 AM Brian Inglis via Cygwin-apps
wrote:
>
> On 2023-12-03 13:34, Jon Turney via Cygwin-apps wrote:
> > On 30/11/2023 12:17, Daisuke Fujimura via Cygwin-apps wrote:
> >> Implementations that conditionally branch on variables are simple.
> >>
> >> The proposed retry implementation complicates git.cygclass, but I
> >> think it reduces the maintainer's effort.
> >>
> >> I have created a patch for a retry implementation.
> >> Could you review it?
> >
> > Thanks very much.
> >
> > Sure.
> >
> >> diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
> >> index e53a7985..1e26ab37 100644
> >> --- a/cygclass/git.cygclass
> >> +++ b/cygclass/git.cygclass
> >> @@ -76,19 +76,33 @@ git_fetch() {
> >># (not allowed for a hash, unless remote is configured to permit
> >># it with allow*SHA1InWant).
> >>_depth="--depth 1"
> >> + _branch=""
> >
> > I think this is not necessary, as expanding an undefined variable is
> > permitted
> > and has the equivalent empty value.
> >
> >>if defined GIT_TAG
> >>then
> >> - _depth+=" --branch ${GIT_TAG}"
> >> + _depth=" --branch ${GIT_TAG}"
> >
> > I think this wants to be _branch, as otherwise that used but never defined?
> >
> >>elif defined GIT_BRANCH
> >>then
> >> - _depth+=" --branch ${GIT_BRANCH}"
> >> + _depth=" --branch ${GIT_BRANCH}"
> >
> > Likewise.
> >
> >>fi
> >>fi
> >>
> >># T likely doesn't exist at this point, so create it first
> >>mkdir -p ${T}
> >>cd ${T}
> >> - verbose git clone ${_depth} --no-checkout ${GIT_URI} ${GIT_MODULE}
> >> || error "git clone failed"
> >> + _gitlog=${T}/git.$$.log
> >> + verbose git clone ${_depth} ${_branch} --no-checkout ${GIT_URI}
> >> ${GIT_MODULE} |& tee ${_gitlog}
> >> + if [ ${PIPESTATUS[0]} != 0 ]
> >> + then
> >> + grep "fatal: dumb http transport does not support shallow
> >> capabilities" ${_gitlog} >& /dev/null
> >
> > Can't this just use 'grep -q' ?
> >
> > I wonder if there's a locale issue here (i.e. will git produce a localized
> > error
> > message if LANG etc. is defined?)
> >
> > Maybe depending on the precise string is too fragile, and we should just
> > unconditionally retry to see if things get better?
> >
> >> + if [ $? = 0 ]
> >> + then
> >> + warning "git clone failed, retry without --depth option"
> >> + verbose git clone ${_branch} --no-checkout ${GIT_URI} ${GIT_MODULE}
> >> || error "git clone failed"
> >> + else
> >
> > In this case, the clone failed for a different reason, but we've eaten the
> > output from git, so maybe there's no indication given as to why?
> >
> > Do we want to do something like "cat ${_gitlog}" here?
> >
> >> + error "git clone failed"
> >> + fi
> >> + fi
> >>cd ${T}/${GIT_MODULE}
> >>
> >> #v* git.cygclass/GIT_BRANCH
> >>
> >>
> >> On Mon, Nov 20, 2023 at 11:23 PM Jon Turney
Re: [ITP] gflags 2.2.2
Thank you for your review. I will merge the documentation and scripts into the runtime package. gflags.cygport diff : https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3d92ec96da0cfb58ffee465eb65eec2f0b923f19 CI : https://github.com/cygwin/scallywag/actions/runs/7085452227 On Mon, Dec 4, 2023 at 12:06 AM Jon Turney wrote: > > On 25/11/2023 08:55, Daisuke Fujimura via Cygwin-apps wrote: > >> The one question I have is about what 'gflags_completions.sh' is for? Is > >> this a helper for scripts other packages using gflags might install in > >> /etc/bash_completion.d/, or an example? or generally useful? > > > > gflags_completions.sh is a script that generates completions for > > options supported by gflags. > > > > - > > https://stackoverflow.com/questions/32555861/how-to-get-bash-tab-completions-for-your-own-project-with-gflags > > > > Also, since major distributions such as arch and fedora include this > > script in their packages, we decided it would be better to include it > > in the cygwin package as well. > > > > - https://archlinux.org/packages/extra/x86_64/gflags/files/ > > - https://src.fedoraproject.org/rpms/gflags/blob/rawhide/f/gflags.spec > > > > However, perhaps this should be included in runtime or development. > > Thanks. That makes perfect sense. > > Yeah, it seems like perhaps it should be with the runtime, I think. >
Re: [PATCH cygport] git.cygclass: Suppress the depth option
Implementations that conditionally branch on variables are simple.
The proposed retry implementation complicates git.cygclass, but I
think it reduces the maintainer's effort.
I have created a patch for a retry implementation.
Could you review it?
diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
index e53a7985..1e26ab37 100644
--- a/cygclass/git.cygclass
+++ b/cygclass/git.cygclass
@@ -76,19 +76,33 @@ git_fetch() {
# (not allowed for a hash, unless remote is configured to permit
# it with allow*SHA1InWant).
_depth="--depth 1"
+ _branch=""
if defined GIT_TAG
then
- _depth+=" --branch ${GIT_TAG}"
+ _depth=" --branch ${GIT_TAG}"
elif defined GIT_BRANCH
then
- _depth+=" --branch ${GIT_BRANCH}"
+ _depth=" --branch ${GIT_BRANCH}"
fi
fi
# T likely doesn't exist at this point, so create it first
mkdir -p ${T}
cd ${T}
- verbose git clone ${_depth} --no-checkout ${GIT_URI} ${GIT_MODULE}
|| error "git clone failed"
+ _gitlog=${T}/git.$$.log
+ verbose git clone ${_depth} ${_branch} --no-checkout ${GIT_URI}
${GIT_MODULE} |& tee ${_gitlog}
+ if [ ${PIPESTATUS[0]} != 0 ]
+ then
+ grep "fatal: dumb http transport does not support shallow
capabilities" ${_gitlog} >& /dev/null
+ if [ $? = 0 ]
+ then
+ warning "git clone failed, retry without --depth option"
+ verbose git clone ${_branch} --no-checkout ${GIT_URI} ${GIT_MODULE}
|| error "git clone failed"
+ else
+ error "git clone failed"
+ fi
+ fi
cd ${T}/${GIT_MODULE}
#v* git.cygclass/GIT_BRANCH
On Mon, Nov 20, 2023 at 11:23 PM Jon Turney wrote:
>
> On 19/11/2023 02:11, Daisuke Fujimura via Cygwin-apps wrote:
> > Some git providers do not support smart transport, so specifying the
> > depth option will result in an error.
>
> Right. This is a bug and needs fixing.
>
> Thanks for the patch.
>
> > ```
> > Cloning into ''...
> > fatal: dumb http transport does not support shallow capabilities
> > ```
> >
> > Therefore, I suggest adding a variable to suppress the depth option.
> > (Variable names should be changed to something appropriate according
> > to the naming convention.)
> >
> > diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
> > index e53a7985..0aa97a09 100644
> > --- a/cygclass/git.cygclass
> > +++ b/cygclass/git.cygclass
> > @@ -75,7 +75,12 @@ git_fetch() {
> > # shallow fetch a ref (master, branch or tag) with --depth=1
> > # (not allowed for a hash, unless remote is configured to permit
> > # it with allow*SHA1InWant).
> > - _depth="--depth 1"
> > + _depth=""
> > + # git provider does not support smart transport
> > + if ! defined GIT_PROVIDER_NOT_SUPPORT_SMART_TRANSPORT
>
> If you're going to add a variable which changes the behaviour of cygport
> like this, it should be documented (by adding an appropriate robodoc
> comment)
>
> This could just be named something a little shorter, like
> "GIT_URI_NO_SMART_TRANSPORT", since it's really a property of the URI's
> host?
>
> But I wonder if wouldn't just be better to try with --depth and then
> fallback to without it, if that fails (especially if we can tell it
> failed for that reason).
>
> (Looking at [1], that seems a better approach than trying to probe the
> URI for smart transport support, which seems problematic)
>
> [1]
> https://stackoverflow.com/questions/9270488/is-it-possible-to-detect-whether-a-http-git-remote-is-smart-or-dumb
>
> What do you think?
>
> > + then
> > + _depth="--depth 1"
> > + fi
> > if defined GIT_TAG
> > then
> > _depth+=" --branch ${GIT_TAG}"
> >
>
Re: [ITP] gflags 2.2.2
> The one question I have is about what 'gflags_completions.sh' is for? Is > this a helper for scripts other packages using gflags might install in > /etc/bash_completion.d/, or an example? or generally useful? gflags_completions.sh is a script that generates completions for options supported by gflags. - https://stackoverflow.com/questions/32555861/how-to-get-bash-tab-completions-for-your-own-project-with-gflags Also, since major distributions such as arch and fedora include this script in their packages, we decided it would be better to include it in the cygwin package as well. - https://archlinux.org/packages/extra/x86_64/gflags/files/ - https://src.fedoraproject.org/rpms/gflags/blob/rawhide/f/gflags.spec However, perhaps this should be included in runtime or development. On Tue, Nov 21, 2023 at 2:13 AM Jon Turney wrote: > > On 16/11/2023 23:20, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > [ITP] A new package proposal: gflags > > > > - gflags > > - libgflags2.2 > > - libgflags-devel > > > > > > > > SUMMARY: Commandline flags module for C++ > > HOMEPAGE: https://github.com/gflags/gflags > > SRC_URI: https://github.com/gflags/gflags/archive/refs/tags/v2.2.2.tar.gz > > LICENSE: BSD-3-Clause > > > > > > > > Corresponding Linux/Unix packages are searched: > > - https://repology.org/project/gflags/versions > > > > Cygportfile: > > - > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/gflags > > > > Packages, logs: > > - https://github.com/cygwin/scallywag/actions/runs/6893072156 > > > > Looks good. > > I've added this to your packages. > > The one question I have is about what 'gflags_completions.sh' is for? Is > this a helper for scripts other packages using gflags might install in > /etc/bash_completion.d/, or an example? or generally useful? >
[PATCH cygport] git.cygclass: Suppress the depth option
Some git providers do not support smart transport, so specifying the
depth option will result in an error.
```
Cloning into ''...
fatal: dumb http transport does not support shallow capabilities
```
Therefore, I suggest adding a variable to suppress the depth option.
(Variable names should be changed to something appropriate according
to the naming convention.)
diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
index e53a7985..0aa97a09 100644
--- a/cygclass/git.cygclass
+++ b/cygclass/git.cygclass
@@ -75,7 +75,12 @@ git_fetch() {
# shallow fetch a ref (master, branch or tag) with --depth=1
# (not allowed for a hash, unless remote is configured to permit
# it with allow*SHA1InWant).
- _depth="--depth 1"
+ _depth=""
+ # git provider does not support smart transport
+ if ! defined GIT_PROVIDER_NOT_SUPPORT_SMART_TRANSPORT
+ then
+ _depth="--depth 1"
+ fi
if defined GIT_TAG
then
_depth+=" --branch ${GIT_TAG}"
[ITP] gflags 2.2.2
Hello, [ITP] A new package proposal: gflags - gflags - libgflags2.2 - libgflags-devel SUMMARY: Commandline flags module for C++ HOMEPAGE: https://github.com/gflags/gflags SRC_URI: https://github.com/gflags/gflags/archive/refs/tags/v2.2.2.tar.gz LICENSE: BSD-3-Clause Corresponding Linux/Unix packages are searched: - https://repology.org/project/gflags/versions Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/gflags Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/6893072156
Re: [ITP] simdjson 3.6.0
Thank you for reviewing. As you pointed out, it is not appropriate to include developer documentation in the runtime package, so I will fix simdjson.cygport. On Mon, Nov 13, 2023 at 12:06 AM Jon Turney wrote: > > On 11/11/2023 08:41, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > [ITP] A new package proposal: simdjson > > > > - libsimdjson19 > > - libsimdjson-devel > > > > > > > > SUMMARY: Parsing gigabytes of JSON per second > > HOMEPAGE: https://github.com/simdjson/simdjson > > SRC_URI: > > https://github.com/simdjson/simdjson/archive/refs/tags/v3.6.0.tar.gz > > LICENSE: Apache-2.0 > > > > > > > > Corresponding Linux/Unix packages are searched: > > - https://repology.org/project/simdjson/versions > > > > Cygportfile: > > - > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/simdjson > > > > Packages, logs: > > - https://github.com/cygwin/scallywag/actions/runs/6833007543 > > > > This looks fine. > > One minor quibble I have is that you've chosen to place all of the > documentation in the runtime package. > > I'd suggest, if possible, placing the "developer documentation" (i.e. > docs describing the API and it's performance) in the devel package, > while keeping the LICENSE and README etc. with the runtime. >
[ITP] cgif 0.3.2
Hello, [ITP] A new package proposal: cgif - libcgif0 - libcgif-devel SUMMARY: GIF encoder written in C HOMEPAGE: https://github.com/dloebl/cgif SRC_URI: https://github.com/dloebl/cgif/archive/refs/tags/V0.3.2.tar.gz LICENSE: MIT Corresponding Linux/Unix packages are searched: - https://repology.org/project/cgif/versions Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/cgif Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/6834368998
[ITP] simdjson 3.6.0
Hello, [ITP] A new package proposal: simdjson - libsimdjson19 - libsimdjson-devel SUMMARY: Parsing gigabytes of JSON per second HOMEPAGE: https://github.com/simdjson/simdjson SRC_URI: https://github.com/simdjson/simdjson/archive/refs/tags/v3.6.0.tar.gz LICENSE: Apache-2.0 Corresponding Linux/Unix packages are searched: - https://repology.org/project/simdjson/versions Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/simdjson Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/6833007543
[ITP] libfastjson 1.2304.0
Hello, [ITP] A new package proposal: libfastjson - libfastjson4 - libfastjson-devel SUMMARY: Fast json library for C HOMEPAGE: https://github.com/rsyslog/libfastjson SRC_URI: https://github.com/rsyslog/libfastjson/archive/refs/tags/v1.2304.0.tar.gz LICENSE: MIT Corresponding Linux/Unix packages are searched: - https://repology.org/project/libfastjson/versions Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/libfastjson Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/6832706909
Re: [Attn Maintainer] json-c
src_test is not redefined in cmake.cygclass (and ninja.cygclass) in
cygport-0.36.3. Therefore, I defined src_test in json-c.cygport.
- https://github.com/cygwin/cygport/blob/0.36.6/cygclass/cmake.cygclass
- https://github.com/cygwin/cygport/blob/0.36.6/cygclass/ninja.cygclass
I agree that it would be preferable to have src_test defined in one of
these cygclasses.
On Sun, Oct 1, 2023 at 11:43 PM Jon Turney wrote:
>
> On 24/09/2023 13:40, Daisuke Fujimura via Cygwin-apps wrote:
> > Hi,
> >
> > I previously reported that json-c.pc seems incorrect.
> > - https://cygwin.com/pipermail/cygwin/2023-August/254350.html
> >
> > The modified version of json-c.cygport and its CI results are shown below.
> > - cygport
> >-
> > https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=42b2343c88e9ba85dd689579335a6691bb27
> > - CI
> >- https://github.com/cygwin/scallywag/actions/runs/6286740463
> >
> > Patch is also attached.
>
> Thanks.
>
> Since Marco isn't available at the moment, I did an NMU with this change.
>
> > - PATH=${B}:${PATH} ctest
> > + PATH=${B}:${PATH} ninja_test
>
> Not sure if this part is needed.
>
> But it seems like it indicates a missing piece in cygport. Perhaps there
> should be a src_test() defined by the cmake.cygclass which does
> ninja_test or ctest depending on the generator?
>
[Attn Maintainer] json-c
Hi, I previously reported that json-c.pc seems incorrect. - https://cygwin.com/pipermail/cygwin/2023-August/254350.html The modified version of json-c.cygport and its CI results are shown below. - cygport - https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=42b2343c88e9ba85dd689579335a6691bb27 - CI - https://github.com/cygwin/scallywag/actions/runs/6286740463 Patch is also attached. json-c.cygport.diff Description: Binary data
[ITA] ruby-vte 3.4.3
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-vte Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5650194808 Upstream: Ruby/vte is removed - https://github.com/ruby-gnome/ruby-gnome/blob/3.4.4/NEWS#L137 ruby-vte.cygport.diff Description: Binary data
[ITA] ruby-goocanvas1 1.2.6
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-goocanvas1 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5581096545 ruby-goocanvas1.cygport.diff Description: Binary data
[ITA] ruby-goocanvas2 2.2.0
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-goocanvas2 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5561336490 Upstream: Ruby/goocanvas is removed - https://github.com/ruby-gnome/ruby-gnome/blob/2.2.1/NEWS#L14 ruby-goocanvas2.cygport.diff Description: Binary data
[ITA] ruby-gtk3 4.1.7
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gtk3 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5538271507 ruby-gtk3.cygport.diff Description: Binary data
Re: [ITA] ruby-gtk2 3.4.3
> I don't quite understand what this last line here means? Dead upstream? Ruby/GTK2 has been removed in Ruby/GNOME 3.4.4. - https://github.com/ruby-gnome/ruby-gnome/blob/4.1.8/NEWS.rd#L418 If this is the case, should I continue to maintain Ruby/GTK2 3.4.3? It seems to be maintained in fedora. - https://src.fedoraproject.org/rpms/rubygem-gtk2 On Mon, Jul 10, 2023 at 2:08 AM Jon Turney wrote: > > On 09/07/2023 15:05, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > > > > > Cygportfile: > > - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gtk2 > > > > Packages, logs: > > - https://github.com/cygwin/scallywag/actions/runs/5500133199 > > Done, thanks. > > > Changes: > > - Remove patch : 3.2.4-cygwin-deps.patch > >- Deleted dependencies restored > > - Add patch : 3.4.3-*.patch > >- Resolve undefined references > > - Add fedora patch > > - Add CFLAGS > >- rb_cData is deprecated, removed in ruby32 > > - Fix DEPS_PATH > >- ruby-gtk2 is inactive, it does not match the latest ruby-gnome version > > I don't quite understand what this last line here means? Dead upstream? > > >
[ITA] ruby-gdk3 4.1.7
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gdk3 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5500418963 ruby-gdk3.cygport.diff Description: Binary data
[ITA] ruby-gtk2 3.4.3
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gtk2 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5500133199 Changes: - Remove patch : 3.2.4-cygwin-deps.patch - Deleted dependencies restored - Add patch : 3.4.3-*.patch - Resolve undefined references - Add fedora patch - Add CFLAGS - rb_cData is deprecated, removed in ruby32 - Fix DEPS_PATH - ruby-gtk2 is inactive, it does not match the latest ruby-gnome version ruby-gtk2.cygport.diff Description: Binary data
[ITA] ruby-gstreamer1.0 4.1.7
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gstreamer1.0 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5487698737 ruby-gstreamer1.0.cygport.diff Description: Binary data
[ITA] ruby-gdk_pixbuf2
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gdk_pixbuf2 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5443915435 ruby-gdk_pixbuf2.cygport.diff Description: Binary data
Re: [ITA] ruby-atk 4.1.7
Thank you for your advice. I wasn't sure if there was any problem mixing noarch and x86_64 in the same package, but from this description it seems safe. I plan to deploy with `ARCH=noarch`. - https://github.com/cygwin/scallywag/actions/runs/5431600438 On Wed, Jun 28, 2023 at 10:09 PM Jon Turney wrote: > > On 27/06/2023 08:32, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > > > > > Cygportfile: > > - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-atk > > > > Packages, logs: > > - https://github.com/cygwin/scallywag/actions/runs/5383991799 > > > # we have to wait until the old archful ones are archived > > #ARCH=noarch > > I'm not sure what this comment means. > > I think all the historical limitations around changing between arch and > archful have been removed [1], so if this package is now noarch, please > mark it as such. > > Otherwise, looks good. I added this to your packages. > > Thanks. > > [1] https://cygwin.com/pipermail/cygwin-apps/2019-June/039614.html
scallywag error report
I am reporting a scallywag error during git push. remote: scallywag: invoked on repository git/cygwin-packages/libhtp, by maintainer Daisuke Fujimura remote: scallywag: timeout waiting for GitHub to assign a wfr_id remote: scallywag: PLEASE REPORT THIS! remote: scallywag: build 6661 queued on github remote: scallywag: https://cygwin.com/cgi-bin2/jobs.cgi?id=6661 The job is completed, but the status seems to remain pending.
[ITA] ruby-atk 4.1.7
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-atk Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5383991799 ruby-atk.cygport.diff Description: Binary data
[ITA] ruby-pango 4.1.7
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-pango Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5362169241 ruby-pango.cygport.diff Description: Binary data
[ITA] ruby-cairo-gobject 4.1.7
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-cairo-gobject Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5330596103 Changes: - Remove PKG_IGNORE - implib is not generated without the linker option `-out-implib` ruby-cairo-gobject.cygport.diff Description: Binary data
[ITA] ruby-gio2 4.1.7
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gio2 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5295797846 ruby-gio2.cygport.diff Description: Binary data
Re: [ITA] ruby-gobject-introspection 4.1.7
Of the packages that need to be rebuilt for the latest ruby, ruby-gnome will be prioritized. https://www.cygwin.com/packages/reports/ruby_rebuilds.html - ruby-cairo-gobject - ruby-gio2 - ruby-goocanvas* - ruby-gstreamer1.0 - ruby-gtk* - ruby-pango - ruby-vte On Thu, Jun 15, 2023 at 2:39 PM Marco Atzeri via Cygwin-apps wrote: > > On 12/06/2023 16:18, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > > > > > Cygportfile: > > - > > https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gobject-introspection > > > > Packages, logs: > > - https://github.com/cygwin/scallywag/actions/runs/5244423932 > > changed maintainer > > let me know the next ones you plan to work on > as I will be off in the coming days > > Regards > Marco > >
Re: [GOLDSTAR] Re: [ITA] ruby 3.2.2
Thank you. I am deeply grateful and happy to receive this award. On Wed, Jun 14, 2023 at 12:05 AM Andrew Schulman via Cygwin-apps wrote: > > > On 19/04/2023 23:42, Daisuke Fujimura via Cygwin-apps wrote: > > > Hello, > > > > > > > > > > > > Cygportfile: > > > - > > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby > > > > > > Packages, logs: > > > - https://github.com/cygwin/scallywag/actions/runs/4743191979 > > > > According to our rules, Fujimura-san deserves one of our literally > > priceless gold stars for adopting Ruby. > > > > ... and several more, arranged into a tasteful tiara or something, for > > adopting and updating various ruby language packages. > > Awarded! https://cygwin.com/goldstars/#DF >
[ITA] ruby-gobject-introspection 4.1.7
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gobject-introspection Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5244423932 ruby-gobject-introspection.cygport.diff Description: Binary data
[ITA] ruby-glib2 4.1.7
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-glib2 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5228739944 Changes - Remove 2.2.0-rubygem-dirs.patch (Not applicable) - Add ldflags to output implib explicitly ruby-glib2.diff Description: Binary data
Re: [ITP] ruby-mini_portile2 2.8.2
Could you please rename it to `ruby-mini_portile2` instead of
`ruby-mini-portile2` so that it has the same name as the gem if
possible?
(underscore instead of hyphen)
- https://rubygems.org/gems/mini_portile2
On Thu, Jun 8, 2023 at 10:37 PM Jon Turney wrote:
>
> On 08/06/2023 14:27, Daisuke Fujimura via Cygwin-apps wrote:
> > Thank you for your response.
> > It seems that the repository has not been set up yet.
> > Could you please check?
>
> It seems like the package name was typoed ('ruby-mini-portile' rather
> than 'ruby-mini-portile2').
>
> That should be fixed now.
>
> > ```
> > $ git remote -v
> > origin
> > ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org/git/cygwin-packages/ruby-mini_portile2.git
> > (fetch)
> > origin
> > ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org/git/cygwin-packages/ruby-mini_portile2.git
> > (push)
> > $ git push origin master
> >
> > FATAL -- ACCESS DENIED
> > Repogit/cygwin-packages/ruby-mini_portile2
> > UserDaisuke_Fujimura
> > Stage Before git was called
> > Operation Repo write
> >
> > FATAL: W any git/cygwin-packages/ruby-mini_portile2 Daisuke_Fujimura
> > DENIED by fallthru
> > (or you mis-spelled the reponame)
> > fatal: Could not read from remote repository.
> >
> > Please make sure you have the correct access rights
> > and the repository exists.
> > ```
> >
Re: [ITP] ruby-mini_portile2 2.8.2
Thank you for your response. It seems that the repository has not been set up yet. Could you please check? ``` $ git remote -v origin ssh://cyg...@cygwin.com/git/cygwin-packages/ruby-mini_portile2.git (fetch) origin ssh://cyg...@cygwin.com/git/cygwin-packages/ruby-mini_portile2.git (push) $ git push origin master FATAL -- ACCESS DENIED Repogit/cygwin-packages/ruby-mini_portile2 UserDaisuke_Fujimura Stage Before git was called Operation Repo write FATAL: W any git/cygwin-packages/ruby-mini_portile2 Daisuke_Fujimura DENIED by fallthru (or you mis-spelled the reponame) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ``` On Wed, Jun 7, 2023 at 2:05 PM Marco Atzeri via Cygwin-apps wrote: > > On 06/06/2023 15:25, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > [ITP] A new package proposal: ruby-mini_portile2 > > > > - ruby-mini_portile2 > > - ruby-mini_portile2-doc > > added > > > > Reason > > - Required to build ruby-nokorigi > > also changed maintainer >
[ITP] ruby-red-colors 0.3.0
Hello, [ITP] A new package proposal: ruby-red-colors - ruby-red-colors - ruby-red-colors-doc Cygport - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-red-colors Packages and logs - https://github.com/cygwin/scallywag/actions/runs/5209875974 Reason - The latest version of ruby-cairo depends on ruby-red-colors cairo : https://rubygems.org/gems/cairo + red-colors : https://rubygems.org/gems/red-colors
[ITP] ruby-mini_portile2 2.8.2
Hello, [ITP] A new package proposal: ruby-mini_portile2 - ruby-mini_portile2 - ruby-mini_portile2-doc Cygport - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-mini_portile2 Packages and logs - https://github.com/cygwin/scallywag/actions/runs/5187561039 Reason - Required to build ruby-nokorigi - https://rubygems.org/gems/nokogiri
[ITP] ruby-matrix 0.4.2
Hello, [ITP] A new package proposal: ruby-matrix - ruby-matrix - ruby-matrix-doc Cygport - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-matrix Packages and logs - https://github.com/cygwin/scallywag/actions/runs/5187271145 Reason - The latest version of ruby-cairo depends on ruby-matrix cairo : https://rubygems.org/gems/cairo + red-colors : https://rubygems.org/gems/red-colors + matrix : https://rubygems.org/gems/matrix
[ITA] ruby-hpricot 0.8.6
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-hpricot Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5102728345 ruby-hpricot.cygport.diff Description: Binary data
[ITA] ruby-byebug 11.1.3
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-byebug Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5102700939 ruby-byebug.cygport.diff Description: Binary data
[ITA] ruby-unicorn 6.1.0
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-unicorn Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5101529707 Changes - Add runtime dependencies explicitly ruby-unicorn.cygport.diff Description: Binary data
[ITA] ruby-websocket-driver 0.7.5
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-websocket-driver Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5069702023 Changes - Add runtime dependencies explicitly Runtime dependent gems are detected from installed gems, but since scallywag does not install gems that are not explicitly listed in the cygport file, it is unable to detect runtime dependencies through automatic detection.
[ITA] ruby-raindrops 0.20.1
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-raindrops Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5086500118 ruby-raindrops.cygport.diff Description: Binary data
[ITA] ruby-sqlite3 1.6.3
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-sqlite3 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5086092688 ruby-sqlite3.cygport.diff Description: Binary data
[ITA] ruby-pkg-config 1.5.1
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-pkg-config Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5068809911 ruby-pkg-config.cygport.diff Description: Binary data
[ITA] ruby-syck 1.4.1
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-syck Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5046835338 ruby-syck.cygport.diff Description: Binary data
[ITA] ruby-yajl 1.4.3
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-yajl Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5046323775 ruby-yajl.cygport.diff Description: Binary data
[ITA] ruby-puma 6.2.2
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-puma Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5035403880 Changes - Add fedora patch ruby-puma.cygport.diff Description: Binary data
[ITA] ruby-zoom 0.5.0
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-zoom Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5045872311 Changes - LICENSE not defined - https://rubygems.org/gems/zoom (LICENSES: N/A) ruby-zoom.cygport.diff Description: Binary data
Are the dependencies in libpq-devel broken? (Re: [ITA] ruby-mysql2 0.5.5)
I have libpq-devel installed but libpq5 is not installed. https://www.cygwin.com/packages/summary/libpq-devel.html > Package: libpq-devel > depends: cygwin, libintl8, libssl-devel, pkg-config Therefore, it seems to be failing to create hints. https://github.com/cygwin/scallywag/actions/runs/5037987712/jobs/9035199432#step:6:1480 ``` which: no cygpq-5.dll in (/cygdrive/d/a/scallywag/ruby-pg/ruby-pg-1.5.3-1.x86_64/inst/usr/bin:/usr/local/bin:/usr/bin:/usr/bin:/usr/local/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows/System32) ``` Can you fix the dependencies in libpq-devel? On Sat, May 20, 2023 at 9:57 PM Marco Atzeri via Cygwin-apps wrote: > > On 20.05.2023 14:50, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > > > > > Cygportfile: > > - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-mysql2 > > > > Packages, logs: > > - https://github.com/cygwin/scallywag/actions/runs/5032175827 > > changed maintainer
[ITA] ruby-pg 1.5.3
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-pg Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5035067622 ruby-pg.cygport.diff Description: Binary data
[ITA] ruby-oj 3.14.3
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-oj Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5034669025 ruby-oj.cygport.diff Description: Binary data
[ITA] ruby-nio4r 2.5.9
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-nio4r Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5032657089 ruby-nio4r.cygport.diff Description: Binary data
[ITA] ruby-kgio 2.11.4
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-kgio Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5032362958 ruby-kgio.cygport.diff Description: Binary data
[ITA] ruby-mysql2 0.5.5
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-mysql2 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5032175827 ruby-mysql2.cygport.diff Description: Binary data
[ITA] ruby-hitimes 2.0.0
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-hitimes Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5031987345 Changes: - Add ARCH=noarch - https://github.com/copiousfreetime/hitimes/blob/main/HISTORY.md#version-200-2019-09-23 > Remove the C and Java extensions as Process.clock_gettime() has the same resolution as what the extensions did. ruby-hitimes.cygport.diff Description: Binary data
Re: [ITA] ruby-debug_inspector 1.1.0
> If you would like to provide a list of packages, I think it makes sense > to save a bit of time and effort and bulk-approve many ruby-* adoptions, > assuming that you intend to do more, and all you are doing is just > updating the version and modernizing the cygport by adding an > appropriate license etc. Yes, I intend to do so, so could you please approve the `ruby-*` adoptions? However, I would like to update these in the future only at the time of `ruby_xy` version upgrades. (except for security related issues). I think that this may be a low priority, since developers who want to use the latest gems will install them via `gem install` instead of via `setup.exe`. > Obviously, if there's anything you are uncertain of, or would just like > your changes reviewed, don't hesitate to ask here. Thank you for your concern. On Wed, May 10, 2023 at 11:28 PM Jon Turney wrote: > > On 10/05/2023 15:24, Jon Turney via Cygwin-apps wrote: > > On 09/05/2023 09:58, Daisuke Fujimura via Cygwin-apps wrote: > >> Hello, > >> > >> > >> > >> Cygportfile: > >> - > >> https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-debug_inspector > >> > >> Packages, logs: > >> - https://github.com/cygwin/scallywag/actions/runs/4920404552 > > > > Looks good. I added this to your packages. > > > > Thanks. > > If you would like to provide a list of packages, I think it makes sense > to save a bit of time and effort and bulk-approve many ruby-* adoptions, > assuming that you intend to do more, and all you are doing is just > updating the version and modernizing the cygport by adding an > appropriate license etc. > > > Obviously, if there's anything you are uncertain of, or would just like > your changes reviewed, don't hesitate to ask here. >
[ITA] ruby-debug_inspector 1.1.0
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-debug_inspector Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4920404552 ruby-debug_inspector.cygport.diff Description: Binary data
[ITA] ruby-curses 1.4.4
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-curses Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4909628745 ruby-curses.cygport.diff Description: Binary data
[ITA] ruby-bindex 0.8.1
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-bindex Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4898447211 ruby-bindex.cygport.diff Description: Binary data
Request for correction of calm/report.py
Since the h1 string in ruby_rebuild.html is still perl, I request that calm/report.py be modified to support ruby. - https://sourceware.org/git/?p=cygwin-apps/calm.git;a=blob;f=calm/reports.py;h=f659cf5f51e8a76c9f199fb09bb4a04d45ae86f4;hb=HEAD#l250
[ITA] ruby-bcrypt 3.1.18
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-bcrypt Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4890117487 ruby-bcrypt.cygport.diff Description: Binary data
Re: [ITA] ruby-tk 0.4.0
> If you can locally build a working package, you can use 'cygport upload' > to upload it (and then push the update to the packaging repo with > '--push-option=nobuild'). Thanks for the advice! I have confirmed that ruby-tk can be packaged by updating cygport and ruby-rdoc. - https://github.com/cygwin/scallywag/actions/runs/4889008372 - https://github.com/cygwin/scallywag/actions/runs/4889008372/jobs/8727225513#step:6:223 (Bin dir is correct) - https://github.com/cygwin/scallywag/actions/runs/4889008372/jobs/8727225513#step:6:1722 (ERROR not found) On Wed, May 3, 2023 at 2:22 AM Jon Turney wrote: > > On 02/05/2023 10:31, Daisuke Fujimura via Cygwin-apps wrote: > >> Is this error expected? > > > > Sorry, I missed that. > > > > This seems to be caused by rdoc-6.1.2 not working with ruby-3.x. > > > > - > > https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-keyword-arguments-in-ruby-3-0/ > > > > Therefore, it is necessary to update rdoc first, but packaging > > rdoc-6.5.0 also fails for the same reason, so it needs to be updated > > by other means besides scallywag: > > If you can locally build a working package, you can use 'cygport upload' > to upload it (and then push the update to the packaging repo with > '--push-option=nobuild'). > > > - Create a package using ruby-2.6.4. > > - Create a package using rdoc-6.5.0 installed in a different location > > with gem install. > > > > Other issues have also been found. > > > > - > > https://github.com/cygwin/scallywag/actions/runs/4850129175/jobs/8642826755#step:6:223 > > > > This seems to need a fix in rubygems.cygclass, so I will send a patch. > > > > I will work in the following order. > > > > 1. Send a patch for rubygems.cygclass > > 2. ITA ruby-rdoc > > 3. ITA ruby-tk > > Thanks very much. >
[ITA] ruby-rdoc 6.5.0
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-rdoc Packages: - https://yacp.osdn.jp/ita/ruby-rdoc/ > Therefore, it is necessary to update rdoc first, but packaging > rdoc-6.5.0 also fails for the same reason, so it needs to be updated > by other means besides scallywag: > - Create a package using ruby-2.6.4. > - Create a package using rdoc-6.5.0 installed in a different location > with gem install. I created a package with the latter. ruby-rdoc.diff Description: Binary data
[PATCH cygport] rubygems.cygclass: set relative paths in bindir
If the `--build-root` option is specified for the `gem` command, the value of the `--bindir` option must be a relative path. https://github.com/rubygems/rubygems/blob/v3.4.12/lib/rubygems/installer.rb#L678-L679 This problem seems to have occurred since this commit. https://github.com/cygwin/cygport/commit/18bd795f82d3abeff333d35ce089dd55fa2b192c rubygems.cygclass.patch Description: Binary data
Re: [ITA] ruby-tk 0.4.0
> Is this error expected? Sorry, I missed that. This seems to be caused by rdoc-6.1.2 not working with ruby-3.x. - https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-keyword-arguments-in-ruby-3-0/ Therefore, it is necessary to update rdoc first, but packaging rdoc-6.5.0 also fails for the same reason, so it needs to be updated by other means besides scallywag: - Create a package using ruby-2.6.4. - Create a package using rdoc-6.5.0 installed in a different location with gem install. Other issues have also been found. - https://github.com/cygwin/scallywag/actions/runs/4850129175/jobs/8642826755#step:6:223 This seems to need a fix in rubygems.cygclass, so I will send a patch. I will work in the following order. 1. Send a patch for rubygems.cygclass 2. ITA ruby-rdoc 3. ITA ruby-tk On Tue, May 2, 2023 at 2:56 AM Jon Turney wrote: > > On 01/05/2023 10:54, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > > > > > Cygportfile: > > - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-tk > > > > Packages, logs: > > - https://github.com/cygwin/scallywag/actions/runs/4850129175 > > Is this error expected? > > https://github.com/cygwin/scallywag/actions/runs/4850129175/jobs/8642826755#step:6:1723 > > >> If you subsequently adopt the ruby-tk package, please remember to add > >> ruby_tk_OBSOLETES="ruby-tcltk" there (as that's the preferred way to > >> record obsoletions nowadays) > > > > Added according to advice. > > Looks good. I added this to your packages. > > Thanks
[ITA] ruby-tk 0.4.0
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-tk Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4850129175 > If you subsequently adopt the ruby-tk package, please remember to add > ruby_tk_OBSOLETES="ruby-tcltk" there (as that's the preferred way to > record obsoletions nowadays) Added according to advice. ruby-tk.diff Description: Binary data
Re: [ITA] ruby 3.2.2
> Yeah, I'm not quite sure what that statement means. It's not literally > "every single binary in cygwin" > > I don't really know enough about ruby be sure how to interpret it. > There's some subset of packages which need rebuilding (as discussed > below), and maybe any locally installed gems which have binaries? As you pointed out, the sub-packages and gems installed locally using the gem command that depend on cygruby*0.dll will be subject to recompilation. I apologize for the insufficient explanation. On Wed, Apr 26, 2023 at 7:13 AM Jon Turney wrote: > > On 25/04/2023 22:10, Daisuke Fujimura via Cygwin-apps wrote: > > Thank you for your response. > > > > Following the announcement of the previous update, I would like to > > note that the binaries need to be recompiled. > > - > > https://www.mail-archive.com/cygwin-announce-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org/msg08753.html > > Yeah, I'm not quite sure what that statement means. It's not literally > "every single binary in cygwin" > > I don't really know enough about ruby be sure how to interpret it. > There's some subset of packages which need rebuilding (as discussed > below), and maybe any locally installed gems which have binaries? > > >> I applied my usual workaround (which is adding 'ruby_23' to an internal > >> list of things which are allowed to not be provided), and set the job to > >> rerun, which seems to have succeeded. > > > > Does this mean adding `ruby_23` to `depend2` in some packages in setup.ini? > > Not really. > > The failure was a consequence of that. As previously mentioned, using > some special tools, I've retroactively added appropriate ruby_xy > requires: in the .hint files for existing packages which: > > * install into /usr/lib/ruby/vendor_ruby/x.y/ > * install into /usr/lib/gems/ruby/x.y/ > * contain executable files linked to cygrubyxy0.dll because they embed a > ruby interpreter (which seems to be just kross-ruby, kf5-kross-ruby and > weechat-ruby) > > > I would like to know more about the specifications of setup.ini. Is > > there any documentation available somewhere? > > Sure, the documentation is at: > > https://sourceware.org/cygwin-apps/setup.ini.html > > Feel free to ask if you have further questions not covered by that. >
Re: [ITA] ruby 3.2.2
Thank you for your response. Following the announcement of the previous update, I would like to note that the binaries need to be recompiled. - https://www.mail-archive.com/cygwin-announce@cygwin.com/msg08753.html > I applied my usual workaround (which is adding 'ruby_23' to an internal > list of things which are allowed to not be provided), and set the job to > rerun, which seems to have succeeded. Does this mean adding `ruby_23` to `depend2` in some packages in setup.ini? I would like to know more about the specifications of setup.ini. Is there any documentation available somewhere? On Tue, Apr 25, 2023 at 10:52 PM Jon Turney wrote: > > On 25/04/2023 10:56, Daisuke Fujimura via Cygwin-apps wrote: > >> I don't think so. Please, go ahead and deploy. > > > > I tried to deploy twice, but it failed. > > > > First attempt: > > - https://github.com/cygwin/scallywag/actions/runs/4791077183 > > > > ``` > > ERROR: package 'ruby-tcltk' version '3.2.2-1' has empty install tar > > file, but it's not in ['virtual', '_obsolete'] category > > ERROR: error while validating merged x86_64 packages for Daisuke Fujimura > > SUMMARY: 2 ERROR(s) > > ``` > > > > I fixed it according to the error message. > > - > > https://cygwin.com/cgit/cygwin-packages/ruby/commit/?id=e1bc357d4ca0423b5ec92aaeb3846adf7351efa3 > > > > Thanks. > > If you subsequently adopt the ruby-tk package, please remember to add > ruby_tk_OBSOLETES="ruby-tcltk" there (as that's the preferred way to > record obsoletions nowadays) > > > Second attempt: > > - https://github.com/cygwin/scallywag/actions/runs/4791758304 > > > > ``` > > ERROR: package 'ruby-caca' version '0.99.beta19-4' depends: 'ruby_23', > > but nothing satisfies that > > ERROR: package 'ruby-marisa' version '0.2.4-2' depends: 'ruby_23', but > > nothing satisfies that > > ERROR: package 'ruby-marisa' version '0.2.4-3' depends: 'ruby_23', but > > nothing satisfies that > > ERROR: package 'ruby-openbabel' version '2.3.2-6' depends: 'ruby_23', > > but nothing satisfies that > > ERROR: package 'ruby-openbabel' version '2.3.2-5' depends: 'ruby_23', > > but nothing satisfies that > > ERROR: package 'ruby-openwsman' version '2.6.3-3' depends: 'ruby_23', > > but nothing satisfies that > > ERROR: package 'ruby-openwsman' version '2.6.3-2' depends: 'ruby_23', > > but nothing satisfies that > > ERROR: package 'ruby-xapian' version '1.2.24-1' depends: 'ruby_23', > > but nothing satisfies that > > ERROR: package 'ruby-xapian' version '1.4.5-1' depends: 'ruby_23', but > > nothing satisfies that > > ERROR: package 'ruby-zinnia' version '0.06-8' depends: 'ruby_23', but > > nothing satisfies that > > ERROR: package 'ruby-zinnia' version '0.06-9' depends: 'ruby_23', but > > nothing satisfies that > > ERROR: package 'subversion-ruby' version '1.11.1-1' depends: > > 'ruby_23', but nothing satisfies that > > ERROR: x86_64 package set has errors after removing stale packages > > ERROR: error while evaluating stale packages for Daisuke Fujimura > > SUMMARY: 14 ERROR(s) > > ``` > > > > When I deployed ruby-3.2.2, ruby-2.3.6 (which provides ruby_23) was > > moved to the vault, resulting in some ruby-* subpackages being unable > > to satisfy the dependency of ruby_23. > > > > To resolve this, the following methods are being considered: > > > > - Do not move ruby-2.3.6 to the vault (I cannot do this myself). > > - Rebuild the subpackages. > > - Any other methods? > > Yeah, calm needs to learn how to deal with this scenario better. > > Probably what should actually happen here is that these packages get > expired at the same time that the last thing providing ruby_23 gets > expired (as they can no longer be installed and thus keeping them is a > bit pointless) > > > Is there anything I can do to deploy ruby-3.2.2? > > I applied my usual workaround (which is adding 'ruby_23' to an internal > list of things which are allowed to not be provided), and set the job to > rerun, which seems to have succeeded. > > > Apologies for the inconvenience, and thanks again for updating ruby! >
Re: [ITA] ruby 3.2.2
> I don't think so. Please, go ahead and deploy.
I tried to deploy twice, but it failed.
First attempt:
- https://github.com/cygwin/scallywag/actions/runs/4791077183
```
ERROR: package 'ruby-tcltk' version '3.2.2-1' has empty install tar
file, but it's not in ['virtual', '_obsolete'] category
ERROR: error while validating merged x86_64 packages for Daisuke Fujimura
SUMMARY: 2 ERROR(s)
```
I fixed it according to the error message.
-
https://cygwin.com/cgit/cygwin-packages/ruby/commit/?id=e1bc357d4ca0423b5ec92aaeb3846adf7351efa3
Second attempt:
- https://github.com/cygwin/scallywag/actions/runs/4791758304
```
ERROR: package 'ruby-caca' version '0.99.beta19-4' depends: 'ruby_23',
but nothing satisfies that
ERROR: package 'ruby-marisa' version '0.2.4-2' depends: 'ruby_23', but
nothing satisfies that
ERROR: package 'ruby-marisa' version '0.2.4-3' depends: 'ruby_23', but
nothing satisfies that
ERROR: package 'ruby-openbabel' version '2.3.2-6' depends: 'ruby_23',
but nothing satisfies that
ERROR: package 'ruby-openbabel' version '2.3.2-5' depends: 'ruby_23',
but nothing satisfies that
ERROR: package 'ruby-openwsman' version '2.6.3-3' depends: 'ruby_23',
but nothing satisfies that
ERROR: package 'ruby-openwsman' version '2.6.3-2' depends: 'ruby_23',
but nothing satisfies that
ERROR: package 'ruby-xapian' version '1.2.24-1' depends: 'ruby_23',
but nothing satisfies that
ERROR: package 'ruby-xapian' version '1.4.5-1' depends: 'ruby_23', but
nothing satisfies that
ERROR: package 'ruby-zinnia' version '0.06-8' depends: 'ruby_23', but
nothing satisfies that
ERROR: package 'ruby-zinnia' version '0.06-9' depends: 'ruby_23', but
nothing satisfies that
ERROR: package 'subversion-ruby' version '1.11.1-1' depends:
'ruby_23', but nothing satisfies that
ERROR: x86_64 package set has errors after removing stale packages
ERROR: error while evaluating stale packages for Daisuke Fujimura
SUMMARY: 14 ERROR(s)
```
When I deployed ruby-3.2.2, ruby-2.3.6 (which provides ruby_23) was
moved to the vault, resulting in some ruby-* subpackages being unable
to satisfy the dependency of ruby_23.
To resolve this, the following methods are being considered:
- Do not move ruby-2.3.6 to the vault (I cannot do this myself).
- Rebuild the subpackages.
- Any other methods?
Is there anything I can do to deploy ruby-3.2.2?
On Tue, Apr 25, 2023 at 5:10 AM Jon Turney wrote:
>
> On 24/04/2023 00:44, Daisuke Fujimura via Cygwin-apps wrote:
> >> This is what I get for not trying these things. I think nesting the
> >> substitution like that isn't valid in bash, so maybe:
> >>
> >> SOVERSION=${VERSION%.*}
> >> ruby_PROVIDES="ruby_${SOVERSION//./}"
> >>
> >> actually works?
> >
> > It worked. Thank you very much.
> >
> > ```
> > $ cygport ruby.cygport vars ruby_PROVIDES
> > declare -- ruby_PROVIDES="ruby_32"
> > ```
> >
> > -
> > https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=9b448625c2166d5c7310c295bfa4328d24ac5444
> > -
> > https://github.com/cygwin/scallywag/actions/runs/4780609520/jobs/8498537391
> >
> >
> > I think I can release ruby-3.2.2-1 without applying the cygport patch,
> > but is there any problem if I deploy it?
>
> I don't think so. Please, go ahead and deploy.
>
> > (The cygport patch should not be needed until someone rebuilds the
> > ruby-* subpackages.)
>
> Right. Hopefully I'll get around around to doing a cygport release with
> that change this week.
>
Re: [ITA] ruby 3.2.2
> This is what I get for not trying these things. I think nesting the
> substitution like that isn't valid in bash, so maybe:
>
> SOVERSION=${VERSION%.*}
> ruby_PROVIDES="ruby_${SOVERSION//./}"
>
> actually works?
It worked. Thank you very much.
```
$ cygport ruby.cygport vars ruby_PROVIDES
declare -- ruby_PROVIDES="ruby_32"
```
-
https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=9b448625c2166d5c7310c295bfa4328d24ac5444
- https://github.com/cygwin/scallywag/actions/runs/4780609520/jobs/8498537391
I think I can release ruby-3.2.2-1 without applying the cygport patch,
but is there any problem if I deploy it?
(The cygport patch should not be needed until someone rebuilds the
ruby-* subpackages.)
On Sun, Apr 23, 2023 at 10:35 PM Jon Turney wrote:
>
> On 22/04/2023 13:04, Daisuke Fujimura via Cygwin-apps wrote:
> >>>>>> Are you planning to adopt also the ruby-* sub-packages ?
> >
> > I intend to do that.
> >
> >
> >>> 2. Modify cygport and release it.
> >>> - Add code to detect dependencies on `ruby_xy`.
> >>> - It is similar to the process for `perl5_xy0`.
> >>> -
> >>> https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L442
> >>> -
> >>> https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L639
> >>
> >> Yes.
> >>
> >> I'm not asking you to do this work though, unless you really feel like it
> >> :)
> >
> > Please review the attached diff.
>
> That looks like almost exactly what's needed.
>
> Thank you very much for that!
>
> >>> - Add `ruby_PROVIDES="ruby_${${VERSION%.*}//./}"` to ruby.cygport.
> >
> > ```
> > /tmp/cygport-ruby/ruby.cygport: line 49: ${${VERSION%.*}//./}: bad
> > substitution
> > ```
> >
> > Is the warning being displayed because $VERSION (=3.2.2) starts with a
> > number?
>
> This is what I get for not trying these things. I think nesting the
> substitution like that isn't valid in bash, so maybe:
>
> SOVERSION=${VERSION%.*}
> ruby_PROVIDES="ruby_${SOVERSION//./}"
>
> actually works?
>
Re: [ITA] ruby 3.2.2
> >>>> Are you planning to adopt also the ruby-* sub-packages ?
I intend to do that.
> > 2. Modify cygport and release it.
> > - Add code to detect dependencies on `ruby_xy`.
> > - It is similar to the process for `perl5_xy0`.
> > -
> > https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L442
> > -
> > https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L639
>
> Yes.
>
> I'm not asking you to do this work though, unless you really feel like it :)
Please review the attached diff.
> > - Add `ruby_PROVIDES="ruby_${${VERSION%.*}//./}"` to ruby.cygport.
```
/tmp/cygport-ruby/ruby.cygport: line 49: ${${VERSION%.*}//./}: bad substitution
```
Is the warning being displayed because $VERSION (=3.2.2) starts with a number?
On Sat, Apr 22, 2023 at 5:06 AM Jon Turney wrote:
>
> On 21/04/2023 20:36, Daisuke Fujimura via Cygwin-apps wrote:
> > Thank you for your review.
> >
> > Based on your review, I understand that the following steps are necessary.
> >
> > Could you please let me know if it is correct?
> >
> > 1. Release `ruby-2.6.4-2`.
> > - Add `ruby_PROVIDES="ruby_${${VERSION%.*}//./}"` to ruby.cygport.
> > - The value of this variable will be `ruby_26`.
> > - `provides: ruby_26` is added to `ruby-2.6.4-2.hint`.
>
> This isn't needed. I've retroactively modified the existing 2.6.4-1 and
> 2.6.3-1 packages to have this provide.
>
> > 2. Modify cygport and release it.
> > - Add code to detect dependencies on `ruby_xy`.
> > - It is similar to the process for `perl5_xy0`.
> > -
> > https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L442
> > -
> > https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L639
>
> Yes.
>
> I'm not asking you to do this work though, unless you really feel like it :)
>
> > 3. Rebuild `ruby-*` subpackages.
>
> Again, this isn't needed as I can retroactively modify existing packages.
>
> > - The new cygport adds `depends: ruby_26` to the hint.
>
> I've retroactively added this to the packages listed below, which
> install into /usr/lib/ruby/vendor_ruby/2.6/ a .so linked to cygruby260.dll:
>
> > - (Question) Does a gem that has no dependencies on `cygruby*.dll`
> > need to rebuild?
>
> I don't really know enough about ruby to answer that question, but
> I don't think so.
>
> > 4. Release `ruby-3.2.2-1`.
> > - The value of `provides` becomes `ruby_32`.
> > - Packages that depend on `ruby_26` will no longer be installable.
> > 5. Rebuild `ruby-*` subpackages.
> > - The rebuild adds `depends: ruby_32` to the hint.
>
> Yes.
>
> The idea is that this will ensures that packages which are installed
> together will work together, going forwards.
>
> > On Fri, Apr 21, 2023 at 1:13 AM Jon Turney wrote:
> >> On 20/04/2023 11:50, Jon Turney via Cygwin-apps wrote:
> >>> On 20/04/2023 04:28, Marco Atzeri via Cygwin-apps wrote:
> >>>> On 20.04.2023 00:42, Daisuke Fujimura via Cygwin-apps wrote:
> >>>>> Hello,
> >>>>>
> >>>>>
> >>>>>
> >>>>> Cygportfile:
> >>>>> -
> >>>>> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby
> >>>>>
> >>
> >> Looks fine. Thanks very much for updating this!
> >>
> >>>>> Packages, logs:
> >>>>> - https://github.com/cygwin/scallywag/actions/runs/4743191979
> >>>>
> >>>>
> >>>> all yours
> >>>>
> >>>> Are you planning to adopt also the ruby-* sub-packages ?
> >>>>
> >>>> Regards
> >>>> Marco
> >>>
> >>> I have a concern about how this changes a soversioned dll inside the
> >>> package (from cygruby260.dll to cygruby320.dll)
> >>>
> >>> I don't know if there's anything linked against this DLL (perhaps ruby
> >>> bindings provided by other packages) which will get broken?
> >>>
> >>> Please hold off on uploading this until I have a chance to look into
> >>> that issue a bit more.
> >> It seems we have a handful of ruby binding packages, which install a .so
> >> file into /usr/lib/ruby/vendor_ruby/2.6/ which is linked against
> >> cygruby260.dll:
> >>
> >> ruby
Re: [ITA] ruby 3.2.2
Thank you for your review.
Based on your review, I understand that the following steps are necessary.
Could you please let me know if it is correct?
1. Release `ruby-2.6.4-2`.
- Add `ruby_PROVIDES="ruby_${${VERSION%.*}//./}"` to ruby.cygport.
- The value of this variable will be `ruby_26`.
- `provides: ruby_26` is added to `ruby-2.6.4-2.hint`.
2. Modify cygport and release it.
- Add code to detect dependencies on `ruby_xy`.
- It is similar to the process for `perl5_xy0`.
-
https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L442
-
https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L639
3. Rebuild `ruby-*` subpackages.
- The new cygport adds `depends: ruby_26` to the hint.
- (Question) Does a gem that has no dependencies on `cygruby*.dll`
need to rebuild?
4. Release `ruby-3.2.2-1`.
- The value of `provides` becomes `ruby_32`.
- Packages that depend on `ruby_26` will no longer be installable.
5. Rebuild `ruby-*` subpackages.
- The rebuild adds `depends: ruby_32` to the hint.
On Fri, Apr 21, 2023 at 1:13 AM Jon Turney wrote:
>
> On 20/04/2023 11:50, Jon Turney via Cygwin-apps wrote:
> > On 20/04/2023 04:28, Marco Atzeri via Cygwin-apps wrote:
> >> On 20.04.2023 00:42, Daisuke Fujimura via Cygwin-apps wrote:
> >>> Hello,
> >>>
> >>>
> >>>
> >>> Cygportfile:
> >>> -
> >>> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby
> >>>
>
> Looks fine. Thanks very much for updating this!
>
> >>> Packages, logs:
> >>> - https://github.com/cygwin/scallywag/actions/runs/4743191979
> >>
> >>
> >> all yours
> >>
> >> Are you planning to adopt also the ruby-* sub-packages ?
> >>
> >> Regards
> >> Marco
> >
> > I have a concern about how this changes a soversioned dll inside the
> > package (from cygruby260.dll to cygruby320.dll)
> >
> > I don't know if there's anything linked against this DLL (perhaps ruby
> > bindings provided by other packages) which will get broken?
> >
> > Please hold off on uploading this until I have a chance to look into
> > that issue a bit more.
> It seems we have a handful of ruby binding packages, which install a .so
> file into /usr/lib/ruby/vendor_ruby/2.6/ which is linked against
> cygruby260.dll:
>
> ruby-gv
> ruby-marisa
> ruby-openbabel
> ruby-openwsman
> ruby-solv
> ruby-xapian
> ruby-zinnia
> subversion-ruby
>
> (There might also be some other packages which link with that dll to
> embed the ruby interpreter or something, but those are harder for me to
> identify quickly...)
>
> I think this can be handled in the same way as perl, i.e. add something
> like "ruby_PROVIDES=ruby_${${VERSION%.*}//./}" to ruby.cygport, and add
> a mechanism to cygport to make the binding packages have an additional
> dependency on that provide.
>
> I'll look into retroactively adding this to the existing ruby 2.6.x
> packages, to prevent non-working combinations of packages getting installed.
>
[ITA] ruby 3.2.2
Hello, Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4743191979 ruby.cygport.diff Description: Binary data ruby.submodule.diff Description: Binary data
Re: [ITA] rubygems 3.4.12
I had saved the ssh key because I had already used it to update other packages. Perhaps it was because the connection environment was different than usual. Thanks for the advice. On Tue, Apr 18, 2023 at 1:23 AM Brian Inglis via Cygwin-apps wrote: > > On 2023-04-17 05:29, Daisuke Fujimura via Cygwin-apps wrote: > > I tried again and succeeded. > > It seems it was a temporary problem. > > Thanks for the advice. > > > On Mon, Apr 17, 2023 at 7:40 PM Jon Turney > > wrote: > >> On 17/04/2023 11:28, Daisuke Fujimura via Cygwin-apps wrote: > >>>> I changed maintainer-ship to you > > >>> I can't push on git, is there anything else I should do? > >>> I confirmed that my name is mentioned in the rubygems section of > >>> cygwin-pkg-maint. > >>> > >>> ``` > >>> $ git remote -v > >>> origin > >>> ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org/git/cygwin-packages/rubygems.git > >>> (fetch) > >>> origin > >>> ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org/git/cygwin-packages/rubygems.git > >>> (push) > >>> $ git push origin master > >>> kex_exchange_identification: Connection closed by remote host > >>> Connection closed by 8.43.85.97 port 22 > > >> This just looks like problem establishing the ssh connection. > >> If it's not a transient problem, you can try 'ssh cyg...@cygwin.com > >> alive', and then maybe adding '-vvv' may give some hints as to what's > >> going wrong... > > >>> fatal: Could not read from remote repository. > >>> Please make sure you have the correct access rights > >>> and the repository exists. > >>> ``` > > Don't you have to make one ssh connection to save your host key, any time your > host or ssh key changes, before other operations will work? > > -- > Take care. Thanks, Brian Inglis Calgary, Alberta, Canada > > La perfection est atteinte Perfection is achieved > non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add > mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut > -- Antoine de Saint-Exupéry
Re: [ITA] rubygems 3.4.12
I tried again and succeeded. It seems it was a temporary problem. Thanks for the advice. On Mon, Apr 17, 2023 at 7:40 PM Jon Turney wrote: > > On 17/04/2023 11:28, Daisuke Fujimura via Cygwin-apps wrote: > >> I changed maintainer-ship to you > > > > I can't push on git, is there anything else I should do? > > > > I confirmed that my name is mentioned in the rubygems section of > > cygwin-pkg-maint. > > > > ``` > > $ git remote -v > > origin > > ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org/git/cygwin-packages/rubygems.git > > (fetch) > > origin > > ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org/git/cygwin-packages/rubygems.git > > (push) > > > > $ git push origin master > > kex_exchange_identification: Connection closed by remote host > > Connection closed by 8.43.85.97 port 22 > > This just looks like problem establishing the ssh connection. > > If it's not a transient problem, you can try 'ssh cyg...@cygwin.com > alive', and then maybe adding '-vvv' may give some hints as to what's > going wrong... > > > fatal: Could not read from remote repository. > > > > Please make sure you have the correct access rights > > and the repository exists. > > ``` >
Re: [ITA] rubygems 3.4.12
> I changed maintainer-ship to you
I can't push on git, is there anything else I should do?
I confirmed that my name is mentioned in the rubygems section of
cygwin-pkg-maint.
```
$ git remote -v
origin ssh://cyg...@cygwin.com/git/cygwin-packages/rubygems.git (fetch)
origin ssh://cyg...@cygwin.com/git/cygwin-packages/rubygems.git (push)
$ git push origin master
kex_exchange_identification: Connection closed by remote host
Connection closed by 8.43.85.97 port 22
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
```
On Sun, Apr 16, 2023 at 10:30 AM Daisuke Fujimura
wrote:
>
> Thank you for your review.
>
> As you indicated, we have decided that it is preferable to download
> the file from the official site.
>
> I confirmed that there are no differences in the packages.
>
> On Sun, Apr 16, 2023 at 3:20 AM Jon Turney
> wrote:
> >
> > On 14/04/2023 13:55, Daisuke Fujimura via Cygwin-apps wrote:
> > > Hello,
> > >
> > >
> > >
> > > Cygportfile:
> > > -
> > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=tree;h=refs/heads/rubygems;hb=refs/heads/rubygems
> >
> > Would it make more sense to use:
> >
> > SRC_URI="https://rubygems.org/rubygems/rubygems-${VERSION}.tgz";
> >
> > ?
> >
> >
Re: [ITA] rubygems 3.4.12
Thank you for your review.
As you indicated, we have decided that it is preferable to download
the file from the official site.
I confirmed that there are no differences in the packages.
On Sun, Apr 16, 2023 at 3:20 AM Jon Turney wrote:
>
> On 14/04/2023 13:55, Daisuke Fujimura via Cygwin-apps wrote:
> > Hello,
> >
> >
> >
> > Cygportfile:
> > -
> > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=tree;h=refs/heads/rubygems;hb=refs/heads/rubygems
>
> Would it make more sense to use:
>
> SRC_URI="https://rubygems.org/rubygems/rubygems-${VERSION}.tgz";
>
> ?
>
>
[ITA] rubygems 3.4.12
Hello, Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=tree;h=refs/heads/rubygems;hb=refs/heads/rubygems Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4698944134 rubygems.cygport.diff Description: Binary data
[ITP] bzip3 1.3.0
Hello, [ITP] A new package proposal: bzip3 - bzip3 - libbzip3_0 - libbzip3-devel SUMMARY: Better and stronger spiritual successor to BZip2 HOMEPAGE: https://github.com/kspalaiologos/bzip3 SRC_URI: https://github.com/kspalaiologos/bzip3/archive/refs/tags/1.3.0.tar.gz LICENSE: LGPL-3.0-or-later Corresponding Linux/Unix packages are searched: - https://repology.org/project/bzip3/versions Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/bzip3 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4643575116
Fwd: Error running setup-x86_64.exe: syntax error in setup.zst
I think it's the effect of the latest gnubg package, can anyone fix it? https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gnubg.git;a=blobdiff;f=gnubg.cygport;h=559ae03f174cbcd3ad7ab3fcca11ad210f45ed0f;hp=471f68c78804b0da14e7a22fa9befce86cc2521e;hb=0961ac54da1a03e8c747281f8359449636dd0db7;hpb=522ffd2cf1f6fb831f14b239058d5f589a176917 -- Forwarded message - From: Keith Thompson via Cygwin Date: Fri, Apr 7, 2023 at 10:45 AM Subject: Error running setup-x86_64.exe: syntax error in setup.zst To: Cc: Keith Thompson Running setup-x86_64.exe on a Windows 10 laptop, I get this error message: https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line 30182: syntax error, unexpected $undefined, expecting COMMA or NL https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line 30182: unrecognized line 30183 (do you have the latest setup?) https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line 30203: syntax error, unexpected $undefined, expecting COMMA or NL https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line 30203: unrecognized line 30204 (do you have the latest setup?) (I can't copy the text from the message box so I retyped it.) I re-downloaded setup-x86_64.exec, and it's identical to the one on my laptop. I'm using the mirrors.kernel.org mirror. The setup.zst from mirrors.dotsrc.org is identical. I decompressed setup.zst and I do see something suspicious on the indicated lines. Here's line 30182: build-depends: \, bison, cygport, dblatex, docbook2X, flex, gettext-devel, libGLU-devel, libcairo-devel, libcanberra-gtk-devel, libcurl-devel, libfreetype-devel, libglib2.0-devel, libgmp-devel, libgtk2.0-devel, libgtkglext1.0-devel, libpango1.0-devel, libpng-devel, libreadline-devel, libsqlite3-devel, libxslt, python3-devel, texinfo Line 30203 is similar. I don't see a lone backslash anywhere else in the file. The setup.zst from mirrors.sonic.net does *not* have problematic build-depends lines. (Switching to a different mirror might be a workaround, but I haven't tried it yet.) The "bad" setup.zst has "setup-timestamp: 1680813730" (Thu 2023-04-06 20:42:10 UTC). The "good" setup.zst has "setup-timestamp: 1680795371" (Thu 2023-04-06 15:36:11 UTC). The bad one is about 5 hours newer than the good one. I'm concerned that the bad setup.zst might propagate to other mirrors. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ITP] libhtp 0.5.42
Thank you for your review. > libhtp2_CONTENTS=" > usr/bin/*-2.dll > usr/share > " > > So that if and when the soversion changes, packaging fails, rather than > silently ploughing on to create a libhtp2 package containing > cyghtp-3.dll, with hilarious consequences. That's a good idea. - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/libhtp.git;a=blob;f=libhtp.cygport;h=6bde0aa62289a179b5c6c697c6ce621ec11de02d;hb=55abbe06056ffc608165e1904b78d540457d98bc#l33 On Wed, Apr 5, 2023 at 3:25 AM Jon Turney wrote: > > On 02/04/2023 15:17, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > [ITP] A new package proposal: libhtp > > > > - libhtp2 > > - libhtp-devel > > Thanks! > > > > > > > > > SUMMARY: Security-aware parser for the HTTP protocol > > HOMEPAGE: https://github.com/OISF/libhtp > > SRC_URI: https://github.com/OISF/libhtp/archive/refs/tags/0.5.42.tar.gz > > LICENSE: BSD-3-Clause > > > > > > > > Corresponding Linux/Unix packages are searched: > > - https://repology.org/project/libhtp/versions > > > > Cygportfile: > > - > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/libhtp > > You might want to consider writing something like: > > libhtp2_CONTENTS=" > usr/bin/*-2.dll > usr/share > " > > So that if and when the soversion changes, packaging fails, rather than > silently ploughing on to create a libhtp2 package containing > cyghtp-3.dll, with hilarious consequences. > > > > > Packages, logs: > > - https://github.com/cygwin/scallywag/actions/runs/4587137631 > > > Otherwise, looks good. > > I added this to your packages. >
[ITP] libhtp 0.5.42
Hello, [ITP] A new package proposal: libhtp - libhtp2 - libhtp-devel SUMMARY: Security-aware parser for the HTTP protocol HOMEPAGE: https://github.com/OISF/libhtp SRC_URI: https://github.com/OISF/libhtp/archive/refs/tags/0.5.42.tar.gz LICENSE: BSD-3-Clause Corresponding Linux/Unix packages are searched: - https://repology.org/project/libhtp/versions Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/libhtp Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4587137631
[ITP] tractorgen 0.31.7
Hello, [ITP] A new package proposal: tractorgen - tractorgen SUMMARY: Generates ASCII tractors HOMEPAGE: http://www.vergenet.net/~conrad/software/tractorgen/ SRC_URL: http://www.vergenet.net/~conrad/software/tractorgen/dl/tractorgen-0.31.7.tar.gz LICENSE: GPL ( https://github.com/kfish/tractorgen/#license ) Corresponding Linux/Unix packages are searched: - https://repology.org/project/tractorgen/versions Cygport - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=blob;f=tractorgen.cygport;h=64ebbaa19540f613ae942eae0b24fe3349692f91;hb=d9923d14d7c155b673004d329475688ef97df367 CI (playground): - https://cygwin.com/cgi-bin2/jobs.cgi?id=2965
Re: [ITP] cbonsai 1.0.4
Success. Thank you. - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/cbonsai.git;a=summary On Sat, May 29, 2021 at 4:18 PM Marco Atzeri via Cygwin-apps wrote: > > On 29.05.2021 08:27, Daisuke Fujimura via Cygwin-apps wrote: > > I'm trying to upload using SCALLYWAG=deploy, but I can't push. > > > > My fault. Try again
Re: [ITP] cbonsai 1.0.4
I'm trying to upload using SCALLYWAG=deploy, but I can't push. ``` $ git push --set-upstream cyg...@cygwin.com:/git/cygwin-packages/cbonsai master FATAL: W any git/cygwin-packages/cbonsai Daisuke_Fujimura DENIED by fallthru (or you mis-spelled the reponame) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. $ ``` Can you authorize me to do this? On Sat, May 29, 2021 at 3:06 PM Marco Atzeri via Cygwin-apps wrote: > > On 29.05.2021 06:37, Daisuke Fujimura via Cygwin-apps wrote: > >> please note last version is now 1.1.1 > > > > Cygport: > > - > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=blob;f=cbonsai.cygport;h=d3267ad5a022958436af71d525be30b072c03658;hb=9b70c610eefd4a00b125b5d71c764e25bb5fdc0a > > > > CI (playground): > > - https://cygwin.com/cgi-bin2/jobs.cgi?id=2094 > > - https://ci.appveyor.com/project/cygwin/scallywag/builds/39377612 > > > > Can you please review it again? > > > > no need. > > please upload
Re: [ITP] cbonsai 1.0.4
> please note last version is now 1.1.1 Cygport: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=blob;f=cbonsai.cygport;h=d3267ad5a022958436af71d525be30b072c03658;hb=9b70c610eefd4a00b125b5d71c764e25bb5fdc0a CI (playground): - https://cygwin.com/cgi-bin2/jobs.cgi?id=2094 - https://ci.appveyor.com/project/cygwin/scallywag/builds/39377612 Can you please review it again? On Sat, May 29, 2021 at 4:08 AM Marco Atzeri via Cygwin-apps wrote: > > On 27.05.2021 04:33, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > [ITP] A new package proposal: cbonsai > > > > - cbonsai > > > > > > > > SUMMARY: Grow bonsai trees in your terminal > > HOMEPAGE: https://gitlab.com/jallbrit/cbonsai > > SRC_URL: > > https://gitlab.com/jallbrit/cbonsai/-/archive/v1.0.4/cbonsai-v1.0.4.tar.bz2 > > LICENSE: GPLv3 > > > > > > > > Corresponding Linux/Unix packages are searched: > > - https://repology.org/project/cbonsai/versions > > added. > > please note last version is now 1.1.1 > >
[ITP] cbonsai 1.0.4
Hello,
[ITP] A new package proposal: cbonsai
- cbonsai
SUMMARY: Grow bonsai trees in your terminal
HOMEPAGE: https://gitlab.com/jallbrit/cbonsai
SRC_URL:
https://gitlab.com/jallbrit/cbonsai/-/archive/v1.0.4/cbonsai-v1.0.4.tar.bz2
LICENSE: GPLv3
Corresponding Linux/Unix packages are searched:
- https://repology.org/project/cbonsai/versions
Cygport
- https://yacp.osdn.jp/itp/cbonsai/cbonsai.cygport
CI (playground):
- https://cygwin.com/cgi-bin2/jobs.cgi?id=2880
- https://ci.appveyor.com/project/cygwin/scallywag/builds/39341570
Since this programs require keystrokes, I tested it manually, as
shown below.
```
$ cd ${B}
$ ./${PN}.exe
```
Re: [ITP] tty-clock 2.3
Thank you for your approval. On Thu, May 27, 2021 at 1:03 AM Marco Atzeri via Cygwin-apps wrote: > > > On 25.05.2021 23:52, Daisuke Fujimura via Cygwin-apps wrote: > > Sorry, typo in the link to the review target. > > > >> Cygport, packages and logs: > >> - https://yacp.osdn.jp/itp/tty-clocks/ > > > > https://yacp.osdn.jp/itp/tty-clock/ > > > > > >> - added BUILD_REQUIRES > >> - defined VERSION="2.3" and RELEASE=1 explicitly > > > > https://yacp.osdn.jp/itp/tty-clock/tty-clock.cygport already solves > > the above problem. > > > > Can you please review it ( > > https://yacp.osdn.jp/itp/tty-clock/tty-clock.cygport ) again? > > > > I added tty-clock to the list of packages, you can upload > > Regards > Marco >
Re: [ITP] tty-clock 2.3
Sorry, typo in the link to the review target. > Cygport, packages and logs: > - https://yacp.osdn.jp/itp/tty-clocks/ https://yacp.osdn.jp/itp/tty-clock/ > - added BUILD_REQUIRES > - defined VERSION="2.3" and RELEASE=1 explicitly https://yacp.osdn.jp/itp/tty-clock/tty-clock.cygport already solves the above problem. Can you please review it ( https://yacp.osdn.jp/itp/tty-clock/tty-clock.cygport ) again? On Wed, May 26, 2021 at 4:07 AM Marco Atzeri via Cygwin-apps wrote: > > On 25.05.2021 18:40, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > [ITP] A new package proposal: tty-clock > > > > - tty-clock > > > > > > > > SUMMARY: Clock using lib ncurses > > HOMEPAGE: https://github.com/xorg62/tty-clock > > SRC_URL: https://github.com/xorg62/tty-clock/archive/refs/tags/v2.3.tar.gz > > LICENSE: BSD-3-Clause License > > > > > > attached modified cygport > > - added BUILD_REQUIRES > - defined VERSION="2.3" and RELEASE=1 explicitly > > 1bl1 is not a good release number
[ITP] tty-clock 2.3
Hello,
[ITP] A new package proposal: tty-clock
- tty-clock
SUMMARY: Clock using lib ncurses
HOMEPAGE: https://github.com/xorg62/tty-clock
SRC_URL: https://github.com/xorg62/tty-clock/archive/refs/tags/v2.3.tar.gz
LICENSE: BSD-3-Clause License
Corresponding Linux/Unix packages are searched:
- https://repology.org/project/tty-clock/versions
Cygport, packages and logs:
- https://yacp.osdn.jp/itp/tty-clocks/
CI (playground):
- https://cygwin.com/cgi-bin2/jobs.cgi?id=2863
- https://ci.appveyor.com/project/cygwin/scallywag/builds/39316404
Prototype:
- https://github.com/fd00/yacp/commit/427603bd3547f67bb4aa34e892b42ef1614040e5
Since these programs require keystrokes, we tested them manually, as
shown below.
```
$ cd ${B}
$ ./${PN}.exe
```
Re: [ITP] no-more-secrets 0.3.3
Thank you for your approval.
On Fri, Dec 11, 2020 at 11:51 PM Ken Brown via Cygwin-apps
wrote:
>
>
>
> On 12/1/2020 7:46 AM, Daisuke Fujimura via Cygwin-apps wrote:
> > Hello,
> >
> > Can anyone please review it?
> >
> > On Sat, Nov 14, 2020 at 5:35 AM Daisuke Fujimura
> > wrote:
> >>
> >> Hello,
> >>
> >> [ITP] A new package proposal: no-more-secrets
> >>
> >> - no-more-secrets
> >>
> >>
> >>
> >> SUMMARY: Recreation of the decrypting text effect from the 1992 movie
> >> Sneakers
> >> HOMEPAGE: https://github.com/bartobri/no-more-secrets
> >> SRC_URL: https://github.com/bartobri/no-more-secrets/archive/v0.3.3.tar.gz
> >> LICENSE: GNU General Public License v3.0
> >>
> >>
> >>
> >> Corresponding Linux/Unix packages are searched:
> >> - https://repology.org/project/no-more-secrets/versions
> >>
> >> Cygport, packages and logs:
> >> - https://yacp.osdn.jp/itp/no-more-secrets/
> >>
> >> CI (playground):
> >> - https://cygwin.com/cgi-bin2/jobs.cgi?id=1254
> >> - https://ci.appveyor.com/project/cygwin/scallywag/builds/36302294
> >>
> >> Prototype:
> >> -
> >> https://github.com/fd00/yacp/tree/f5018e37cc3b6e82f55fd59cef4414fc1ee19856/no-more-secrets
> >>
> >>
> >>
> >> Since these programs require keystrokes, we tested them manually, as
> >> shown below.
> >>
> >> ```
> >> $ cd ${B}
> >> $ ./bin/nms.exe -a < LICENSE
> >> $ ./bin/sneakers.exe
> >> ```
>
> GTG.
>
> Ken
Re: [ITP] no-more-secrets 0.3.3
Hello,
Can anyone please review it?
On Sat, Nov 14, 2020 at 5:35 AM Daisuke Fujimura wrote:
>
> Hello,
>
> [ITP] A new package proposal: no-more-secrets
>
> - no-more-secrets
>
>
>
> SUMMARY: Recreation of the decrypting text effect from the 1992 movie Sneakers
> HOMEPAGE: https://github.com/bartobri/no-more-secrets
> SRC_URL: https://github.com/bartobri/no-more-secrets/archive/v0.3.3.tar.gz
> LICENSE: GNU General Public License v3.0
>
>
>
> Corresponding Linux/Unix packages are searched:
> - https://repology.org/project/no-more-secrets/versions
>
> Cygport, packages and logs:
> - https://yacp.osdn.jp/itp/no-more-secrets/
>
> CI (playground):
> - https://cygwin.com/cgi-bin2/jobs.cgi?id=1254
> - https://ci.appveyor.com/project/cygwin/scallywag/builds/36302294
>
> Prototype:
> -
> https://github.com/fd00/yacp/tree/f5018e37cc3b6e82f55fd59cef4414fc1ee19856/no-more-secrets
>
>
>
> Since these programs require keystrokes, we tested them manually, as
> shown below.
>
> ```
> $ cd ${B}
> $ ./bin/nms.exe -a < LICENSE
> $ ./bin/sneakers.exe
> ```
Re: [ITP] gti 1.7.0
Thank you for your approval. On Fri, Nov 13, 2020 at 4:57 AM Marco Atzeri via Cygwin-apps wrote: > > On 11.11.2020 20:42, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > [ITP] A new package proposal: gti > > > > - gti > > > > > > > > GTG
Please advice for create a package with no soversion specified
I'm trying to create a package for googletest, but no soversion is specified in the original source. - https://github.com/google/googletest/issues/3113 What soversion should I set if I want to set my own soversion in cygwin with no soversion specified? 1. 0 (default for autotools) - https://github.com/OpenMandrivaAssociation/gtest/blob/master/googletest-1.8.0-sonames.patch 2. 1.10.0 (software version) - https://www.archlinux.org/packages/community/x86_64/gtest/ 3. other than the above - https://packages.debian.org/bullseye/amd64/libgtest-dev/filelist (provide static only)
