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
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
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:
>
, for verification rather than gpg signatures, for example
.asc, .sig, .sign, etc;
use these checksum files when provided in a similar manner to gpg signatures;
these files are often provided with fixed names which may be renamed
on download to unique values using cygport URI fragment support like
#/$NAME
,
.sign, etc;
use these checksum files when provided in a similar manner to gpg
signatures;
these files are often provided with fixed names which may be renamed
on download
to unique values using cygport URI fragment support like
#/$NAME-VERSION.sha...sum;
use coreutils cksum as it supports all
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
gt; > > > +}
> > > > Sorry I didn't notice this before, and I am terrible at writing shell,
> > > > but perhaps you could share the reasoning behind writing this as above,
> > > > and not as, e.g.
> > > >
> > > > (cd ${top} && env BLAH $
in a similar manner to gpg signatures;
these files are often provided with fixed names which may be renamed on download
to unique values using cygport URI fragment support like
#/$NAME-VERSION.sha...sum;
use coreutils cksum as it supports all modern and legacy checksums and formats.
https://repo.or.cz
my cached signed upstream package downloads and compared the
logs from gpg2 --verify and gpgv2, so what benefit is reporting trust level
"[unknown]" and expired keys from cygport, and what are you meant to do about
expired keys for upstream package signers?
[While checking also came across
as, e.g.
(cd ${top} && env BLAH ${cmd})
avoiding all the verbiage in the description of ANNOUNCE_EDITOR about it
being fed into 'bash -c' (and hence getting evaluated twice??) rather
than just run?
None of the mentioned variables are exported to the environment by cygport.
I wanted to ke
avoiding all the verbiage in the description of ANNOUNCE_EDITOR about it
> > being fed into 'bash -c' (and hence getting evaluated twice??) rather
> > than just run?
> >
> >
>
> None of the mentioned variables are exported to the environment by cygport.
> I wante
-licenses
file intended to distribute with cygport. The file is grep'able.and
reduced to the bare minimum for this use case.
and everything under:
https://github.com/spdx/license-list-data
I didn't find a single file which lists the licenses there.
GH does not always make access easy
Brian Inglis via Cygwin-apps writes:
> Utility gpgv2 is the gpg2 release of gpgv, a lighter, script friendly,
> single operation gpg verification helper designed for use in scripts
> instead of gpg2 --verify: see 'info gpg2 helper gpgv'
NAK. This tool doesn't check for expired keys and also
gpg signatures;
> these files are often provided with fixed names which may be renamed on
> download
> to unique values using cygport URI fragment support like
> #/$NAME-VERSION.sha...sum;
> use coreutils cksum as it supports all modern and legacy checksums and
> formats.
https:/
n provided with fixed names which may be renamed on download
to unique values using cygport URI fragment support like
#/$NAME-VERSION.sha...sum;
use coreutils cksum as it supports all modern and legacy checksums and formats.
define __sum_verify() after __gpg_verify();
add to readonly function defin
From: "Brian Inglis"
Utility gpgv2 is the gpg2 release of gpgv, a lighter, script friendly,
single operation gpg verification helper designed for use in scripts
instead of gpg2 --verify: see 'info gpg2 helper gpgv'
__gpg_verify(): use gpgv2 not gpg2 --verify
Signed-off-by: Brian Inglis
---
On 28/04/2024 13:21, Christian Franke via Cygwin-apps wrote:
ASSI via Cygwin-apps wrote:
Christian Franke via Cygwin-apps writes:
_FORTIFY_SOURCE=3 is supported by Cygwin 3.5.0 headers and Cygwin gcc
13.2.1 test release.
Silently falls back to level 2 if level 3 is unsupported (older
headers
On 2024-04-30 15:07, Christian Franke via Cygwin-apps wrote:
Brian Inglis via Cygwin-apps wrote:
On 2024-04-30 11:45, Christian Franke via Cygwin-apps wrote:
The new script uses the SPDX webpages to create the license file. I didn't
find a usable single license list at https://github.com/spdx
Brian Inglis via Cygwin-apps wrote:
On 2024-04-30 11:45, Christian Franke via Cygwin-apps wrote:
...
Attached.
The new script uses the SPDX webpages to create the license file. I
didn't find a usable single license list at https://github.com/spdx
What about:
On 2024-04-30 11:45, Christian Franke via Cygwin-apps wrote:
Jon Turney via Cygwin-apps wrote:
PS: I have a local script which checks SPDX Identifiers and expressions. Any
interest to add this to cygport and then check LICENSE settings?
Oh, yes please. That sounds like a good idea.
Attached
Jon Turney via Cygwin-apps wrote (thread "[PATCH cygport] Add
repro-finish command"):
...
PS: I have a local script which checks SPDX Identifiers and
expressions. Any interest to add this to cygport and then check
LICENSE settings?
Oh, yes please. That sounds like a good idea.
Jon Turney wrote:
On 10/03/2024 16:33, Christian Franke via Cygwin-apps wrote:
Jon Turney wrote:
On 23/02/2024 11:23, Christian Franke via Cygwin-apps wrote:
Christian Franke wrote:
The email generated by the cygport announce command is useful, but
actual use cases are somewhat limited due
:
If the path of the top build directory contains a symlink and the
project's build scripts normalize pathnames, no debug info is
created by cygport.
This is because options like
-fdebug-prefix-map=${B}=/usr/src/debug/${PF}
have no effect because ${B} contains a symlink but the compiler is
run
On 10/03/2024 16:33, Christian Franke via Cygwin-apps wrote:
Jon Turney wrote:
On 23/02/2024 11:23, Christian Franke via Cygwin-apps wrote:
Christian Franke wrote:
The email generated by the cygport announce command is useful, but
actual use cases are somewhat limited due to the hard-coded
*
functions.
PS: I have a local script which checks SPDX Identifiers and expressions.
Any interest to add this to cygport and then check LICENSE settings?
Oh, yes please. That sounds like a good idea.
On 10/03/2024 15:44, Christian Franke via Cygwin-apps wrote:
Jon Turney wrote:
On 01/03/2024 13:13, Christian Franke via Cygwin-apps wrote:
It IMO makes sense to compress large and rarely viewed doc files like
change logs. This seems to be common practice on Debian etc.
With current cygport
ASSI via Cygwin-apps wrote:
Christian Franke via Cygwin-apps writes:
_FORTIFY_SOURCE=3 is supported by Cygwin 3.5.0 headers and Cygwin gcc
13.2.1 test release.
Silently falls back to level 2 if level 3 is unsupported (older
headers or gcc) or to level 0 if unsupported at all (C++, clang).
Christian Franke via Cygwin-apps writes:
> _FORTIFY_SOURCE=3 is supported by Cygwin 3.5.0 headers and Cygwin gcc
> 13.2.1 test release.
>
> Silently falls back to level 2 if level 3 is unsupported (older
> headers or gcc) or to level 0 if unsupported at all (C++, clang).
Well, if only that was
ing 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://g
=/usr/share/cygport/tools/dwarf-parse.pl" is the right
incantation.
Perhaps "DWARF_PARSE=1" could be a shorthand for that?
[Sorry still makes me think Dwarvish and Runes e.g.
https://www.evertype.com/standards/iso10646/pdf/cirth.pdf
and if you say ELF I still think zwolf, dre
have some comments in it that you can't believe I
> mean that literally...
As the saying goes: Communication is possible, but improbable…
> Well, OK. This is less useful to people who actually want to use it,
> though, requiring them to know that
> "DWARF_PARSE=/usr/share/cy
habit grown over decades, I always keep an escape hatch for using
local (modified) copies in such scripts.
Well, OK. This is less useful to people who actually want to use it,
though, requiring them to know that
"DWARF_PARSE=/usr/share/cygport/tools/dwarf-parse.pl" is the right
incanta
; Then maybe some comments about what assumptions it's making about the
> human-readable output it's parsing.
So you're asking for a manpage, really. Should be doable with enough
round tuits.
> cygport goes to some lengths to identify the correct objdump to use
> when cross-building,
and expressions.
Any interest to add this to cygport and then check LICENSE settings?
--
Regards,
Christian
From b08796262308cf1b3a2c063349d024a5ccfd2455 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Mon, 11 Mar 2024 12:12:32 +0100
Subject: [PATCH] Add repro-finish command
This command removes
On 23/02/2024 11:16, Christian Franke via Cygwin-apps wrote:
Brian Inglis via Cygwin-apps wrote:
On 2024-02-21 07:25, Christian Franke via Cygwin-apps wrote:
Change variable name from $s to $has or $s_have as variable $s usually
implies only the plural letter s or nothing; e.g.
...
+
On 23/02/2024 12:09, Christian Franke via Cygwin-apps wrote:
Harmless bug ...
Applied. Thanks.
On 01/03/2024 19:16, Christian Franke via Cygwin-apps wrote:
Christian Franke wrote:
This could be used to check whether a package is possibly
reproducible. Then it could make sense to add a reasonable
SOURCE_DATE_EPOCH value to the cygport file.
[...]
An enhanced version of the patch
Jon Turney wrote:
On 23/02/2024 11:23, Christian Franke via Cygwin-apps wrote:
Christian Franke wrote:
The email generated by the cygport announce command is useful, but
actual use cases are somewhat limited due to the hard-coded email
submission.
The attached patch adds more flexibility
Jon Turney wrote:
On 01/03/2024 13:13, Christian Franke via Cygwin-apps wrote:
It IMO makes sense to compress large and rarely viewed doc files like
change logs. This seems to be common practice on Debian etc.
With current cygport, the following results in ChangeLog and
ChangeLog.gz
On 01/03/2024 13:13, Christian Franke via Cygwin-apps wrote:
It IMO makes sense to compress large and rarely viewed doc files like
change logs. This seems to be common practice on Debian etc.
With current cygport, the following results in ChangeLog and
ChangeLog.gz in the docdir
Jon Turney wrote:
On 26/02/2024 19:53, Christian Franke via Cygwin-apps wrote:
Would it not make more sense to just re-export it if set?
If the cygport file decides to set but not export it, there is
possibly no need to do it. An example is smartmontools.cygport which
passes
On 28/02/2024 15:54, Christian Franke via Cygwin-apps wrote:
Found during testing of 'repro-check' patch with getent-2.18.90-5 source
package.
This patch also removes the requirement to set TZ=UTC before patches are
generated.
Applied, but the commentary could stand to be clearer about
On 23/02/2024 11:23, Christian Franke via Cygwin-apps wrote:
Christian Franke wrote:
The email generated by the cygport announce command is useful, but
actual use cases are somewhat limited due to the hard-coded email
submission.
The attached patch adds more flexibility. The patch is on top
On 26/02/2024 19:53, Christian Franke via Cygwin-apps wrote:
Would it not make more sense to just re-export it if set?
If the cygport file decides to set but not export it, there is possibly
no need to do it. An example is smartmontools.cygport which passes the
unexported variable
t 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. cy
Christian Franke wrote:
This could be used to check whether a package is possibly
reproducible. Then it could make sense to add a reasonable
SOURCE_DATE_EPOCH value to the cygport file.
Example:
$ export SOURCE_DATE_EPOCH=$(date +%s)
$ cygport project.cygport all repro-check
...
*** Info
It IMO makes sense to compress large and rarely viewed doc files like
change logs. This seems to be common practice on Debian etc.
With current cygport, the following results in ChangeLog and
ChangeLog.gz in the docdir:
src_install()
{
...
dodoc ChangeLog
gzip -9 -n "${D}/usr/shar
Christian Franke wrote:
Further tests of 'repro-check' patch revealed that the "origsrc/*"
timestamps in patch files contain the local timezone offset.
This would be no longer needed for patch files if "Modify origsrc
timestamp in patch files if SOURCE_DATE_EPOCH is used" would be applied.
Found during testing of 'repro-check' patch with getent-2.18.90-5 source
package.
This patch also removes the requirement to set TZ=UTC before patches are
generated.
--
Regards,
Christian
From 342ff5113499a83b2ffda441ddc80b4952b400f8 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date:
ul 20 18:27:20 LMT -1141705158
$ date -d @$((-(1<<56)))
date: time ‘-72057594037927936’ is out of range
Would it not make more sense to just re-export it if set?
If the cygport file decides to set but not export it, there is possibly
no need to do it. An example is smartmontools.cygport whic
"SOURCE_DATE_EPOCH=something cygport foo" work as expected?)
Thanks, this is great!
On 18/02/2024 19:51, ASSI via Cygwin-apps wrote:
[...]
dwarf-parse.-pl
There should be some build system changes which install this file,
probably in /usr/share/cygport/tools/, which it can then be run from.
--8<---cut here---st
Harmless bug ...
--
Regards,
Christian
From b1074f4cfe549c852be7fa59d85d312c9579cf0d Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Fri, 23 Feb 2024 13:04:21 +0100
Subject: [PATCH] Fix variable expansion in error message of embedded SMTP perl
script
---
lib/pkg_upload.cygpart | 2 +-
Christian Franke wrote:
The email generated by the cygport announce command is useful, but
actual use cases are somewhat limited due to the hard-coded email
submission.
The attached patch adds more flexibility. The patch is on top of the
"Use correct wording if only one package is anno
Brian Inglis via Cygwin-apps wrote:
On 2024-02-21 07:25, Christian Franke via Cygwin-apps wrote:
Change variable name from $s to $has or $s_have as variable $s usually
implies only the plural letter s or nothing; e.g.
...
+ local has="s have"
+
+ [ $pkg_count != 1 ] || has=" has"
...
On 2024-02-21 07:25, Christian Franke via Cygwin-apps wrote:
Change variable name from $s to $has or $s_have as variable $s usually implies
only the plural letter s or nothing; e.g.
...
+ local has="s have"
+
+ [ $pkg_count != 1 ] || has=" has"
...
+The following package${has} been
The email generated by the cygport announce command is useful, but
actual use cases are somewhat limited due to the hard-coded email
submission.
The attached patch adds more flexibility. The patch is on top of the
"Use correct wording if only one package is announced" patch.
Only cosmetic ...
--
Regards,
Christian
From f1381ebc872f3b099c257677e2b8d5bf2451bb23 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Wed, 21 Feb 2024 13:35:14 +0100
Subject: [PATCH] Use correct wording if only one package is announced
---
lib/pkg_upload.cygpart | 5 -
1 file
Marco Atzeri via Cygwin-apps writes:
> if works should not be the default ?
Let's start with interested parties giving it a spin, shall we? ONce
configured into your .cygportrc it essentially is the default for all
your builds.
> Reducing that time is very interesting for the big stuff
That's
Further tests of 'repro-check' patch revealed that the "origsrc/*"
timestamps in patch files contain the local timezone offset.
The attached patch is on top of the "Add more checks of
SOURCE_DATE_EPOCH" patch. It could also be applied independently but
then requires conflict resolution due to
On 18/02/2024 20:51, ASSI via Cygwin-apps wrote:
Cygport uses "objdump -d -l" to extract the list of source files that
need to be copied into the debuginfo package. This operation triggers
some O(N²) or even higher complexity and in addition has been getting
slower in recent binutil
Cygport uses "objdump -d -l" to extract the list of source files that
need to be copied into the debuginfo package. This operation triggers
some O(N²) or even higher complexity and in addition has been getting
slower in recent binutils releases due to more and more information
This could be used to check whether a package is possibly reproducible.
Then it could make sense to add a reasonable SOURCE_DATE_EPOCH value to
the cygport file.
Example:
$ export SOURCE_DATE_EPOCH=$(date +%s)
$ cygport project.cygport all repro-check
...
*** Info: Build reproducibility test
On 16/02/2024 11:59, Daisuke Fujimura via Cygwin-apps wrote:
Thank you for merging.
I have confirmed that this modification has resulted in the intended behaviour.
[...]
$ head -3 agbsum-15-1bl1.cygport
HOMEPAGE="https://mandelbrot.dk/${PN};
GIT_URI="https://mandelbrot.dk/${PN
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
From b04c8f5e9becd6e91095e2add551f72870c9e869 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Fri, 16 Feb 2024 13:16:06 +0100
Subject: [PATCH] Add more checks of SOURCE_DATE_EPOCH
Fail if it is out of range. Warn if it lies in the future.
Inform whether it is set or set but not
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
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
(older
headers or gcc) or to level 0 if unsupported at all (C++, clang).
Thanks. I applied this.
I'm thinking I want to try to do another cygport release fairly
soonish, so please feel free to remind me about any other patches by
you (or others) which I need to look at before then.
Possibly
wrote:
On 16/09/2023 15:17, Christian Franke via Cygwin wrote:
Found during tests of busybox package:
If the path of the top build directory contains a symlink and
the project's build scripts normalize pathnames, no debug info
is created by cygport.
This is because options like
-fdebug-prefix
++, clang).
Thanks. I applied this.
I'm thinking I want to try to do another cygport release fairly
soonish, so please feel free to remind me about any other patches by
you (or others) which I need to look at before then.
Possibly some initial SOURCE_DATE_EPOCH support:
https://sourceware.org
applied this.
I'm thinking I want to try to do another cygport release fairly soonish,
so please feel free to remind me about any other patches by you (or
others) which I need to look at before then.
_FORTIFY_SOURCE=3 is supported by Cygwin 3.5.0 headers and Cygwin gcc
13.2.1 test release.
Silently falls back to level 2 if level 3 is unsupported (older headers
or gcc) or to level 0 if unsupported at all (C++, clang).
--
Regards,
Christian
From 1a32375682d0e5ff6b80a47de70d3d9cfe0f0780
On 16/12/2023 15:38, Daisuke Fujimura via Cygwin-apps wrote:
I have implemented a curl-based smart transport check. How about this one?
Thanks.
Again, sorry about my terrible slowness in reviewing this.
diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
index e53a7985..f3ed343e
On 2024-01-06 14:16, Jon Turney via Cygwin-apps wrote:
On 06/01/2024 20:10, Brian Inglis via Cygwin-apps wrote:
Updating gsasl to 2.2.1 local package build runs fine, but github scallywag
now fails in two places:
- cygport src_prep src_patch_apply_hook now fails to find patch file passed
On 06/01/2024 20:10, Brian Inglis via Cygwin-apps wrote:
Updating gsasl to 2.2.1 local package build runs fine, but github
scallywag now fails in two places:
- cygport src_prep src_patch_apply_hook now fails to find patch file
passed as $1:
I've looked at the cygport, but what you're doing
Updating gsasl to 2.2.1 local package build runs fine, but github scallywag now
fails in two places:
- cygport src_prep src_patch_apply_hook now fails to find patch file passed as
$1:
```
>>> Preparing gsasl-2.2.1-1.x86_64
>>> Unpacking source gsasl-2.2.1.tar.gz
patch -b
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.cygcla
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}"
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
Attached is the patch after my edits.
From 825353de17d828cd3e6a2a2863f4ea661136c6bb Mon Sep 17 00:00:00 2001
From: Daisuke Fujimura
Date: Sun, 3 Dec 2023 18:44:05 +
Subject: [PATCH cygport] git.cygclass: Retry without the depth option
Some git providers do not support smart transport, so spe
53a7985..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
().
Similar code has been added to lib/pkg_pkg.cygpart __pkg_srcpkg() for
check and definition and __gpg_sign() for use in gpg signing of Cygwin
patches and files.
We should just switch to gpg2 an require that, there is no point in
trying to use GPG 1.x anymore.
https://repo.or.cz/cygport/rpm
to use GPG 1.x anymore.
https://repo.or.cz/cygport/rpm-style.git/commitdiff/84279e484726a68cc8f08e7c9126bef13d9510d7
++1?
should I just retire gpg 1.x and stop having gpg2 as different binary name ?
Or obsolete 1 with 2 and add compatibility symlinks or scripts?
Keep names separate so easy
().
Similar code has been added to lib/pkg_pkg.cygpart __pkg_srcpkg() for
check and definition and __gpg_sign() for use in gpg signing of Cygwin
patches and files.
We should just switch to gpg2 an require that, there is no point in
trying to use GPG 1.x anymore.
https://repo.or.cz/cygport/rpm
been added to lib/pkg_pkg.cygpart __pkg_srcpkg() for
> check and definition and __gpg_sign() for use in gpg signing of Cygwin
> patches and files.
We should just switch to gpg2 an require that, there is no point in
trying to use GPG 1.x anymore.
https://repo.or.cz/cygport/
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--- /usr/share/cygport/lib/src_prep.cygpart.orig2023-08-07
09:46:31.0 -0600
+++ /usr/share/cygport/lib/src_prep.cygpart
y key fingerprint: AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD
--- /usr/share/cygport/lib/pkg_pkg.cygpart.orig 2023-03-08 06:07:57.0
-0700
+++ /usr/share/cygport/lib/pkg_pkg.cygpart 2023-11-19 21:13:16.879391200
-0700
@@ -505,7 +505,7 @@ __gpg_sign() {
echo "${2} si
Jon Turney via Cygwin-apps writes:
> 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
# 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
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
final command in the chain, *including within functions*. In most
> functions in cygport, a non-zero return code will cause cygport to
> error, but because the && chain disables `set -e`, failures within
> src_install are silently ignored. Counterintuitively, having the &&
On Sun, Nov 05, 2023 at 10:24:43PM +, Adam Dinwoodie via Cygwin-apps wrote:
> ```
> #!/usr/bin/bash
>
> src_install () {
> false
> echo "This step *does* run"
> }
>
> src_install && echo "As does this step"
> ```
The above example should have had `set -e` at the top. Everything
command in a pipeline
will cause the script to exit. So both with and without my patch, a
non-zero return code from __prepinstalldirs, src_install or
__src_postinst will cause execution to stop.
The issue is that the && chain disables `set -e` for anything other than
the final command in the chain,
Adam Dinwoodie via Cygwin-apps writes:
> When running as part of a `&&` chain, Bash's `set -e` behaviour is
> suppressed entirely, which means calls that produce non-zero error codes
> will be ignored if they're called inside functions that are part of such
> a chain.
>
> To avoid silent failures
When running as part of a `&&` chain, Bash's `set -e` behaviour is
suppressed entirely, which means calls that produce non-zero error codes
will be ignored if they're called inside functions that are part of such
a chain.
To avoid silent failures from commands in a src_install function being
I've discovered what I _think_ is a cygport bug: most functions within
cygport run with `set -e` enabled in Bash, so if a command has a
non-zero return code that isn't explicitly handled, that'll cause the
cygport command overall to fail. This doesn't work within src_install,
and I _suspect_
In 2eb7c0eb I started making
an effort so that if the "source inputs" have fixed, upstream
timestamps, we'll preserve those in the output the source package.
(Obviously that's not always going to be the case, e.g. where cygport
patches are from a local git checkout, so maybe that's n
:
Found during tests of busybox package:
If the path of the top build directory contains a symlink and
the project's build scripts normalize pathnames, no debug info
is created by cygport.
This is because options like
-fdebug-prefix-map=${B}=/usr/src/debug/${PF}
have no effect because ${B
of busybox package:
If the path of the top build directory contains a symlink and the
project's build scripts normalize pathnames, no debug info is
created by cygport.
This is because options like
-fdebug-prefix-map=${B}=/usr/src/debug/${PF}
have no effect because ${B} contains a symlink
1 - 100 of 1189 matches
Mail list logo
