Re: Where should relnote updates for Cygwin DLL patches be going?

ou explain why? > > I think I haven't been paying close enough attention and have been doing the > relnote updates by rote. But there being two active branches and I > (understandably) don't determine which releases my commits go to means I > should wait until they sh

Re: Where should relnote updates for Cygwin DLL patches be going?

determine which releases my commits go to means I should wait until they show up on the cvs-patches list, then I will know which relnote files to update. That should work OK, right? Is it preferred that relnote updates should be separate patches from the code updates? Thanks, ..mark

Re: Where should relnote updates for Cygwin DLL patches be going?

On Jul 11 01:05, Mark Geisert wrote: > AIUI for cygwin-3_4-branch they currently go to release/3.4.8. > For the main|master branch they currently go where? release/3.5.0 An entry there is only necessary if it doesn't get picked for 3.4 anyway. > I hope to get it right the first time ;-). Is

Where should relnote updates for Cygwin DLL patches be going?

AIUI for cygwin-3_4-branch they currently go to release/3.4.8. For the main|master branch they currently go where? I hope to get it right the first time ;-). Thank you, ..mark

Re: Patches to findutils 4.9.0-1's updatedb to do locking, allow filenames with spaces & progress monitoring, exclude /dev on Cygwin, etc.

since my Linux systems use a different version of locate, I hadn't tested there (nor did I have time to look at the original 4.9.0 source).  I'd been hoping any Cygwin patches wouldn't invalidate it; pity. b) The patch changes the file 'updatedb' which is created at build time instead of th

Re: Patches to findutils 4.9.0-1's updatedb to do locking, allow filenames with spaces & progress monitoring, exclude /dev on Cygwin, etc.

e description says that there are 10 more or less non-trivial changes in it. A squashed diff of 500 lines on a file with 342 lines makes reviewing and discussing of each topic impossible. Would you mind re-sending as separate Git patches? Have a nice day, Berny -- Problem reports:

Patches to findutils 4.9.0-1's updatedb to do locking, allow filenames with spaces & progress monitoring, exclude /dev on Cygwin, etc.

ts by Dan Harkless.  #exec 2> /tmp/updatedb-trace.txt  #set -x +ourname=`basename $0`  # don't verbosely report path to the script in errors + +stderr() { +    echo "$ourname: $*" >&2 +} +  version=' -updatedb (GNU findutils) 4.9.0 +updatedb (GNU findutils) 4.9.0+patches

Re: distutils adoption means cygwin-specific patches will be lost

“import distutils” to resolve to `setuptools._distutils` and thus bypass any patches that may have been applied to distutils as found in the stdlib) with an escape hatch: by setting SETUPTOOLS_USE_DISTUTILS=stdlib. Due to incompatibilities identified with this ereleases, the behavior of using

distutils adoption means cygwin-specific patches will be lost

._distutils` and thus bypass any patches that may have been applied to distutils as found in the stdlib) with an escape hatch: by setting SETUPTOOLS_USE_DISTUTILS=stdlib. Due to incompatibilities identified with this ereleases, the behavior of using the local distutils by default was rolled back

Re: [PATCHES] cygport

Jon Turney writes: > Let me add a 'R-b' for "stop generating packages for obsoletions", > which I almost wasted time writing again. I've just updated the branch with two new things I found a need for: https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream The patch Jon was

Re: [PATCHES] cygport

On 20/02/2021 08:15, Achim Gratz wrote: Achim Gratz writes: I've rebased several of my patches that have been offered before (and a new one) on top of the current upstream and would like to see them picked up: https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream The first

Re: [PATCHES] cygport

Achim Gratz writes: > I've rebased several of my patches that have been offered before (and a > new one) on top of the current upstream and would like to see them > picked up: > > https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream > > The first two ar

[PATCHES] cygport

I've rebased several of my patches that have been offered before (and a new one) on top of the current upstream and would like to see them picked up: https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream The first two are needed for building Perl and Perl distributions

Re: [PATCH 0/3] FAQ api, programming, timezone, setup patches

On 2020-08-25 05:04, Corinna Vinschen wrote: > Hi Brian, > > On Aug 24 14:10, Brian Inglis wrote: >> winsup/doc/faq-api.xml,faq-programming.xml: change Win32 to Windows > > Didn't we agree on WinAPI? Windows is fine when used in the context of > the OS, but Win32 was mainly used to denote the

[PATCH v2 0/3] FAQ setup, using, programming, api, timezone, patches

FAQ updates from suggestions made in various posts Brian Inglis (3): winsup/doc/faq-setup.xml,faq-using.xml: update setup FAQ winsup/doc/faq-api.xml,-programming.xml: change Win32 to Windows or Windows API winsup/doc/faq-api.xml(faq.api.timezone): explain time zone updates

Re: [PATCH 0/3] FAQ api, programming, timezone, setup patches

Hi Brian, On Aug 24 14:10, Brian Inglis wrote: > winsup/doc/faq-api.xml,faq-programming.xml: change Win32 to Windows Didn't we agree on WinAPI? Windows is fine when used in the context of the OS, but Win32 was mainly used to denote the API. So "Windows API" or, better, WinAPI, should be used

[PATCH 0/3] FAQ api, programming, timezone, setup patches

winsup/doc/faq-api.xml,faq-programming.xml: change Win32 to Windows winsup/doc/faq-api.xml(faq.api.timezone): explain time zone updates winsup/doc/faq-setup.xml: update setup FAQ winsup/doc/faq-api.xml | 39 -- winsup/doc/faq-programming.xml | 20 +-- winsup/doc/faq-setup.xml

Re: cmake upstream has merged cygwin patches

;> Hi. > >>> > > >> Thanks Lem, > >> > >> I am impressed, in the past we had much more discussion for having our > >> patches merged upstream. > >> > >> If you want to take over or just co-maintain, > >> let me know &g

Re: cmake upstream has merged cygwin patches

On 08.08.2020 02:47, Lemures Lemniscati via Cygwin-apps wrote: On Fri, 7 Aug 2020 21:51:00 +0200, Marco Atzeri via Cygwin-apps On 07.08.2020 18:06, Lemures Lemniscati via Cygwin-apps wrote: Hi. Thanks Lem, I am impressed, in the past we had much more discussion for having our patches

Re: cmake upstream has merged cygwin patches

On Fri, 7 Aug 2020 21:51:00 +0200, Marco Atzeri via Cygwin-apps > On 07.08.2020 18:06, Lemures Lemniscati via Cygwin-apps wrote: > > Hi. > > > > The cygwin patches for cmake-3.17.3 have been merged into its upstream > > (though I should have discussed for it here). &g

Re: cmake upstream has merged cygwin patches

On 07.08.2020 18:06, Lemures Lemniscati via Cygwin-apps wrote: Hi. The cygwin patches for cmake-3.17.3 have been merged into its upstream (though I should have discussed for it here). Merged by there merge-requests: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5092 https

cmake upstream has merged cygwin patches

Hi. The cygwin patches for cmake-3.17.3 have been merged into its upstream (though I should have discussed for it here). Merged by there merge-requests: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5092 https://gitlab.kitware.com/utils/kwsys/-/merge_requests/197 Merged patches

Re: [PATCH] COMMIT_MSG - cygport patches

Sorry, These cygport patches were expected to allow edits as usual but just went! Minor "unrelated" ~/.gitconfig changes seem to have removed confirmation. This should have been an -F COMMIT_MSG but I typed -m COMMIT_MSG. The next fixes a cygport announce SMTP server issue using cod

Re: cygport patches for consideration

On Sun, 2020-05-10 at 10:58 +0200, Achim Gratz wrote: > I've reworked the series according to your comments, force-pushed to the > same branch: > > https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream Merged, but changed NO_PERL_DEPS to PERL_NO_VENDOR_DEPS. -- Yaakov

Re: cygport patches for consideration

Yaakov Selkowitz writes: […] I've reworked the series according to your comments, force-pushed to the same branch: https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User

Re: cygport patches for consideration

Yaakov Selkowitz writes: >> I guess I can change my cygport generator instead to use >> CPAN_DIR when needed, but haven't got around doing so. > > Depending on its size, it would be nice to get this generator into > cygport's tools, and could possibly be used as the basis for other such >

Re: cygport patches for consideration

On Tue, 2020-04-07 at 18:52 +0200, Achim Gratz wrote: > Yaakov Selkowitz writes: > > > support subdirectories in CPAN download URL > > > > There is no need for two variables to do the same thing. I like > > Reini's idea but let's call it CPAN_SUBDIR instead. What about the > > attached

Re: cygport patches for consideration

On 07/04/2020 17:52, Achim Gratz wrote: Yaakov Selkowitz writes: Automatically create a test release if the release string starts with a literal "0" Nak. There is not necessarily any correlation between a -0.* release and whether it should be test or not. Then there ought to be. :-)

Re: cygport patches for consideration

On Sun, 2020-04-05 at 20:54 +0200, Achim Gratz wrote: > I've prepared a branch on top of current master for your perusal: > > https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream > > As you can see they've been battle-tested by me for quite some time already: > > commit

Re: cygport patches for consideration

postinstall script must not install files if _anything_ with the > same name already exists. Change the test from '-f' to '-e'. If > /usr/bin/diff is installed and the target is a plain file, show the > diff to the default so the user can decide more easily what to

cygport patches for consideration

I've prepared a branch on top of current master for your perusal: https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream As you can see they've been battle-tested by me for quite some time already: commit 779a7dd2fc834d45fb0f46cded647557ece17d8f (to-upstream) Date: Sat

Re: Historical package patches?

Hello Marco, On 11/30/19 4:23 AM, Marco Atzeri wrote: > Am 30.11.2019 um 06:44 schrieb Daniel Santos: >> Hello all, >> >> I'm trying to troubleshoot an issue with an old version of rsync on >> Cygwin.  Is there a git repo somewhere with historical patches?  The >

Re: Historical package patches?

Am 30.11.2019 um 06:44 schrieb Daniel Santos: Hello all, I'm trying to troubleshoot an issue with an old version of rsync on Cygwin.  Is there a git repo somewhere with historical patches?  The version in question is 3.0.4.  This is on a remote machine that I can't change, so I'm trying

Historical package patches?

Hello all, I'm trying to troubleshoot an issue with an old version of rsync on Cygwin.  Is there a git repo somewhere with historical patches?  The version in question is 3.0.4.  This is on a remote machine that I can't change, so I'm trying to decipher what I can from the logs. Thanks, Daniel

Re: Cygwin patches (was Re: [PATCH 00/14] FIFO bug fixes and code simplifications)

On Apr 18 21:00, Ken Brown wrote: > On 4/18/2019 3:04 PM, Corinna Vinschen wrote: > > Ken, you have an account on sware and check-in rights to the cygwin repo > > anyway, so you don't really need me to push patches. > > > > If you feel up to the task, you c

Re: Cygwin patches (was Re: [PATCH 00/14] FIFO bug fixes and code simplifications)

On 4/18/2019 3:04 PM, Corinna Vinschen wrote: > Ken, you have an account on sware and check-in rights to the cygwin repo > anyway, so you don't really need me to push patches. > > If you feel up to the task, you can also go ahead and review and > ultimately push patches from oth

Re: Cygwin patches (was Re: [PATCH 00/14] FIFO bug fixes and code simplifications)

On Apr 18 21:34, Achim Gratz wrote: > Corinna Vinschen writes: > >> No testing will be possible for me in the next two weeks, sorry. > > > > I'll be afk all of March, too. > > So, the past month? :-D s/March/May/ Sorry, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc

Re: Cygwin patches (was Re: [PATCH 00/14] FIFO bug fixes and code simplifications)

Corinna Vinschen writes: >> No testing will be possible for me in the next two weeks, sorry. > > I'll be afk all of March, too. So, the past month? :-D Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11:

Cygwin patches (was Re: [PATCH 00/14] FIFO bug fixes and code simplifications)

; > No testing will be possible for me in the next two weeks, sorry. I'll be afk all of March, too. Ken, you have an account on sware and check-in rights to the cygwin repo anyway, so you don't really need me to push patches. If you feel up to the task, you can also go ahead and revi

[newlib-cygwin] Cygwin: Add console patches to release notes

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=de3c82ee6d28be3aa72a9c4f6e498505af79c2f3 commit de3c82ee6d28be3aa72a9c4f6e498505af79c2f3 Author: Corinna Vinschen Date: Sun Mar 31 19:36:23 2019 +0200 Cygwin: Add console patches to release notes Signed-off-by: Corinna

[newlib-cygwin] Cygwin: document /proc//status and /proc//statm patches

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=09c114d7e2938782328def7b1d934942061db5e9 commit 09c114d7e2938782328def7b1d934942061db5e9 Author: Corinna Vinschen Date: Fri Aug 17 19:21:51 2018 +0200 Cygwin: document /proc//status and /proc//statm patches Signed-off

Re: Workflow for producing patches with cygport?

Thank you. There is no documentation for this from 'cygport --help' or 'man cygport'. Is this an oversight? Matt D. On 11/4/2017 9:04 AM, Jon Turney wrote: On 04/11/2017 10:45, Matt D. wrote: I've gotten this far: download cygport download package src cd /usr/src/package*

Re: Workflow for producing patches with cygport?

On 04/11/2017 10:45, Matt D. wrote: I've gotten this far:   download cygport   download package src   cd /usr/src/package*   cygport package.cygport prep I can now edit the source, compile, etc. But what is the workflow for producing a patch file of my changes? You can use 'cygport

Workflow for producing patches with cygport?

I've gotten this far: download cygport download package src cd /usr/src/package* cygport package.cygport prep I can now edit the source, compile, etc. But what is the workflow for producing a patch file of my changes? Matt D. -- Problem reports:

[PATCH setup 0/9] Setup patches

Add the --user-agent option, and fix a couple of bugs, including those mentioned in the thread https://cygwin.com/ml/cygwin/2017-05/msg00513.html Ake Rehnman (1): Avoid messagebox spam with file:// protocol URLs Jon Turney (8): Allow options which only have long names Alphabetically sort

[PATCH setup 00/10] Various setup patches

Oh, I think I can see a bit of floor over there! Jon Turney (10): isBinary() should return true for orphaned packages Correctly calculate total data to checksum when using IncludeSource Rename category "Misc" to "Orphaned" Make PrereqChecker::setTrust() a static method Move and rename

[PATCH setup 00/15] Various setup patches

Still lacking a convenient river to divert to wash out the filth Jon Turney (15): Add Makefile rule to rename build products to form used when uploading Don't bother storing prev version Rename "Internet Explorer Proxy Settings" to "System Proxy Settings" Remove packageversion::sources(),

[PATCH cygport 0/3] cygport patches

Jon Turney (3): Pass DEPEND through to .hint for source package as build-depends: Don't allow SRC_URI or PATCH_URI to depend on ARCH Update documentation of all and almostall README | 4 ++-- bin/cygport.in | 26 ++ lib/help.cygpart| 3 ++-

[PATCH setup 00/11] Various setup patches

More cleaning out of the Augean stables. Jon Turney (11): Remove pointless abstract base class IniDBBuilder Remove unused package_status_t stored in packageversion class Remove cygpackage::destroy() because it does nothing Make packageversion::source(|s) const Use const version of

Re: [PATCH 0/3] Updated patches for /proc//environ

On Tue, Jan 10, 2017 at 4:41 PM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > On Jan 10 16:02, Erik Bray wrote: >> From: "Erik M. Bray" <erik.b...@lri.fr> >> >> Updated versions of the patch set originally submitted at >> https://cygwin.co

Re: [PATCH 0/3] Updated patches for /proc//environ

On Jan 10 16:02, Erik Bray wrote: > From: "Erik M. Bray" <erik.b...@lri.fr> > > Updated versions of the patch set originally submitted at > https://cygwin.com/ml/cygwin-patches/2017-q1/msg0.html > > I think all the indentation/whitespace/braces are cleaned

Re: [PATCH setup 0/4] Various setup patches

On Dec 12 13:29, Jon Turney wrote: > Dregs of my patch queue :) > > Jon Turney (4): > Use English button labels 'Keep', 'Current' and 'Test' > Fully initialize PROPSHEETPAGE > Remove unused grammar for dependent package architecture information Looks good. Please apply. Thanks, Corinna

[PATCH setup 0/4] Various setup patches

Dregs of my patch queue :) Jon Turney (4): Use English button labels 'Keep', 'Current' and 'Test' Fully initialize PROPSHEETPAGE Remove unused grammar for dependent package architecture information Codesign setup.exe (DO NOT APPLY) .gitignore | 2 ++ Makefile.am | 13 +++--

Re: [PATCH setup 0/5] Various setup patches

On Nov 18 16:46, Jon Turney wrote: > Jon Turney (5): > Give search edit box autohscroll style > Fix validation in RootPage > Ignore malformed lines in a site-list > Start chooser in "Pending" view if this is not a first time > installation > Simplify PickView::insert_pkg Looks good

[PATCH setup 0/5] Various setup patches

Jon Turney (5): Give search edit box autohscroll style Fix validation in RootPage Ignore malformed lines in a site-list Start chooser in "Pending" view if this is not a first time installation Simplify PickView::insert_pkg PickView.cc | 26 +++--- choose.cc |

Re: calm: two patches

Jon Turney writes: > Firstly, this doesn't do what's wanted (always use Base64 encoded > hashes), as the hash is only computed here if it's not available from > a sha512.sum file (which mirror maintenance scripts on sourceware > generate for us) > > So, I guess the correct change would be to

Re: calm: two patches

On 17/09/2016 17:51, Achim Gratz wrote: From 3fa17efb7049f7cc20c119c0a696e4f4212dd6bc Mon Sep 17 00:00:00 2001 From: Achim Gratz Date: Sat, 17 Sep 2016 18:49:19 +0200 Subject: [PATCH 2/2] Write human-readable time in addition to

calm: two patches

>From f35d1d01e83b6e319b249f736b69eb4e4e677d6d Mon Sep 17 00:00:00 2001 From: Achim Gratz Date: Sat, 17 Sep 2016 18:47:44 +0200 Subject: [PATCH 1/2] Use Base64URL encoding for the checksums * calm/package.py (sha512_file): Import base64 and use Base64URL encoding for

Re: [PATCH setup 00/10] Various setup patches

On Aug 4 19:56, Achim Gratz wrote: > Corinna Vinschen writes: > >> The checksum information has to come from somewhere and that somewhere > >> requires a package install or update. Together with that new setup we > >> might > >> have an update of cygccheck and some unrelated packages that

Re: [PATCH setup 00/10] Various setup patches

Corinna Vinschen writes: >> People tend to not re-install their whole set of packages just because >> some new version of setup is announced, > > Uhm? If you download a new setup, but then don't update your packages, > why did you download the latest setup at all? If you don't run this > new

Re: [PATCH setup 00/10] Various setup patches

On Aug 3 20:27, Achim Gratz wrote: > Corinna Vinschen writes: > >> That would be either supplemental files with the hashes or some new .lst > >> format which could/should use a different extension anyway since the > >> transition period will be long. > > > > Why? The transition period can be

Re: [PATCH setup 00/10] Various setup patches

On Aug 3 11:51, Achim Gratz wrote: > Corinna Vinschen writes: > > *If* we do that, the setup files should go under /var/lib/setup. > > Yes. > > > However, why would this make sense exactly? Yes, I know LSB and yada > > yada, but why *exactly* would that make sense in *our* situation? > > In

Re: [PATCH setup 00/10] Various setup patches

On Aug 2 16:30, Jon Turney wrote: > Jon Turney (10): > Remove stray execute permissions > Prevent libtool warning that a getopt++ shared library cannot be built > Add lex and yacc generated files to .gitignore > Downgrade "Running preremove script" logging to debug > Properly report

Re: [PATCH setup 00/10] Various setup patches

Corinna Vinschen writes: > *If* we do that, the setup files should go under /var/lib/setup. Yes. > However, why would this make sense exactly? Yes, I know LSB and yada > yada, but why *exactly* would that make sense in *our* situation? In this case it's just a clean way to separate the old and

Re: [PATCH setup 00/10] Various setup patches

On Aug 3 09:10, Achim Gratz wrote: > Jon Turney writes: > > Track if a package was installed by user, or as a dependency > > Add an additional filter view, showing packages which were user picked > > As a suggestion (and I won't have time for implementation help at the > moment): Please

Re: [PATCH setup 00/10] Various setup patches

Jon Turney writes: > Track if a package was installed by user, or as a dependency > Add an additional filter view, showing packages which were user picked As a suggestion (and I won't have time for implementation help at the moment): Please consider keeping /etc/setup/installed.db at version

Re: cygport patches for TeX Live

On 2016-04-15 12:33, Ken Brown wrote: I'm attaching three patches that I used in preparing the recent test release of the TeX Live collections. The first is self-explanatory. The second and third reflect the fact that I'm now shipping .tlpobj files and maintaining /usr/share/tlpkg/texlive.tlpdb

cygport patches for TeX Live

Yaakov, I'm attaching three patches that I used in preparing the recent test release of the TeX Live collections. The first is self-explanatory. The second and third reflect the fact that I'm now shipping .tlpobj files and maintaining /usr/share/tlpkg/texlive.tlpdb, so that tlmgr knows what

qt patches which seem to make gnuplot qt terminal work on cygwin were uploaded on gnuplot site

in the post against the qt in the cygwin? Tatsuro -- View this message in context: http://cygwin.1069669.n5.nabble.com/qt-patches-which-seem-to-make-gnuplot-qt-terminal-work-on-cygwin-were-uploaded-on-gnuplot-site-tp118143.html Sent from the Cygwin list mailing list archive at Nabble.com

[PATCH setup 0/4] Setup misc patches

Jon TURNEY (4): Fix truncation of Bin? and Src? column headers Add a 'Retry' button to the IDD_FILE_INUSE dialog Don't write LOG_BABBLE output to stdout Remove msg() from LogFile::endEntry() LogFile.cc | 9 +++-- PickView.cc | 16 +--- install.cc | 22

Re: [setup] Makefile.am patches

On 02/18/2015 08:44 AM, Corinna Vinschen wrote: I inspected your code and played around with git-tag and git-describe so it's ok. While tagging for the next release, I noticed this: $ git describe release_2.869-14-g10cac83 $ git describe --match release_\* --abbrev=6 HEAD

Re: [setup] Makefile.am patches

On Feb 18 08:55, Eric Blake wrote: On 02/18/2015 08:44 AM, Corinna Vinschen wrote: I inspected your code and played around with git-tag and git-describe so it's ok. While tagging for the next release, I noticed this: $ git describe release_2.869-14-g10cac83 $ git

Re: [setup] Makefile.am patches

On Feb 16 11:31, Corinna Vinschen wrote: On Feb 16 10:52, Achim Gratz wrote: Corinna Vinschen writes: I saw some .gitattributes file mentioning exactly this ChangeLog merging in the binutils-gdb repo and copied it over so it's part of our repo as well. That deals with the problem

Re: [setup] Makefile.am patches

On Feb 16 23:10, Achim Gratz wrote: Corinna Vinschen writes: The question is, can this be automated so that a commit automatically adds the entry to the ChangeLog file and commit the ChangeLog file at the same time? Or is there some problem with that approach? That way lies madness,

Re: [setup] Makefile.am patches

Corinna Vinschen writes: On Feb 16 16:03, Achim Gratz wrote: Corinna Vinschen writes: I'm more interested in seeing if you can push and how the log message on cygwin-apss-cvs looks like since I made some script changes... Pushed. Thanks. The commit message on cygwin-apps-cvs looks

Re: [setup] Makefile.am patches

Corinna Vinschen writes: Sounds good to me. However, I don't understand it. I expected that it writens the changelog entry automatically to the ChangeLog file, but it doesn't. I just tested it in a local branch. I added this: [merge merge-changelog] name = GNU-style ChangeLog

Re: [setup] Makefile.am patches

On Feb 16 11:22, Eric Blake wrote: On 02/16/2015 02:12 AM, Corinna Vinschen wrote: On Feb 15 17:36, Achim Gratz wrote: Corinna Vinschen writes: We're not going to skip writing ChangeLog entries. If there is some automatism to write *correctly formatted* ChangeLog entries from the git

Re: [setup] Makefile.am patches

On 02/15/2015 07:35 AM, Corinna Vinschen wrote: We're not going to skip writing ChangeLog entries. If there is some automatism to write *correctly formatted* ChangeLog entries from the git commit message, then that method can and should be used. Coreutils and several other GNU projects use

Re: [setup] Makefile.am patches

On 02/16/2015 02:12 AM, Corinna Vinschen wrote: On Feb 15 17:36, Achim Gratz wrote: Corinna Vinschen writes: We're not going to skip writing ChangeLog entries. If there is some automatism to write *correctly formatted* ChangeLog entries from the git commit message, then that method can and

Re: [setup] Makefile.am patches

of the possible interaction of patches sent via email. The subject line might have been folded if it gets too long, so the first paragraph becomes the first line of the commit message. The formatting of the rest of the message (after the first blank line) is kept and becomes the actual commit

Re: [setup] Makefile.am patches

On 16/02/2015 20:52, Corinna Vinschen wrote: On Feb 16 20:34, Achim Gratz wrote: Corinna Vinschen writes: I'm rather confused now. So I don't need git-merge-changelog for automation and I don't need gitlog-to-changelog if I keep the ChangeLog logs. If I don't need any one of them, what *do*

Re: [setup] Makefile.am patches

Corinna Vinschen writes: I'm more interested in seeing if you can push and how the log message on cygwin-apss-cvs looks like since I made some script changes... Pushed. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld:

Re: [setup] Makefile.am patches

On Feb 16 16:03, Achim Gratz wrote: Corinna Vinschen writes: I'm more interested in seeing if you can push and how the log message on cygwin-apss-cvs looks like since I made some script changes... Pushed. Thanks. The commit message on cygwin-apps-cvs looks decent now, doesn't it? I

Re: [setup] Makefile.am patches

On Feb 16 10:52, Achim Gratz wrote: Corinna Vinschen writes: I saw some .gitattributes file mentioning exactly this ChangeLog merging in the binutils-gdb repo and copied it over so it's part of our repo as well. That deals with the problem of merging log files. If you do keep a manual

Re: [setup] Makefile.am patches

Corinna Vinschen writes: I inspected your code and played around with git-tag and git-describe so it's ok. THanks, I'm more interested in seeing if you can push and how the log message on cygwin-apss-cvs looks like since I made some script changes... Later today… Regards, Achim. -- +[Q+

Re: [setup] Makefile.am patches

On Feb 15 17:36, Achim Gratz wrote: Corinna Vinschen writes: We're not going to skip writing ChangeLog entries. If there is some automatism to write *correctly formatted* ChangeLog entries from the git commit message, then that method can and should be used. If they're correctly

Re: [setup] Makefile.am patches

Corinna Vinschen writes: I saw some .gitattributes file mentioning exactly this ChangeLog merging in the binutils-gdb repo and copied it over so it's part of our repo as well. That deals with the problem of merging log files. If you do keep a manual log just about any merge would create a

Re: [setup] Makefile.am patches

On Feb 14 20:06, Achim Gratz wrote: First patch to follow the usual convention of using annotated release tags for determining the version (tag 4782666e90 as release_2.869 for testing). I'm at a loss. Right now, after my last checkin, we're simply continuing to use the ChangeLog version

Re: [setup] Makefile.am patches

Corinna Vinschen writes: On Feb 14 20:06, Achim Gratz wrote: First patch to follow the usual convention of using annotated release tags for determining the version (tag 4782666e90 as release_2.869 for testing). I'm at a loss. Right now, after my last checkin, we're simply continuing to

[setup] Makefile.am patches

First patch to follow the usual convention of using annotated release tags for determining the version (tag 4782666e90 as release_2.869 for testing). From 8d41c6e21673ce22f30e1b4738fe0bf7cdf7e09a Mon Sep 17 00:00:00 2001 From: Achim Gratz strom...@stromeko.de Date: Sat, 14 Feb 2015 18:42:12

Re: cygport patches for TeX Live

/postinstall for the postinstall markers. I'm attaching revised cygport patches. I applied and pushed patches 1 and 3; given the texlive/fontconfig discussion, does 2 still apply? Not as it stands. But for users who have chosen to make the TeX Live fonts available to fontconfig

Re: cygport patches for TeX Live

for this purpose unless there is yet another more specific requirement I didn't find while browsing it. In view of https://cygwin.com/ml/cygwin-apps/2015-01/msg00034.html, I'll use /var/lib/texmf/postinstall for the postinstall markers. I'm attaching revised cygport patches. I applied and pushed

Re: cygport patches for TeX Live

didn't find while browsing it. In view of https://cygwin.com/ml/cygwin-apps/2015-01/msg00034.html, I'll use /var/lib/texmf/postinstall for the postinstall markers. I'm attaching revised cygport patches. I applied and pushed patches 1 and 3; given the texlive/fontconfig discussion, does 2 still

Re: cygport patches for TeX Live

more specific requirement I didn't find while browsing it. In view of https://cygwin.com/ml/cygwin-apps/2015-01/msg00034.html, I'll use /var/lib/texmf/postinstall for the postinstall markers. I'm attaching revised cygport patches. I applied and pushed patches 1 and 3; given the texlive

Re: cygport patches for TeX Live

-apps/2015-01/msg00034.html, I'll use /var/lib/texmf/postinstall for the postinstall markers. I'm attaching revised cygport patches. I'm also attaching, for reference, the corresponding revised perpetual postinstall scripts. Ken From 13b65df78a27fde439b263ee3a0dbaf3dbba1c85 Mon Sep 17 00:00

Re: cygport patches for TeX Live

On 1/5/2015 2:51 AM, Yaakov Selkowitz wrote: On 2014-12-18 07:11, Ken Brown wrote: On 12/18/2014 3:22 AM, Achim Gratz wrote: Ken Brown writes: +if [ -d /usr/share/texmf-dist ] Looks like you'd want if [ -d ${D}/usr/share/texmf-dist ] here. Thanks. I hope this is the last of the

Re: cygport patches for TeX Live

Ken Brown writes: Do you have an opinion about that? I suggested /etc/texmf/postinstall or /var/lib/texmf/postinstall, but Achim had other ideas. The only precedent we have so far is Achim's new _autorebase, which uses /etc/rebase. Even for this I think /etc is the wrong place and I'd

Re: cygport patches for TeX Live

On 2014-12-18 07:11, Ken Brown wrote: On 12/18/2014 3:22 AM, Achim Gratz wrote: Ken Brown writes: +if [ -d /usr/share/texmf-dist ] Looks like you'd want if [ -d ${D}/usr/share/texmf-dist ] here. Thanks. I hope this is the last of the careless mistakes. Patch 0001 applied with

Re: cygport patches for TeX Live

Ken Brown writes: + if [ -d /usr/share/texmf-dist ] Looks like you'd want if [ -d ${D}/usr/share/texmf-dist ] here. In postinstall scripts we remove the updmap calls completely and instead create a file of commands in /etc/texmf/postinstall, to be run by a perpetual postinstall

Re: cygport patches for TeX Live

On 12/18/2014 9:22 AM, Achim Gratz wrote: Ken Brown writes: + if [ -d /usr/share/texmf-dist ] Looks like you'd want if [ -d ${D}/usr/share/texmf-dist ] here. In postinstall scripts we remove the updmap calls completely and instead create a file of commands in

  1   2   3   4   5   6   7   >