Re: [ITA] libid3tag
On Sun, 18 Feb 2024 15:08:56 + Jon Turney wrote: > On 17/02/2024 13:43, Marco Atzeri via Cygwin-apps wrote: > > On 17/02/2024 04:18, Takashi Yano via Cygwin-apps wrote: > >> I would like to adopt libid3tag. > > > > $ git diff | grep ^+ > > +++ b/cygwin-pkg-maint > > +libid3tag Takashi Yano > > +libmad Takashi Yano > > +taglib Takashi Yano > > +taglib-extras Takashi Yano > > +utf8cpp Takashi Yano > > FWIW, I took a look at these cygports and couldn't find anything to > comment on. Good job! Thanks for cheching! -- Takashi Yano
Re: Fwd: calm: cygwin package report for Ken Brown
On 3/20/2023 7:17 PM, Jon Turney wrote: On 20/03/2023 22:17, Ken Brown via Cygwin-apps wrote: It looks like my plan for having scallywag deploy all the TeX Live packages won't work (see below). calm would have to be more permissive and allow deploying a package that requires something that will be provided by a future package. In this case, I made asymptote require tl_2023, which will be provided by the next texlive release. But I don't want to deploy the latter until all the other packages for TeX Live 2023 have been deployed. Unless this is easy to fix, I'll just forget about using scallywag and go back to my old method of uploading everything manually. This is trivially fixable. calm already has a list of 'provides which don't exist (yet)', so I think I just need to add tl_2023 and tl_basic_2023 to that list Future work: make these regexes so we don't have same problem again in a years time. Jon, In preparation for TeX Live 2024, please add tl_2024 and tl_basic_2024 to the list of provides which don't exist yet (unless you've already done the regex future work). Thanks. Ken
Re: Fwd: calm: cygwin package report for Ken Brown
On 19/02/2024 18:59, Ken Brown via Cygwin-apps wrote: On 3/20/2023 7:17 PM, Jon Turney wrote: On 20/03/2023 22:17, Ken Brown via Cygwin-apps wrote: It looks like my plan for having scallywag deploy all the TeX Live packages won't work (see below). calm would have to be more permissive and allow deploying a package that requires something that will be provided by a future package. In this case, I made asymptote require tl_2023, which will be provided by the next texlive release. But I don't want to deploy the latter until all the other packages for TeX Live 2023 have been deployed. Unless this is easy to fix, I'll just forget about using scallywag and go back to my old method of uploading everything manually. This is trivially fixable. calm already has a list of 'provides which don't exist (yet)', so I think I just need to add tl_2023 and tl_basic_2023 to that list Future work: make these regexes so we don't have same problem again in a years time. Jon, In preparation for TeX Live 2024, please add tl_2024 and tl_basic_2024 to the list of provides which don't exist yet (unless you've already done the regex future work). These are controlled by regex now, so these should already be permitted, and I don't need to do anything (yay!): 'tl_\d+' 'tl_basic_\d+'
Re: [cygport] enabling a replacement for "objdump -d -l"
On 18/02/2024 20:51, ASSI via Cygwin-apps wrote: Cygport uses "objdump -d -l" to extract the list of source files that need to be copied into the debuginfo package. This operation triggers some O(N²) or even higher complexity and in addition has been getting slower in recent binutils releases due to more and more information being put into the object files. For gcc-11 extracting the debug source files takes up to 45 minutes per executable (up from about 15 minutes until 2.39) and for gcc-13 (with about 1.5 times the number of lines to extract) it is already taking more than two hours. So if you just package gcc-13 using a single thread you'd be looking on the order of 20 hours wall clock time, which is unacceptable. The deassembly implied by the "-d" (which is not the part that has the superlinear complexity btw, but produces a baseline of 2 hours single thread runtime all by itself) is also unnecessary to extract just the filenames of the source files as we throw away the location information anyway and so I've written a small parser that works on the DWARF dump instead (which can be produced in linear time with a very small scaling factor, so practically constant time even for very large executables). Unfortunately binutils does not yet offer a machine readable format for these dumps, but parsing the text is not too difficult even though the format is undocumented. The DWARF-5 documentation isn't the most enjoyable read, but it was helpful enough to figure it all out. I've also integrated the filtering of unrelated source file information (from system headers and external libraries). The end result is the same runtime as before on small object files, a factor up to 100 speedup for medium sized object files and speedups in the several thousands range for large sized ones (or a total single-thread runtime of less than 20 seconds for gcc-13). Integration into cygport is made configurable via a variable to be set in .cygportrc for instance in order to easily revert back to the original objdump invocation if necessary. I've been producing packages with that setup for a while now and have not noticed any errors. In principle the new parser actually produces more complete output as there can be multiple line number statements and hence source files per location, but objdump only lists one of them in the disassembly (at least sometimes). In practise I haven't found a package until now where the final list (after filtering) is different. if works should not be the default ? Reducing that time is very interesting for the big stuff Regards, Achim. Thanks Marco
