Re: [ITP] neomutt
On 01/31/2018 06:55 PM, Jon Turney wrote: On 30/01/2018 05:56, Federico Kircheis wrote: On 01/28/2018 03:43 PM, Jon Turney wrote: On 28/01/2018 11:38, Federico Kircheis wrote: Name: Federico Kircheis Package: neomutt Done Uploaded. Please upload a x86 package as well. I'm sorry, I uploaded it, too. I thought that the previous upload would have been valid both for x64 and x86. I was unsure how to proceed, so I've downloaded a x86 version of cygwin, copied the cygport file in a separate directory, and so on. Is there a way to update the package for x64 and x86 at once? Without using ftp directly of course. `man cygport` mentions the `--32` and `--64` parameters for building the package, but not for uploading it and I did not want to try it out before messing something up on the server :-) Federico
version anomalies
With the setup 2.885 release candidate, when selecting 'sync' (dist-upgrade) mode, you may find you have some packages installed which setup wants to downgrade. Mostly, these are packages where a version was removed (or relabelled as test), and hasn't (yet) been superseded by a higher version. Currently, you are just supposed to know that you need to downgrade these manually. I have written a script [1] which analyses historical setup.ini data from the Cygwin Time Machine (thanks!), looking for anomalies with version numbers which cause this behaviour. (caveat: CTM only updates once per day, so problems which existed for less than a day e.g. the recent hiccup with libgc1 [2], may not be in this dataset) This finds the following anomalies for x86_64: $ ./version-anomalies.py --arch x86_64 package version version after circa gcc-ada 6.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] gcc-cilkplus6.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] gcc-core6.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] gcc-debuginfo 6.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] gcc-fortran 6.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] gcc-g++ 6.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] gcc-objc6.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] gcc-objc++ 6.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] libatomic1 6.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] libcilkrts5 6.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] libgcc1 6.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] libgfortran36.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] libgnat66.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] libgomp16.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] libobjc46.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] libquadmath06.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] libstdc++6 6.4.0-5 6.4.0-4 circa/64bit/2018/01/20/070117 [a] lftp4.8.0-1 4.7.8-2 circa/64bit/2017/10/10/051431 [b] lftp-debuginfo 4.8.0-1 4.7.8-2 circa/64bit/2017/10/10/051431 [b] fossil 20151102+1.34-1 2.3-1 circa/64bit/2017/09/25/184706 [*] liblz4-devel131-1 1.7.5-1 circa/64bit/2017/09/02/145432 [‡] liblz4_1131-1 1.7.5-1 circa/64bit/2017/09/02/145432 [‡] lz4 131-1 1.7.5-1 circa/64bit/2017/09/02/145432 [‡] lz4-debuginfo 131-1 1.7.5-1 circa/64bit/2017/09/02/145432 [‡] mingw64-i686-lz4131-1 1.7.5-1 circa/64bit/2017/09/02/145432 [‡] mingw64-x86_64-lz4 131-1 1.7.5-1 circa/64bit/2017/09/02/145432 [‡] kde-base-artwork15.04.3-1 5.8.8-1 circa/64bit/2017/04/19/015003 [‡] libproj94.9.3-1 4.9.2-1 circa/64bit/2016/11/10/231405 [c] oxygen-icons15.04.3-1 5.39.0-1 circa/64bit/2016/11/02/231610 [‡] libslang-devel 2.3.1pre17-1 2.3.1a-1 circa/64bit/2016/10/31/131355 [d] libslang2 2.3.1pre17-1 2.3.1a-1 circa/64bit/2016/10/31/131355 [d] slang-debuginfo 2.3.1pre17-1 2.3.1a-1 circa/64bit/2016/10/31/131355 [d] slsh2.3.1pre17-1 2.3.1a-1 circa/64bit/2016/10/31/131355 [d] cscope 15.8.0.1-215.8b-1 circa/64bit/2016/06/07/161250 [*] perl-Carp 1.3301-2 1.38-2 circa/64bit/2015/07/30/131023 [*] xdelta 3.0.9-1 1.1.4-2 circa/64bit/2015/07/17/161023 [e] xdelta-debuginfo3.0.9-1 1.1.4-2 circa/64bit/2015/07/17/161023 [e] socat 2.0.0-b7-11.7.3.1-1 circa/64bit/2015/03/20/171020 [f] perl_autorebase 001001-1 5.26.1-1 circa/64bit/2015/02/16/141018 [g] fossil 20140612172556-3 20151102+1.34-1 circa/64bit/2015/02/08/141019 [*] mingw64-x86_64-binutils 20130314-12.29.1.787c9873-1 circa/64bit/2014/03/16/034442 [*] giflib 4.2.1-1 4.1.6-12 circa/64bit/2013/07/20/142328 [§] giflib-debuginfo4.2.1-1 4.1.6-12 circa/64bit/2013/07/20/142328 [§] libgif-devel
Re: [ITP] neomutt
On 30/01/2018 05:56, Federico Kircheis wrote: On 01/28/2018 03:43 PM, Jon Turney wrote: On 28/01/2018 11:38, Federico Kircheis wrote: Name: Federico Kircheis Package: neomutt Done Uploaded. Please upload a x86 package as well.
Re: setup 2.885 release candidate - please test
On 30/01/2018 20:18, Jon Turney wrote: On 29/01/2018 19:19, Achim Gratz wrote: Jon Turney writes: [...]>>> - The "prereq" page showing dependencies which will be added is replaced by "problems" page showing problems found by the dependency solver, with default solutions. - A "confirm" page is added showing all the changes which will be made. I've not actually commenced the installation yet due to other things I want to fix first, so I can't say whether these two pages work. I guess I should not see them with my normal install script. The interesting part would be if they are skipped when non-interactive mode is given and there was something to add due to dependencies? These should be added (and default solutions applied where the solver identified problems) in non-interactive mode. It seems I missed the part to add default problem solutions in non-interactive mode. - Add support for 'depends2: package (relation version) [...]', in a version section in setup.ini Those lines don't seem to get generated for all packages yet. I currently merge with requires: to produce a working setup.ini re-write and will switch to using requires: when I find no depends2:. Can I assume that all versions have a depends2: line when I find one for [curr]? Yes, with the proviso that empty depends2: lines are currently suppressed (this might be a mistake) Yeah, suppressing these is definitely a mistake, as we need to indicate (in a small number of cases) a package version which has no depends: when other versions do have them. Unfortunately, fixing that reveals that the setup parser doesn't currently permit an empty requires: or depends: list (which I guess explains why they have been suppressed historically)
Re: setup 2.885 release candidate - please test
On 30/01/2018 20:18, Jon Turney wrote: On 30/01/2018 18:49, Achim Gratz wrote: Another thing I noticed today is that when packages get upgraded the transaction list that gets printed to the console seems to always show the removal of the old package _after_ the installation of the new version. I guess that will not happen in this order, but it looks positively weird on screen. Yeah, I think we are reversing the order given by the solver. This should be benign, as we do all the uninstalls before installs. I'll fix that :) Hmm.. actually, I don't know what's going here. We are preserving the order produced by the solver, and it produces a more sensible looking ordering for some more complex transactions, so I don't know why upgrades look backwards...
