Re: setup
On Aug 7, 2015, at 1:47 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Aug 6 17:57, Achim Gratz wrote: I would consider this a release candidate. Some more testing with interactive and ad-hoc installs would be useful, though. I have a vague idea that setup should ideally be part of the Cygwin distro package set. So setup updates itself, and it would be possible to handle public test releases. The issue of overwriting setup while setup is running could be worked around by setup first copying itself to a intermediate filename (e.g. .setup.exe) and then exce'ing that copy. You’d have to couple this either with a MoveFileEx(…, MOVEFILE_DELAY_UNTIL_REBOOT) call or a background task that replaces /bin/setup.exe with %LOCALAPPDATA%/Temp/setup-v$next.exe. This would be a nice point to give setup.exe a CLI language for installing packages in yum/apt-get fashion, too. (Yes, yes, I know, SHTDI.)
Re: setup
On Aug 6 17:57, Achim Gratz wrote: Corinna Vinschen writes: OK for push? Yes, thank you. Done. I would consider this a release candidate. Some more testing with interactive and ad-hoc installs would be useful, though. How do you want to handle this? We don't have real provisions for setup.exe release candidates. Maybe we should change how we provide setup updates in future? I have a vague idea that setup should ideally be part of the Cygwin distro package set. So setup updates itself, and it would be possible to handle public test releases. The issue of overwriting setup while setup is running could be worked around by setup first copying itself to a intermediate filename (e.g. .setup.exe) and then exce'ing that copy. Other ideas how we could handle this? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpfLagDzcbtL.pgp Description: PGP signature
Adding a subpackage
I've discovered a neat Git tool -- git subtree -- which is part of Git's contrib directory and isn't something we currently distribute as part of any of the existing Git-related packages. I'd like to start adding this to the stack of Git packages I build and distribute. I don't think the build stage is going to be difficult, but what (if anything) do I need to do to get git-subtree as a package that's in setup.ini? Is it just a case of uploading the new package and setup.hint, or do I need to do some additional magic? Adam
Re: [Attn Maintainer] git git-svn
On Sun, Aug 02, 2015 at 08:35:25AM +0200, Achim Gratz wrote:
The tests for 2.5.0 just completed:
--8---cut here---start-8---
fixed 1
success 12528
failed 0
broken 179
total 12808
--8---cut here---end---8---
…on both architectures. I do not have cvs installed, so those tests (as
well as Perforce) have not run.
I'm going to continue to be cautious: while I think the risk of bumping
up to v2.5.0 is very low, if there are problems with that or any of the
other numerous recent changes (this has been the first time a release
has got above the -1 version since I took over maintainership), I want
to keep the changes reasonably slow to help narrow down where the
problem comes from.
A few suggestions for changes to the cygport:
--8---cut here---start-8---
SRC_URI=https://git.kernel.org/cgit/git/git.git/snapshot/${PN}-v${PV}.tar.gz;
SRC_DIR=${PN}-v${PV}
--8---cut here---end---8---
Then not inherit git, a snapshot is less wasteful then the cloning
unless you plan to really work with the repository which cygport makes
difficult anyway.
Done. I switched from something similar when I took over the
maintainership, as using inherit git seemed like The Right Thing To Do
when I was first playing around with Cygport. As you say, though, it's
just adding overhead with no advantage. (Indeed if I want to play
around with the Git repository itself, I already have a copy of that
ready to go.)
--8---cut here---start-8---
[[ $ARCH_x86_64 ]] DEPEND=$DEPEND libiconv libiconv-devel
--8---cut here---end---8---
Drop this line and add libiconv, libiconv-devel plus dblatex to the
DEPENDS unconditionally.
I'm sure when I first added that line, it made sense with the
dependencies. I've made this change as well now, though, as it seems to
be the right thing to do at this point.
Thanks!
Adam
Re: [Attn Maintainer] git git-svn
On Sat, Aug 01, 2015 at 08:17:59PM +0200, Achim Gratz wrote: Adam Dinwoodie writes: I think git-svn should and used to depend on subversion-perl, but this seems to have gone missing, somehow. How very odd! That was one of the automatically generated dependencies, so presumably the dependency generation has just gone a bit sideways, probably because of the Perl version change. I don't think so, that package hasn't been renamed or anything like that. As long as the installed.db and the *.lst.gz files are OK, it should find these. Well my latest rebuild picked up the dependency automatically, and the only thing I can think of that changed between the two is that I picked up the latest version of subversion-perl. Whatever it was, it's fixed now :)
Re: setup
Corinna Vinschen writes: I would consider this a release candidate. Some more testing with interactive and ad-hoc installs would be useful, though. How do you want to handle this? We don't have real provisions for setup.exe release candidates. True. At the moment it'd probably mean that some other folks on this list try it and give their GTG. They'd either have to build it themselves or maybe use the AppVeyor build from Jon Turney. Maybe we should change how we provide setup updates in future? I have a vague idea that setup should ideally be part of the Cygwin distro package set. So setup updates itself, and it would be possible to handle public test releases. We could add a new key to setup.ini that indicates the existence of a test version and have setup ask if the user would maybe want to use that instead. Ideally setup would then download and exec it if the user choses to run it. I don't have code ready to do that, though… Another problem that needs to be solved is to know how much exposure the new setup.exe really had to decide if it's good for release. The issue of overwriting setup while setup is running could be worked around by setup first copying itself to a intermediate filename (e.g. .setup.exe) and then exce'ing that copy. Other ideas how we could handle this? As said before, the idea that setup.exe needs to be entirely self-contained is both an advantage and limiting what it can do. I haven't had time yet to check, but a minimal Cygwin install system w/ busybox might not be too large compared to the connectivity demands of todays' Windows itself. Here setup.exe would just need to unpack the current image of the install system and provide the GUI to pick the packages and control the actual installation. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: Adding a subpackage
Adam Dinwoodie writes: I've discovered a neat Git tool -- git subtree -- which is part of Git's contrib directory and isn't something we currently distribute as part of any of the existing Git-related packages. openSUSE ships this in git-core since some time. AFAIK the only reason it is still in contrib is the fact that it can't work on Windows. I'd like to start adding this to the stack of Git packages I build and distribute. I don't think the build stage is going to be difficult, but what (if anything) do I need to do to get git-subtree as a package that's in setup.ini? Is it just a case of uploading the new package and setup.hint, or do I need to do some additional magic? If it's a sub-package (i.e. the source package is git), then you just package it up the usual way. If you'd want it standalone (not advisable in this case) you would need to ITP it so it gets added to the list of packages you maintain. BTW, git-merge-changelog (from GNUlib) would be a candidate for this treatment and is currently lacking from Cygwin. 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: [Attn Maintainer] git git-svn
Adam Dinwoodie writes: I'm going to continue to be cautious: while I think the risk of bumping up to v2.5.0 is very low, if there are problems with that or any of the other numerous recent changes (this has been the first time a release has got above the -1 version since I took over maintainership), I want to keep the changes reasonably slow to help narrow down where the problem comes from. No problem. I just had to run the build box overnight anyway and figured it would get through a Git build until I looked at it in the morning. Done. I switched from something similar when I took over the maintainership, as using inherit git seemed like The Right Thing To Do when I was first playing around with Cygport. As you say, though, it's just adding overhead with no advantage. (Indeed if I want to play around with the Git repository itself, I already have a copy of that ready to go.) I have a few packages that use Git repositories, but I always clone them from local repos. That won't work for official packages obviously, but if cygport gets smarter and caches the repos someplace else (like already possible with package archives) it might be more useful to work from a Git repo. Especially if cygport was getting smart enough to get a tarball instead of cloning if it isn't set up to cache the repo. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
