Re: [PATCH rebase] Make rebaseall a wrapper around the autorebase postinstall, script
On Jul 21 09:50, Ken Brown wrote: > On 7/21/2022 5:09 AM, Corinna Vinschen wrote: > > We're using the "?p=" URLs on the cygin-apps website, too. Maybe it's > > just me, but to me it looks better if we change this to the 2nd form > > where possible. What do you think? > > I agree that it looks better without the ?p=. I have no idea why the latter > is used on the cygwin-apps website. > > > Just a style issue, but the two functions should stay first in the file. > > Please move this code just right before the trap call. > > > > Other than that, LGTM. > > I've made all the changes you suggested and pushed it. Great, I pushed a patch to simplify the URLs and added a link from the Cygwin homepage to the cygwin apps homepage. Thanks, Corinna
Re: [PATCH rebase] Make rebaseall a wrapper around the autorebase postinstall, script
On 7/21/2022 5:09 AM, Corinna Vinschen wrote: We're using the "?p=" URLs on the cygin-apps website, too. Maybe it's just me, but to me it looks better if we change this to the 2nd form where possible. What do you think? I agree that it looks better without the ?p=. I have no idea why the latter is used on the cygwin-apps website. Just a style issue, but the two functions should stay first in the file. Please move this code just right before the trap call. Other than that, LGTM. I've made all the changes you suggested and pushed it. Ken
Re: [PATCH rebase] Make rebaseall a wrapper around the autorebase postinstall, script
Hi Ken,
On Jul 20 16:14, Ken Brown wrote:
> Patch attached.
> From bcbc7f9768854a6e6aaf1a450cdaabc61241ea9d Mon Sep 17 00:00:00 2001
> Homepage:
>
>
> The primary rebase web site is:
>
> -http://www.tishler.net/jason/software/rebase/
> +https://cygwin.com/git/?p=cygwin-apps/rebase.git
Shouldn't that be https://sourceware.org/cygwin-apps/ ?
I mean, it's the only real web page apart from git access.
Also
https://cygwin.com/git/?p=cygwin-apps/rebase.git
vs.
https://cygwin.com/git/cygwin-apps/rebase.git
Both work but the 2nd URL avoids that ugly ?p=.
We're using the "?p=" URLs on the cygin-apps website, too. Maybe it's
just me, but to me it looks better if we change this to the 2nd form
where possible. What do you think?
> Download:
>
>
> -The primary rebase download site is:
> -
> -http://www.tishler.net/jason/software/rebase/
> -
> -Access to the CVS development sources is available:
> +Access to the git development sources is available:
>
> -cvs -d:pserver:anon...@cygwin.com:/cvs/cygwin-apps co rebase
> +git clone git://cygwin.com/git/cygwin-apps/rebase.git
Better use https here, rather than git.
> DefaultFileList=
> DefaultSuffixes='dll|so|oct'
>
> +# Determine platform
> +Platform=`uname -s`
> +case $Platform in
> + *MINGW* | *mingw* ) Platform=mingw ;;
> + *CYGWIN* | *cygwin* ) Platform=cygwin ;;
> + *MSYS* | *msys* ) Platform=msys ;;
> + * )
> +echo "Unsupported platform: $Platform" 1>&2
> +exit 1
> +;;
> +esac
> +
> +# On Cygwin, just call the _autorebase postinstall script
> +case $Platform in
> + cygwin)
> +if [ "$#" -gt 0 ]
> +then
> + echo "usage: ${ProgramName}"
> + exit 1
> +fi
> +exec /etc/postinstall/0p_000_autorebase.dash
> +;;
> + *)
> +;;
> +esac
> +
> # Define functions
> usage()
> {
Just a style issue, but the two functions should stay first in the file.
Please move this code just right before the trap call.
Other than that, LGTM.
Thanks,
Corinna
[PATCH rebase] Make rebaseall a wrapper around the autorebase postinstall, script
Patch attached.From bcbc7f9768854a6e6aaf1a450cdaabc61241ea9d Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Wed, 20 Jul 2022 12:14:42 -0400
Subject: [PATCH] Make rebaseall a wrapper around the autorebase postinstall
script
Do this on Cygwin only; the behavior on MinGW and MSYS is unchanged.
Bump version to 4.6.1.
---
NEWS | 5 +++
README | 30
configure.ac | 2 +-
rebaseall.in | 100 +++
4 files changed, 56 insertions(+), 81 deletions(-)
diff --git a/NEWS b/NEWS
index f982c32..c824d5b 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,10 @@
$Id$
+4.6.1
+==
+* Make rebaseall a wrapper around /etc/postinstall/0p_000_autorebase.dash
+ (Cygwin only).
+
4.3.0
==
* Add --oblivious/-O option: do not touch files already in the
diff --git a/README b/README
index 6383fcf..9456b5e 100644
--- a/README
+++ b/README
@@ -53,9 +53,13 @@ the following will be displayed when the problem is
triggered:
C:\cygwin\bin\python.exe: *** unable to remap C:\cygwin\bin\cygssl.dll to
same address as parent(0xDF) != 0xE0
-Note that rebaseall is only a stop-gap measure. Eventually the rebase
-functionality will be added to Cygwin's setup.exe, so that rebasing will
-happen automatically.
+On Cygwin, rebaseall has been replaced by the postinstall script
+/etc/postinstall/0p_000_autorebase.dash, provided by the _autorebase
+package. This script runs every time Cygwin's setup program is run.
+See /usr/share/doc/Cygwin/_autorebase.README.
+
+For the convenience of users who may wish to rebase between runs of
+setup, rebaseall is now a wrapper around that postinstall script.
On Vista and newer, it is possible to employ the Address Space Layout
Randomization facility to help solve the image load address clashing
@@ -163,7 +167,7 @@ the next section.
Command line syntax
-rebaseall
+rebaseall (MinGW and MSYS only)
The following is the rebaseall command line syntax:
@@ -358,31 +362,25 @@ Issues:
The following are the known Cygwin rebase issues:
-1. rebase should be integrated with Cygwin's setup.exe.
-
-2. rebase does not handle in-use DLLs.
+1. rebase does not handle in-use DLLs.
-3. rebase skips read-only DLLs.
+2. rebase skips read-only DLLs.
-Issues #1, #2, and #3 also apply to the peflags utility.
+These issues also apply to the peflags utility.
Homepage:
The primary rebase web site is:
-http://www.tishler.net/jason/software/rebase/
+https://cygwin.com/git/?p=cygwin-apps/rebase.git
Download:
-The primary rebase download site is:
-
-http://www.tishler.net/jason/software/rebase/
-
-Access to the CVS development sources is available:
+Access to the git development sources is available:
-cvs -d:pserver:anon...@cygwin.com:/cvs/cygwin-apps co rebase
+git clone git://cygwin.com/git/cygwin-apps/rebase.git
Mailing Lists:
diff --git a/configure.ac b/configure.ac
index 91415d5..f66c2a6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,7 +2,7 @@
# configure.ac for rebase
AC_PREREQ([2.64])
-AC_INIT([rebase], [4.6.0], [cyg...@cygwin.com])
+AC_INIT([rebase], [4.6.1], [cyg...@cygwin.com])
AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_SRCDIR([peflags.c])
AC_PREFIX_DEFAULT([/usr])
diff --git a/rebaseall.in b/rebaseall.in
index af4fe3f..b624939 100644
--- a/rebaseall.in
+++ b/rebaseall.in
@@ -38,6 +38,32 @@ DefaultVerbose=
DefaultFileList=
DefaultSuffixes='dll|so|oct'
+# Determine platform
+Platform=`uname -s`
+case $Platform in
+ *MINGW* | *mingw* ) Platform=mingw ;;
+ *CYGWIN* | *cygwin* ) Platform=cygwin ;;
+ *MSYS* | *msys* ) Platform=msys ;;
+ * )
+echo "Unsupported platform: $Platform" 1>&2
+exit 1
+;;
+esac
+
+# On Cygwin, just call the _autorebase postinstall script
+case $Platform in
+ cygwin)
+if [ "$#" -gt 0 ]
+then
+ echo "usage: ${ProgramName}"
+ exit 1
+fi
+exec /etc/postinstall/0p_000_autorebase.dash
+;;
+ *)
+;;
+esac
+
# Define functions
usage()
{
@@ -76,27 +102,6 @@ case `uname -m` in
;;
esac
-# Determine platform
-Platform=`uname -s`
-case $Platform in
- *MINGW* | *mingw* ) Platform=mingw ;;
- *CYGWIN* | *cygwin* ) Platform=cygwin ;;
- *MSYS* | *msys* ) Platform=msys ;;
- * )
-echo "Unsupported platform: $Platform" 1>&2
-exit 1
-;;
-esac
-
-# On x86_64 Cygwin,
Re: autorebase and user-installed dynamic objects
On 9/27/2021 9:21 AM, ASSI wrote: Ken Brown via Cygwin-apps writes: Note that there are a lot of complaints about non-existent .eln files. I'm experimenting with native-compilation builds of emacs, and I know why these errors are occurring. But I don't think that should be preventing the full rebase from working. It doesn't, based on this information I'd say everything worked as it should. I've fixed the error that was causing rebase to complain about non-existent .eln files, and emacs seems to be working great now (64-bit only). It's possible that we'll find that little or nothing further needs to be done for the 64-bit case. I'm thinking of putting out a test release of emacs so that we can get some more data. In case you want to try it yourself before I get around to doing that, you can find the current version of the .cygport file on the playground branch of the source repo (https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/emacs.git). Ken
Re: autorebase and user-installed dynamic objects
Ken Brown via Cygwin-apps writes: > $ ls -al /var/cache/rebase/ > total 579 > drwxr-xr-x+ 1 kbrown-admin None 0 2021-09-27 08:35 ./ > drwxr-xr-x+ 1 kbrown-admin None 0 2021-09-27 08:35 ../ > -rw-r--r-- 1 kbrown-admin None115 2021-09-27 08:35 fullrebase.done > -rw-r--r-- 1 kbrown-admin None 138550 2021-09-27 08:35 rebase_all > -r--r--r-- 1 kbrown-admin None 25689 2021-09-27 08:35 rebase_dyn > -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_dyn.old > -r--r--r-- 1 kbrown-admin None 31 2021-09-27 08:35 rebase_dyn_exe > -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_dyn_exe.old > -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_epoch > -r--r--r-- 1 kbrown-admin None 55862 2021-09-27 08:35 rebase_exe > -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_exe.old > -r--r--r-- 1 kbrown-admin None 120902 2021-09-27 08:35 rebase_lst > -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_lst.old > -r--r--r-- 1 kbrown-admin None 236372 2021-09-27 08:35 rebase_pkg > -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_pkg.old > -rw-r--r-- 1 kbrown-admin None 64 2021-09-27 08:35 rebuild_always > > Note that rebase_pkg is much bigger than rebase_all. That's normal, rebase_pkg contains a mix that later gets filtered and split into rebase_lst and rebase_exe; rebase_all is the unification (minus comment lines) of rebase_lst and rebase_dyn. >> /var/log/setup.log.full > > Attached. Note that there are a lot of complaints about non-existent > .eln files. I'm experimenting with native-compilation builds of > emacs, and I know why these errors are occurring. But I don't think > that should be preventing the full rebase from working. It doesn't, based on this information I'd say everything worked as it should. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: autorebase and user-installed dynamic objects
On 9/27/2021 2:43 AM, ASSI wrote: Ken Brown via Cygwin-apps writes: I just tried to do a full rebase (by running 'rebase-trigger full'), but it seems that files from installed packages aren't being rebased. Looking at /var/cache/rebase, it looks like the files in rebase_pkg aren't making it into rebase_all. It should already do a full rebase when you re-install (the latest version is 001091-0.1). I just reinstalled it. Please do that and post / paste: ls -al /var/cache/rebase $ ls -al /var/cache/rebase/ total 579 drwxr-xr-x+ 1 kbrown-admin None 0 2021-09-27 08:35 ./ drwxr-xr-x+ 1 kbrown-admin None 0 2021-09-27 08:35 ../ -rw-r--r-- 1 kbrown-admin None115 2021-09-27 08:35 fullrebase.done -rw-r--r-- 1 kbrown-admin None 138550 2021-09-27 08:35 rebase_all -r--r--r-- 1 kbrown-admin None 25689 2021-09-27 08:35 rebase_dyn -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_dyn.old -r--r--r-- 1 kbrown-admin None 31 2021-09-27 08:35 rebase_dyn_exe -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_dyn_exe.old -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_epoch -r--r--r-- 1 kbrown-admin None 55862 2021-09-27 08:35 rebase_exe -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_exe.old -r--r--r-- 1 kbrown-admin None 120902 2021-09-27 08:35 rebase_lst -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_lst.old -r--r--r-- 1 kbrown-admin None 236372 2021-09-27 08:35 rebase_pkg -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_pkg.old -rw-r--r-- 1 kbrown-admin None 64 2021-09-27 08:35 rebuild_always Note that rebase_pkg is much bigger than rebase_all. /var/log/setup.log.full Attached. Note that there are a lot of complaints about non-existent .eln files. I'm experimenting with native-compilation builds of emacs, and I know why these errors are occurring. But I don't think that should be preventing the full rebase from working. Ken setup.log.full.xz Description: Binary data
Re: autorebase and user-installed dynamic objects
Ken Brown via Cygwin-apps writes: > I just tried to do a full rebase (by running 'rebase-trigger full'), > but it seems that files from installed packages aren't being rebased. > Looking at /var/cache/rebase, it looks like the files in rebase_pkg > aren't making it into rebase_all. It should already do a full rebase when you re-install (the latest version is 001091-0.1). Please do that and post / paste: ls -al /var/cache/rebase /var/log/setup.log.full Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: autorebase and user-installed dynamic objects
On 9/26/2021 4:07 AM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: Installs fine now, thanks. Please install the latest update. I just tried to do a full rebase (by running 'rebase-trigger full'), but it seems that files from installed packages aren't being rebased. Looking at /var/cache/rebase, it looks like the files in rebase_pkg aren't making it into rebase_all. Ken
Re: autorebase and user-installed dynamic objects
Ken Brown via Cygwin-apps writes: > Installs fine now, thanks. Please install the latest update. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: autorebase and user-installed dynamic objects
On 9/25/2021 11:45 AM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: I tried to install this with 'setup -X', but I'm getting a Download Incomplete pop-up saying that there was a download error for _autorebase-001090-0.1. Can you try again, please? Installs fine now, thanks. I'll try it out with emacs over the next few days. Ken
Re: autorebase and user-installed dynamic objects
Ken Brown via Cygwin-apps writes: > I tried to install this with 'setup -X', but I'm getting a Download > Incomplete pop-up saying that there was a download error for > _autorebase-001090-0.1. Can you try again, please? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: autorebase and user-installed dynamic objects
On 9/25/2021 9:26 AM, Achim Gratz wrote: I have an interim update that works more or less like the current implementation plus some fixes to be more resilient against filenames containing spaces somewhere (I'd appreciate if somone would actually test that this works), but allows to have more fine-grained control over the locations or files to be rebased (changed documentation below). The .eln suffix is already included in the list of extensions. This only works on systems where the user directory is fully accessible to setup, as it will still be done during the normal autorebase step. Any user-specific rebase that caters to those installations that do not fulfill that requirement will have to wait for the requisite support in rebase to appear. Point setup to use this additional install source: root=http://cygwin.stromeko.net/ $root/stage and install the test package for _autorebase contained therein. I tried to install this with 'setup -X', but I'm getting a Download Incomplete pop-up saying that there was a download error for _autorebase-001090-0.1. Ken
Re: autorebase and user-installed dynamic objects
Achim Gratz writes: > Ken Brown via Cygwin-apps writes: >> I've taken a stab at this (attached). > > I'm a bit short on time right now, but my plan is to remove the user.d > functions from rebaselst and instead implement an option that will make > it work on non-system files (e.g. user directory). That should cut down > on code duplication I hope and make it easier to later take advantage of > an updated rebase that can work with more than one database. I have an interim update that works more or less like the current implementation plus some fixes to be more resilient against filenames containing spaces somewhere (I'd appreciate if somone would actually test that this works), but allows to have more fine-grained control over the locations or files to be rebased (changed documentation below). The .eln suffix is already included in the list of extensions. This only works on systems where the user directory is fully accessible to setup, as it will still be done during the normal autorebase step. Any user-specific rebase that caters to those installations that do not fulfill that requirement will have to wait for the requisite support in rebase to appear. Point setup to use this additional install source: root=http://cygwin.stromeko.net/ $root/stage and install the test package for _autorebase contained therein. --8<---cut here---start->8--- _autorebase === This package provides scripts to keep the Cygwin system properly rebased. By default this happens incrementally, which means only dynamic objects that have been installed after the last run of rebase will be considered and the current rebase map takes account of the already rebased parts of the installation. The scripts must be run by the system administrator or from another account that has all the necessary access rights. Over time the rebase map can fragment. By triggering a full rebase, all dynamic objects on the system are treated as newly installed and the existing rebase map is cleared before doing the rebase. To perform a full rebase, execute "rebase-trigger fullrebase". Then shut down Cygwin including any services you have installed and simply run setup.exe. The rebase will be performed even when the installation did not get modified in any way. Subsequent runs of setup.exe will again rebase in incremental mode. Some programs allow the user to create or install dynamic objects after installation. Since these are not part of an installed package, they wouldn't be rebased automatically, as their location isn't known to the package system. Entire subtrees to be searched for dynamic objects can be advertised in /var/lib/rebase/dynpath.d/, /var/lib/rebase/localpath.d/ and /var/lib/rebase/userpath.d/ for packaged paths, locally provided paths and user paths, respectively. The format of files in these directories is one absolute path per line. The list of suffixes that files need to have to be considered dynamic objects in these locations is hardcoded as "dll|so|eln|oct|mex". Files that should be rebased, but do not have one of these suffixes can be advertised in /var/lib/dynfile.d, /var/lib/localfile.d and /var/lib/userfile.d for packaged files, locally provided files and user files, respectively. The format of files in these directories is one absolute file name per line. Packagers should name their files after the (main) application package that creates the dynamic objects at the advertised location and must not package anything in either the local*.d or user*.d directories. The local system administrator should only place files in local*.d directories and otherwise keep the naming scheme as used for packages. The user*.d file names should start with the account name of the user the advertised locations belong to. The user running the installation must have full access rights to all such paths and all such locations must be available (e.g. remote or encrypted volumes must be mounted and unlocked, respectively). The incremental rebase is controlled by the script /usr/bin/rebaselst. Except for debugging purposes this script should not be run directly by users. Like any other attempt at rebasing it doesn't work correctly on a live Cygwin system. --8<---cut here---end--->8--- Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: autorebase and user-installed dynamic objects
Ken Brown via Cygwin-apps writes: > I've taken a stab at this (attached). I'm a bit short on time right now, but my plan is to remove the user.d functions from rebaselst and instead implement an option that will make it work on non-system files (e.g. user directory). That should cut down on code duplication I hope and make it easier to later take advantage of an updated rebase that can work with more than one database. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: autorebase and user-installed dynamic objects
On 9/20/2021 8:57 AM, Ken Brown via Cygwin-apps wrote:
On 9/20/2021 1:58 AM, ASSI wrote:
Ken Brown via Cygwin-apps writes:
2. Create a script /usr/bin/rebaselst_usr similar to rebaselst, with a
few modifications:
a) All files are in the user's home directory:
l=${HOME}/.config/rebase
b=${HOME}/.cache/rebase
db=${l}/dynpath.d
I've taken a stab at this (attached). The appropriate command, then, is
'rebaselst_usr dyn rebase'. Within emacs I would use something like
(if (eq system-type 'cygwin)
(call-process "rebaselst_usr" nil
'(:file "")
nil "dyn" "rebase"))
I'm not sure yet where this would go so that it's called after compilation but
before the compiled file is loaded. I'll see if Eli can help.
Ken
#!/bin/dash
export PATH=/bin
l=${HOME}/.config/rebase
b=${HOME}/.cache/rebase
eb="${b}/rebase_epoch"
db="${l}/dynpath.d"
for d in ${b} ${db} ; do
if [ ! -d ${d} ] ; then
echo "Directory ${d} does not exist, trying to re-create."
mkdir -p ${d}
fi
done
BaseAddress=''
if [ "x86_64" = $( uname -m ) ] ; then
DefaultBaseAddress=0x4
else
DefaultBaseAddress=0x07000
fi
rebuild="no"
noaslr="no"
verbose=""
doSuffixes='dll|so|oct|mex|eln'
exeSuffixes='exe'
dynPaths=$( cat ${db}/* | sort -u )
dynLocs=''
for d in ${dynPaths} ; do
[ -d "${d}" ] && dynLocs="${dynLocs} ${d}"
done
usage () {
echo "
rebaselst [-h | --help | [ | ... ]]
Commands, will be executed in order:
--verbose
Run some commands with verbose output.
--rebuild
Later commands will discard information in cache files and
rebuild them from scratch.
--no-rebuild
Keep and use information in cache files. This is the default,
can be used to cancel effect of a \"--rebuild\" earlier on the
command line.
update
Update all caches.
dyn
Update cache for dynamic language modules and libraries. This
currently implies \"--rebuild\" since modules could have been
installed by the user and the cache would be outdated.
--noaslr
Remove ASLR and TSAware flags from dynamic objects.
rebase
Rebase with the information in cache files (i.e does not imply
an \"update\").
peflags
Set PE flags on executables with the information in cache
files (i.e does not imply an \"update\").
"
}
check_file () {
if [ "$2" = "yes" -a -e $1 ] ; then
echo "removing $1"
rm -f $1
fi
if [ ! -e "${eb}" ] ; then
touch -d "@0" "${eb}" || \
touch -d "1980-01-01 00:00 UTC""${eb}" || \
touch -d "1999-05-03 07:29:06 UTC" "${eb}" || \
touch -d "2002-08-17 07:00 CEST" "${eb}"
fi
if [ ! -e "$1" ] ; then
echo "creating empty $1"
touch -r "${eb}" "$1"
fi
if [ "$2" != "nowrite" -a -e $1 ] ; then
chmod 644 "$1"
fi
}
_tr () {
local IFS s r
IFS="/-+.,"
for s in $1; do
r="${r}_${s}"
done
echo "${r}"
}
update_file () {
local IFS f g k l m
f="$1"
g="${f}.old"
mv -f "${f}" "${g}"
cat >"${f}" <>"${f}"
chmod 444 "${f}"
}
rebase_do () {
local g
g="${b}/rebase_all"
echo "Rebasing with list ${g}, built from $@."
cat $@ | grep -vE '^#' | sort -u >"${g}"
if [ ! -e "/etc/rebase.db.i386" -a ! -e "/etc/rebase.db.x86_64" ] ; then
BaseAddress="-b ${DefaultBaseAddress}"
fi
rebase ${BaseAddress} ${verbose} -n -O -T "${g}"
if [ "noaslr" = "yes" ] ; then
peflags ${verbose} -d0 -t0 -T "${g}"
fi
BaseAddress=''
}
peflags_do () {
local g
g="${b}/rebase_all_exe"
echo "Setting PE flags with list ${g}, built from $@."
cat $@ | grep -vE '^#|ddd\/Ddd\.exe$' | sort -u >"${g}"
peflags ${verbose} -t1 -T "${g}"
}
rebase_dyn () {
local g
g="${b}/rebase_dyn"
check_file "${g}" "yes"
if [ "x" = "${dynLocs:-x}" ] ; then
touch "${g}"
else
echo "Looking for dynamic language modules/libraries in:"
for d in ${dynLocs} ; do echo " ${d}" ; done
echo "Updating rebase information for dynamic language modules/libraries
${g}."
find ${dynLocs} -xdev -regextype posix-extended -regex
".*\.(${doSuffixes})$" -newer "${g}" >>"${g}"
fi
update_file "${g}"
}
if [ "$#" = "0" ] ; then
set -- "--help"
fi
while [ $# -gt 0 ] ; do
case "$1" in
--verbose )
verbose=--verbose
;;
--rebuild )
rebuild=yes
;;
--noaslr )
noaslr=yes
;;
--no-rebuild )
rebuild=no
;;
rebase )
rebase_do "${b}/rebase_dyn"
;;
peflags )
peflags_do "${b}/rebase_exe"
;;
update )
shift
set -- dummy dyn $@
;;
dyn )
rebase_dyn
;;
-h|--help|* )
usage
exit 127
;;
esac
shift
done
exit 0
Re: autorebase and user-installed dynamic objects
On 9/20/2021 1:58 AM, ASSI wrote:
Ken Brown via Cygwin-apps writes:
1. Modify rebaseall and rebaselst to recognize 'eln' as a suffix and
to recognize the standard directory where emacs will install the
system-wide .eln files (corresponding to the preloaded libraries).
That would be which directory?
When I build emacs from the upstream repo (without setting prefix) I see
ELN_DESTDIR='/usr/local/lib/emacs/28.0.50/
So I guess they will be in a subdirectory of /usr/lib/emacs when I build emacs
for Cygwin.
2. Create a script /usr/bin/rebaselst_usr similar to rebaselst, with a
few modifications:
a) All files are in the user's home directory:
l=${HOME}/.config/rebase
b=${HOME}/.cache/rebase
db=${l}/dynpath.d
…and there is this knotty problem. The user has one home directory, but
she might be using many different hosts and both Cygwin architectures.
The rebase information is host and architecture specific. I have no
good solution for that yet and I don't know if XDG provides for that
situation. Things might have to go into /var/run/user or some similar
location instead. Note that the architecture dependence of eln (or
really build dependence on a particular Emacs config if you want to be
precise) already is a problem for Emacs in general and I haven't paid
attention as to how they intend to solve that.
I haven't noticed any discussion of that. I don't know about dependence on a
particular Emacs config. But that was never an issue for elc files, so I doubt
if it's an issue for eln files. There's certainly architecture dependence, but
I don't think that will be a problem for us. If rebase encounters a library
intended for a different architecture, I think it will skip it, just as it skips
in-use files, won't it?
Ken
Re: autorebase and user-installed dynamic objects
Ken Brown via Cygwin-apps writes:
> 1. Modify rebaseall and rebaselst to recognize 'eln' as a suffix and
> to recognize the standard directory where emacs will install the
> system-wide .eln files (corresponding to the preloaded libraries).
That would be which directory?
> 2. Create a script /usr/bin/rebaselst_usr similar to rebaselst, with a
> few modifications:
>
> a) All files are in the user's home directory:
>
> l=${HOME}/.config/rebase
> b=${HOME}/.cache/rebase
> db=${l}/dynpath.d
…and there is this knotty problem. The user has one home directory, but
she might be using many different hosts and both Cygwin architectures.
The rebase information is host and architecture specific. I have no
good solution for that yet and I don't know if XDG provides for that
situation. Things might have to go into /var/run/user or some similar
location instead. Note that the architecture dependence of eln (or
really build dependence on a particular Emacs config if you want to be
precise) already is a problem for Emacs in general and I haven't paid
attention as to how they intend to solve that.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: autorebase and user-installed dynamic objects
On 9/19/2021 3:09 PM, Achim Gratz wrote:
Ken Brown via Cygwin-apps writes:
First of all, I think we should make /var/lib/rebase/user.d/
work as documented.
No, that won't help and I should actually remove that facility since it
can't be fixed. The user directory can not assumed to be even
accessible when setup runs. So anything involving a user directory must
be run under that user account, after setup has completed. Anything
that can be done via setup should be done with packages (and those can
already use the dynpath.d facility).
OK.
Users could list their emacs user directory there, and people who
build emacs themselves could also list their emacs build directory.
That way things could be kept reasonably stable in the long run via
the autorebase postinstall script. Implicit in this is that the
results of all these rebases would be stored in the user's rebase
database.
The question of where to store the result is not really important at the
moment. We can just re-generate the intended result each time; if and
only if that works should we then optimize via caching.
How about this as a starting point:
1. Modify rebaseall and rebaselst to recognize 'eln' as a suffix and to
recognize the standard directory where emacs will install the system-wide .eln
files (corresponding to the preloaded libraries).
2. Create a script /usr/bin/rebaselst_usr similar to rebaselst, with a few
modifications:
a) All files are in the user's home directory:
l=${HOME}/.config/rebase
b=${HOME}/.cache/rebase
db=${l}/dynpath.d
b) Each user can create create files in ${db} containing the directories in
which rebaselst_usr should look for libraries to be rebased. In the case of
emacs, I would probably provide a script that users can call to create the
default ${db}/emacs, containing the line ${HOME}/.emacs.d/eln-cache. I don't
know if there are other packages that would want to do something similar.
c) Other obvious modifications/deletions, such as making the rebase ephemeral
for now.
3. Run emacs from a script that calls rebaselst_usr before launching
/usr/bin/emacs. I'll have to think about naming issues. It would be nice if
the script could just be called "emacs", but then something else has to be renamed.
After each compilation, but before the new .eln file is loaded, emacs
could call rebaselst with suitable arguments to rebase that new file
(and add it to the user database).
Yes, something like that or something else with similar effect. But
first we need to figure out if we can get it working at all.
Actually, we could probably just have emacs call rebaselst_usr after each
compilation. Those .eln files that are already loaded won't be rebaseable, but
so what?
Ken
Re: autorebase and user-installed dynamic objects
Ken Brown via Cygwin-apps writes: > I'm not sure the rebase of the emacs user directory has to be > ephemeral. That would just be a POC to show that it works in a general sense. > First of all, I think we should make /var/lib/rebase/user.d/ > work as documented. No, that won't help and I should actually remove that facility since it can't be fixed. The user directory can not assumed to be even accessible when setup runs. So anything involving a user directory must be run under that user account, after setup has completed. Anything that can be done via setup should be done with packages (and those can already use the dynpath.d facility). > Users could list their emacs user directory there, and people who > build emacs themselves could also list their emacs build directory. > That way things could be kept reasonably stable in the long run via > the autorebase postinstall script. Implicit in this is that the > results of all these rebases would be stored in the user's rebase > database. The question of where to store the result is not really important at the moment. We can just re-generate the intended result each time; if and only if that works should we then optimize via caching. > After each compilation, but before the new .eln file is loaded, emacs > could call rebaselst with suitable arguments to rebase that new file > (and add it to the user database). Yes, something like that or something else with similar effect. But first we need to figure out if we can get it working at all. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: autorebase and user-installed dynamic objects
On 9/19/2021 12:39 PM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: A per-user database sounds like a good idea. Well, the problem is how to maintain it. So let's for the moment skip that part and see if it would work when we pretend we'd already solved that problem. An ephemeral rebase is essentially a user-defined database that gets thrown away immediately, so you can not re-use its information. We would need to replace emacs with a wrapper script that checks a cookie file against the system wide rebase database and if the latter is newer, trigger an ephemeral rebase of the emacs user directory. The same should be done for each compilation. If that works, then we can try to figure out how to not constantly rebase stuff that doesn't need to get rebased again via some sort of user rebase database. I'm not sure the rebase of the emacs user directory has to be ephemeral. First of all, I think we should make /var/lib/rebase/user.d/ work as documented. Users could list their emacs user directory there, and people who build emacs themselves could also list their emacs build directory. That way things could be kept reasonably stable in the long run via the autorebase postinstall script. Implicit in this is that the results of all these rebases would be stored in the user's rebase database. After each compilation, but before the new .eln file is loaded, emacs could call rebaselst with suitable arguments to rebase that new file (and add it to the user database). Ken
Re: autorebase and user-installed dynamic objects
Ken Brown via Cygwin-apps writes: > A per-user database sounds like a good idea. Well, the problem is how to maintain it. So let's for the moment skip that part and see if it would work when we pretend we'd already solved that problem. An ephemeral rebase is essentially a user-defined database that gets thrown away immediately, so you can not re-use its information. We would need to replace emacs with a wrapper script that checks a cookie file against the system wide rebase database and if the latter is newer, trigger an ephemeral rebase of the emacs user directory. The same should be done for each compilation. If that works, then we can try to figure out how to not constantly rebase stuff that doesn't need to get rebased again via some sort of user rebase database. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: autorebase and user-installed dynamic objects
[Redirected from the main Cygwin list.] On 9/19/2021 2:18 AM, ASSI wrote: Ken Brown via Cygwin writes: Looking into /usr/bin/rebaselst, I think I see the problem. The function rebase_user() greps the file /var/lib/rebase/user.d/kbrown for the relevant suffixes, That's how it was originally intended to work, IIRC (but the documentation indeed wrongly suggests to put paths there). Obviously since we didn't have that situation before I never fully tested and completed this part. instead of looking for files in /home/kbrown/.emacs.d/eln-cache. Shouldn't rebase_user use a variable "userLocs" analogous to the variable "dynLocs" used by rebase_dyn()? Or am I completely misunderstanding how this is supposed to work? For reasons I don't exactly remember, I wanted to avoid that. Probably because the user directory might not be available or accessible for the install user, but then obviously you'd just as likely have a problem with the actual rebasing also. I've been mulling the idea of having user specific rebase databases on top of the system one (or more generally a hierarchy of rebase DB) several times and that's one of the reasons they might be needed. Let's discuss how this can and should work on cygwin-apps. A per-user database sounds like a good idea. Ken
Re: autorebase and user-installed dynamic objects
Ken Brown via Cygwin writes: > Looking into /usr/bin/rebaselst, I think I see the problem. The > function rebase_user() greps the file /var/lib/rebase/user.d/kbrown > for the relevant suffixes, That's how it was originally intended to work, IIRC (but the documentation indeed wrongly suggests to put paths there). Obviously since we didn't have that situation before I never fully tested and completed this part. > instead of looking for files in > /home/kbrown/.emacs.d/eln-cache. Shouldn't rebase_user use a variable > "userLocs" analogous to the variable "dynLocs" used by rebase_dyn()? > Or am I completely misunderstanding how this is supposed to work? For reasons I don't exactly remember, I wanted to avoid that. Probably because the user directory might not be available or accessible for the install user, but then obviously you'd just as likely have a problem with the actual rebasing also. I've been mulling the idea of having user specific rebase databases on top of the system one (or more generally a hierarchy of rebase DB) several times and that's one of the reasons they might be needed. Let's discuss how this can and should work on cygwin-apps. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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
autorebase and user-installed dynamic objects
Achim, In preparation for using emacs's new native compilation feature, I've been experimenting with using autorebase to rebase the *.eln files created in a user's home directory. As a start, I created a file /var/lib/rebase/user.d/kbrown containing the line /home/kbrown/.emacs.d/eln-cache . I also modified /usr/bin/rebaseall and /usr/bin/rebaselst so that they would recognize 'eln' as a suffix of a file needing to be rebased. I then ran setup and let it do its autorebase, but the *.eln files didn't get rebased. Looking into /usr/bin/rebaselst, I think I see the problem. The function rebase_user() greps the file /var/lib/rebase/user.d/kbrown for the relevant suffixes, instead of looking for files in /home/kbrown/.emacs.d/eln-cache. Shouldn't rebase_user use a variable "userLocs" analogous to the variable "dynLocs" used by rebase_dyn()? Or am I completely misunderstanding how this is supposed to work? Thanks. Ken -- 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: Autorebase errors; mintty won't launch
On Aug 16 15:36, Corinna Vinschen wrote: > On Aug 16 06:40, Emily Jackson wrote: > > I installed the latest test version of Cygwin, and afterward autorebase > > hung for several minutes until I cancelled it. I ran setup.exe again and > > got these errors: > > [...] > > Confirmed. Something's broken in the new strto_l > functionality. Investigating.. The brokenness was actually in the isXXX_l macros and functions. strtol() and friends now call isspace_l() under the hood, and this completely ignored the most common use-case... when no per-thread locale has been established. I'll build a new testrelease soon. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Autorebase errors; mintty won't launch
On Aug 16 06:40, Emily Jackson wrote: > I installed the latest test version of Cygwin, and afterward autorebase > hung for several minutes until I cancelled it. I ran setup.exe again and > got these errors: > [...] Confirmed. Something's broken in the new strto_l functionality. Investigating.. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Autorebase errors; mintty won't launch
I installed the latest test version of Cygwin, and afterward autorebase
hung for several minutes until I cancelled it. I ran setup.exe again and
got these errors:
Package: 0/Perpetual
0p_000_autorebase.dash exit code 256
0p_update-info-dir.dash exit code 256
Package: z/Perpetual
zp_desktop-file-utils.sh exit code 256
zp_fontconfig_cache_1.sh exit code 256
zp_glib2.0.sh exit code 256
zp_hicolor-icon-theme.sh exit code 256
zp_shared-mime-info.sh exit code 256
I also can't launch mintty or the X server. I have tried rebooting my
PC, but that didn't help. [I am running Windows 10 64-bit.]
This is the end of the setup.log.full file:
2016/08/16 06:25:56 running: C:\cygwin64\bin\dash.exe
"/etc/postinstall/0p_000_autorebase.dash"
0 [main] dash 11560 C:\cygwin64\bin\dash.exe: *** fatal error -
add_item ("\??\C:\cygwin64", "/", ...) failed, errno 1
Stack trace:
FrameFunctionArgs
000ABCE 0018005BF2E (0018023C2BA, 00180219C59, 000ABCE,
0008B30)
000ABCE 00180046439 (0009BB0, 000ABCE, 1D1F7B0F4E61624,
000)
000ABCE 00180046472 (0009BB0, 001, 000ABCE,
635C3A435C3F3F5C)
000ABCE 001800C8ADC (000, 000CE00, 001800BA2B8,
1D1F7B0FDD6F114)
000CC00 00180115A55 (000, 000, 001800B29BE,
000)
000CCC0 00180046A63 (000, 000, 000,
000)
000 001800456E3 (000, 000, 000,
000)
000FFF0 00180045794 (000, 000, 000,
000)
End of stack trace
2016/08/16 06:26:13 abnormal exit: exit code=256
2016/08/16 06:26:13 running: C:\cygwin64\bin\dash.exe
"/etc/postinstall/0p_update-info-dir.dash"
0 [main] dash 14208 C:\cygwin64\bin\dash.exe: *** fatal error -
add_item ("\??\C:\cygwin64", "/", ...) failed, errno 1
Stack trace:
FrameFunctionArgs
000ABCE 0018005BF2E (0018023C2BA, 00180219C59, 000ABCE,
0008B30)
000ABCE 00180046439 (0009BB0, 000ABCE, 1D1F7B0FED0DEEA,
000)
000ABCE 00180046472 (0009BB0, 001, 000ABCE,
635C3A435C3F3F5C)
000ABCE 001800C8ADC (000, 000CE00, 001800BA2B8,
1D1F7B107C1C1BF)
000CC00 00180115A55 (000, 000, 001800B29BE,
000)
000CCC0 00180046A63 (000, 000, 000,
000)
000 001800456E3 (000, 000, 000,
000)
000FFF0 00180045794 (000, 000, 000,
000)
End of stack trace
2016/08/16 06:26:30 abnormal exit: exit code=256
2016/08/16 06:26:32 running: C:\cygwin64\bin\bash.exe --norc --noprofile
"/etc/postinstall/zp_desktop-file-utils.sh"
0 [main] bash 13480 C:\cygwin64\bin\bash.exe: *** fatal error -
add_item ("\??\C:\cygwin64", "/", ...) failed, errno 1
Stack trace:
FrameFunctionArgs
000ABCE 0018005BF2E (0018023C2BA, 00180219C59, 000ABCE,
0008B30)
000ABCE 00180046439 (0009BB0, 000ABCE, 1D1F7B10A6A2281,
000)
000ABCE 00180046472 (0009BB0, 001, 000ABCE,
635C3A435C3F3F5C)
000ABCE 001800C8ADC (000, 000CE00, 001800BA2B8,
1D1F7B1135B0602)
000CC00 00180115A55 (000, 000, 001800B29BE,
000)
000CCC0 00180046A63 (000, 000, 000,
000)
000 001800456E3 (000, 000, 000,
000)
000FFF0 00180045794 (000, 000, 000,
000)
End of stack trace
2016/08/16 06:26:49 abnormal exit: exit code=256
2016/08/16 06:26:49 running: C:\cygwin64\bin\bash.exe --norc --noprofile
"/etc/postinstall/zp_fontconfig_cache_1.sh"
0 [main] bash 7452 C:\cygwin64\bin\bash.exe: *** fatal error -
add_item ("\??\C:\cygwin64", "/", ...) failed, errno 1
Stack trace:
FrameFunctionArgs
000ABCE 0018005BF2E (0018023C2BA, 00180219C59, 000ABCE,
0008B30)
000ABCE 00180046439 (0009BB0, 000ABCE, 1D1F7B114B6A6D2,
000)
000ABCE 00180046472 (0009BB0, 001, 000ABCE,
635C3A435C3F3F5C)
000ABCE 001800C8ADC (000, 000CE00, 001800BA2B8,
1D1F7B11DA77E76)
000CC00 00180115A55 (000, 000, 001800B29BE,
000)
000CCC0 00180046A63 (000, 000, 000,
000)
000 001800456E3 (000, 000, 000,
000)
000FFF0 00180045794 (000, 000, 000,
000)
End of stack trace
2016/08/16 06:27:07 abnormal exit: exit code=256
2016/08/16 06:27:07 running: C:\cygwin64\bin\bash.exe --norc --noprofile
"/etc/postinstall/zp_glib2.0.sh"
0 [main] bash 8292 C:\cygwin64\bin\bash.exe: *** fatal error -
add_item ("\??\C:\cygwin64&q
Re: Autorebase hangs on install
Jack Bartley writes: > For the first time, I tried installing the 64-bit Cygwin on my Windows > 7 machine using the setup-x86_64.exe. Once I reach > '/etc/postinstall/0p_000_autorebase.dash' the installation gets stuck. > I haven't waited at this stage for more than a few hours but I have > not got past it. The longest I have personally witnessed was a little over one hour, so that would indicate you have some BLODA interfering with the rebasing. More specifically I suspect some real-time virus scanner in which case you should create an exception for the Cygwin installation directory or temporarily disable that function. > The other entry I found to be similar is entitled "setup - > 0p_000_autorebase.dash hangs" found > athttps://cygwin.com/ml/cygwin/2015-06/msg00136.html. Following a > mention of this in this conversation I ended bash processes whilst > running the setup and found that this enabled me to pass the > Autorebase stage. There isn't any bash process running when autorebase is happening. I'm going to assume you meant dash for the moment. > However, the setup then would just hang at a later > stages. Yes, just randomly killing postinstall steps isn't going to help you any further. […] > I should note, that I ran step one in the Cygwin64 terminal. That was correct. > It's worth also pointing out that when I've tried to install new > packages the same problem recurs. I did not save the log file the very > first time I try to install Cygwin, but I have the log file for a more > recent attempt. I'm happy to attach this to a future email if this > would help. Alternatively, I could just include important parts of it > in an email. How do I go about opening these files (those beginning > setup.log.run, found in var/log. The *run* files are only left there if the setup process gets aborted somehow. Since you say you aborted every single one, that should have left that many of these files. setup.log.full has the abridged logging for all installs and setup.log is the complete log for the last install. They are all simple text files. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Autorebase hangs on install
On 04/07/2016 23:05, Jack Bartley wrote: Dear all, Thanks in advance for your help. First I ought to say that there are other instances of similar problems occurring on this mailing list-I've tried to follow the advice but after a decent amount of time and effort have not managed to resolve the issue. For the first time, I tried installing the 64-bit Cygwin on my Windows 7 machine using the setup-x86_64.exe. Once I reach '/etc/postinstall/0p_000_autorebase.dash' the installation gets stuck. I haven't waited at this stage for more than a few hours but I have not got past it. Any possible BLODA around ? https://cygwin.com/faq/faq.html#faq.using.bloda Thanks again for your help Jack can you provide a copy of cygcheck.out Problem reports: http://cygwin.com/problems.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Autorebase hangs on install
Dear all, Thanks in advance for your help. First I ought to say that there are other instances of similar problems occurring on this mailing list-I've tried to follow the advice but after a decent amount of time and effort have not managed to resolve the issue. For the first time, I tried installing the 64-bit Cygwin on my Windows 7 machine using the setup-x86_64.exe. Once I reach '/etc/postinstall/0p_000_autorebase.dash' the installation gets stuck. I haven't waited at this stage for more than a few hours but I have not got past it. What follows is details on what I've tried. A previous entry on the mailing list entitled "New cygwin install hanging on postinstall" to be found at https://www.cygwin.com/ml/cygwin/2016-01/msg00246.html describes a similar problem. Note, in this mailing list entry the initial problem was one of hanging a different stage, but later in the conversation the author claims their installation spends a long time at the same step. However, their installation does pass this step. The other entry I found to be similar is entitled "setup - 0p_000_autorebase.dash hangs" found athttps://cygwin.com/ml/cygwin/2015-06/msg00136.html. Following a mention of this in this conversation I ended bash processes whilst running the setup and found that this enabled me to pass the Autorebase stage. However, the setup then would just hang at a later stages. I do not have the full list of all the places it hung, but this is the error message I received after installation " Package: 0/Perpetual 0p_000_autorebase.dash exit code 1 0p_update-info-dir.dash exit code 1 Package: _/Unknown package 000-cygwin-post-install.sh exit code -6 base-files-mketc.sh exit code -6 base-files-profile.sh exit code -6 bash.sh exit code 1 ca-certificates.sh exit code -6 coreutils.sh exit code -6 lynx.sh exit code -6 man-db.sh exit code -6 mintty.sh exit code -6 " Once I'd completed this (possibly faulty) installation I restarted my machine and tried to re-base (though I'm not really sure what that means) manually. To do that I followed the instructions here https://www.cygwin.com/ml/cygwin/2016-01/msg00216.html "You need to do a full rebase. I recommend that you do this as follows: 1. Run '/usr/bin/rebase-trigger full'. 2. Reboot, and make sure no Cygwin processes or services are running. 3. Run setup. " I should note, that I ran step one in the Cygwin64 terminal. When reading a different mailing list entry (found at https://www.cygwin.com/ml/cygwin/2013-08/msg00449.html) I realise that I possibly should have ran that with ash or bash. I also followed the instructions of the latter link which are as follows: " Can you try what happens if you stop all Cygwin processes, start a lone dash.exe and enter "/usr/bin/rebaseall" on the command line? Does it run and silently exits, or do you see any kind of error message? " The result of this was that nothing discernible happened for a minute or so and then a "$" was returned in the bash, but I did not receive any error messages. However, having rebooted and tried to run setup again it still hangs at the Autorebase stage. It's worth also pointing out that when I've tried to install new packages the same problem recurs. I did not save the log file the very first time I try to install Cygwin, but I have the log file for a more recent attempt. I'm happy to attach this to a future email if this would help. Alternatively, I could just include important parts of it in an email. How do I go about opening these files (those beginning setup.log.run, found in var/log. Thanks again for your help Jack -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygwin update hang on autorebase
I tried to update my cygwin in win7 64 bit DELL optiplex 7020 desktop but the process hang after downloading the update. I manually kill each bash.exe process and it can move to the next step but will continue hang. I also tried to have a complete fresh installation, the process hang at autorebase. After killing the dash.exe, the process hang at post install stage. Thanks --Wei -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin update hang on autorebase
On 12/18/2015 4:40 PM, Xie, Wei wrote: I tried to update my cygwin in win7 64 bit DELL optiplex 7020 desktop but the process hang after downloading the update. I manually kill each bash.exe process and it can move to the next step but will continue hang. I also tried to have a complete fresh installation, the process hang at autorebase. After killing the dash.exe, the process hang at post install stage. Are you sure autorebase was hanging? Maybe you just didn't wait long enough for it to finish. It can take a long time, especially if you installed a lot of packages. You might first try to do a base install, with no extra packages chosen. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
autorebase failed for unknown package
Hi there, I have spent a while attempting to solve this myself, but I apologize for anything obvious I may have missed. I am getting the following messages for both Cygwin and Cygwin64 on my laptop: Package: Unknown package autorebase.bat exit code 1 Here are details that may narrow it down. 1. They were previously working without this message, which I encountered when updating to get the Shellshock bug fix. 2. I then performed a full uninstall / reboot / confirm no Cygwin processes / reinstall, first of Cygwin64 and then Cygwin32 but still saw the issue. 3. I used the default minimum package lists. 4. I tried two different mirrors with the same result. 5. I also tried reinstall of all selected package with the same result. Thanks for any additional troubleshooting suggestions you can provide. I tried to attach my full setup logs, but it causes me to exceed the spam score threshold for this mailing list. Nothing jumps out at me, but here's the message with some context: 2014/10/06 18:59:44 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/coreutils.sh 2014/10/06 18:59:44 running: cmd.exe /c C:\cygwin\etc\postinstall\autorebase.bat 2014/10/06 18:59:44 abnormal exit: exit code=1 2014/10/06 18:59:44 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/base-files-mketc.sh Stephen -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: autorebase failed for unknown package
Here is the contents of autorebase.bat. I don't know much about rebasing or batch files so I may be way off base (heh), but should dash be bash? @echo off rem Postinstall scripts are always started from the Cygwin root dir rem so we can just call dash from here path .\bin;%path% dash /bin/rebaseall -p On Mon, Oct 6, 2014 at 7:16 PM, Stephen Dewey stepheneliotde...@gmail.com wrote: Hi there, I have spent a while attempting to solve this myself, but I apologize for anything obvious I may have missed. I am getting the following messages for both Cygwin and Cygwin64 on my laptop: Package: Unknown package autorebase.bat exit code 1 Here are details that may narrow it down. 1. They were previously working without this message, which I encountered when updating to get the Shellshock bug fix. 2. I then performed a full uninstall / reboot / confirm no Cygwin processes / reinstall, first of Cygwin64 and then Cygwin32 but still saw the issue. 3. I used the default minimum package lists. 4. I tried two different mirrors with the same result. 5. I also tried reinstall of all selected package with the same result. Thanks for any additional troubleshooting suggestions you can provide. I tried to attach my full setup logs, but it causes me to exceed the spam score threshold for this mailing list. Nothing jumps out at me, but here's the message with some context: 2014/10/06 18:59:44 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/coreutils.sh 2014/10/06 18:59:44 running: cmd.exe /c C:\cygwin\etc\postinstall\autorebase.bat 2014/10/06 18:59:44 abnormal exit: exit code=1 2014/10/06 18:59:44 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/base-files-mketc.sh Stephen -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: autorebase failed for unknown package
Greetings, Stephen Dewey! should dash be bash? No. If you don't have `dash' installed, you need to re-run Setup. -- WBR, Andrey Repin (anrdae...@yandex.ru) 07.10.2014, 4:51 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [RFC] Incremental autorebase
Updated again to read paths to search for additional dynamic objects in
/etc/rebase/dynpath.d/ and dropping content there initially for octave,
perl, php, R, and python2[67].
D=http://cygwin.stromeko.net/release/_incautorebase
${D}/_incautorebase-6-1.tar.bz2
${D}/_incautorebase-6-1-src.tar.bz2
${D}/setup.hint
If rebase turns out to use a different directory I can change that
again.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [RFC] Incremental autorebase
Yaakov (Cygwin/X) writes: Don't forget python3.2 and ruby. Thanks for the reminder, ruby was simply an omission in my mail (it is in the package), but python3.2 isn't — I'll add it in the next update. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [RFC] Incremental autorebase
I've updated the incremental autorebase package to work with additional
dynamic languages (most notably ruby) and to take advantage of the
perpetual postinstall scripts that I'm proposing in another post. If
anybody is aware of further places that would need to be inspected for
dynamic objects the user might have installed without adding a proper
Cygwin package, please let me know and I'll add these as well. I
currently err on the side of caution, for instance it would usually be
enough to check site_perl, since vendor_perl should have only packaged
libraries. I may make the script more selective later, suggestions and
comments towards that goal are also welcome.
D=http://cygwin.stromeko.net/release/_incautorebase
${D}/_incautorebase-4-1.tar.bz2
${D}/_incautorebase-4-1-src.tar.bz2
${D}/setup.hint
The first installation and then each re-installation of the package will
trigger a full rebase of the installed Cygwin. Together with the
above-mentioned change to setup.exe each update, install (or simply
letting setup.exe do nothing by keeping all packages) will incrementally
rebase the installed Cygwin.
This should pretty much ensure that problems that are fixable by
rebasing should be taken care of with no instructions more complicated
then re-install the _incautorebase package via setup.exe ever
necessary. If it needs to get any more fool-proof or user-friendly, the
first screen that setup.exe shows could even have a freindly green
button just for doing either a full or an incremental rebase and nothing
else.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [RFC] Incremental autorebase
New version with bugfixes, setup.hint file and postinstall script (the old files have been removed): $cygwin=http://cygwin.stromeko.net/ wget $cygwin/release/_incautorebase/_incautorebase-2-2-src.tar.bz2 wget $cygwin/release/_incautorebase/_incautorebase-2-2.tar.bz2 wget $cygwin/release/_incautorebase/setup.hint I consider this version feature complete. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [RFC] Incremental autorebase
If you're still following, I've uploaded the latest version of the incremental rebase script: $cygwin=http://cygwin.stromeko.net/ wget $cygwin/release/_incautorebase/_incautorebase-1-8-src.tar.bz2 wget $cygwin/release/_incautorebase/_incautorebase-1-8.tar.bz2 There is now a short usage / help section displayed if rebaselst is invoked with no arguments (or -h / --help). Also, packages can now be deleted without having to do a full rebuild of the cache files. I've managed to use builtins instead of externals in some more places which generally helps to speed up things. There are one or two things I'd like to add before I consider it feature-complete (a manpage would be nice). I'd appreciate if someone with some more experience in shell scripting would have a look and critique what's been written so far. Some of the things that allow to use builtins look a bit too hacky to me and maybe there's a better way to get the same result that I#m just not aware of. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [RFC] Incremental autorebase
On Jun 3 18:02, ASSI wrote: As suggested in http://permalink.gmane.org/gmane.os.cygwin/132585 I have implemented a rebase script that (except for the first invocation) incrementally builds the rebase list by checking which package lists are older than the last time autorebase has been done. Users can drop lists with their own executables and dynamic objects and these will also be rebased (update of those lists is the responsibility of the user). Additionally it takes over the job of perlrebase and allows to set the TSAware flag. After each installation with setup.exe (I remove the dependencies to _autorebase, so this is never installed or run), I call this script as follows: %CYGWIN_INST%\bin\ash -c PATH=/bin rebaselst %REBUILD% update %CYGWIN_INST%\bin\ash -c PATH=/bin rebaselst %CLEARDB% rebase peflags (one could in fact do that in a single invocation of ash, since the command line is processed strictly in sequence). %REBUILD% and %CLEARDB% are normally the empty string, but can be set to --rebuild and --cleardb if necessary with an option to the setup.bat I'm using. The source package can be downloaded at: http://cygwin.stromeko.net/release/_incautorebase/_incautorebase-1-4- src.tar.bz2 Feedback is welcome. I just had a look into the script and the idea looks good to me. How do you imagine to integrate that script into the normal flow? As far as I'm concerned, it would be most helpful to integrate the functionality into the rebaseall script, which can also be called from the _autorebase postinstall script. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFC] Incremental autorebase
Corinna Vinschen writes: I just had a look into the script and the idea looks good to me. Thanks. How do you imagine to integrate that script into the normal flow? As far as I'm concerned, it would be most helpful to integrate the functionality into the rebaseall script, which can also be called from the _autorebase postinstall script. If you want a replacement for rebaseall you'd call /bin/rebaselst update rebase peflags This isn't an exact duplication of rebaseall, but it could be implemented if desired. The script might process the option rebaseall or even recognize if it is called as rebaseall via a link and just act accordingly so that any scripts using rebaseall would continue to function. A usage/help option or README would also need to be written. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [RFC] Incremental autorebase
On Sunday 03 June 2012, 18:02:57, ASSI wrote: [...] Updated package available at: http://cygwin.stromeko.net/release/_incautorebase/_incautorebase-1-6- src.tar.bz2 Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
[RFC] Incremental autorebase
As suggested in http://permalink.gmane.org/gmane.os.cygwin/132585 I have implemented a rebase script that (except for the first invocation) incrementally builds the rebase list by checking which package lists are older than the last time autorebase has been done. Users can drop lists with their own executables and dynamic objects and these will also be rebased (update of those lists is the responsibility of the user). Additionally it takes over the job of perlrebase and allows to set the TSAware flag. After each installation with setup.exe (I remove the dependencies to _autorebase, so this is never installed or run), I call this script as follows: %CYGWIN_INST%\bin\ash -c PATH=/bin rebaselst %REBUILD% update %CYGWIN_INST%\bin\ash -c PATH=/bin rebaselst %CLEARDB% rebase peflags (one could in fact do that in a single invocation of ash, since the command line is processed strictly in sequence). %REBUILD% and %CLEARDB% are normally the empty string, but can be set to --rebuild and --cleardb if necessary with an option to the setup.bat I'm using. The source package can be downloaded at: http://cygwin.stromeko.net/release/_incautorebase/_incautorebase-1-4- src.tar.bz2 Feedback is welcome. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
autorebase
Hi, Did I miss an announcement? I notice now in my setup log: 2012/05/14 10:27:13 running: cmd.exe /c C:\cygwin\etc\postinstall\autorebase.bat Does this mean that I do not need anymore to run in an ash shell: ./rebaseall ./peflagsall followed with (in bash): perlrebase ...after an update? I acknowledge I have had much fewer fork failures in recent times than I used to. Thanks, Marc -- View this message in context: http://old.nabble.com/autorebase-tp33828522p33828522.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: autorebase
Greetings, Marc Girod! Did I miss an announcement? Yes. I notice now in my setup log: 2012/05/14 10:27:13 running: cmd.exe /c C:\cygwin\etc\postinstall\autorebase.bat Does this mean that I do not need anymore to run in an ash shell: ./rebaseall ./peflagsall Yes. followed with (in bash): perlrebase ...after an update? Probably. I acknowledge I have had much fewer fork failures in recent times than I used to. -- WBR, Andrey Repin (anrdae...@freemail.ru) 14.05.2012, 14:58 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gold star for autorebase please?
On Tue, Mar 27, 2012 at 1:17 PM, Corinna Vinschen wrote: On Mar 27 13:06, Christopher Faylor wrote: I think Corinna's efforts for all of the work that went into getting autorebase working in setup.exe deserve a gold star. Could she get one please? Hey, I just did my job ;) Yea, but we all need good encouragement from our peers when the job gets done. http://en.wikipedia.org/wiki/Gold_Star -- Earnie -- https://sites.google.com/site/earnieboyd -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gold star for autorebase please?
I think Corinna's efforts for all of the work that went into getting autorebase working in setup.exe deserve a gold star. Could she get one please? Awarded: http://cygwin.com/goldstars/#CV -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gold star for autorebase please?
Greetings, Earnie Boyd! On Tue, Mar 27, 2012 at 1:17 PM, Corinna Vinschen wrote: On Mar 27 13:06, Christopher Faylor wrote: I think Corinna's efforts for all of the work that went into getting autorebase working in setup.exe deserve a gold star. Could she get one please? Hey, I just did my job ;) Yea, but we all need good encouragement from our peers when the job gets done. - gets done. + gets well done. http://en.wikipedia.org/wiki/Gold_Star ^^ this. -- WBR, Andrey Repin (anrdae...@freemail.ru) 29.03.2012, 01:43 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
gold star for autorebase please?
I think Corinna's efforts for all of the work that went into getting autorebase working in setup.exe deserve a gold star. Could she get one please? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gold star for autorebase please?
On Mar 27 13:06, Christopher Faylor wrote: I think Corinna's efforts for all of the work that went into getting autorebase working in setup.exe deserve a gold star. Could she get one please? Hey, I just did my job ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
