Re: [ITP] maxima-5.35.1
On Mar 10 21:27, Achim Gratz wrote: > 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" Perfect. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpaA7K2ADH2G.pgp Description: PGP signature
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: [PATCH setup 4/4] Silently ignore 'x' and 'g' type tar extended headers
On 10/03/2015 14:23, Corinna Vinschen wrote: On Mar 10 14:01, Jon TURNEY wrote: On 06/03/2015 06:08, Achim Gratz wrote: Jon TURNEY writes: It seems that base-files has an 'x' extended header for each file, apparently to store the mtime. 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? If your patch allows to unpack a POSIX tar archive correctly, without generating a warning... why would you like to drop it? POSIX tar archive are (potentially) not unpacked strictly correctly in both cases, as they contain extra information that setup does not interpret. All this patch changes is if we warn about that loss of information, or silently drop it.
Re: [PATCH setup 4/4] Silently ignore 'x' and 'g' type tar extended headers
On Mar 10 14:01, Jon TURNEY wrote: > On 06/03/2015 06:08, Achim Gratz wrote: > >Jon TURNEY writes: > >>It seems that base-files has an 'x' extended header for each file, > >>apparently to > >>store the mtime. > > > >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? If your patch allows to unpack a POSIX tar archive correctly, without generating a warning... why would you like to drop it? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpq9G8m_Yz2z.pgp Description: PGP signature
Re: [PATCH setup 4/4] Silently ignore 'x' and 'g' type tar extended headers
On 06/03/2015 06:08, Achim Gratz wrote: Jon TURNEY writes: It seems that base-files has an 'x' extended header for each file, apparently to store the mtime. 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?
Re: perl-5.14.4
On Mar 5 14:20, Corinna Vinschen wrote: > On Feb 16 16:42, Achim Gratz wrote: > > Corinna Vinschen writes: > > > Uh oh, the debug information is either broken (which is unlikely) or GDB > > > doesn't use it anymore due to the CRC mismatch. Maybe the same CRC > > > mismatch breaks objcopy in cygport, given that both are based on the > > > same BFD code? > > > > Maybe, but none of the tools ever complained about the CRC (I remember > > that GDB checks it though). A CRC should be a fixable thing, though. > > > > > For the time being, is it really required to rebase the DLLs for testing > > > before the debug information is split off? If you could do the rebase > > > and test cycle after splitting off the debug info, the problem should be > > > neglectable. > > > > For the moment I've changed the patch to EUMM to check if it's run from > > cygport and not rebase the just produced DLL in that case. I only need > > to remember to package the module before testing instead of the other > > way around (and do a manual rebase before testing, but that isn't > > difficult). So, I have a workaround. > > FYI: https://sourceware.org/bugzilla/show_bug.cgi?id=18025 > > 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 Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpp_Yw56UHh9.pgp Description: PGP signature
Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]
Hi Andrew, On Mar 7 08:14, Andrew Schulman wrote: > > Should I get anything for taking the orphaned > > grep/gperf/bison/diffutils/gzip when cgf left? (A single gold star is > > plenty for me; that plush hippo is above and beyond the level of effort > > it took :) > > For sure: https://cygwin.com/goldstars/#EB > > Sorry for the oversight. If anyone else is due some gold stars that I > overlooked, please let me know. Just this one, afaics: https://cygwin.com/ml/cygwin-apps/2015-03/msg00069.html Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpbafDm_OyFc.pgp Description: PGP signature
Re: [ITP] maxima-5.35.1
On Mar 7 08:07, Achim Gratz wrote: > Yaakov correctly pointed out the 32bit maxima I rememebered to be in > Cygwin was actually from ports, so here's the requisite ITP for maxima > to introduce it into Cygwin properly. 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. 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. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpoVxNba0dTu.pgp Description: PGP signature
Re: [ITA/ITP] lots of perl distributions
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. 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. > [...] > 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. You could try the new cygport upload feature. It uses lftp under the hood. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpbiOlppALPX.pgp Description: PGP signature
