Perl distributions

Here we go again: perl-IPC-Cmd now depends on perl-Module-Load-Conditional, can somebody please make me the maintainer of the new package. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2:

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

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

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

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

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

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

New Perl distribution dependency

For the next round of distribution updates I need a new dependency, perl-XSLoader. Could someone please add this to my list of packages (mind the capitalization)? Thanks. Regards, Achim.

Re: perl-5.24?

Ken Brown writes: > I'm wondering whether you have plans to update perl to 5.24. The biber > developer has just announced that the next version of biber will require > it because "they have the postfix dereference notion officially > supported and I can get rid of the the horrible

Re: perl-5.24?

Ken Brown writes: > I'm wondering whether you have plans to update perl to 5.24. The biber > developer has just announced that the next version of biber will require > it because "they have the postfix dereference notion officially > supported and I can get rid of the the horrible

Re: per-version hints proposal

Eric Blake writes: > Except when upstream version numbers go backwards. We'd have to adopt > something like Fedora's "epoch" numbering if we want our version numbers > to always be increasing (by bumping the epoch any time upstream versions > go backwards). Oh please not. I've looked into this

Re: [Updated/New] Perl distributions

Jon Turney writes: > I'm not sure setup.ini is the right format for that information, but > yes, some kind of upload manifest would be good. Well, it was a format we already know how to produce and consume and delivers a good checksum for each file. The other thing that's easily used is hashdeep

Re: Perl CPAN - list of modules needed

Jari Aalto writes: > Ok, Here is list of modules that would be need for the programs: > > Mail::Box::Manager > Mail::Message > Date::Format > Date::Parse > Lchown::lchown > > E.g. latest rsnapshop requires Lchown::lchown before I can update it. Done. Regards, Achim. -- +<[Q+

Re: [Updated/New] Perl distributions

Jon Turney writes: > In this update, the following packages don't seem to be valid xz files: > > perl-Business-ISBN-2.011-1-src.tar.xz > perl-Regexp-Common-2016060801-1-src.tar.xz > perl-XML-LibXML-2.0125-1.tar.xz > perl-XML-LibXML-2.0125-1-src.tar.xz > perl-Mojolicious-6.64-1.tar.xz >

Re: [ITP] Perl distributions

Achim Gratz writes: > perl-MailTools THis is already in the distribution, I forgot to remove it from the list, sorry. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downl

[ITP] Perl distributions

The following Perl distributions are ready for incorporation into Cygwin as dependencies for Jaris packages: perl-Cpanel-JSON-XS perl-File-Remove perl-File-Slurper perl-Font-AFM perl-HTML-Formatter perl-IO-stringy perl-LWP-Online perl-Lchown perl-MIME-Types perl-Mail-Box perl-Mail-Box-Parser-C

Re: Perl CPAN - list of modules needed

Jari Aalto writes: > Ok, Here is list of modules that would be need for the programs: > > Mail::Box::Manager > Mail::Message That would be in perl-Mail-Box, Yaakov already maintains perl-MailTools from the same author and they seem closely related in the relase cadence, so I'd yield to him if

Re: clock - re-add to distribution (Perl modules now available)

Jari Aalto writes: > cloc (count lines of code) was removed because the needed > Perl modules were not yet in Cygwin. In general, if you are missing a Perl distribution in Cygwin, please drop me a line here or in the main Cygwin list. Unless it doesn't build for both architectures I see no

Re: [ITP] libsass v3.3.6

Marcos Vives Del Sol writes: > 2016-06-08 7:46 GMT+02:00 Achim Gratz: >> They didn't forget anything, you are just not using a release tarball. >> In that case you are expected to either build from a proper Git checkout >> or run the release preparations yourself before config

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Achim Gratz writes: > Yaakov Selkowitz writes: >> The attached list contains packages which on the surface appear to be >> noarch but haven't been moved yet. PLEASE **DOUBLE-CHECK** your >> packages on this list, and if your package qualifies, proceed as >> abov

Re: [ITP] libsass v3.3.6

Marcos Vives Del Sol writes: > On 07/06/2016 11:49, Achim Gratz wrote: >> Based on the way configure is supposed to be working it seems that either >> the tarball you're using is incomplete (did you use a Git snapshot?) or >> they forgot to package the VERSION file. >

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

ence. Achim Gratz perl-common-sense This installs into the arch-specific branches of vendor_perl because it uses some Perl internals that are specific to the runtime config. Actually I'll have to re-spin that package since it tries to install into the 5.14 branch.

Re: [ITP] libsass v3.3.6

Marcos Vives Del Sol writes: > This script is called using m4_esyscmd_s from configure.ac line 6: > - > AC_INIT([libsass], m4_esyscmd_s([./version.sh]), [support@...]) > - > to set the library version at compile time. Then configure uses it to >

Re: gcovr - Suitable for Cygwin?

David Stacey writes: > Note that gcovr isn't available for Fedora or CentOS, although this > could be because it hasn't been packaged for these distros, rather than > any incompatibility in the licence. It is, however, available for Debian > and Ubuntu [2]. Debian has it, of all

Re: fish curr and prev are reversed

Corinna Vinschen writes: > I added > > prev: 2.3.0-1 > curr: 2.3b1-1 > > to all setup.hint files. That's what calm already does (it sees 2.3b1 like 2.3.1, IIRC). Andrew wanted the beta version (2.3b1) to be previous to the release (2.3.0). Regards, Achim.

Re: fish curr and prev are reversed

Andrew Schulman writes: > AFAIK the last setup.hint that I uploaded didn't include curr: or prev: lines, > so this looks to be what calm decided to do. Can someone please fix it? Just add the curr: and prev: lines to setup.hint and upload that new file (for both the main

[ITP] Perl Distributions

Please add these two new distributions to my list of packages: perl-Lingua-Translit perl-List-SomeUtils Thanks. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld:

Re: Lingua::Translit

Achim Gratz <Stromeko@...> writes: > I haven't forgotten, but I've been using up the time last weekend with > figuring out which packages to move to noarch and I am currently waiting > for that move to happen. I'll get to that over the weekend most likely. Regards, Achim.

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Yaakov Selkowitz writes: > Done. Thanks. :-) 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: Lingua::Translit

Ken Brown writes: > Just a gentle ping, in case you've forgotten about this. I haven't forgotten, but I've been using up the time last weekend with figuring out which packages to move to noarch and I am currently waiting for that move to happen. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Achim Gratz writes: > I'll check my other packages next week. Here's the wave of Perl distributions as previously determined by true dedup (the one marked with an asterisk is not mine and may have been moved already). I've quickly checked the latest build logs again for my own Perl distributi

Re: [RFC] splitting documentation

Marco Atzeri writes: > To move the documentation in a noarch package > I split lilypond in two source packages. I'm not too enamored with this idea… we will eventually end up with the possibility of having parts of packages noarch and other parts arch-ful. Trying to preempt that goal by going

Re: Building from source packages

packages mistakenly use DEPENDS rather than DEPEND, which is silently ignored pkg maintainer --- -- cloog-isl Achim Gratz isl Achim Gratz mpclibAchim Gratz Heh. I'm pretty sure I've inherited the packages that way... I'll try to remember

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

If you haven't done so already, please move to noarch: _autorebase base-files I'll check my other packages next week. -- Achim. (on the road :-)

Re: Lingua::Translit

Am 11.05.2016 um 14:27 schrieb Ken Brown: The next version of Biber will have a dependency on Lingua::Translit. Can you add that to the distro when you get a chance? I'll have a look at that. Not this week, though. -- Achim. (on the road :-)

Re: Dedup x86/x86_64 --> noarch

Andrew Schulman writes: > I feel as though I've once again missed some important discussion about > package > maintenance. Your question implies that we can now upload packages with arch > "noarch". Is that true? Meanwhile it has become true, although Jon and Yaakov are still in the early

Re: Dedup x86/x86_64 --> noarch

Jon Turney writes: > I've deployed an updated calm, and moved perl-Test-Base to noarch. Thanks. > From my brief testing, setup handles this layout with no problems. I > also checked that noarch files in a download package directory shared > between x86 and x86_64 setup works as expected. > >

Re: Dedup x86/x86_64 --> noarch

Jon Turney writes: > I think 'generally' is over-stating the case, the vast majority of > source packages should be arch-less. I said "not generally", which I think makes a slightly less sweeping statement. In any case, I just wanted to point out that some of the existing source packages have

Re: [ITP] unison2.49

Andrew Schulman writes: > I've built and uploaded packages for the next version of unison, unison2.49. > Please add unison2.49 to the package list with me as maintainer. Sorry, but why do you need to make the version part of the package name? Could you name that package just unison, please?

Re: unison-2.48 build fails with latest ocaml and flexdll (ping: Yaakov, Damien)

Andrew Schulman writes: > I'm not sure if you meant that as diagnosis or solution. It doesn't seem like a > solution. Changing the image base of my compiles seems like an extraordinary > measure. Unison has always built just fine OOTB before. Well, then just manually

Re: unison-2.48 build fails with latest ocaml and flexdll (ping: Yaakov, Damien)

Andrew Schulman writes: >> I'm trying to build unison 2.48.3, which worked fine the last time I tried >> it, in June 2015. Today the build fails, with "flexdll error: cannot >> relocate": >> >> >>> Compiling unison2.48-2.48.3-2.x86_64 >> ocamlc -o mkProjectInfo unix.cma str.cma mkProjectInfo.ml

Re: Dedup x86/x86_64 --> noarch

Corinna Vinschen writes: > The src packages would ideally be in a src subdir, parallel to the > noarch and $arch dirs. Hmm, I'm not soure I'd like that. The src packages are not generally arch-less. There are several examples where either the cygport files, the patches or even the source

Re: Dedup x86/x86_64 --> noarch

Achim Gratz writes: > Looking at the current repo content we'd save about 30GB from the dedup > of the src abd doc packages alone and probably about 20GB from dedup in > the remaining packages. I've implemented some POC code and deduped my Cygwin mirror (it is missing most of KDE and

Re: cygport: info file compression

Yaakov Selkowitz writes: > On 2016-04-10 06:39, Achim Gratz wrote: >> Is there a way to suppress the compression of info pages? Maxima >> directly reads help info from the info files and fails to display help >> if the info file does not exist (since it's now having a .g

[RFC] locked-down setup

For the Cygwin installer at work I've locked down setup to not accept nor read in extra keys and to always check the signatures (and exit when there is no signature present). Of course I've also changed the built-in key. If there's general interest in such a modification I'd offer to develop

Dedup x86/x86_64 --> noarch

After a discussion on IRC about de-duping the noarch content out of package files (where I was told this would be too difficult), I've just tried what would happen for two of my packages, maxima and perl. Maxima is practically a noarch package, save for the clisp memory image. Perl has gobs and

cygport: RESTRICT strip should include debuginfo

Building a package that uses RESTRICT="strip" produces an error in the postinstall phase since the ${T}/.dbgsrc.out file will not exist. So you then need to use RESTRICT="strip debuginfo", which seems a bit strange. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk

cygport: info file compression

Is there a way to suppress the compression of info pages? Maxima directly reads help info from the info files and fails to display help if the info file does not exist (since it's now having a .gz suffix). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Re: Dodgy functions (finitel, strold)

Doug Henderson writes: > I modified your program to display the actual hex value of the a, b, > and c variables. The b and c variables have different bit patterns. It > appears that the %a format conversion is (correctly) detecting ±inf > and NaN according to IEEE 754, and ignoring the value of

Re: Dodgy functions (finitel, strold)

Achim Gratz writes: > Achim Gratz writes: >> Long story short, they seem to report a finite value on at least some >> NaN constructs and then the %a format for the Perl sprintf outputs those >> bits as a hex FP number rather than just printing "NaN". On 64bit the

Re: Dodgy functions

Achim Gratz writes: > Long story short, they seem to report a finite value on at least some > NaN constructs and then the %a format for the Perl sprintf outputs those > bits as a hex FP number rather than just printing "NaN". On 64bit the > culprit is actually finitel, of c

Dodgy functions (was: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8)

Yaakov Selkowitz writes: >> Doing that seems to have changed the behaviour of sprintf and now one of >> the tests involving NaN and the %a format fails. Ideas? > > Can you be more specific? I've finally drilled to the bottom of this (on 64bit so far, but the issues and workarounds are quite

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

Yaakov Selkowitz writes: > On 2016-03-20 14:04, Achim Gratz wrote: >> Doing that seems to have changed the behaviour of sprintf and now one of >> the tests involving NaN and the %a format fails. Ideas? > > Can you be more specific? The error is this: --8<

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

Corinna Vinschen writes: > These functions are defined on both platforms. What's *not* defined on > 64 bit, but only on 32 bit, are the same functions preceeded with an > underscore, e.g. _copysign. > > Can you please check again? There's something else going wrong here. What's going wrong is

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

Corinna Vinschen writes: >> If so, it might be a good idea for maintainers to test that nothing >> unexpected happens when they build their packages. > > Yes, that's really a good idea. I've run a fresh build of Perl on this. - there's a new signal: SIGIOT - two new symbols are found:

Test via Gmane

"Am I on?" (Janis Joplin) Regards, Aschim.

Re: calm messages [x86]

Adam Dinwoodie writes: > I think, rather than working out what the correct dependencies here > should be and configuring them manually, particularly for Perl modules > where the mapping from a Perl module name to the Cygwin package isn't > always obvious, That shouldn't happen, but you need to

Re: [ITA] wtf-0.0.4-8

Corinna Vinschen writes: > On Mar 18 13:23, Andrew Schulman wrote: >> Besides, I got to invent a dungbomb award and give it to myself. What >> could top that?! > > Right. I envy you. What do I have to do to get one of those? Switch back all repositories to CVS… (ducks). Regards, Achim. --

Re: [ITA] procps

Wayne Porter writes: > I have just finished porting procps 3.3.9 and wanted to share it with > the community. That's actually procps-ng or is it not? If so, it seems the current version is 3.3.11 from looking at my Linux box. Also, the current procps maintainer is quite active on the Cygwin ml,

Re: Keep calm

Jon Turney writes: > I've disabled upset (the perl script on sourceware.org, which performs > the task of composing setup.ini from setup.hints and moving uploads), > and enabled calm (a re-write from scratch to perform these tasks). The access rights on the setup.ini file are borked. Can you

Re: clisp/maxima

Ken Brown writes: > Sorry, I blew it. I already uploaded them with the !ready cookie. So > our packages will be out of sync until you (or Someone™) adds the > !ready for maxima. No worries, I'm waiting on the upload just now. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb

Re: clisp/maxima

Achim Gratz writes: > Achim Gratz writes: >>> I won't upload it until I get the OK from you. >> >> Let me see when I get to that. > > How about now? :-) I'm standby with the files on cygwin.com, I just > need to place the !ready cookie. Please put your files in

Re: clisp/maxima

Achim Gratz writes: >> I won't upload it until I get the OK from you. > > Let me see when I get to that. How about now? :-) I'm standby with the files on cygwin.com, I just need to place the !ready cookie. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Androm

Re: clisp/maxima

Ken Brown writes: > I have a new release of clisp ready to go (x86_64 only) [*]. If I > remember correctly, this means you will need to rebuild maxima. I'll have to check that, but I guess yes (I'm not sure how exactly this gets decided, but it's a new compiler and likely different configure

Re: [SECURITY] perl: CVE-2016-2381

Achim Gratz writes: > Yaakov Selkowitz writes: >> A security vulnerability has been made public for perl: > > I've asked on p5p what the plan is for another 5.22 release. If that's > too far off, I'll just patch 5.22.1, otherwise I'll wait for these > patches (there are mor

Re: [SECURITY] perl: CVE-2016-2381

Yaakov Selkowitz writes: > A security vulnerability has been made public for perl: I've asked on p5p what the plan is for another 5.22 release. If that's too far off, I'll just patch 5.22.1, otherwise I'll wait for these patches (there are more fixes on the branch) to be released in 5.22.2.

Re: [ITP] libSBML-5.12.0-core and moose-3.0.2

Corinna Vinschen writes: > More important to me is that the maintainer-to-be subscribes to the > cygwin user mailing list as well as the cygwin-apps maintainer mailing > list and promises to scna the list for user problems with his/her > package. s/scna/scan/ I suppose? Regards, Achim. -- +<[Q+

[ITP] perl-Canary-Stability

A new build dependency for perl-JSON-XS, diff for cygwin-pkg-maint: --- cygwin-pkg-maint.old 2016-02-27 14:12:11.984344233 +0100 +++ cygwin-pkg-maint 2016-02-27 14:13:08.685025481 +0100 @@ -2323,6 +2323,7 @@ perl-Business-ISSN Achim Gratz/Ken Brown perl-Cairo

Re: trying to upload new wcd update (Erwin is new designated maintainer)

waterlan writes: > Thanks. Does this mean that the files I uploaded are accepted now? Yes, they are now up. > They are gone. Or do I need to upload new files. I guess Jon triggered the move manually, at least none of today's notice emails had that package mentioned. Regards, Achim. -- +<[Q+

Re: setup.hint documentation issues

Jon Turney writes: >> OK, although we might need some sort of escaping in the long run. > > Yes, I have no problem with later adding escaping e.g. using '\', if > needed, since that can written with a character by character lexer. Indeed and it should also be possible to parse via regex. IN any

Re: [ITP] Inetutils 1.9.4

D. Boland writes: >> These tools are provided separately in many Linux distros for quite >> some time, and while those tools can be started by inetd, inetd >> doesn't require them and they don't require inetd (xinetd is perfectly >> capable of replacing inetd). > > I don't see why this makes

Re: Removing cygwin32-*, cygwin64-*

Tony Kelman writes: > Would this impact the ability to upload package builds via cygport --32 ? > I just tried > > $ cygport --32 p7zip-15.09-2.cygport upload > /usr/share/cygport/lib/compilers.cygpart: line 287: i686-pc-cygwin-gcc: > command not found > > from within 64 bit cygwin on my new

Re: [SECURITY] p7zip: CVE-2015-1038

Tony Kelman writes: > I'm not very familiar with the intricacies of ssh auth options, as you > can probably guess. I tried removing ~/.ssh/known_hosts (backing up to > a different file name) but no change. Is there a cygport or sftp or ssh > option via command line or environment variable that I

Re: [SECURITY] p7zip: CVE-2015-1038

Tony Kelman writes: > Thanks for the help Corinna. > > I don't have anything for sourceware or cygwin.com in > ~/.ssh/known_hosts, should I? Recently the default configuration has been changed to only have hashes in that file. You could change it back or use ssh management commands to remove the

Re: How to get upload rights for existing packages

Corinna Vinschen writes: >> Sure, but co-maintenance _is_ possible, with each of the maintainers >> having their own separate upload area. > > Yes, but Michael still has to become maintainer, even if co-maintainer. True, in the absence of anything better he should probably ITA the package and

Re: Removing cygwin32-*, cygwin64-*

Yaakov Selkowitz writes: > Is anyone using the cygwin32- and/or cygwin64-* cross-compiling > toolchain for anything besides cross-building cygwin itself? I would > like to remove most of these from the distro if at all possible. Never used them… :-) Regards, Achim. -- +<[Q+ Matrix-12

Re: setup.hint documentation issues

Jon Turney writes: > I think currently UTF-8 displays correctly in the HTML package pages, > but neither encoding displays correctly in setup. > > I'd suggest that we specify UTF-8 and eventually fix setup to handle that. UTF-8 these days, please. > I'd suggest this mangling is removed, and

Re: [ITP] Inetutils 1.9.4

Corinna Vinschen writes: >> So I added these on the 'required' lines. > > They are not actually *required* to run inetd, right? Does it really > make sense to add them as require packages then? I don't think so (not checked all scripts, though), although people who expect these programs to

Re: perl-Win32-API / perl-Win32-GUI

Yaakov Selkowitz writes: >> did you test these modules? > > Of course I did; that's why there are several patches to perl-Win32-GUI. I don't easily see if these were cross-compiled, so I don't know if you were able to run the tests. Win32-API currently fails several tests even though it appears

Re: How to get upload rights for existing packages

Corinna Vinschen writes: > This is not quite how it works. The maintainer has upload permissions > using his/her ssh key. You only get to do that if you become package > maintainer. See https://sourceware.org/cygwin-apps/package-upload.html Sure, but co-maintenance _is_ possible, with each of

perl-Win32-API / perl-Win32-GUI

Hi Yaakov, did you test these modules? I haven't looked at the new Win32GUI release, but Win32-API is likely missing this patch (at least to compile natively on Cygwin): --- origsrc/Win32-API-0.82/Callback/Callback.xs 2014-07-29 21:00:08.0 +0200 +++

Re: [ITP] Perl distributions

Jon Turney writes: > Applied. Thank you. 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

[ITP] Perl distributions

Achim Gratz/Ken Brown perl-CarpAchim Gratz perl-CGI Yaakov Selkowitz +perl-Class-Accessor Achim Gratz perl-Class-Singleton Yaakov Selkowitz perl-Class

Re: [HEADSUP] requires to obsolete Perl packages

Yaakov Selkowitz writes: > I fixed whatever was remaining on sourceware. However, we CANNOT > remove the upgrade helpers, as there are (unfortunately) certain to be > users which have yet to upgrade their systems. Thank you very much. As long as these are all obsolete I don't really care.

Re: [PATCH setup 0/3] Setup replacement for incver_ifdep

Ken Brown writes: […] Now for something completely different: when you pull that script into some info package, could you please swicth it to dash? Most if not all of the postinstall scripts would probably work with dash, so if you#re working on one you should check and switch it if appropriate.

Re: [PATCH setup 0/3] Setup replacement for incver_ifdep

Jon Turney writes: >>> You could read the md5sums into variables instead and just compare the >>> resulting strings within bash. Otherwise we'd have to add diffutils to >>> the Base category. > > I've made this change. Thank you very much. > As an interim solution, I've adopted

Re: Changing Setup's license to GPLv3+

Corinna Vinschen writes: > does anything speak against switching Setup's license to GPLv3+? > If nobody complains, I'll bump to v3+ in a week or so. I have no problem with that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation

Re: Changing Setup's license to GPLv3+

Warren Young writes: >> I'm not trying to do that single-handedly and without reason. I'm >> asking here to reach out to the current active developers. A switch >> from GPLv2+ to GPLv3+ works without having to reach out to *all* >> copyright holder. > > I don’t think I agree with that. "9.

Re: [cygport] Bugfixes

Yaakov Selkowitz writes: > Do we really need to sort twice? On closer inspection, the last sort doesn't do anything at all since it operates on a single line. Corrected patch at http://repo.or.cz/cygport/rpm-style.git/commitdiff/2ed7b33c7b7730a7c3acddd78069c5bf2281b3a4 Regards, Achim. --

Perl distributions

2016-01-16 18:51:38.340996565 +0100 +++ cygwin-pkg-maint 2016-01-16 19:30:05.023440957 +0100 @@ -1788,7 +1788,6 @@ perl-ExtUtils-MakeMaker Achim Gratz perl-ExtUtils-PkgConfig Achim Gratz/Yaakov Selkowitz perl-File-Copy-Recursive Achim

Re: [cygport] Bugfixes

Yaakov Selkowitz writes: >> http://repo.or.cz/cygport/rpm-style.git/commitdiff/c57857ab52ba0c1c7edf37ae4fb9384690dd1df1 > > Do we really need to sort twice? Not necessarily, but I didn't want to run sed on the whole lot. I've not tested which way is consuming more resources, though. The final

[ITP] Perl distributions

@@ -1908,8 +1908,10 @@ perl-Socket6 Achim Gratz perl-Spiffy Achim Gratz perl-Sub-ExporterAchim Gratz +perl-Sub-IdentifyAchim Gratz perl-Sub-Install Achim

Re: [ITP] Perl distributions

Marco Atzeri writes: > Done Thanks. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html

Re: [HEADSUP] requires to obsolete Perl packages

Achim Gratz writes: >> There are a number of packages still requiring obsoleted Perl packages >> that I want to delete now, so these setup.hint files need to be fixed. >> Here is what I've found so far with a proposed replacement in >> parenthesis. >> >>

Re: [HEADSUP] requires to obsolete Perl packages

Achim Gratz writes: > Achim Gratz writes: >>> There are a number of packages still requiring obsoleted Perl packages >>> that I want to delete now, so these setup.hint files need to be fixed. >>> Here is what I've found so far with a proposed replacement in >>&g

Please fix your setup.hint files (was: [HEADSUP] requires to obsolete Perl packages)

There are a number of packages still requiring obsoleted Perl packages that I want to delete now, so these setup.hint files need to be fixed. Here is what I've found so far with a proposed replacement in parenthesis. perl_vendor (only on 32bit since it never existed on 64bit): === Yaakov

Re: Please fix your setup.hint files

Corinna Vinschen writes: >> Remark: SWI Prolog doesn't compile from the source package. > > It did when I created it. Well, certainly. :-) > Yes, it's spurious. I removed the perl_vendor from setup.hint for now. > I don't intend to repackage SWI-Prolog for a while. Thanks. Regards, Achim.

[cygport] Bugfixes

The following two patches fix a bug in the shebang detection which was not properly restricted to just the beginning of the file and a more obscure on in the dependency extraction. http://repo.or.cz/cygport/rpm-style.git/commitdiff/d5bd5854cce3acfea7572ce0276519149ee92081

Re: AVX on Cygwin

Corinna Vinschen writes: >> I hope this affects 64 bit only? I don't know if it would even be possible to run AVX code from 32bit, but yes, the three reports so far have been from 64bit systems. > Btw., for the time being it might be prudent to disable AVX in gmp... There is no configure option

Re: AVX on Cygwin

Corinna Vinschen writes: > On second thought, what I'm wondering about is what exactly *is* the > problem with AVX? While the AVX context isn't saved when running signal > handlers or getcontext, it's very unlikely that the AVX state changes at > all when running a system function or signal

Re: [PATCH setup 0/3] Setup replacement for incver_ifdep

Corinna Vinschen writes: > I trust both of you to do the right thing. My question here is only, > can we get a solution soon so we can get rid of the old upset method for > the info files? Achim, how long would it take to create the same > solution for info you're using for rebase? Would it

AVX on Cygwin

You may have noted that the recent gmp update makes problems on some machines and two of the three reports come from Broadwell CPU. There is one thing that did indeed change with the update and that is use of the AVX ADC instruction on Broadwell/Skylake. Is it possible that somehow the stack

Re: [PATCH setup 0/3] Setup replacement for incver_ifdep

Jon Turney writes: >> So, should we try to guard against that (installations on a USB stick >> are probably the only practical occurence these days)? I wouldn't mind >> if we just unconditionally rebuild on FAT(32). > > Thinking this over, it doesn't seem that hard to use a hash to > determine if

<    2   3   4   5   6   7   8   9   10   11   >