Re: setup
Achim Gratz writes: > The new SHA512 checksums are rather lengthy. Could we switch them to > Base64 (perhaps the URL and file safe variant) instead of the current > hex encoding instead (maybe with an SHA512: prefix if we want to support > both)? I've implemented this in setup and genini to create base64url encoded checksums. Setup deals nicely with a setup.ini that has a mix of MD5 (some packages from ports), SHA512-hex (all of cygwin) and SHA512-Base64 (my local packages) checksums. The latter ones are base64url as defined in RFC4648, which means the '+' and '/' characters get replaced by '-' and '_' to be filename and URL safe. Like this: --8<---cut here---start->8--- install: ../x86/cygwin/docbook2X/docbook2X-0.8.8-1.tar.bz2 286260 a2b46ebd6aeb73eebe3f001ee847fa9bc1b46231b58fc728c25197e7750cfd55285d57e77dbf5d093f80362396fa4bc4dde740cc0d0f8fcb1561278410dbebba install: ../noarch/cygport/docbook2odf/docbook2odf-0.244-1.tar.bz2 25411 289b39695a7e388c2f2ac5b8c752fa6b install: ../x86/patches/perl-Class-Factory-Util/perl-Class-Factory-Util-1.7-3.tar.xz 12420 FUfRHLQiyuK8PT4OOd7TH-2y4IgexoUxCVPJo-1_-pGAkyIQh0sbth92Nrk_wdA-YMdW3BSOLpa12gfoEJsh8g --8<---cut here---end--->8--- I'll have to write a ChangeLog and clean up the code a bit before I'll post the patches. 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: Perl 5.22.0
> The current plan is that the packages should be available on my server
> by the end of the week latest.
I've just uploaded the files, please point setup at:
setup-{x86,x86_64}.exe -XOs http://cygwin.stromeko.net/
Please rebuild your Perl distributions again, since officially RCx
releases are not binary compatible with the official ones.
If you've already installed RC2, then you'll have to re-install
everything Perl (setup doesn't recognize 5.22.0-RC2 as being pre-5.22.0
and all distributions that haven't had a version bump in the meantime
still come with the same release number). Instead of clicking on all
hundreds of selection boxes, you can do this before starting setup:
sed -re 's/(5\.22\.0-)(RC2-)?[0-9]/\10/;s/( perl-.*-)[0-9]+\./\10./' \
-i.bak /etc/setup/installed.db
This will cause all Perl related stuff to be updated without your manual
intervention.
> Depending on how the rebuilds of the other packages and distributions
> depending on the new Perl are progressing I might release a test
> version on cygwin.com as well.
This has become less likely, given my work schedule.
> Otherwise the first official Cygwin release will be 5.22.1, scheduled
> for beginning of July.
At the moment that is plan A, so everyone has about four weeks to build
for Perl 5.22 using the 5.22.0 "private" release. No rebuilds of
distributions will be necessary with the 5.22.1 version bump.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: cygport: allow setting prev:, curr:, and test: in autogenerated setup.hint
Andrew Schulman writes: > I have a package (socat) where I need to set the curr: and test: fields in > setup.hint. I got tired of adding them to the autogenerated setup.hint files > after every build, so I wrote a patch for cygport to support specifying them > in > the cygport file. For example, setting > > CURR=1.7.3.0-2 > TEST=2.0.0-b8-1 > > in the cygport file will give > > curr: 1.7.3.0-2 > test: 2.0.0-b8-1 > > in setup.hint. The PREV, PKG_PREV, CURR, PKG_CURR, TEST, and PKG_TEST > variables > are all supported. > > The variable name TEST might be too generic, but I'm not aware of any other > uses > for it, and grep -r '\' in the cygport source turns up none. If > necessary it could be renamed to e.g. SETUP_TEST, but then probably CURR, > PKG_CURR etc. would all have to be renamed too. At least if it ever gets exported, then TEST will be throwing a monkey wrench into a few build systems, I suspect. > The patch is in the setup.hint branch of > https://github.com/andrex-e-schulman/cygport.git. It seems you've re-invented something that David Rothenberger has implemented before in a slightly different way: http://thread.gmane.org/gmane.os.cygwin.applications/26034 It's also integrated in my patched-up version of cygport here: git://repo.or.cz/cygport/rpm-style.git FWIW, I've been using Dave's patch a few times and it seems slightly less verbose than what you've got. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: setup
Yaakov Selkowitz writes: > Anyone looking at the sources would be tainted thereby. Because we are > concerned about the licensing of upset, AFAICS we are going to have to > clean-room reverse-engineer this. So what exactly does upset that genini doesn't when it comes to generating setup.ini and what other functions does it do in the maintenance of the download area (which I assume is the part where it gets hairy)? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: setup
Corinna Vinschen writes: > There's no reason for upset to create more than one style of checksum. > MD5, SHA512, SHA512/base64, whatever. What I'm talking about is the > client side. The setup tool should understand all types of checksums > used. Right now it identifies MD5 vs. SHA512 just by the length of > the checksum. OK, that's easy, then. Just check for 86 and 88 characters for the non-padded and padded variant of the base64 digest. > CMD is out of the question, this running on a Linux box. The scripts just set up the environment and then call to Perl. It's really a lot easier to do in (ba)sh than in cmd, so that doesn't need to worry you. Again, the origin of those scripts was a different task, so I'd like to spend some time on discussion of the feature set you're envisioning for this. > I forgot that the upset repo has been hidden from the public for a long > time, and these days there isn't even a repo since it has been deleted :-P > > If you're willing to take a look into these upset perl scripts, please > apply for a normal ssh account on sourceware.org via > > https://sourceware.org/cgi-bin/pdw/ps_form.cgi > > Use my private email address as approver. And make sure to use > *another* public SSH key for shell access than the one you're using > for Cygwin uploads to avoid confusion. I'll do that, but expect no comment before Perl 5.22 gets out the door. 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: Perl 5.22.0
Achim Gratz writes: > The 5.22.0 release of Perl has happened on schedule. The Cygwin > packages are building at the moment, I will need another day or two for > the distribution rebuilds. I've patched up the Perl packages to where I want them. There were some extra files packaged by accident that shouldn't have been there and a few things that still have not been upstreamed. The stage 1 / bootstrap is running for x86_64 and x86 will follow tomorrow. I'll probably do a stage 2 build to be sure that I haven't picked up any RC2 remnants by accident before making the packages available around the end of the week. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: setup
Corinna Vinschen writes: >> Why? In any case it'd be easy enough to make it switchable. > > Transition period. We should do changes like that in two steps, first > updating to a setup which handles the new checksums, then changing the > generation of checksums to the new method. Like we did with > MD5->SHA512. It's smoother that way. It's also certainly not a bad > idea to continue supporting the older checksum methods. You're very > likely not the only person creating his/her own setup.ini files and > every change may break a script elsewhere :) Yes, but in this case you're really talking about the setup.exe side, not the generation of the setup via upset or genini (which I thought you were talking about, since that's the part implemented in Perl). If we use the SHA512: prefix then both hex and base64 encoded checksum are distinguishable easily and we might even throw in MD5 just for fun. I don't see off-hand why either upset or genini should be capable of emitting both styles into the same setup.ini, but it is easy enough to do this per setup.ini file creation by adding an option to specify which digest you want. > You seem to be doing this on a regular basis with your own scripts. Is > that right? Would you think your own method is just hacked to work, or > do you think your own ini creation scripts are clean enough to release > them to the public? No, it's fairly sophisticated already, but not yet feature-complete and requires a few clean-ups (don't they always?). > I'm asking because, right now, we're relying on a convoluted perl script > set which is hard to understand (at least for non-perl guys), is missing > comments, has no maintainer, and above all, has a questionable license. What I have is also mostly a Perl script plus a few CMD files around it, so that part likely wouldn't change. > Upset is a beast. It handles ini file creation as well as creating the > package information for https://cygwin.com/cgi-bin2/package-grep.cgi, > as well as the package upload post-processing. Since I can't even look at upset, I use genini for the initial setup.ini creation for any local packages (I have many of those). The rest of the process is taking multiple setup.ini files and rewrites them into a new one, then installs the necessary files into a staging area, which can optionally be cleaned of files not being referenced anymore after an update or change of packages to install. The staging area is then replicated onto the real installation directory. This is under control of a setup.conf file that looks more or less exactly like the name implies. You define your package sources and their dependency order (should they provide the same package, which is what happens for packages that I carry local patches for), and then list the packages you want to have available (you can inject new group names so it's easier to install via setup.exe). Dependencies are pulled in automatically and you can specify that you want an experimental or previous package instead of current. It can also automatically pull devel and debug packages into groups so that they do not clutter the install for non-developer installs and are by default available on those install that are for developers. You can also blacklist a package in some package source if you want to reverse the order just for one package or if there's a packaging error in an external package source. > I would very much appreciate if we could split these tasks into separate, > independent scripts or tools under GPL or BSD license. Well, if we keep this as a task for Perl it would make most sense to put those things into Perl modules, one per task. If a standalone script is preferred in some place we can always fatpack those modules again. > So, what about your scripts? Do you think they could be used as a > start? Do you have, perhaps, fun to rewrite the upset functionality in > a maintainable form and *gasp* maintain it? As I said, I'm coming at this from a different angle: the need to integrate multiple package sources and make a new install hierarchy that can be used locally, without being connected to the Internet and without carrying all the baggage around that a full mirror would have. Plus, I need the install to be fully scriptable to install for users that have no admin rights. The features that I'm missing is explicit version pinning (unfortunately I'll have to do some extensive changes under the hood to get rid of the current prev-curr-test structure, didn't think of that early enough) and the ability to keep different versions of an installation around. I sort of can do that already if I'm careful enough not to clean away files that are still needed, but it's too fragile even for very sparse usage, so I use the staging directory for release tests at the moment. 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/D
Re: setup
Corinna Vinschen writes: >> Because of the openssl branch in Git. > > Oh, that was a bad idea. I won't remove the branch for historical > reasons, but we don't really want to link agaionst OpenSSL when we > already link against gcrypt. OK, makes sense. >> > This was a drop-in replacement for Digest::MD5. Anything else I'll >> > let somebody do who better knows perl. >> >> THen the call $ctx->hexdigest() would need to be replaced by >> $ctx->b64digest(). > > No, it would need to support this additionally. Why? In any case it'd be easy enough to make it switchable. >> > Apart from this, the sah512.sum files are not only generated for the >> > Cygwin release dir, they are generated on the sourceware ftp area >> > system-wide. >> >> I'm only talking about SHA512 in the setup.ini files, though. The >> sha512.sum files have no bearing on that. > > So what exactly is the problem with the longer checksums? I don't > see any problem here, especially when the file is being compressed > anyway. I'm not concerned about the size (although I note that even if compression recognized it's looking at an SHA512 it would at best be able to compress it down to 64 bytes anyway). The difference between 128 and 86 (or 88 padded) characters is pretty noticeable on screen. It's probably a bit unusual that I look at setup files so often (since I generate my own), but it still disturbes me. The other thing (but that really is unrelated, as I could take care of it on other ways) is that I still plan to move to a repository format that allows multiple versions to be active at the same time (via different setup.ini files pointing into the same repo hierarchy) and I was thinking of using the SHA512 to do directory balancing like it's done for the object directory in Git. ~ (2001) du -sh /mnt/mirror/cygwin 52G /mnt/mirror/cygwin ~ (2002) find /mnt/mirror/cygwin -type f |wc 44778 44778 3340383 ~ (2003) find /mnt/mirror/cygwin -type d | wc 11079 11079 602401 ~ (2004) ls -d /mnt/mirror/cygwin/x86/release/* | wc 20712071 89831 Using a 6bit key into a two level tree would seem to provide a better balance for this structure than 8bit or I could go single level with a 12bit key. It needs to provide optimum performance over network, so the optimum likely is at a different point than a local file system. 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
Perl 5.22.0
The 5.22.0 release of Perl has happened on schedule. The Cygwin packages are building at the moment, I will need another day or two for the distribution rebuilds. The current plan is that the packages should be available on my server by the end of the week latest. Depending on how the rebuilds of the other packages and distributions depending on the new Perl are progressing I might release a test version on cygwin.com as well. Otherwise the first official Cygwin release will be 5.22.1, scheduled for beginning of July. 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: setup
Corinna Vinschen writes: >> Since it seems you plan to use libcrypto from OpenSSL anyway: >> https://gist.github.com/barrysteyn/7308212#file-base64decode-c > > I don't. Why do you think so? Because of the openssl branch in Git. > This was a drop-in replacement for Digest::MD5. Anything else I'll > let somebody do who better knows perl. THen the call $ctx->hexdigest() would need to be replaced by $ctx->b64digest(). > Apart from this, the sah512.sum files are not only generated for the > Cygwin release dir, they are generated on the sourceware ftp area > system-wide. I'm only talking about SHA512 in the setup.ini files, though. The sha512.sum files have no bearing on that. 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: setup
Corinna Vinschen writes: > On May 29 21:37, Achim Gratz wrote: >> >> The new SHA512 checksums are rather lengthy. Could we switch them to >> Base64 (perhaps the URL and file safe variant) instead of the current >> hex encoding instead (maybe with an SHA512: prefix if we want to support >> both)? > > Not for the time being. Sombody would have to add code to setup as well > as upset to make this work. Since it seems you plan to use libcrypto from OpenSSL anyway: https://gist.github.com/barrysteyn/7308212#file-base64decode-c Otherwise I'd prefer something less obtuse, there is C++ code with compatible license or I could roll my own. For upset, I don't know what interface you're using. For the object interface you'd simply switch from hexdigest() to b64digest() and for the functional interface from sha512_hex() to sha512_base64(). 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: cygwin.com sftp key fingerprint?
Corinna Vinschen writes:
> Running your commands on sourceware itself shows the exact same
> results when accessing the public host RSA key:
>
> $ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
> 1024 1d:1e:46:7f:4d:73:8d:10:20:c3:4c:5a:34:14:44:23
> /etc/ssh/ssh_host_rsa_key.pub (RSA)
> $ awk '{print $2}' /etc/ssh/ssh_host_rsa_key.pub | base64 -d | sha256sum -b |
> sed 's/ .*$//' | xxd -r -p | base64
> MFNiczzfX8/nvLSRZwR3CxMyycKtMan64Zm4C373FeM=
That's good enough, I'd say. :-)
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: [Attn Maintainer] octave
Marco Atzeri writes: > if I understood correctly a script called > > /etc/postinstall/zp_octave_finish.dash > > will be always executed at the end of the postinstall script > sequence and never renamed as ".done". Yes. > I am moving the octave update script in > /var/lib/octave/update_packages_list > > so the new octave update should work as: > > 1) every octave-forge preremove/postinstall script >touches /var/lib/octave/update.flag > > 2) zp_octave_finish.dash checks if >/var/lib/octave/update.flag exists > and if so execute > /usr/bin/octave-cli /var/lib/octave/update_packages_list > > 3) /var/lib/octave/update_packages_list >updates the octave package database and removes the > /var/lib/octave/update.flag Yes, that's how it works. > If there are no fork issue on 32 bit, I will implement > in this way on 4.0.0 that I am just building together with > update of the 50s octave-forge packages. If there are fork issues, they would be hitting the users just the same. Again, autorebase runs before any other postinstall scripts. 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: cygwin.com sftp key fingerprint?
Andrew Schulman writes: > OK, here you go. The patch is a bit large, because I took the opportunity to > reorganize the text a bit and add a new section showing how to upload packages > the automated way using cygport up. The complete revised page is at > http://home.comcast.net/~andrex2/cygwin/package-upload.html . Looks good. However, you still haven't verified the fingerprint(s) with Sourceware Overseers or did you? That I'm getting the same fingerprint as you is a good sign, but certainly not a confirmation. 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: [ITA] Perl distributions (in preparation of Perl 5.22)
Marco Atzeri writes: > perl-Graphics-Magick and perl-Image-Magick are available in test. Thanks. > I don't think postgresql-plperl is urgent, so I will wait upstream 9.4.3 > that should arrive in one week to make the double update. > If you need it now let me know. I don't need it. But if anybody is indeed using it, they should not update Perl before the new version is available, so we need to announce that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: Perl distributions
Corinna Vinschen writes: >> Can somebody please remove it directly on sourceware so that the >> setup.ini files can be generated correctly? > > Is this fixed? I don't see a perl-Term-ReadKey-debuginfo dir. John Turney was on IRC yesterday and removed it. All is well now. :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: cygwin.com sftp key fingerprint?
Andrew Schulman writes:
> I show the SFTP key fingerprint for cygwin.com as
>
> SHA256:MFNiczzfX8/nvLSRZwR3CxMyycKtMan64Zm4C373FeM
>
> Can anyone please confirm that?
> ssh-keygen -lvf cygwin.com.pub
1024 1d:1e:46:7f:4d:73:8d:10:20:c3:4c:5a:34:14:44:23 [MD5] cygwin.com (RSA)
+--[ RSA 1024]+
| EO&.o.oo o+|
| +o* . .o+|
| . + . . .|
| + o . |
|S o |
| |
| |
| |
| |
+--[MD5]--+
> awk '{print $3}' cygwin.com.pub | base64 -d | sha256sum -b | sed 's/ .*$//' |
> xxd -r -p | base64
MFNiczzfX8/nvLSRZwR3CxMyycKtMan64Zm4C373FeM=
> Is the key fingerprint posted anywhere on cygwin.com or sourceware.org? I
> can't
> find it. If not, would someone mind adding it to the "Uploading Packages to
> cygwin.com" page (https://sourceware.org/cygwin-apps/package-upload.html), so
> people can verify it?
Good idea.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Perl distributions
Yaakov Selkowitz writes: > This looks like it has been done already. Am I missing something? I seem to be unable to remove the debuginfo directory of the obsoleted package: upset: x86_64 release in unstable state: couldn't move /var/ftp/pub/cygwin/x86_64/release/perl-TermReadKey/perl-Term-ReadKey/perl-Term-ReadKey-debuginfo -> /sourceware/snapshot-tmp/cygwin/x86_64/perl-TermReadKey/perl-Term-ReadKey - Is a directory Can somebody please remove it directly on sourceware so that the setup.ini files can be generated correctly? Also, the hint on https://sourceware.org/cygwin-apps/package-upload.html "This technique should work with directories but some confusion may arise if you delete a directory, recreate it, and attempt to remove it again. This scenario has not been tested." should either be deleted (if removing directories does not in fact work) or needs clarification on what conditions must be met for it to work. 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: [Attn Maintainer] octave
Marco Atzeri writes: > /usr/share/octave/site/m/startup/octaverc is updating > "/usr/share/octave/packages" > if any subdirectory under "/usr/share/octave/" has been added > or removed, to update the octave package database. > > Why do you see actions under "/usr/lib" ? I simply remembered wrong. > See note on: > https://sourceware.org/ml/cygwin-announce/2014-08/msg00033.html In any case, making a whole directory mode 666 on a server isn't going to fly. >> Could you please remove that code and put the update into a post-install >> script? > > It is build as such as a normal post-install script will not work. TeXLive had the same problem, that's one of the reasons perpetual postinstall scripts were introduced. You can look at that to see how Ken deals with that. > I will look if I can find a mechanism that allow a common approach for > the 50s octave-* packages. > > In the past these problems make another solution impossible: > > - the script must run octave and due to octave lib dependency a fork > failures on 32bit was almost guarantee. This is not a problem anymore since your postinstall action will be run after autorebase. > - the script must run for any postinstall - postremove of any > octave-* (forge packages). So > 1) it will be heavy to run it 50 times, it must be a common one. No, you just place a trigger that is then collected by the perpetual postinstall. > 2) we have no post remove. With perpetual post-install, pre-remove is working just as well as long as octave itself is installed. > 3) If also octave is removed the post remove must not run. In this case the perpetual postinstall script is also removed, so whether the trigger is or isn't there makes no difference. > - /usr/share/octave/packages does not exist if the database is empty > so I can not change its permission in the postinstall phase before > its creation. Why is that? Just because cygport by default removes empty directories? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [ITA] Perl distributions (in preparation of Perl 5.22)
Yaakov Selkowitz writes: > On Fri, 2015-05-29 at 21:57 +0200, Achim Gratz wrote: >> Yaakov Selkowitz writes: >> > In the meantime I did update cygwin-pkg-maint (but next time, patch >> > please instead of a new file). >> >> I'm quite sure I sent a patch? Are you talking about the naming of the >> a/b in the patch? > > https://cygwin.com/ml/cygwin-apps/2015-05/msg00048.html :-P Sorry, I really meant to send a patch. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [ITA] Perl distributions (in preparation of Perl 5.22)
Yaakov Selkowitz writes: > In the meantime I did update cygwin-pkg-maint (but next time, patch > please instead of a new file). I'm quite sure I sent a patch? Are you talking about the naming of the a/b in the patch? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: Perl distributions
Yaakov Selkowitz writes: > This looks like it has been done already. Am I missing something? No, but I did since nobody told me. I still need to make and install the obsoletion package unless you beat me to it. 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: [ITA] Perl distributions (in preparation of Perl 5.22)
Yaakov Selkowitz writes: > I also have a bunch of packages in Ports that will have to be rebuilt > for 5.22. I should be able to start working on that next week based on > your RC2 repo, but I'd like to hold off on releasing this until at least > mine and Marco's packages are ready. I sort of forgot about Ports… but yes, that is another consideration to make. If things go as currently scheduled I should have the final build up on my server around Wednesday, I think. You should build the packages to be released with the final version from my server to be totally safe, but RC2 is available now for setting up and checking if anything needs fixing. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
setup
The new SHA512 checksums are rather lengthy. Could we switch them to Base64 (perhaps the URL and file safe variant) instead of the current hex encoding instead (maybe with an SHA512: prefix if we want to support both)? 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: [ITA] Perl distributions (in preparation of Perl 5.22)
Achim Gratz writes: […] The upstream release of Perl 5.22.0 is still scheduled for June 1st. > This means that again Yaakov as well as Marco and Volker need to > re-release those. I need to hear from you three when you are ready to do these updates, otherwise the Cygwin release of Perl will need to be postponed. 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
[Attn Maintainer] octave
The site octaverc has code that tries to keep the package directory up-to-date. That's a no-no, since normal users don't have permission to change files under /usr/lib. Could you please remove that code and put the update into a post-install script? 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
Re: perl-5.22.0-RC2 / Perl distributions
David Stacey writes: > Thanks for your e-mail. I'm very happy for you to upload perl-Text-CSV > and perl-Text-CSV_XS for the purposes of getting the new version of > perl rolled out. Thanks, that's the plan, then. 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: perl-5.22.0-RC2 / Perl distributions
David Stacey writes: > I downloaded this with the intention of building perl-Text-CSV_XS and > perl-Text-CSV, but discovered that you'd built them already! I'm more > than happy for you to build these packages for the sake of > transitioning to a new release of perl, but I'd like to keep > maintenance of them, at least for the time being. I needed those for other stuff, so I went ahead and built it. If you'd rather want to upload the new packages yourself, that's one more person to coordinate the upload with, which I think we will manage. You will have to rebuild the package once more before the upload when the final version of Perl is available. 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: perl-5.22.0-RC2 / Perl distributions
Ken Brown writes: > biber-1.8 seems fine with perl-5.22.0. Since I may be out of town > with poor internet access when you're ready for the transition, I went > ahead and uploaded it to sourceware (x86_64 only), along with a new > release of texlive-collection-bibtexextra [*]. At transition time, > someone just has to put !ready in my x86_64 upload area. Thanks, Ken. Have a nice vacation! Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [ITA] Perl distributions (in preparation of Perl 5.22)
Achim Gratz writes: > Here are the changes necessary to get Perl-5.22 into Cygwin: […] I forgot XML-Writer, here's the additional diff for that: --- cygwin-pkg-maint2015-05-22 21:20:11.0 +0200 +++ cygwin-pkg-maint.new2015-05-25 17:22:25.197982956 +0200 @@ -1414,6 +1426,7 @@ perl-XML-SAX Achim Gratz/Yaakov Selkowitz perl-XML-SAX-Base Achim Gratz/Yaakov Selkowitz perl-XML-Simple Achim Gratz/Yaakov Selkowitz +perl-XML-Writer Achim Gratz/Ken Brown perl-YAML Achim Gratz/Yaakov Selkowitz perl-YAML-LibYAML Achim Gratz phodav Yaakov Selkowitz 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: perl-5.22.0-RC2 / Perl distributions
Ken Brown writes: >> I have the first two already from my last look at Biber… OK, the rest is >> now up, too. > > I don't see XML::Writer. Sorry, this should be fixed now. 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: perl-5.22.0-RC2 / Perl distributions
Ken Brown writes: > The latest version of Biber requires autovivification, XML::Writer, > and Text::Roman. And Test::Difference is required for running the > tests. Can you add those? I have the first two already from my last look at Biber… OK, the rest is now up, too. > Here's a trickier one: Biber wants Unicode::Normalize, version <= > 1.17. There's a comment that says "1.18 removes XS and is too slow". > I'm not sure what to do about that. Any advice? That is due to a deprecation in Perl 5.20 and later: --8<---cut here---start->8--- Revision history for Perl extension Unicode::Normalize. 1.18 Tue May 27 22:04:23 2014 - XSUB is now deprecated and removed. see perl 5.20.0, perldelta, Internal Changes, deprecation of uvuni_to_utf8 etc. --8<---cut here---end--->8--- I don't know if it's still possible to build on 5.22, depending on where in the deprecation cycle we are with that function. But the earlier module versions have been pulled from CPAN anyway and only 1.18 is available. If it's just "too slow", then why do the Biber folks care? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: perl-5.22.0-RC2 / Perl distributions
Ken Brown writes: > I don't see perl-5.22.0-RC2 for x86_64. I'm attaching the setup.ini > that setup-x86_64.exe downloaded from your server. That should be fixed. THanks for the heads-up. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: Perl distributions
Achim Gratz writes: > I just realized that the 64bit distribution has a perl-Term-ReadKey > package that should have been obsoleted by perl-TermReadkey (sans the > hyphen). Can somebody please move the directory perl-Term-ReadKey into > perl-TermReadkey so I can create and install the obsoletion package? Ping? 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
perl-5.22.0-RC2 / Perl distributions
I've built perl-5.22.0-RC2 and bootstrapped the Perl distributions for
Cygwin (well, most of them -- I will send another ITA for some
additional ones I've hat to build later). It doesn't make much sense to
try a test release on sourceware, so I've uploaded to my own server,
which you can use (in addition to) the normal package archive(s):
setup-{x86,x86_64}.exe -XOs http://cygwin.stromeko.net/
Let me know if anything is missing.
The release of Perl 5.22.0 is still scheduled for June 1st. Now that
I've bootstrapped another set of packages should be ready in about a day
or two I think, so a Cygwin release beginning of June might be in the
cards. Switching to the new Perl version will require that _all_ other
Perl distributions be re-packaged, so anything I didn't build will have
to be ready at the same time. Please build and test your Perl
distribution packages with RC2 so that the final build will go smooth.
If you've rather had me build your packages instead (aside from the ones
mentioned above), let me know.
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: Plans for Perl 5.22
Achim Gratz writes: > Ken Brown writes: >> I'm wondering what your plans are for Perl 5.22, which I think is due >> to be released in a couple weeks. > > I've just built perl-5.33-RC1. That's perl-5.22-RC1 of course, sorry for the typo. 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: Plans for Perl 5.22
Ken Brown writes: > I'm wondering what your plans are for Perl 5.22, which I think is due > to be released in a couple weeks. I've just built perl-5.33-RC1. I need to do some changes to actually be able to package the result and then of course install it locally and build the Perl distribution packages. If that works out I could upload it to my server for any interested folks to install from there. I've not been around for any release of Perl so I can't really say how this will be handled, but there are a number of last minute changes that may trigger an RC2, otherwise the release is scheduled for June 1st. I might just be able to get everything done before traveling in June, but I'd prefer to postpone the Cygwin release to until after I'm back at the end of that month. 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
[ITA] mosh
Mosh has been orphaned by Reini Urban and the setup.hint in 32bit is currently having a wrong dependency. I'm using mosh and would like to take over maintenance. Since there was no intervening upstream release, I've simply rebuilt using cygport and the latest toolchain. wget="wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/x86/release/mosh/";; $wget/mosh-1.2.4-3-src.tar.xz $wget/mosh-1.2.4-3.tar.xz $wget/mosh-debuginfo/mosh-debuginfo-1.2.4-3.tar.xz $wget/mosh-debuginfo/setup.hint $wget/setup.hint wget="wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/x86_64/release/mosh/";; $wget/mosh-1.2.4-3-src.tar.xz $wget/mosh-1.2.4-3.tar.xz $wget/mosh-debuginfo/mosh-debuginfo-1.2.4-3.tar.xz $wget/mosh-debuginfo/setup.hint $wget/setup.hint 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: [ITA] more Perl distributions
Yaakov Selkowitz writes: > Done. Thank you. 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
[ITA] more Perl distributions
I should already own perl-Types-Serialiser (I did the upload), but cygwin-pkg-maint has no trace of it so it needs a correction. In addition I'd like to update a few distributions currently owned by Yaakov, so if that's OK with you, please make me a co-maintainer. --8<---cut here---start->8--- --- cygwin-pkg-maint2015-05-09 00:24:18.0 +0200 +++ cygwin-pkg-maint.new2015-05-15 09:00:57.908064093 +0200 @@ -1216,7 +1216,7 @@ perl-Capture-Tiny Achim Gratz/Ken Brown perl-Carp Achim Gratz perl-Class-XSAccessor Achim Gratz -perl-Clone Yaakov Selkowitz +perl-Clone Achim Gratz/Yaakov Selkowitz perl-common-sense Achim Gratz perl-Compress-Bzip2 Achim Gratz perl-Config-AutoConf Achim Gratz/Ken Brown @@ -1239,9 +1239,9 @@ perl-Devel-Autoflush Achim Gratz perl-Devel-Symdump Achim Gratz perl-Date-Simple Achim Gratz/Ken Brown -perl-DBD-mysql Yaakov Selkowitz -perl-DBD-SQLite Yaakov Selkowitz -perl-DBI Yaakov Selkowitz +perl-DBD-mysql Achim Gratz/Yaakov Selkowitz +perl-DBD-SQLite Achim Gratz/Yaakov Selkowitz +perl-DBI Achim Gratz/Yaakov Selkowitz perl-Digest-HMAC Achim Gratz/Yaakov Selkowitz perl-Digest-SHA1 Achim Gratz/Yaakov Selkowitz perl-Encode-EUCJPASCII Achim Gratz/Ken Brown @@ -1388,7 +1388,7 @@ perl-Text-Glob Achim Gratz/Ken Brown perl-Text-WrapI18N Yaakov Selkowitz perl-Tie-Cycle Achim Gratz/Ken Brown -perl-TimeDateYaakov Selkowitz +perl-TimeDate Achim Gratz/Yaakov Selkowitz perl-Tk Yaakov Selkowitz perl-Tk-Canvas-GradientColor Yaakov Selkowitz perl-Tk-ColoredButtonYaakov Selkowitz @@ -1396,6 +1396,7 @@ perl-Tk-Getopt Yaakov Selkowitz perl-Tk-Pod Yaakov Selkowitz perl-Try-Tiny Achim Gratz +perl-Types-Serialiser Achim Gratz perl-Unicode-Collate Achim Gratz/Ken Brown perl-Unicode-GCString Achim Gratz/Ken Brown perl-Unicode-Linebreak Achim Gratz/Ken Brown @@ -1411,7 +1412,7 @@ perl-XML-Parser Achim Gratz/Yaakov Selkowitz perl-XML-SAX Achim Gratz/Yaakov Selkowitz perl-XML-SAX-Base Achim Gratz/Yaakov Selkowitz -perl-XML-Simple Yaakov Selkowitz +perl-XML-Simple Achim Gratz/Yaakov Selkowitz perl-YAML Achim Gratz/Yaakov Selkowitz perl-YAML-LibYAML Achim Gratz phodav Yaakov Selkowitz --8<---cut here---end--->8--- 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: MATE category ?
Yaakov Selkowitz writes:
> Thanks for noticing. I have added all of these, plus PHP and Ruby, to
> setup.html.
The Video category is present in setup.ini, but missing from the list.
In setup.ini we currently have a mixture of Gnome and GNOME that
probably needs to be cleaned up and a lone OCaml package that probably
should just be some other category (it was likely moved from Ports,
which uses that category more often).
Also, genini still hasn't been updated with the latest changes. OK to
install this patch?
--- genini.~1.15.~ 2013-10-07 23:11:35.0 +0200
+++ genini 2015-05-09 10:06:02.225951407 +0200
@@ -6,7 +6,7 @@
# for details.
#
use File::Basename;
-use Digest::MD5;
+use Digest::SHA;
use Getopt::Long;
use strict;
@@ -20,9 +20,14 @@
my ($outfile, $help, $recursive);
my $arch = 'x86';
my $release;
-my @cmp_fmts = qw(gz bz2 lzma xz);
+my @cmp_fmts = qw(xz bz2 lzma gz);
-GetOptions('okmissing=s'=>\@okmissing, 'output=s'=>\$outfile, 'help'=>\$help,
'release=s'=>\$release, 'arch=s'=>\&arch_handler, 'recursive'=>\$recursive) or
usage;
+GetOptions('okmissing=s'=>\@okmissing,
+ 'output=s'=>\$outfile,
+ 'help'=>\$help,
+ 'release=s'=>\$release,
+ 'arch=s'=>\&arch_handler,
+ 'recursive'=>\$recursive) or usage;
$help and usage;
@main::okmissing{@okmissing} = @okmissing;
@@ -190,6 +195,7 @@
my $setup_hint = "$d/setup.hint";
return unless -e $setup_hint;
parse("$setup_hint", $pname);
+next unless exists $pkg{$pname};
my $explicit = 0;
for my $what ('', "[prev]\n", "[test]\n") {
my $x = $pkg{$pname}{$what};
@@ -246,9 +252,9 @@
myerror "can't open $f - $!" unless $main::okmissing{$what};
return undef;
};
-my $md5 = Digest::MD5->new;
-$md5->addfile(\*F);
-$x->{$what} = join(' ', $f, -s $f, $md5->hexdigest);
+my $sha512 = Digest::SHA->new(512);
+$sha512->addfile(\*F);
+$x->{$what} = join(' ', $f, -s $f, $sha512->hexdigest);
}
sub tarball {
@@ -260,8 +266,8 @@
return "$f";
}
}
-# default to .bz2 (even though we know it is missing)
-return "$d/" . "$b" . "bz2";
+# default to .nf (because we know it is missing)
+return "$d/" . "$b" . "nf";
}
sub fnln {
@@ -312,9 +318,10 @@
BEGIN {
my @cats = qw'
- Admin Archive Audio Base Comm Database Debug Devel Doc Editors Games
- Gnome Graphics Interpreters KDE Libs Mail Math Mingw Net Perl
- Publishing Python Science Shells Sound System Text Utils Web X11
+ Accessibility Admin Archive Audio Base Comm Database Devel Doc
+ Editors Games GNOME Graphics Interpreters KDE Libs LXDE Mail MATE
+ Math Mingw Net Perl PHP Python Publishing Ruby Science Shells
+ System Text Utils Video Web X11 Xfce
_obsolete _PostInstallLast
';
@main::categories{map {lc $_} @cats} = @cats;
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: cygport no longer removes "cygwin" from the dependency list
Yaakov Selkowitz writes:
> Good catch. OTOH, we were only skipping the 'cygwin' dep in setup.hint
> because of an issue with deptree ordering of postinstall scripts. Given
> the recent changes to postinstall handling in setup, is there any reason
> we can't just stop ignoring the cygwin dep?
I'm not aware that this would have changed the dependency order. Doing
this would probably require to postpone base package deps in general.
I'll have to do some things in setup to re-instate the possibility of
pruning an installation in unattended mode. I'll have a look, but can't
promise I'll have enough time to get to the dependency issue. Here's a
patch to fix that instance in cygport instead:
>From f4113a1776d35dd39ee3a3aa114495635782a300 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Thu, 7 May 2015 22:08:18 +0200
Subject: [PATCH] lib/pkg_pkg.cygpart: Cygwin is at version 2.x now...
---
lib/pkg_pkg.cygpart | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index da8c9b2..acd4cf9 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -737,7 +737,7 @@ __pkg_dist() {
if [ "${CBUILD##*-}" = "cygwin" ]
then
pkg_bin_requires=$(__list_deps $(sort -fu ${T}/.${pkg_name[${n}]}.lst | sed -e '\|/$|d;s| |^_^|g') \
- | sort -fu | sed -e "/^cygwin-1/d;/^${pkg_name[${n}]}-[0-9].*$/d;s/-[0-9].*$//g" \
+ | sort -fu | sed -e "/^cygwin-[12]/d;/^${pkg_name[${n}]}-[0-9].*$/d;s/-[0-9].*$//g" \
| sed -e ':a;N;$!ba;s/\n/ /g')
__step "${pkg_name[${n}]} requires: ${pkg_bin_requires} ${!pkg_requires_var}"
else
--
2.3.7
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: [ITP] cfitsio : FITS (Flexible Image Transport System) lib and utility
Marco Atzeri writes: > Noted. But he patched autoconf and I patched cmake build. > Similar outcome, I just packed more utilities. > > I will look at the zlib approach In any case, since a bunch of Ports packages depend on that library, you'll need to coordinate the move into Cygwin with Yaakov. Since you're planning to package a new version, I think this would be easiest if you only added packages, but otherwise kept the packaging the same, so that the Cygwin package was a drop-in replacement. 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: Plans for Perl 5.22
Ken Brown writes: > I'm wondering what your plans are for Perl 5.22, which I think is due > to be released in a couple weeks. It'll probably be released end of May if all current blockers are resolved by that time. If not, there's another 5.21 release and the next release slot would be end of June. > I'm expecting to release TeX Live > 2015 in mid June, and it would be nice to be able to update Biber to > the current version at the same time. > > Do you think you will have released Perl 5.22 by then? If it's not > stable enough yet, maybe you could make a test release, and I could > make a corresponding test release of Biber. I've been building the last few test releases and it looks there are no Cygwin specific bugs that need to be taken care of. So in principle I could do the release rather fast. However, considering the fact that there are a bunch of Perl modules that need updating and not all of them are mine, the most likely course of action is that I'll upload the new Perl and my distributions to my own site so that interested parties (in particular, other package maintainers) can pick it up from there, build and test their stuff and we'll then coordinate the switchover. I'll be on a business trip beginning of June, so the actual release might be later that month if everything else works out OK. 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: [ITP] cfitsio : FITS (Flexible Image Transport System) lib and utility
Marco Atzeri writes: > package already presents in the major disti's. Yaakov has the previous version in ports, IIRC with a slightly different packaging. You might want to check his cygport files and coordinate with him. 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: [ITP] perl-WWW-Curl
Marco Atzeri writes: > I think you don't need any ITP for perl packages. > They are yours by default. Then my !packages file should probably just say "|perl\-.*" at the end. :-P > Do you need just an entry on > https://cygwin.com/cygwin-pkg-maint Yes, thanks for doing that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [ITP] perl-WWW-Curl
Achim Gratz writes: > As requested here: > > https://cygwin.com/ml/cygwin/2015-03/msg00525.html > > The package provides a Perl binding to libcurl. It compiles cleanly on > x86 and with an implicit conversion overflow warning on x86_64 (looks > harmless) and tests cleanly on both architectures. Ping… 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: Perl distributions
Achim Gratz writes: > I just realized that the 64bit distribution has a perl-Term-ReadKey > package that should have been obsoleted by perl-TermReadkey (sans the > hyphen). Can somebody please move the directory perl-Term-ReadKey into > perl-TermReadkey so I can create and install the obsoletion package? Ping… 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: [ATTN Maintainer] csih
Corinna Vinschen writes: >> I just did a 'cvs diff'… > > $ echo "diff -upN" >> ~/.cvsrc Great, done. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [ATTN Maintainer] csih
Corinna Vinschen writes: > diff -up, please, it's much easier to read. I just did a 'cvs diff'… > Yes, please apply. Done. > That should work. IIUC Chuck was trying to check if every single right > has been granted, but the single call to editrights should do the same > thing, given that it calls LsaAddAccountRights and returns an error if > that function returns an error. > > Feel free to apply a patch after testing. Will try later. 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: [ATTN Maintainer] csih
Corinna Vinschen writes:
>> There's another fix that should probably go into the scripts: The
>> service users should get SeDenyInteractiveLogonRight (they already have
>> SeDenyRemoteLogonRight). At least on my Windows7 Pro/64bit laptop the
>> accounts show up on the login screen otherwise.
>
> Still, https://cygwin.com/acronyms/#PGA? Really, I mean it.
Sorry, I was temporarily out of round tuits.
Index: cygwin-service-installation-helper.sh
===
RCS file: /cvs/cygwin-apps/csih/cygwin-service-installation-helper.sh,v
retrieving revision 1.37
diff -r1.37 cygwin-service-installation-helper.sh
3038a3039
> /usr/bin/editrights -a SeDenyInteractiveLogonRight -u
> ${csih_PRIVILEGED_USERNAME} &&
OK to commit?
BTW, is there some deeper reason to use
/usr/bin/editrights -a SeAssignPrimaryTokenPrivilege -u
${csih_PRIVILEGED_USERNAME} &&
/usr/bin/editrights -a SeCreateTokenPrivilege -u
${csih_PRIVILEGED_USERNAME} &&
/usr/bin/editrights -a SeTcbPrivilege -u ${csih_PRIVILEGED_USERNAME} &&
/usr/bin/editrights -a SeDenyInteractiveLogonRight -u
${csih_PRIVILEGED_USERNAME} &&
/usr/bin/editrights -a SeDenyRemoteInteractiveLogonRight -u
${csih_PRIVILEGED_USERNAME} &&
/usr/bin/editrights -a SeServiceLogonRight -u
${csih_PRIVILEGED_USERNAME} &&
username_got_all_rights="yes"
instead of
/usr/bin/editrights \
-a SeAssignPrimaryTokenPrivilege -a SeCreateTokenPrivilege -a
SeTcbPrivilege \
-a SeDenyInteractiveLogonRight -a SeDenyRemoteInteractiveLogonRight \
-a SeServiceLogonRight -u ${csih_PRIVILEGED_USERNAME} &&
username_got_all_rights="yes"
? Because if there is, that seems like a bug in editrights that should
be fixed.
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
Re: [ATTN Maintainer] csih
Corinna Vinschen writes: >> "Windows 8.1 N with Bing" gets reported as "Windows 8.1 China" (probably >> renamed by MS after the fact). Marketing wins this round apparently. All documentation I can find still says "country specific Windows variant" and suggests "China" as the variant name to go with that. Yet clearly Windows itself knows it has been named "N with Bing". >> It seems that either it would need to be linked statically or the >> library provided in a place where it can be found. > > I *do* take patches... > > ...and, yes, we should move this and the other cygwin-apps projects to > git as well. If there wouldn't be these lame time constraints like, > say, onmly 24 hours a day. I just realized I still have the CVS checkout from the script fixes anyway. A quick look doesn't reveal any obvious reason why this executable would be linked against libwinpthread… and indeed if I compile it on Cygwin it doesn't. So, no patch required, but a rebuild is in order. You might have had LDFLAGS or CFLAGS set while building the package? There's another fix that should probably go into the scripts: The service users should get SeDenyInteractiveLogonRight (they already have SeDenyRemoteLogonRight). At least on my Windows7 Pro/64bit laptop the accounts show up on the login screen otherwise. 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
[PATCH] genini.pl: create SHA512 instead of MD5 checksums
diff --git a/genini.pl b/genini.pl
index 973ecfd..f5b13ea 100755
--- a/genini.pl
+++ b/genini.pl
@@ -6,7 +6,7 @@
# for details.
#
use File::Basename;
-use Digest::MD5;
+use Digest::SHA;
use Getopt::Long;
use strict;
@@ -228,9 +228,9 @@ sub filer {
myerror "can't open $f - $!" unless $main::okmissing{$what};
return undef;
};
-my $md5 = Digest::MD5->new;
-$md5->addfile(\*F);
-$x->{$what} = join(' ', $f, -s $f, $md5->hexdigest);
+my $sha512 = Digest::SHA->new(512);
+$sha512->addfile(\*F);
+$x->{$what} = join(' ', $f, -s $f, $sha512->hexdigest);
}
sub tarball {
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
[ITP] perl-WWW-Curl
As requested here: https://cygwin.com/ml/cygwin/2015-03/msg00525.html The package provides a Perl binding to libcurl. It compiles cleanly on x86 and with an implicit conversion overflow warning on x86_64 (looks harmless) and tests cleanly on both architectures. --8<---cut here---start->8--- wget="wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/x86/release/perl-WWW-Curl/";; $wget/perl-WWW-Curl-4.17-1-src.tar.xz $wget/perl-WWW-Curl-4.17-1.tar.xz $wget/perl-WWW-Curl-debuginfo/perl-WWW-Curl-debuginfo-4.17-1.tar.xz $wget/perl-WWW-Curl-debuginfo/setup.hint $wget/setup.hint --8<---cut here---end--->8--- --8<---cut here---start->8--- wget="wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/x86_64/release/perl-WWW-Curl/";; $wget/perl-WWW-Curl-4.17-1-src.tar.xz $wget/perl-WWW-Curl-4.17-1.tar.xz $wget/perl-WWW-Curl-debuginfo/perl-WWW-Curl-debuginfo-4.17-1.tar.xz $wget/perl-WWW-Curl-debuginfo/setup.hint $wget/setup.hint --8<---cut here---end--->8--- 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
[ATTN Maintainer] csih
While csih is currently orphaned… :-( I still found these bugs: "Windows 8.1 N with Bing" gets reported as "Windows 8.1 China" (probably renamed by MS after the fact). Also: > /usr/lib/csih/getAccountName.exe /usr/lib/csih/getAccountName.exe: error while loading shared libraries: libwinpthread-1.dll: cannot open shared object file: No such file or directory It seems that either it would need to be linked statically or the library provided in a place where it can be found. 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: SSH key for upload access
Thomas Wolff writes: > Hmm, so why does lftp ask me for a password? Because you get bumped to the SSH connection only after you've connected via password-less login. Create the following bookmark in lftp (yes, that colon after cygwin is important) to avoid the password prompt: cygwin sftp://cygwin:@cygwin.com Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Perl distributions
Jon TURNEY writes: > On 28/03/2015 16:37, Achim Gratz wrote: >> I have a few corrections and additions to the Perl distributions. > > Applied. Thank you very much. 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: Perl distributions
I just realized that the 64bit distribution has a perl-Term-ReadKey package that should have been obsoleted by perl-TermReadkey (sans the hyphen). Can somebody please move the directory perl-Term-ReadKey into perl-TermReadkey so I can create and install the obsoletion package? 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
Perl distributions
I have a few corrections and additions to the Perl distributions. --8<---cut here---start->8--- --- cygwin-pkg-maint2015-03-27 16:11:48.0 +0100 +++ cygwin-pkg-maint.new2015-03-28 17:17:31.369634092 +0100 @@ -1218,6 +1218,7 @@ perl-Config-Tiny Achim Gratz perl-CPAN-DistnameInfo Achim Gratz perl-CPAN-Meta Achim Gratz +perl-CPAN-Meta-Check Achim Gratz perl-CPAN-Meta-Requirements Achim Gratz perl-CPAN-Meta-YAML Achim Gratz perl-CPAN-Reporter Achim Gratz @@ -1257,6 +1258,7 @@ perl-File-Listing Achim Gratz/Yaakov Selkowitz perl-File-pushd Achim Gratz perl-File-Slurp Achim Gratz/Ken Brown +perl-File-Slurp-Tiny Achim Gratz perl-File-Slurp-Unicode Achim Gratz/Ken Brown perl-File-Which Achim Gratz perl-Getopt-ArgvFile Yaakov Selkowitz @@ -1291,7 +1293,7 @@ perl-Inline-Files Achim Gratz perl-IO-CaptureOutput Achim Gratz perl-IO-HTML Achim Gratz/Ken Brown -perl-Prompt-Tiny Achim Gratz +perl-IO-Prompt-Tiny Achim Gratz perl-IO-Socket-INET6 Achim Gratz perl-IO-Socket-IP Achim Gratz/Yaakov Selkowitz perl-IO-Socket-SSL Achim Gratz/Yaakov Selkowitz @@ -1316,6 +1318,7 @@ perl-Metabase-Fact Achim Gratz perl-MIME-Charset Achim Gratz/Ken Brown perl-Module-Build Achim Gratz +perl-Module-Metadata Achim Gratz perl-Module-ScanDeps Achim Gratz/Yaakov Selkowitz perl-Module-Signature Achim Gratz perl-Mozilla-CA Achim Gratz/Ken Brown @@ -1335,7 +1338,7 @@ perl-Parse-RecDescent Achim Gratz perl-Path-Class Achim Gratz perl-Pod-Coverage Achim Gratz -perl-Pod-Excapes Achim Gratz +perl-Pod-Escapes Achim Gratz perl-Pod-Simple Achim Gratz perl-POD2-Base Achim Gratz perl-Probe-Perl Achim Gratz @@ -1355,7 +1358,7 @@ perl-TermReadkey Achim Gratz perl-Term-ReadKey Achim Gratz/Yaakov Selkowitz perl-Term-ReadLine-Gnu Achim Gratz/Yaakov Selkowitz -perl-Term-Readline-Perl Achim Gratz +perl-Term-ReadLine-Perl Achim Gratz perl-Test-Base Achim Gratz perl-Test-Fatal Achim Gratz perl-Test-NoWarnings Achim Gratz --8<---cut here---end--->8--- The additions are build and runtime dependencies recently introduced to distributions I have updated. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Question about clisp version naming
Ken Brown writes: > OK, that's good. I'd still like to get it to work, but I'm stumped at > the moment. I've tried tweaking the build in various ways, but I > can't get dumping of executables and dynamic modules to work > simultaneously. > > The earlier approach of using a lisp DLL came the closest to working, > but that's not viable if the resulting DLL can't be rebased. I *think* the problem in both cases is that the executable is not properly linked and thus can't be relocated. It seems that having a lisp.o, the memory dump and some linker script should get the desired dump.exe without the breakage. 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: Question about clisp version naming
Ken Brown writes: >> So maybe you could dump a memory image maxima.mem and start it with a >> script that calls 'clisp -M maxima.mem'. I'm already doing that. :-) > I just took a look at the maxima package, and it seems that you > already use a script that does something like this in the absence of a > maxima executable. Is it really much slower to start maxima that way? Not for me, but I'm using an SSD. I haven't yet tested on spinning rust or over slow network. But I don't really think it makes much of a difference, it seems it just has to open one more file than it would otherwise. I'm not sure if there are other platforms for clisp that can't dump executables, if so you might look at whether they remove the corresponding code and/or warn or error out on an attempt to dump an executable. > I tried 'clisp -M maxima.mem', and it started up instantly. Whatever > other overhead there is in the maxima script seems to be the same > whether there's a maxima executable or not. But maybe I'm missing > something. As I said, I've revoked the maxima-exec-clisp package for now, so whether you either come up with a solution for that problem or conclude that dumping of executables isn't going to be supported on Cygwin, I'm fine. For whatever reason, the exec stuff is the default for clisp and building the non-exec had required some jumping through hoops (building them both in one go wasn't even supported). But I've fixed that now. 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
Re: Question about clisp version naming
Ken Brown writes:
> And indeed it does. I've still got a couple of things to clean up,
> but I expect to upload a new clisp soon that no longer uses lisp.dll.
> I hope that will solve the Maxima problem
It doesn't… Instead of lisp.dll it now requires lisp.exe to be in $PATH
and it produces an executable that immediately segfaults. This has
nothing to do with maxima, you can produce the same abort more simply
with:
clisp -norc -q -x '(progn (ext:saveinitmem "test.exe" :init-function (function
exit) :EXECUTABLE t))'
env PATH=${PATH}:/usr/lib/clisp-2.49+/base ./test.exe
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: Question about clisp version naming
Ken Brown writes: >> How does the >> lisp.exe in clisp relate to the one that would be in maxima-exec-clisp? > > Achim will have to answer this one. I don't really know either. The executable dump is provided by clisp and you can name the resulting exe any which way you want. For maxima, it's maxima.exe. This file is (looking at both the non-executable memory image and the executable one) an exe stub with the non-executable image as an overlay. I don't really know where the stub comes from, but I don't see it directly relating to lisp.exe at the moment. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: Question about clisp version naming
Ken Brown writes: > Great. Thanks for testing. There's probably no reason for me to > upload a new clisp package right now (unless it would help you). But > I'll give you a heads up when I'm ready to do that. I've now drilled to the bottom of what I had assumed were build/package problems… it turns out that if you rebase the lisp.dll, then the dumped executable that depends on it stops working. The dumped executable as well as clisp.exe is OK since rebase decides it can't touch it. The other interesting thing to note is that rebase has altered lisp.dll even though it says it didn't. --8<---cut here---start->8--- /mnt/share/maint (2015) objdump -h /usr/lib/clisp-2.49+/base/lisp.dll /usr/lib/clisp-2.49+/base/lisp.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00107794 69a81000 69a81000 0600 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 0001b3e4 69b89000 69b89000 00107e00 2**6 CONTENTS, ALLOC, LOAD, DATA 2 .rdata000d4dbc 69ba5000 69ba5000 00123200 2**6 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .buildid 0035 69c7a000 69c7a000 001f8000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .eh_frame 000241f4 69c7b000 69c7b000 001f8200 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .bss 4fb8 69ca 69ca 2**6 ALLOC 6 .edata00014b0b 69ca5000 69ca5000 0021c400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .idata3914 69cba000 69cba000 00231000 2**2 CONTENTS, ALLOC, LOAD, DATA 8 .reloc0002964c 69cbe000 69cbe000 00234a00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .debug_aranges 0778 69ce8000 69ce8000 0025e200 2**3 CONTENTS, READONLY, DEBUGGING 10 .debug_info 004519d6 69ce9000 69ce9000 0025ea00 2**0 CONTENTS, READONLY, DEBUGGING 11 .debug_abbrev c2e3 6a13b000 6a13b000 006b0400 2**0 CONTENTS, READONLY, DEBUGGING 12 .debug_line 0004088c 6a148000 6a148000 006bc800 2**0 CONTENTS, READONLY, DEBUGGING 13 .debug_frame 0038 6a189000 6a189000 006fd200 2**2 CONTENTS, READONLY, DEBUGGING 14 .debug_str0001f4a7 6a18a000 6a18a000 006fd400 2**0 CONTENTS, READONLY, DEBUGGING 15 .debug_loc001113f0 6a1aa000 6a1aa000 0071ca00 2**0 CONTENTS, READONLY, DEBUGGING 16 .debug_ranges 0004deb0 6a2bc000 6a2bc000 0082de00 2**0 CONTENTS, READONLY, DEBUGGING /mnt/share/maint (2016) maxima -v + '[' clisp = clisp ']' + '[' true = true ']' + '[' -x /usr/lib/maxima/5.35.1/binary-clisp/maxima ']' + exec /usr/lib/maxima/5.35.1/binary-clisp/maxima -q '' -- -v '' '' '' '' '' '' '' '' Maxima 5.35.1 http://maxima.sourceforge.net using Lisp CLISP 2.49+ (2010-07-17) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) /mnt/share/maint (2017) rebase -sO /usr/lib/clisp-2.49+/base/lisp.dll rebase: oblivious file "/usr/lib/clisp-2.49+/base/lisp.dll" already found in rebase database (file and database kept unchanged). /mnt/share/maint (2018) maxima -v + '[' clisp = clisp ']' + '[' true = true ']' + '[' -x /usr/lib/maxima/5.35.1/binary-clisp/maxima ']' + exec /usr/lib/maxima/5.35.1/binary-clisp/maxima -q '' -- -v '' '' '' '' '' '' '' '' module 'syscalls' requires package OS. /mnt/share/maint (2019) objdump -h /usr/lib/clisp-2.49+/base/lisp.dll /usr/lib/clisp-2.49+/base/lisp.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00107794 4d1b1000 4d1b1000 0600 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 0001b3e4 4d2b9000 4d2b9000 00107e00 2**6 CONTENTS, ALLOC, LOAD, DATA 2 .rdata000d4dbc 4d2d5000 4d2d5000 00123200 2**6 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .buildid 0035 4d3aa000 4d3aa000 001f8000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .eh_frame 000241f4 4d3ab000 4d3ab000 001f8200 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .bss 4fb8 4d3d 4d3d 2**6 ALLOC 6 .edata00014b0b 4d3d5000 4d3d5000 0021c400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .idata3914 4d3ea000 4d3ea000 00231000 2**2 CONTENTS, ALLOC, LOAD, DATA 8 .reloc0002964c 4d3ee000 4d3ee000 00234a00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .debug_aranges 0778 4d418000 4d4
Re: Question about clisp version naming
Yaakov Selkowitz writes: >> Looking at the executable it seems that it is a very small (~66 kiB) >> stub that then proceeds to load the rest of the file after having >> started the runtime. The memory image seems simply bolted on (as an >> overlay?), and gets removed when the executable is stripped. UPX says it found an overlay and doesn't compress it. > That sounds very similar to OCaml; if so, I would expect there to be > some sort of magic number in the binary that can be used to identify > this type of executable (just because file(1) doesn't know about it > doesn't mean it doesn't exist). If we can pinpoint that, cygport can be > patched to not strip them. That string is likely a good initial bet: 000107b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 |...c| 000107c0 6c 69 73 70 00 69 31 38 6e 00 73 79 73 63 61 6c |lisp.i18n.syscal| 000107d0 6c 73 00 00 00 00 00 b4 fc d7 e7 03 00 00 00 50 |ls.P| Or really, just check if the executable has an overlay and leave it alone if so, like UPX does. No magic required. 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: Question about clisp version naming
Ken Brown writes: > The clisp executables are not stripped because apparently there's a > disassemble command within clisp that doesn't work if the executables > are stripped. I don't actually know anything about this, but there > was a comment about that in the .cygport file that I inherited from > Reini. This may or may not explain why maxima.exe didn't like being > stripped. Looking at the executable it seems that it is a very small (~66 kiB) stub that then proceeds to load the rest of the file after having started the runtime. The memory image seems simply bolted on (as an overlay?), and gets removed when the executable is stripped. 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: Question about clisp version naming
Ken Brown writes: >> No it doesn't. Specifically, it doesn't like being stripped. I'll >> RESTRICT that, let's hope it works now… Yup, it does. > > Great. Thanks for testing. There's probably no reason for me to > upload a new clisp package right now (unless it would help you). But > I'll give you a heads up when I'm ready to do that. I'll continue to use the workaround for this (hopefully final) iteration of the maxima package. I'll drop that part of the patch when it is no longer necessary. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: Question about clisp version naming
Yaakov Selkowitz writes: > Is there an issue with stripping clisp executables? Yes, with the executable dumps. > Is there a magic > number we can use to detect these automatically? File identifies them as plain executables. CLisp knows which runtime they were rpdocued from, so there must by some symbols to pull this information from. Ken should have an answer, otherwise I can investigate later. In any case these are the only executables shipped with maxima, so RESTRICT=strip doesn't do any harm at the moment. 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: Question about clisp version naming
Achim Gratz writes: >> The loading of memory images via clisp works, so I'll pull the >> maxima-exec-clisp package until we get to the bottom of this. > > Hmm. Scratch that, I think I got the maxima.exe (dumped image) to work. > Let's see if it survives installation. No it doesn't. Specifically, it doesn't like being stripped. I'll RESTRICT that, let's hope it works now… Yup, it does. 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: Question about clisp version naming
Achim Gratz writes: > Ken Brown writes: >> Just for testing purposes, I've built a new clisp with >> /usr/bin/cyglisp.dll and /usr/lib/liblisp.dll.a, and I've uploaded it >> to my Cygwin repository: >> >> http://sanibeltranquility.com/cygwin/ >> >> When you get a chance, please test it and see if it allows you to >> avoid your workaround. If so, I'll think about whether it's worth >> repackaging following Fedora. > > This has the same problem as the current release: any attempt to run > lisp.exe (or an executable dump) will produce this message: > > ...lib/clisp-2.49+/base (2120) ./lisp.exe > module 'syscalls' requires package OS. > /mnt/share/maint (2125) /usr/lib/clisp-2.49+/base/lisp.exe > module 'syscalls' requires package OS. > > The loading of memory images via clisp works, so I'll pull the > maxima-exec-clisp package until we get to the bottom of this. Hmm. Scratch that, I think I got the maxima.exe (dumped image) to work. Let's see if it survives installation. 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: Question about clisp version naming
Ken Brown writes: > Just for testing purposes, I've built a new clisp with > /usr/bin/cyglisp.dll and /usr/lib/liblisp.dll.a, and I've uploaded it > to my Cygwin repository: > > http://sanibeltranquility.com/cygwin/ > > When you get a chance, please test it and see if it allows you to > avoid your workaround. If so, I'll think about whether it's worth > repackaging following Fedora. This has the same problem as the current release: any attempt to run lisp.exe (or an executable dump) will produce this message: ...lib/clisp-2.49+/base (2120) ./lisp.exe module 'syscalls' requires package OS. /mnt/share/maint (2125) /usr/lib/clisp-2.49+/base/lisp.exe module 'syscalls' requires package OS. The loading of memory images via clisp works, so I'll pull the maxima-exec-clisp package until we get to the bottom of this. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: Question about clisp version naming
Ken Brown writes: > I thought this would all work fine because lisp.dll was in the same > directory as lisp.exe. And it does work fine for users of clisp. But > I didn't think about applications like Maxima that would need to link > against lisp.dll. Maxima doesn't link against this library, it uses clisp' capability of dumping an executable that has the application pre-loaded. In fact, if you simply start the resulting EXE (not through the maxima wrapper) you'll be greeted by a CLisp prompt. > I think my new proposal (with /usr/bin/cyglisp.dll and > /usr/lib/liblisp.dll.a) will work better. I don't know whether it's > best to split off libclisp and clisp-devel subpackages. Fedora has a > separate clisp-devel package, but it contains a lot of files that are > currently (and have always been) in the main clisp package on > Cygwin. At the moment, it's probably a higher priority to get > something in the distro that Achim can use to build Maxima. But I'm > open to suggestion on all of this. I have a workaround for maxima and building and testing the package as we speak. We can test the new clisp packaging more thoroughly later on. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [ITA/ITP] lots of perl distributions
Yaakov Selkowitz writes: > I believe these are all gone from Ports now, would you mind > double-checking? Within the next week, yes. If I still find something, I'll let you know. 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: Question about clisp version naming
Ken Brown writes: > This sounds like a packaging error on my part. First of all, lisp.dll > is new with the latest clisp; it was part of my solution to the > dynamic loading problem. But from what you say, it sounds like I > should put it in /usr/bin. In fact, I should rename it to > cyglisp.dll, with a corresponding /usr/lib/liblisp.dll.a, so that > applications can link against it with '-llisp'. Would this solve the > problem? That would solve the problem, AFAICS (I'd go with cygclisp.dll, though). I've meanwhile found out that if I put the clisp dir3ectory in PATH the library is also found. But I had to patch the scripts calling maxima for that, so if this isn't necessary then this is even better. > In retrospect, I should have made the new clisp a test release, to > avoid breaking things. Sorry about that. No problem, I didn't know this would cause breakage either. AT the moment nobody else seems to use these things anyway. :-) 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
Re: Question about clisp version naming
Ken Brown writes: > My work was based on the tip of the upstream Mercurial repository, > which shows a version number of 2.49+ and is at revision 15623. So I > was thinking of using 2.49+hg15623 as the version number. Will upset > be happy with that? Or is there some other standard way of assigning > version numbers in cases like this? Maxima needs to be rebuilt for the new clisp, but the clisp-exec build errors out with /mnt/share/maint/maxima.x86_64/build/src/binary-clisp/maxima.exe: error while loading shared libraries: lisp.dll: cannot open shared object file: No such file or directory I'm not sure if that's a build error on the clisp side or something I need to fix in maxima yet, but if you know what to do, please chime in. If I link the lisp.dll from clisp into the binary-clisp directory _and_ start maxima with the cwd in that same directory I can start it. But not if I just add to PATH. It also works if lisp.dll gets linked into /usr/bin. So how do I tell that executable where to look for libraries at runtime? The clisp mem-based build runs the tests (not finished yet). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: perl-5.14.4
Corinna Vinschen writes: >> So the binutils problem is fixed upstream, we're just waiting for GDB >> to catch up. Another collegue of mine will have a look as soon as time >> permits. > > Here's one for testing, Achim: > > https://cygwin.com/ml/cygwin-announce/2015-03/msg00020.html That works correctly now. 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: [ITA] perl-Error, perl-Locale-gettext, perl-Win32-GUI, perl-libwin32
Ken Brown writes: > The current upstream Biber depends on File-Slurp. But it also > requires Perl 5.16 or later, so I won't be able to rebuild it and get > rid of the dependency on File-Slurp-Unicode until you update Perl in > May. I've had a quick look. Of course they do use that one feature (unicode case folding) introduced with 5.16 that can't be backported via modules to 5.14.4… oh well. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Question about clisp version naming
Yaakov Selkowitz writes: > Obviously we don't have %dist, but did you continue reading to the > "Non-Numeric Version in Release" section? Yes. I can somewhat understand the rationale for putting this in the release part, but I still like the openSUSE numbering better. The central question is how you introduce ordering and it's easily taken care of by prepending the ISO data before any version monikers that don't strictly increment. We've got a bunch of those already in Cygwin as well (most of them from Jari IIRC), so why should we change that now? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Question about clisp version naming
Yaakov Selkowitz writes: > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning The way I read this, there is no suggestion of putting these extra version parts in or after the %dist and/or build number, which is what we use the release field for. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [ITA] perl-Error, perl-Locale-gettext, perl-Win32-GUI, perl-libwin32
Yaakov Selkowitz writes: >> This is not a distribution anymore but became a bundle consiting of some >> 40 distributions, of which 8 don't build. Yaakov, can you please >> obsolete it as nothing depends on it anyway. I'll ITP the Win32-* >> packages as I get them to compile later on. > > Obsolete it how? What will be replacing it? Removing it from the x86 distro really. Nothing depends on it and I believe it has stopped working several years ago. As I said, this is now a bundle on CPAN that comprises of some 30+ distributions, about a third of which don't compile or don't test cleanly. I'll eventually get to it and see what is salvageable for Cygwin, but it will take some time. 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
Re: [ITA/ITP] lots of perl distributions
Yaakov Selkowitz writes: > If you are using a new build, the proper way to handle this would be to > bump RELEASE so that the distro package takes precedence; that way I > don't have to remove the package from Ports the very instant it lands in > the distro. The alternative would have been for me to copy over the > existing tarballs from Ports, which is "cleaner" because then they > really are the same package. I have done that (I hope I didn't miss anything, at the moment that is all manual). As long as you don't release new packages with the same version number everything should be fine. 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
Re: Question about clisp version naming
Achim Gratz writes: > As you wish. I still think his view is somewhat unique looking at the > version numbers in several Linux distros that provide packages > in-between-official-releases from several VCS. The only case that I > know where the VCS revision tag was used in the relase part of the > version string was when the release was made from a local branch in all > other cases they'd been appended to the latest release version string. Here are a few examples from my Tumbleweed installation for illustration: | grub2-x86_64-efi | 2.02~beta2-33.1| | libffi4-32bit | 4.8.3+r218481-2.1 | | libiniparser0-32bit | 3.1.0.git20140619_c5beb80a-3.1 | | liblockdev1-32bit | 1.0.3_git201003141408-29.2 | | libspeex1-32bit | 1.1.999_1.2rc2-1.1 | | shim | 0.7.318.81ee561d-9.1 | | libx265-32| 0.32hg20140928-2.10| Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Question about clisp version naming
Ken Brown writes: >> Version numbers like the one Ken has proposed are becoming common in >> Linux distributions, so we'd rather check that setup handles them >> correctly. I think Jari already uses a bunch of them. The thing here >> is that for all versioning schemes that use hashes you need to prepend >> an ISO date so things sort correctly, but I'd rather not append this to >> the release number, so I'd suggest VERSION=2.49+MMDDhg15623 instead. >> Also, I don't think it's a good idea to allow "." in the release >> number. Alphas already work in that place (I use that for snapshots >> since years) and are a lot less ambigous if you try to parse the release >> out of a file name. > > Sorry, but Yaakov says we already allow dots in the release number, > and he's the distro czar. So I'm going with his suggestion. As you wish. I still think his view is somewhat unique looking at the version numbers in several Linux distros that provide packages in-between-official-releases from several VCS. The only case that I know where the VCS revision tag was used in the relase part of the version string was when the release was made from a local branch in all other cases they'd been appended to the latest release version string. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [ITA] perl-Error, perl-Locale-gettext, perl-Win32-GUI, perl-libwin32
Jon TURNEY writes: > Sure, no problem. Thanks. > perl-Win32-GUI is only used by the startup shell script as a way to > retrieve GetSystemMetrics(SM_C(X|Y)VIRTUALSCREEN). I'm sure that can > be re-written another way. So is that shell script just not working on x86_64 at all or is it already changed there? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [ITA] perl-Error, perl-Locale-gettext, perl-Win32-GUI, perl-libwin32
Achim Gratz writes: > Ken, would you still know if the Log-Log4Perl and Text-BibTeX tests were > clean previously? I'm getting what looks like an encoding problem from > Text-BibTeX and an offset in some file sizes(?) for Log-Log4Perl. The "offset" seems to be a file mode check that doesn't work due to me being an administrator. Text-BibTeX tests clean in the stage2 build, so there's either a dependency cycle or missing dependency somewhere. In any case, it looks good to me now. Lastly, could you please check if Biber really needs the obsolete File-Slurp-Unicode or couldn't just depend on File-Slurp instead? 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: [ITA] perl-Error, perl-Locale-gettext, perl-Win32-GUI, perl-libwin32
Achim Gratz writes: > These four packages still install into the perl-5.10 directories on > 32bit and need to be updated for perl-5.14. > > I'll have to see what to do about the last two, because I'm pretty sure > that libwin32 doesn't build on 64bit. This is not a distribution anymore but became a bundle consiting of some 40 distributions, of which 8 don't build. Yaakov, can you please obsolete it as nothing depends on it anyway. I'll ITP the Win32-* packages as I get them to compile later on. > I may obsolete them (Win32-GUI is > required by XtoW, though, so that would have ripple effects). John, can XtoW please be re-packaged so it doesn't depend on perl-Win32-GUI, like it already doesn't on x86_64? The package doesn't build and it looks like there'll be some bug hunting necessary before it does again. > To the maintainers of other Perl distributions: if there's any you want > to part with, please let me know and I'll most likely adopt them. All right, that would need the diff below which also includes some new build dependencies. Yaakov, I need to rename perl-Unicode-GCString -> perl-Unicode-LineBreak perl-Locale-gettext -> perl-gettext Could you please move these packages into the respective new subdirectories so the obsoletion will work correctly without upsetting upset? Ken, would you still know if the Log-Log4Perl and Text-BibTeX tests were clean previously? I'm getting what looks like an encoding problem from Text-BibTeX and an offset in some file sizes(?) for Log-Log4Perl. --8<---cut here---start->8--- --- cygwin-pkg-maint2015-03-12 14:09:19.0 +0100 +++ cygwin-pkg-maint.new2015-03-12 23:35:15.735761203 +0100 @@ -1186,10 +1186,10 @@ perl-Archive-Zip Achim Gratz/Yaakov Selkowitz perl-Authen-SASL Yaakov Selkowitz perl-B-Generate Achim Gratz -perl-Business-ISBN Ken Brown -perl-Business-ISBN-Data Ken Brown -perl-Business-ISMN Ken Brown -perl-Business-ISSN Ken Brown +perl-Business-ISBN Achim Gratz/Ken Brown +perl-Business-ISBN-Data Achim Gratz/Ken Brown +perl-Business-ISMN Achim Gratz/Ken Brown +perl-Business-ISSN Achim Gratz/Ken Brown perl-Cairo Yaakov Selkowitz perl-Cairo-GObject Yaakov Selkowitz perl-Capture-TinyAchim Gratz/Ken Brown @@ -1198,47 +1198,54 @@ perl-Clone Yaakov Selkowitz perl-common-senseAchim Gratz perl-Compress-Bzip2 Achim Gratz -perl-Config-AutoConf Ken Brown +perl-Config-AutoConf Achim Gratz/Ken Brown perl-Config-Perl-V Achim Gratz perl-Config-Tiny Achim Gratz perl-CPAN-DistnameInfo Achim Gratz +perl-CPAN-Meta Achim Gratz +perl-CPAN-Meta-Requirements Achim Gratz +perl-CPAN-Meta-YAML Achim Gratz perl-CPAN-Reporter Achim Gratz perl-CPAN-Testers-Report Achim Gratz perl-Data-Alias Achim Gratz -perl-Data-CompareKen Brown -perl-Data-Diver Ken Brown -perl-Data-Dump Ken Brown +perl-Data-Compare Achim Gratz/Ken Brown +perl-Data-Diver Achim Gratz/Ken Brown +perl-Data-Dump Achim Gratz/Ken Brown perl-Data-GUID Achim Gratz perl-Data-OptListAchim Gratz perl-Data-UUID Achim Gratz perl-Devel-Autoflush Achim Gratz perl-Devel-Symdump Achim Gratz -perl-Date-Simple Ken Brown +perl-Date-Simple Achim Gratz/Ken Brown perl-DBD-mysql Yaakov Selkowitz perl-DBD-SQLite Yaakov Selkowitz perl-DBI Yaakov Selkowitz perl-Digest-HMAC Achim Gratz/Yaakov Selkowitz perl-Digest-SHA1 Achim Gratz/Yaakov Selkowitz -perl-Encode-EUCJPASCII Ken Brown -perl-Encode-HanExtra Ken Brown -perl-Encode-JIS2KKen Brown +perl-Encode-EUCJPASCII Achim Gratz/Ken Brown +perl-Encode-HanExtra A
Re: [ITA] perl-Error, perl-Locale-gettext, perl-Win32-GUI, perl-libwin32
Yaakov Selkowitz writes: > On Thu, 2015-03-12 at 07:52 +0100, Achim Gratz wrote: >> These four packages still install into the perl-5.10 directories on >> 32bit and need to be updated for perl-5.14. > > The curr: release of perl-Locale-gettext is already built for 5.14, only > the prev: release is 5.10. That being said, if you're willing to carry > the existing patchset, you're welcome to comaintain it. I just looked at which packages put files in the 5.10 path this morning, so sorry I missed that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
[ITA] perl-Error, perl-Locale-gettext, perl-Win32-GUI, perl-libwin32
These four packages still install into the perl-5.10 directories on 32bit and need to be updated for perl-5.14. I'll have to see what to do about the last two, because I'm pretty sure that libwin32 doesn't build on 64bit. I may obsolete them (Win32-GUI is required by XtoW, though, so that would have ripple effects). To the maintainers of other Perl distributions: if there's any you want to part with, please let me know and I'll most likely adopt them. 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: Question about clisp version naming
Yaakov Selkowitz writes: >> My work was based on the tip of the upstream Mercurial repository, which >> shows a version number of 2.49+ and is at revision 15623. So I was >> thinking of using 2.49+hg15623 as the version number. Will upset be >> happy with that? Or is there some other standard way of assigning >> version numbers in cases like this? > > With setup now being stricter about versions wrt upgrading, we need to > be as well. Because this is a post-2.49 revision, it should be > VERSION=2.49 and RELEASE=2.MMDDhg15623 (since there was already a > -1). Version numbers like the one Ken has proposed are becoming common in Linux distributions, so we'd rather check that setup handles them correctly. I think Jari already uses a bunch of them. The thing here is that for all versioning schemes that use hashes you need to prepend an ISO date so things sort correctly, but I'd rather not append this to the release number, so I'd suggest VERSION=2.49+MMDDhg15623 instead. Also, I don't think it's a good idea to allow "." in the release number. Alphas already work in that place (I use that for snapshots since years) and are a lot less ambigous if you try to parse the release out of a file name. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [PATCH setup 4/4] Silently ignore 'x' and 'g' type tar extended headers
Jon TURNEY writes: >> That's a result of me having built that file on openSUSE and openSUSE's >> decision to default to POSIX format instead of GNU. > > Hmm... maybe I should drop this patch, if the correct thing to do is > to build base-files with tar --format=gnu? GNU's been threatening to make POSIX the default for over a decade now, it's just that some openSUSE maintainer sprung into action a bit prematurely on that issue. The PAX extended headers are not needed by setup whatever their content may be AFAIK, but it would be nice if they didn't produce spuroius warnings or errors. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [ITP] maxima-5.35.1
Achim Gratz writes: >> Package is GTG With a change to the sdescs to allow a user at least >> a bit of information in sdesc what the subpackages are doing. > > Yeah, I'll fix that before release. Does that look better to you? maxima/setup.hint:sdesc: "Maxima - Computer Algebra System" maxima/maxima-exec-clisp/setup.hint: sdesc: "Maxima - CLisp executable" maxima/maxima-lang-de-utf8/setup.hint:sdesc: "Maxima - Localization for de" maxima/maxima-lang-es-utf8/setup.hint:sdesc: "Maxima - Localization for es" maxima/maxima-lang-pt-utf8/setup.hint:sdesc: "Maxima - Localization for pt" maxima/maxima-lang-pt_BR-utf8/setup.hint: sdesc: "Maxima - Localization for pt_BR" maxima/maxima-xmaxima/setup.hint: sdesc: "Maxima - Tcl/Tk based GUI" 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: [ITA/ITP] lots of perl distributions
Achim Gratz writes: > In order to get rid of perl_vendor on 32bit and update the packages to > the same versions on 64bit, I need to maintain the packages that were > formerly in perl_vendor plus another bunch that either are new > dependencies or are needed to build and test those packages. Done. Upset didn't complain, so I hope everything is OK. Yaakov, could you please remove the packages from ports that are now available in Cygwin proper? There have been a few collisions already with the 64bit distribution, some even with the same version number (they were probably the same packages in reality, but it still feels unclean). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [ITA/ITP] lots of perl distributions
Achim Gratz writes:
> I can use lftp myself, I'll just have to creatre a bunch of aliases or
> scripts, not sure yet how much I'm going to automate this.
Here's the set of lftp aliases to put into the lftp rc file.
--8<---cut here---start->8---
alias cygdn "lcd ~/cygwin/cygwin.lftp && cd / && mirror --scan-all-first
--use-cache -evvv"
alias cygup "lcd ~/cygwin/cygwin.lftp && cd / && mirror -X \\!packages
--scan-all-first --use-cache -Revvv"
alias cygtst "lcd ~/cygwin/cygwin.lftp && cd / && mirror -X \\!packages
--scan-all-first --use-cache -Revvv --dry-run"
alias cyggo "!touch -- x86{,_64}/\!ready && mput x86*/*ready"
--8<---cut here---end--->8---
You might want to play with the mirror:parallel-directories and
mirror:parallel-transfer-count settings, although sourceware is just
really slow for me ATM no matter which settings. I've also created a
bookmark for cygwin so that lftp doesn't ask for a password (since
cygwin is a password-less user). BTW, on the command line you can
achieve the same effect using the '-u cygwin,' option.
--8<---cut here---start->8---
cygwin sftp://cygwin:@cygwin.com
--8<---cut here---end--->8---
So, 106 packages all uploaded. Wish me luck… :-)
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [ITP] maxima-5.35.1
Corinna Vinschen writes: > I don't quite like the SUSE packaging with splitting out the language > packs, but the Fedora packaging, while using another strategy, isn't > really better, so that's ok. …and Debian's and Arch's is even worse, IMHO. I wouldn't mind putting the localization files back in the main package, but then there are probably a lot of people who'd never use those files. > What's not quite ok are the setup.hint files, IMHO. You have 7 packages > and all ldesc's and sdesc's are exactly identical. While that's perhaps > not much of a problem for the language packs, it certainly is for > "maxima" vs. "maxima-exec-clisp" and "maxima-xmaxima". How's the user > to know what each of these packages is doing when looking them up in > setup? > > maxima "Maxima Computer Algebra System" > maxima-exec-clisp "Maxima Computer Algebra System" > maxima-xmaxima "Maxima Computer Algebra System" > > Package is GTG With a change to the sdescs to allow a user at least > a bit of information in sdesc what the subpackages are doing. Yeah, I'll fix that before release. Thanks for checking. 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
Re: [ITA/ITP] lots of perl distributions
Corinna Vinschen writes: > On Mar 10 07:40, Achim Gratz wrote: >> Achim Gratz writes: >> > The upload was extremely slow and I've had the connection drop a few >> > times. Does sourceware throttle connections? At the moment I can't >> > even get a directory listing via sshfs anymore, although lftp still >> > seems to cope just fine. >> >> It seems I crossed a threshold with the number of directories in my >> release areas… :-( > > I'm not sure that's the problem. The fact that it worked until I populated it with all the Perl distributions and that it still works as long as I don't try to readdir the **/release/ directories (which are the only ones that are so large) made me suspect that. > This looks like the same problem > Federico and I have with sftp uploads for some reason. I pinged > overseers a couple of days ago but got no reply. For some reason it > works fine with lftp, though. Yes, omly it's a lot less transparent to me. > You could try the new cygport upload feature. It uses lftp under the > hood. I can use lftp myself, I'll just have to creatre a bunch of aliases or scripts, not sure yet how much I'm going to automate this. I won't use the cygport facility, mainly because I won't put my SSH key on the build box, but also because it doesn't easily cater to the common situation that I need to do things to a bunch of packages and/or remove some other stuff at the same time. 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: [ITA/ITP] lots of perl distributions
Achim Gratz writes: > The upload was extremely slow and I've had the connection drop a few > times. Does sourceware throttle connections? At the moment I can't > even get a directory listing via sshfs anymore, although lftp still > seems to cope just fine. It seems I crossed a threshold with the number of directories in my release areas… :-( --8<---cut here---start->8--- getdir[0] [00032] OPENDIR [00032] HANDLE 14bytes (185ms) [00033] READDIR [00034] READDIR debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0 debug1: client_input_channel_req: channel 0 rtype e...@openssh.com reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK Transferred: sent 5064, received 4464 bytes, in 2.8 seconds Bytes per second: sent 1799.7, received 1586.5 debug1: Exit status -1 remote host has disconnected executing <-X> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-2> <-s> --8<---cut here---end--->8--- Is there someone who can check what's going on on the server side here? If not I'll have to switch to using lftp for the upload, but that gives me a lot less transparency about what is going on and so increases the chances of doing something wrong. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [ITA/ITP] lots of perl distributions
Achim Gratz writes: > Yaakov Selkowitz writes: >> upset does indeed live up to its name in such a case, so we need to >> rearrange directories on sourceware to match the new layout. I have >> done so for perl-LWP, so please proceed. > > Thank you very much. I'll do the upload later today. The upload was extremely slow and I've had the connection drop a few times. Does sourceware throttle connections? At the moment I can't even get a directory listing via sshfs anymore, although lftp still seems to cope just fine. The upload appears to have finished, but I want to check everything again. I'll stop for today and try again tomorrow. 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: [ITA/ITP] lots of perl distributions
Yaakov Selkowitz writes: > upset does indeed live up to its name in such a case, so we need to > rearrange directories on sourceware to match the new layout. I have > done so for perl-LWP, so please proceed. Thank you very much. I'll do the upload later today. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [ITA/ITP] lots of perl distributions
Marco Atzeri writes: > as perl-LWP is a 64bit package required by several other packages, > you can not just drop it. I said I'm going to obsolete it, not drop it. > One possible solution is: > > bump perl-LWP with a empty tar > put in setup.hint > category: _obsolete > requires: perl-libwww-perl > > there are several examples in both the 2 setup.ini. > See file lengths of 32 of xz tar file. Cygport has produced that package already for me. It just wants me to put it in a different directory for whatever reason (I consider that a bug at the moment). If I move those files into perl-LWP I think I'm left with a package that has no sources in [curr] which upset is known to complain about. > PS: I do not see any perl-libwww-perl directory Not yet, until I've figured out what's the correct way forward. 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: [ITA/ITP] lots of perl distributions
Marco Atzeri writes: > done Thank you. I'm ready for the upload, but there's one thing I don't know how to handle correctly: I'm obsoleting perl-LWP in favor of perl-libwww-perl (that's the actual distribution name and it is needed for automated checking of dependencies via CPAN or MetaCPAN). Cygport provides an obsoletion package _inside_ the perl-libwww-perl directory and points to it as an external source. I think that upset might be upset when it finds the existing perl-LWP directory, so how is this obsoletion supposed to work in reality? Should I just delete the existing perl-LWP (I don't think I can delete the directory, though)? 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
