* scallywag / cygport not pulling lzip @ 2021-01-08 7:38 Marco Atzeri 2021-01-08 13:23 ` ASSI 0 siblings, 1 reply; 13+ messages in thread From: Marco Atzeri @ 2021-01-08 7:38 UTC (permalink / raw) To: cygwin-apps Hi Jon, it seems that cygport is not pulling the decompressor that is supposed to recognise: https://ci.appveyor.com/project/cygwin/scallywag/builds/37134000/job/0m9h56ptrwwyg3hc >> Unpacking source flex-2.6.4.tar.lz tar (child): lzip: Cannot exec: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now *** ERROR: tar xf flex-2.6.4.tar.lz failed Regards Marco ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scallywag / cygport not pulling lzip 2021-01-08 7:38 scallywag / cygport not pulling lzip Marco Atzeri @ 2021-01-08 13:23 ` ASSI 2021-01-08 13:58 ` Marco Atzeri 0 siblings, 1 reply; 13+ messages in thread From: ASSI @ 2021-01-08 13:23 UTC (permalink / raw) To: cygwin-apps Marco Atzeri via Cygwin-apps writes: > it seems that cygport is not pulling the decompressor > that is supposed to recognise: > > https://ci.appveyor.com/project/cygwin/scallywag/builds/37134000/job/0m9h56ptrwwyg3hc > >>> Unpacking source flex-2.6.4.tar.lz > tar (child): lzip: Cannot exec: No such file or directory > tar (child): Error is not recoverable: exiting now > tar: Child returned status 2 > tar: Error is not recoverable: exiting now > *** ERROR: tar xf flex-2.6.4.tar.lz failed Since tar is a Base package it doesn't require lzip (which would effectively make it a Base install). You have to add lzip to BUILD_REQUIRES or switch to the GZip archive. 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scallywag / cygport not pulling lzip 2021-01-08 13:23 ` ASSI @ 2021-01-08 13:58 ` Marco Atzeri 2021-01-08 14:21 ` Jon Turney 0 siblings, 1 reply; 13+ messages in thread From: Marco Atzeri @ 2021-01-08 13:58 UTC (permalink / raw) To: cygwin-apps On 08.01.2021 14:23, ASSI wrote: > Marco Atzeri via Cygwin-apps writes: >> it seems that cygport is not pulling the decompressor >> that is supposed to recognise: >> >> https://ci.appveyor.com/project/cygwin/scallywag/builds/37134000/job/0m9h56ptrwwyg3hc >> >>>> Unpacking source flex-2.6.4.tar.lz >> tar (child): lzip: Cannot exec: No such file or directory >> tar (child): Error is not recoverable: exiting now >> tar: Child returned status 2 >> tar: Error is not recoverable: exiting now >> *** ERROR: tar xf flex-2.6.4.tar.lz failed > > Since tar is a Base package it doesn't require lzip (which would > effectively make it a Base install). You have to add lzip to > BUILD_REQUIRES or switch to the GZip archive. > > > Regards, > Achim. > Hi Achim, this is an upstream source package. IMHO cygport should pull tar and all the decompressor that is supposed to manage. $ grep SRC_URI NEWS ... * SRC_URI supports .tar.lz archives. * SRC_URI accepts .tar.xz archives. * SRC_URI accepts .tar.lzo archives. ... ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scallywag / cygport not pulling lzip 2021-01-08 13:58 ` Marco Atzeri @ 2021-01-08 14:21 ` Jon Turney 2021-01-08 16:52 ` Brian Inglis 0 siblings, 1 reply; 13+ messages in thread From: Jon Turney @ 2021-01-08 14:21 UTC (permalink / raw) To: cygwin-apps On 08/01/2021 13:58, Marco Atzeri via Cygwin-apps wrote: > On 08.01.2021 14:23, ASSI wrote: >> Marco Atzeri via Cygwin-apps writes: >>> it seems that cygport is not pulling the decompressor >>> that is supposed to recognise: >>> >>> https://ci.appveyor.com/project/cygwin/scallywag/builds/37134000/job/0m9h56ptrwwyg3hc >>> >>> >>>>> Unpacking source flex-2.6.4.tar.lz >>> tar (child): lzip: Cannot exec: No such file or directory >>> tar (child): Error is not recoverable: exiting now >>> tar: Child returned status 2 >>> tar: Error is not recoverable: exiting now >>> *** ERROR: tar xf flex-2.6.4.tar.lz failed >> >> Since tar is a Base package it doesn't require lzip (which would >> effectively make it a Base install). You have to add lzip to >> BUILD_REQUIRES or switch to the GZip archive. >> >> >> Regards, >> Achim. >> > > Hi Achim, > > this is an upstream source package. > > IMHO cygport should pull tar and all the decompressor that > is supposed to manage. > > $ grep SRC_URI NEWS > ... > * SRC_URI supports .tar.lz archives. > * SRC_URI accepts .tar.xz archives. > * SRC_URI accepts .tar.lzo archives. > ... Yeah, perhaps lzip should be a dependency of cygport. For the moment, I've applied a tweak to scallywag to ensure lzip gets installed. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scallywag / cygport not pulling lzip 2021-01-08 14:21 ` Jon Turney @ 2021-01-08 16:52 ` Brian Inglis 2021-01-08 17:13 ` Achim Gratz 0 siblings, 1 reply; 13+ messages in thread From: Brian Inglis @ 2021-01-08 16:52 UTC (permalink / raw) To: cygwin-apps On 2021-01-08 07:21, Jon Turney wrote: > On 08/01/2021 13:58, Marco Atzeri via Cygwin-apps wrote: >> On 08.01.2021 14:23, ASSI wrote: >>> Marco Atzeri via Cygwin-apps writes: >>>> it seems that cygport is not pulling the decompressor >>>> that is supposed to recognise: >>>> >>>> https://ci.appveyor.com/project/cygwin/scallywag/builds/37134000/job/0m9h56ptrwwyg3hc >>>> >>>> >>>>>> Unpacking source flex-2.6.4.tar.lz >>>> tar (child): lzip: Cannot exec: No such file or directory >>>> tar (child): Error is not recoverable: exiting now >>>> tar: Child returned status 2 >>>> tar: Error is not recoverable: exiting now >>>> *** ERROR: tar xf flex-2.6.4.tar.lz failed >>> >>> Since tar is a Base package it doesn't require lzip (which would >>> effectively make it a Base install). You have to add lzip to >>> BUILD_REQUIRES or switch to the GZip archive. >>> >>> >>> Regards, >>> Achim. >>> >> >> Hi Achim, >> >> this is an upstream source package. >> >> IMHO cygport should pull tar and all the decompressor that >> is supposed to manage. >> >> $ grep SRC_URI NEWS >> ... >> * SRC_URI supports .tar.lz archives. >> * SRC_URI accepts .tar.xz archives. >> * SRC_URI accepts .tar.lzo archives. >> ... > > Yeah, perhaps lzip should be a dependency of cygport. ...and zstd as Achim is working on that. I do not think we should encourage use of lower compression ratio packages in cygport and calm, and their libraries in setup. It appears zstd gives up compression to gain faster decompression with less memory which may be advantageous for loading a kernel, but less optimal for MBs of base packages. [Download size will remain significant in regions with poor or unreliable infrastructure, and that may include large rural populations and remote areas in developed countries, where achievable transfer rates and/or download limits are low, base data charges or overages are expensive e.g. Canada telecomm costs are higher than most other countries, has many areas with limited services, and remote communities and indigenous reservations may still have only metered landline/microwave service AKA long distance dialup at best, and many northern and western areas of Canada and the US still have little or no GSM mobile coverage, perhaps only legacy systems https://www.gsma.com/coverage/ ]. > For the moment, I've applied a tweak to scallywag to ensure lzip gets installed. ...and zstd also please. Perhaps consideration should also be given to setting appropriate compression defaults in cygport for all supported package compressors e.g. GZIP=-9, XZ_OPT=-7 which does not increase the memory required from the default -6 but improves compression, ZSTD_CLEVEL=19 and ZSTD_NBTHREADS=`nproc` perhaps? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scallywag / cygport not pulling lzip 2021-01-08 16:52 ` Brian Inglis @ 2021-01-08 17:13 ` Achim Gratz 2021-01-08 18:09 ` Brian Inglis 2021-01-09 19:08 ` Achim Gratz 0 siblings, 2 replies; 13+ messages in thread From: Achim Gratz @ 2021-01-08 17:13 UTC (permalink / raw) To: cygwin-apps Brian Inglis writes: >> Yeah, perhaps lzip should be a dependency of cygport. Since it promises to enable it's use, yes. I wouldn't mind to add a dependency to tar also. > ...and zstd as Achim is working on that. That dependency has already been added to tar, so there is no need to do anything special. [as you could hav seen by looking at any of the recent CI logs] > I do not think we should encourage use of lower compression ratio > packages in cygport and calm, and their libraries in setup. > It appears zstd gives up compression to gain faster decompression with > less memory which may be advantageous for loading a kernel, but less > optimal for MBs of base packages. That difference is in the order of 3% over the full distribution at the highest compression setting and roughly 5% is you use a compression setting that is about as slow as xz. The installation time on the other hand is dramatically shorter with zstd. > Perhaps consideration should also be given to setting appropriate > compression defaults in cygport for all supported package compressors > e.g. GZIP=-9, XZ_OPT=-7 which does not increase the memory required > from the default -6 but improves compression, ZSTD_CLEVEL=19 and > ZSTD_NBTHREADS=`nproc` perhaps? It is relatively useless to have zstd run with multiple threads in compression mode since a lot of what takes time there is inherently single threaded. It already does use an I/O thread to keep the data pipes fed unless you specifically forbid 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scallywag / cygport not pulling lzip 2021-01-08 17:13 ` Achim Gratz @ 2021-01-08 18:09 ` Brian Inglis 2021-01-08 19:11 ` Achim Gratz 2021-01-09 19:08 ` Achim Gratz 1 sibling, 1 reply; 13+ messages in thread From: Brian Inglis @ 2021-01-08 18:09 UTC (permalink / raw) To: cygwin-apps On 2021-01-08 10:13, Achim Gratz wrote: > Brian Inglis writes: >>> Yeah, perhaps lzip should be a dependency of cygport. > > Since it promises to enable it's use, yes. I wouldn't mind to add a > dependency to tar also. I would support that for technical reasons alone, although hoped for uptake of lzip across GNU or by other projects has been limited to the package itself and others by the same developer, as its goals of providing archive redundancy and recoverability have been obviated by reliable network links and larger storage sizes. >> ...and zstd as Achim is working on that. > > That dependency has already been added to tar, so there is no need to do > anything special. > > [as you could hav seen by looking at any of the recent CI logs] > >> I do not think we should encourage use of lower compression ratio >> packages in cygport and calm, and their libraries in setup. >> It appears zstd gives up compression to gain faster decompression with >> less memory which may be advantageous for loading a kernel, but less >> optimal for MBs of base packages. > > That difference is in the order of 3% over the full distribution at the > highest compression setting and roughly 5% is you use a compression > setting that is about as slow as xz. The installation time on the other > hand is dramatically shorter with zstd. Do we know what the frequency weighted difference is on bandwidth of packages actually downloaded? I am more concerned with mirror providers (and also the lack of them) especially those with limited resources, and those in marginal locations and circumstances, for whom download time and charges may override other considerations, and perhaps prevent them (or many) from accessing or taking full advantage of available software. I doubt the unarchiving time difference is more than a blip in the total time required to *download* *AND* install any package, greatly outweighed by the download time difference, unless you are on a big pipe to a nearby mirror. [I take into consideration that it used to be cheaper to dialup NIST ACTS Colorado to set the time, than anywhere in Canada, and downloads did not become reasonably affordable until I could get network access from a local dialup.] ;^> >> Perhaps consideration should also be given to setting appropriate >> compression defaults in cygport for all supported package compressors >> e.g. GZIP=-9, XZ_OPT=-7 which does not increase the memory required >> from the default -6 but improves compression, ZSTD_CLEVEL=19 and >> ZSTD_NBTHREADS=`nproc` perhaps? > > It is relatively useless to have zstd run with multiple threads in > compression mode since a lot of what takes time there is inherently > single threaded. It already does use an I/O thread to keep the data > pipes fed unless you specifically forbid that. That is valid consideration indeed as suggested. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scallywag / cygport not pulling lzip 2021-01-08 18:09 ` Brian Inglis @ 2021-01-08 19:11 ` Achim Gratz 2021-01-11 22:05 ` Brian Inglis 0 siblings, 1 reply; 13+ messages in thread From: Achim Gratz @ 2021-01-08 19:11 UTC (permalink / raw) To: cygwin-apps Brian Inglis writes: > Do we know what the frequency weighted difference is on bandwidth of > packages actually downloaded? Not that I know of, as everything goes through mirrors. But I happen to have a complete Cygwin mirror on disk at the moment plus another one that only has the packages for my install and that's a fairly large installation, but without a desktop environment: 30G /mnt/mirror/cygwin 149G /mnt/fullmirror/cygwin So you can probably assume that only about 20% of the files are frequently accessed (likely significantly less since most folks would not install the debuginfo or source packages that are included in the above figure). > I am more concerned with mirror providers (and also the lack of them) > especially those with limited resources, and those in marginal > locations and circumstances, for whom download time and charges may > override other considerations, and perhaps prevent them (or many) from > accessing or taking full advantage of available software. We could save way more space than that by de-duplicating the noarch parts into their own archives as I have already demonstrated before. The last time I did that I was cutting out around 30GiB IIRC. > I doubt the unarchiving time difference is more than a blip in the > total time required to *download* *AND* install any package, greatly > outweighed by the download time difference, unless you are on a big > pipe to a nearby mirror. It is not, with a typical VDSL connection I'd be able to download faster than I can install on a more typical machine, I need only about 5MiB/s to saturate the filesystem for small files and around 20…40MiB/s for large ones (to an NVMe drive, a spinning disk or some of the slower SSD can't sustain that). But that point is somewhat moot since setup will always mirror to disk first and that's not easy to change since we read the file twice: once for the SHA512 check (which can use up to around 300MiB/s input bandwidth somewhat higher in peaks and then the actual installation). I have a large base of internal installations that I feed from a (single) local repo and some of those machines are behind rather slow links (not quite modem speed, but still slow by todays standards) and using zstd still makes quite the difference there. The more typical install time was reduced by a bit under 50% for both slow and fast connections, so I no longer recommend that folks reserve time specifically for the Cygwin installation as I had done before. 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scallywag / cygport not pulling lzip 2021-01-08 19:11 ` Achim Gratz @ 2021-01-11 22:05 ` Brian Inglis 2021-01-12 16:28 ` Brian Inglis 0 siblings, 1 reply; 13+ messages in thread From: Brian Inglis @ 2021-01-11 22:05 UTC (permalink / raw) To: cygwin-apps On 2021-01-08 12:11, Achim Gratz wrote: > Brian Inglis writes: >> Do we know what the frequency weighted difference is on bandwidth of >> packages actually downloaded? > > Not that I know of, as everything goes through mirrors. But I happen to > have a complete Cygwin mirror on disk at the moment plus another one > that only has the packages for my install and that's a fairly large > installation, but without a desktop environment: > > 30G /mnt/mirror/cygwin > 149G /mnt/fullmirror/cygwin > > So you can probably assume that only about 20% of the files are > frequently accessed (likely significantly less since most folks would > not install the debuginfo or source packages that are included in the > above figure). > >> I am more concerned with mirror providers (and also the lack of them) >> especially those with limited resources, and those in marginal >> locations and circumstances, for whom download time and charges may >> override other considerations, and perhaps prevent them (or many) from >> accessing or taking full advantage of available software. > > We could save way more space than that by de-duplicating the noarch > parts into their own archives as I have already demonstrated before. > The last time I did that I was cutting out around 30GiB IIRC. > >> I doubt the unarchiving time difference is more than a blip in the >> total time required to *download* *AND* install any package, greatly >> outweighed by the download time difference, unless you are on a big >> pipe to a nearby mirror. > > It is not, with a typical VDSL connection I'd be able to download faster > than I can install on a more typical machine, I need only about 5MiB/s > to saturate the filesystem for small files and around 20…40MiB/s for > large ones (to an NVMe drive, a spinning disk or some of the slower SSD > can't sustain that). But that point is somewhat moot since setup will > always mirror to disk first and that's not easy to change since we read > the file twice: once for the SHA512 check (which can use up to around > 300MiB/s input bandwidth somewhat higher in peaks and then the actual > installation). Some setup phase stats from my own most recent upgrade of about 130MB of downloads, and stats since 2013 (nearly 8 years) since I last cleared setup.log: $ cyg-setup-phase-times.awk /var/log/setup.log.full sv 00:04:26 dl 00:01:28 pr 00:00:02 ui 00:00:36 ex 00:03:35 pi 00:07:12 $ cyg-setup-phase-times.awk /var/log/setup.log sv 04:32:46 dl 02:31:27 pr 00:16:08 ui 00:51:10 ex 06:06:49 pi 00:00:41 phases are: sv - solve formerly Adding required packages - high times are interaction delays dl - download pr - preremove ui - uninstall ex - extract pi - postinstall so your comments about extracts are validated, taking about 3 times as long as downloads even on a currently 2MByte/s medium speed cable modem link to a nearby (7.5km direct, 11km drive, 15 hop 10ms round trip) university campus mirror in recent years. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scallywag / cygport not pulling lzip 2021-01-11 22:05 ` Brian Inglis @ 2021-01-12 16:28 ` Brian Inglis 2021-01-12 19:46 ` ASSI 0 siblings, 1 reply; 13+ messages in thread From: Brian Inglis @ 2021-01-12 16:28 UTC (permalink / raw) To: cygwin-apps On 2021-01-11 15:05, Brian Inglis wrote: > On 2021-01-08 12:11, Achim Gratz wrote: >> Brian Inglis writes: >>> Do we know what the frequency weighted difference is on bandwidth of >>> packages actually downloaded? >> >> Not that I know of, as everything goes through mirrors. But I happen to >> have a complete Cygwin mirror on disk at the moment plus another one >> that only has the packages for my install and that's a fairly large >> installation, but without a desktop environment: >> >> 30G /mnt/mirror/cygwin >> 149G /mnt/fullmirror/cygwin Currently mirrors.html states 160GB total. >> So you can probably assume that only about 20% of the files are >> frequently accessed (likely significantly less since most folks would >> not install the debuginfo or source packages that are included in the >> above figure). >> >>> I am more concerned with mirror providers (and also the lack of them) >>> especially those with limited resources, and those in marginal >>> locations and circumstances, for whom download time and charges may >>> override other considerations, and perhaps prevent them (or many) from >>> accessing or taking full advantage of available software. >> >> We could save way more space than that by de-duplicating the noarch >> parts into their own archives as I have already demonstrated before. >> The last time I did that I was cutting out around 30GiB IIRC. Rsync delta download data transfer quantities are still significant on metered or limited accounts with high overage charges: mirror storage cost is trivial by comparison. Parents are being hit with $Ks monthly overage charges run up by their kids downloading and running games on multiple devices, or cut off after hitting their limit if they block overages, which prevents access to school or work until the next month capacity allowance kicks in! >>> I doubt the unarchiving time difference is more than a blip in the >>> total time required to *download* *AND* install any package, greatly >>> outweighed by the download time difference, unless you are on a big >>> pipe to a nearby mirror. >> >> It is not, with a typical VDSL connection I'd be able to download faster >> than I can install on a more typical machine, I need only about 5MiB/s >> to saturate the filesystem for small files and around 20…40MiB/s for >> large ones (to an NVMe drive, a spinning disk or some of the slower SSD >> can't sustain that). But that point is somewhat moot since setup will >> always mirror to disk first and that's not easy to change since we read >> the file twice: once for the SHA512 check (which can use up to around >> 300MiB/s input bandwidth somewhat higher in peaks and then the actual >> installation). > > Some setup phase stats from my own most recent upgrade of about 130MB of > downloads, and stats since 2013 (nearly 8 years) since I last cleared setup.log: Added average and standard deviation per run for multiple runs, and total times for all runs, including another set with data only since the solver was added early 2018; trivial runs with no download etc. phase times are not counted, but their solve times may be included in stats: $ cyg-setup-phase-times.awk /var/log/setup.log.full sv 00:04:26 dl 00:01:28 pr 00:00:02 ui 00:00:36 ex 00:03:35 pi 00:07:12 tot 00:17:19 runs 1 $ cyg-setup-phase-times.awk /var/log/setup.log.solve sv 00:04:06 dl 00:00:33 pr 00:00:04 ui 00:00:20 ex 00:01:16 pi 00:12:05 avg 00:18:27 runs 66 sv 00:06:11 dl 00:00:53 pr 00:00:17 ui 00:00:25 ex 00:02:05 pi 00:11:08 dev 00:12:57 runs 66 sv 04:30:50 dl 00:37:07 pr 00:04:57 ui 00:22:03 ex 01:24:25 pi 13:18:32 tot 20:17:54 runs 66 $ cyg-setup-phase-times.awk /var/log/setup.log sv 00:00:45 dl 00:00:25 pr 00:00:02 ui 00:00:08 ex 00:01:01 pi 00:04:01 avg 00:06:24 runs 358 sv 00:03:06 dl 00:00:57 pr 00:00:09 ui 00:00:15 ex 00:05:29 pi 00:06:25 dev 00:09:03 runs 358 sv 04:32:46 dl 02:31:27 pr 00:16:08 ui 00:51:10 ex 06:04:40 pi 23:58:16 tot 1 14:14:27 runs 358 > phases are: > > sv - solve formerly Adding required packages - high times are interaction delays > dl - download > pr - preremove > ui - uninstall > ex - extract > pi - postinstall > > so your comments about extracts are validated, taking nearly 3 times as long as > downloads on a currently 2MByte/s medium speed cable modem link to a nearby > (7.5km direct, 11km drive, 15 hop 10ms round trip) university campus mirror in > recent years. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scallywag / cygport not pulling lzip 2021-01-12 16:28 ` Brian Inglis @ 2021-01-12 19:46 ` ASSI 0 siblings, 0 replies; 13+ messages in thread From: ASSI @ 2021-01-12 19:46 UTC (permalink / raw) To: cygwin-apps Brian Inglis writes: > Currently mirrors.html states 160GB total. I'm only mirroring the stuff that setup might actually use. The other mirror, as I said is only what setup actually uses, plus one previous version plus the sources of that. > Rsync delta download data transfer quantities are still significant on > metered or limited accounts with high overage charges: mirror storage > cost is trivial by comparison. Storage doesn't cost anything apparently so I'd not worry about it. I've been using a metered connection over modem for long enough to know how it feels to run an 8 hour download to get all the stuff for the next update. But these days pretty much anybody expects you to be able to download another GiB each month and in the grand scheme of things Cygwin doesn't really matter unless you insist on downloading everything ( and even then that is only once). > Parents are being hit with $Ks monthly overage charges run up by their > kids downloading and running games on multiple devices, or cut off > after hitting their limit if they block overages, which prevents > access to school or work until the next month capacity allowance kicks > in! That's not something we can help with, really. 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scallywag / cygport not pulling lzip 2021-01-08 17:13 ` Achim Gratz 2021-01-08 18:09 ` Brian Inglis @ 2021-01-09 19:08 ` Achim Gratz 1 sibling, 0 replies; 13+ messages in thread From: Achim Gratz @ 2021-01-09 19:08 UTC (permalink / raw) To: cygwin-apps Achim Gratz writes: > Since it promises to enable it's use, yes. I wouldn't mind to add a > dependency to tar also. Since lzip is not a very large package and tar just released a new version… should I add the dependency or should I keep things as they are? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scallywag / cygport not pulling lzip @ 2022-08-14 19:07 Hannes Mueller 0 siblings, 0 replies; 13+ messages in thread From: Hannes Mueller @ 2022-08-14 19:07 UTC (permalink / raw) To: cygwin-apps Hello, I run into the same problem as discussed in https://www.mail-archive.com/cygwin-apps@cygwin.com/msg37597.html I found no final decision in this mail thread and the problem is still existing. I would also expect cygport depends on lzip, since source files are provided in this format. Maybe also tar should depend on lzip. Best regards, Hannes ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-08-14 19:07 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-08 7:38 scallywag / cygport not pulling lzip Marco Atzeri 2021-01-08 13:23 ` ASSI 2021-01-08 13:58 ` Marco Atzeri 2021-01-08 14:21 ` Jon Turney 2021-01-08 16:52 ` Brian Inglis 2021-01-08 17:13 ` Achim Gratz 2021-01-08 18:09 ` Brian Inglis 2021-01-08 19:11 ` Achim Gratz 2021-01-11 22:05 ` Brian Inglis 2021-01-12 16:28 ` Brian Inglis 2021-01-12 19:46 ` ASSI 2021-01-09 19:08 ` Achim Gratz 2022-08-14 19:07 Hannes Mueller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).