Re: setup-*.exe --help default explanation re -D/-L options [Was: [ANNOUNCEMENT] Updated: setup (2.917)]

[Jon Turney]

On 01/02/2022 21:46, Adam Dinwoodie wrote:

On Tue, Feb 01, 2022 at 04:53:47PM +, Jon Turney wrote:

[...]

Note that I tweaked the behaviour of this a bit in [1]

[1] 
https://cygwin.com/git/?p=cygwin-apps/setup.git;a=commit;h=147fc15d0222e050779b18a209991c258d85944f

I think that makes the current help text accurately describe non-interactive
mode.

There are some cases in interactive mode which are obscure (e.g. '-M'
without '-D' or '-L' gets you whatever mode you used last time without
showing you what it was, but I'm not sure if that needs to be here.


Ah, okay.  I think I hit this with `-M` and assumed -- evidently
incorrectly -- that the same behaviour would exist for `-q`.  I agree
the current text is entirely accurate for the fully non-interactive
mode.


[...]>

I definitely see no harm in that approach, and I agreed that'd make
things clearer again.  But, as above, I think the key thing from my
perspective would be for `-M` and `-q` to have consistent behaviour.
 Yes, on reflection, I think that change isn't quite right, and '-M' 
should be handled the same as '-q' there (i.e. '-D' & '-L' is the 
default, unless explicitly specified otherwise)

Re: setup trying to install not existing packages

[Jon Turney]

On 24/01/2022 05:30, Marco Atzeri wrote:


in same cases Setup is trying to install python-sip 6.5.0-1
https://sourceware.org/pipermail/cygwin/2022-January/250604.html

It seems the missing install row that we are currently accepting
is not properly understood by Setup

[...]

Wow, what an oversight.

This just a bug in setup, in that it creates a python-sip 6.5.0-1 
package, even though it doesn't have an install line (and so there's no 
path to download it from, so if we produce a solution including it, the 
download is just going to fail)


there should be 3 packages that are pulling python-sip but really need 
python2-sip


picard, pulseaudio-equalizer, python-pykde4 seem to be the effected 
packages.


Should be fixed in setup 2.917, which doesn't add that bogus package to 
the data model, so the solution includes python-sip 4.19.6-1, which 
pulls in python2-sip 4.19.6-1

Re: setup build failure

[Jon Turney]

On 05/10/2021 17:29, Ken Brown via Cygwin-apps wrote:
The current setup sources fail to build because ~StringChoiceOption is 
not defined:


   CXXLD    setup.exe
/usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld: io_stream_cygfile.o:/home/kbrown/src/cygsetup/x86_64/../setup/io_stream_cygfile.cc:40: 
undefined reference to `StringChoiceOption::~StringChoiceOption()'
/usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld: io_stream_cygfile.o:/home/kbrown/src/cygsetup/x86_64/../setup/io_stream_cygfile.cc:43: 
undefined reference to 
`StringChoiceOption::StringChoiceOption(std::vectorconst*, int>, std::allocator > >, char, char 
const*, std::__cxx11::basic_string, 
std::allocator > const&, bool, int, int)'
/usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld: main.o:/home/kbrown/src/cygsetup/x86_64/../setup/main.cc:107: 
undefined reference to `StringChoiceOption::~StringChoiceOption()'
/usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld: main.o:/home/kbrown/src/cygsetup/x86_64/../setup/main.cc:107: 
undefined reference to 
`StringChoiceOption::StringChoiceOption(std::vectorconst*, int>, std::allocator > >, char, char 
const*, std::__cxx11::basic_string, 
std::allocator > const&, bool, int, int)'

collect2: error: ld returned 1 exit status


You need to autoreconf in the libgetopt++ subdir (the simplest way is 
just to re-run the top-level bootstrap.sh script)


I'm not sure why the necessary autofoolery doesn't happen automatically.

Re: setup 2.906 release candidate - please test

[Jon Turney]

On 17/03/2021 20:08, Jon Turney wrote:

On 17/03/2021 20:02, Jon Turney wrote:


A new setup release candidate is available at:

   https://cygwin.com/setup/setup-2.906.x86_64.exe (64 bit version)
   https://cygwin.com/setup/setup-2.906.x86.exe    (32 bit version)

Please test, and report any problems here.

This is not the place for setup feature requests.


Pretty late in preparing this release, I discovered that in Fedora 33, 
the MinGW-w64 32-bit compiler has been changed from sjlj to dwarf2 
unwinding C++ exception handling.


I believe this means that exceptions cannot propagate up through Windows 
code, so the release needs to be delayed until the source code has been 
inspected to see if there's any place where e.g. we throw an exception 
from a Windows callback, but I'd like to get this out for some testing 
already.


I think that this does effect some error cases, where we throw an error 
and expect it to get propagated through a callback.


So for the moment, I've added a configure time check that the x86 
compiler is configured with sjlj exceptions, and dropped back to 
building on Fedora 32.


Long term, I'm not sure what the best approach is.  Using 
-fno-exceptions and adjusting the code not to use exceptions would be a 
start, but that just leaves us silently exiting if an exception is 
thrown from libstdc++...

Re: setup 2.906 release candidate - please test

[Jon Turney]

On 25/03/2021 20:22, kaptain.biwo...@gmail.com wrote:


I have tested version 2.906 of setup and I am facing one issue on windows
10:


Thanks for testing.


I got this message: In order to use libusb0, you must download and rune
the LibUSB-Win32 driver from:
https://sourceforge.net/projects/libusb-win32/files.../libusb-win32-devel-filter-1.2.6.0.exe


It's unclear if you mean that this message is new with this version of
setup, or has always been a problem.

This message is correct (and expected) if you are installing libusb0.

(this is the package for the deprecated 0.1 libUSB API, so we shouldn't
have any packages which require it, but it seems we still have a few...)

Quoted from:
http://cygwin.1069669.n5.nabble.com/setup-2-906-release-candidate-please-test-tp157282p157374.html

It is new with this version.
I have never seen this kind of message by the past.


I'm not able to reproduce this problem.

Can you tell me:
- are you using the 32- or 64-bit version of setup 2.906?
- is the libusb0 package installed?
- do you get this message every time you run setup 2.906?

Re: setup 2.906 release candidate - please test

[Jon Turney]

On 22/03/2021 16:35, kaptain.biwo...@gmail.com wrote:



A new setup release candidate is available at:

https://cygwin.com/setup/setup-2.906.x86_64.exe (64 bit version)
https://cygwin.com/setup/setup-2.906.x86.exe(32 bit version)

Please test, and report any problems here.

This is not the place for setup feature requests.

Changes compared to 2.905:


[...]



Quoted from:
  
http://cygwin.1069669.n5.nabble.com/setup-2-906-release-candidate-please-test-tp157282.html

I have tested version 2.906 of setup and I am facing one issue on windows 10:


Thanks for testing.


I got this message: In order to use libusb0, you must download and rune the 
LibUSB-Win32 driver from:
https://sourceforge.net/projects/libusb-win32/files.../libusb-win32-devel-filter-1.2.6.0.exe


It's unclear if you mean that this message is new with this version of 
setup, or has always been a problem.


This message is correct (and expected) if you are installing libusb0.

(this is the package for the deprecated 0.1 libUSB API, so we shouldn't 
have any packages which require it, but it seems we still have a few...)

Re: setup 2.906 release candidate - please test

[Brian Inglis]

On 2021-03-17 14:02, Jon Turney wrote:

A new setup release candidate is available at:
   https://cygwin.com/setup/setup-2.906.x86_64.exe (64 bit version)
   https://cygwin.com/setup/setup-2.906.x86.exe    (32 bit version)
Please test, and report any problems here.
This is not the place for setup feature requests.
Changes compared to 2.905:
- If a selected site URL saved from the last run starts with "http://;, and an 
identical URL, except starting with "https://;, is in the current mirror list, 
migrate it from "http://; to "https://;.
- Propagate the value of the CYGWIN environment variable into post-install and 
pre-remove scripts (Thanks to Michael Wild for this patch).

   Partially addresses: 
https://cygwin.com/pipermail/cygwin/2020-August/245994.html
- Warn about unknown package names used with '--packages' or '--remove-packages' 
options.
- Move (potentially localizable) installation progress and package action 
strings to string table resource.

- Fix new warnings and build issues with gcc 10.


Not seeing any issues with this test release.
Sometime in the last while, Cygwin Setup started making the default chooser 
column widths 100-200px wide, and I don't see any obviously relevant change in 
the log, nor any issues in setup.log.full.
Only unusual occurrence may be /etc/setup/setup.rc chooser_window_settings has 
4G-1 in fields 4-7 of window placement, and wondered if those could be getting 
used incorrectly for column width calculations?
I'm on Windows 1909 19H1 10.0.18363.1379 until my next update which says it has 
20H? pending.


--
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.]

Re: setup 2.906 release candidate - please test

[Ken Brown via Cygwin-apps]

On 3/17/2021 5:16 PM, Thomas Wolff wrote:

Am 17.03.2021 um 21:02 schrieb Jon Turney:


A new setup release candidate is available at:

  https://cygwin.com/setup/setup-2.906.x86_64.exe (64 bit version)
  https://cygwin.com/setup/setup-2.906.x86.exe    (32 bit version)

Please test, and report any problems here.
I feel the need to take this occasion to woe about the terrible UI of setup. Two 
years or more ago there was a major revision, sarcastically accompanied by the 
comment the UI would have been pushed forward to the 90s. Before that, you could 
simply select a package by clicking one (!) checkbox. Since then, you have to 
open a popup, scroll to the latest version and click that. This multiplies the 
effort to do selections significantly and it's quite a nuisance.


If you double-click in the New column, I think it will do what you want.

Ken

Re: setup 2.906 release candidate - please test

[Thomas Wolff]

Am 17.03.2021 um 21:02 schrieb Jon Turney:


A new setup release candidate is available at:

  https://cygwin.com/setup/setup-2.906.x86_64.exe (64 bit version)
  https://cygwin.com/setup/setup-2.906.x86.exe    (32 bit version)

Please test, and report any problems here.
I feel the need to take this occasion to woe about the terrible UI of 
setup. Two years or more ago there was a major revision, sarcastically 
accompanied by the comment the UI would have been pushed forward to the 
90s. Before that, you could simply select a package by clicking one (!) 
checkbox. Since then, you have to open a popup, scroll to the latest 
version and click that. This multiplies the effort to do selections 
significantly and it's quite a nuisance.


This is not the place for setup feature requests.
It's not a feature as it was much better before; it's a regression. Can 
we please get back a fast-usable interface?

Thomas



Changes compared to 2.905:

- If a selected site URL saved from the last run starts with 
"http://;, and an identical URL, except starting with "https://;, is 
in the current mirror list, migrate it from "http://; to "https://;.


- Propagate the value of the CYGWIN environment variable into 
post-install and pre-remove scripts (Thanks to Michael Wild for this 
patch).
  Partially addresses: 
https://cygwin.com/pipermail/cygwin/2020-August/245994.html


- Warn about unknown package names used with '--packages' or 
'--remove-packages' options.


- Move (potentially localizable) installation progress and package 
action strings to string table resource.


- Fix new warnings and build issues with gcc 10.

Re: setup 2.906 release candidate - please test

[Jon Turney]

On 17/03/2021 20:02, Jon Turney wrote:


A new setup release candidate is available at:

   https://cygwin.com/setup/setup-2.906.x86_64.exe (64 bit version)
   https://cygwin.com/setup/setup-2.906.x86.exe    (32 bit version)

Please test, and report any problems here.

This is not the place for setup feature requests.


Pretty late in preparing this release, I discovered that in Fedora 33, 
the MinGW-w64 32-bit compiler has been changed from sjlj to dwarf2 
unwinding C++ exception handling.


I believe this means that exceptions cannot propagate up through Windows 
code, so the release needs to be delayed until the source code has been 
inspected to see if there's any place where e.g. we throw an exception 
from a Windows callback, but I'd like to get this out for some testing 
already.

Re: setup 2.902 release candidate - please test

[ASSI]

Jon Turney writes:
>> - Embeds a new Cygwin public key (which nothing is actually signed
>> with yet)
>
> setup.ini is now being signed with both old and new Cygwin keys.

As I have my own mirror script that will then combine any local packages
into one targeted install hierarchy and I _do_ check the signatures
(that has saved me from broken mirrors a few times), I've had to go and
import the new keys, which then gives me:

... mirroring
 ==>/mnt/mirror/cygwin/x86/setup.xz.sig
 ==>/mnt/mirror/cygwin/x86/setup.xz
Waiting for 2 transfers to finish 2 1  
...all transfers finished!
gpg: Signature made Sa, 14. Mrz 2020 11:53:57 CET
gpg:using DSA key 1169DF9F22734F743AA59232A9A262FF676041BA
gpg: Good signature from "Cygwin " [unknown]   
gpg: Signature made Sa, 14. Mrz 2020 11:53:57 CET 
gpg:using RSA key 56405CF6FCC81574682A5D561A698DE9E2E56300
gpg: Good signature from "Cygwin " [unknown]   

So external signature checks actually work exactly as intended, thanks.


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

Re: setup 2.902 release candidate - please test

[Jon Turney]

On 28/02/2020 17:45, Jon Turney wrote:


A new setup release candidate is available at:

   https://cygwin.com/setup/setup-2.902.x86_64.exe (64 bit version)
   https://cygwin.com/setup/setup-2.902.x86.exe    (32 bit version)


[...]


* using multiple keys (i.e. the .sig file contains multiple signatures), 
where a signature from a known key is not the first one appearing.


- Embeds a new Cygwin public key (which nothing is actually signed with 
yet)


setup.ini is now being signed with both old and new Cygwin keys.

* The '--disable-old-keys' option disables use of the current Cygwin 
signing key.


... so it's now possible to successfully run setup, even when using this 
option.


(as setup will ignore the first signature (made with the old key) and 
verify the next signature made with the new key)


... and hopefully existing setup keeps on working as well :)

Re: setup 2.894 release candidate - please test

[Andrew Schulman]

> Am 13.10.2018 um 20:49 schrieb Jon Turney:
> > 
> > A new setup release candidate is available at:
> > 
> >    https://cygwin.com/setup/setup-2.894.x86_64.exe (64 bit version)
> >    https://cygwin.com/setup/setup-2.894.x86.exe    (32 bit version)
> > 
> > Please test and report any problems here.
> 
> very nice.
> 
> May I have a hippo for Jon ?
> 
> Regards
> Marco

Awarded! http://cygwin.com/goldstars/#JTy

Re: setup 2.894 release candidate - please test

[Marco Atzeri]

Am 15.10.2018 um 09:12 schrieb Mark Geisert:

Corinna Vinschen wrote:

On Oct 14 13:29, Achim Gratz wrote:

Marco Atzeri writes:

May I have a hippo for Jon ?


+1


+1


+1
Looks and works great in my limited testing.

..mark



Andrew,
May I have the Hippo for Jon ?

Regards
Marco

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Re: setup 2.894 release candidate - please test

[Jon Turney]

On 14/10/2018 12:20, Achim Gratz wrote:

Jon Turney writes:

A new setup release candidate is available at:

   https://cygwin.com/setup/setup-2.894.x86_64.exe (64 bit version)
   https://cygwin.com/setup/setup-2.894.x86.exe(32 bit version)

Please test and report any problems here.


I've built both versions myself and everything is working smoothly.  Thanks!

One slight issue is with the UI: the selection box for the version is
hiding part of the version string even when the window is wide enough to
accommodate it fully while the column to the left is larger than it would
need to be.  I have no idea how difficult that'd be to fix.


I've adjusted the sizing of the 'new' column so it allows for the width 
of the drop-down button as well as the version.

Re: setup 2.894 release candidate - please test

[Jon Turney]

On 15/10/2018 21:35, Marco Atzeri wrote:

Am 13.10.2018 um 20:49 schrieb Jon Turney:


A new setup release candidate is available at:

   https://cygwin.com/setup/setup-2.894.x86_64.exe (64 bit version)
   https://cygwin.com/setup/setup-2.894.x86.exe    (32 bit version)

Please test and report any problems here.



Noted an inconsistency in the action drop menu.
It proposes the available test version also when the test box is not 
checked.


Just noted on binutils 2.31.1-1

I think it should not report it, or highlight the "test" status


Test versions are always selectable in the package chooser at the moment.

I've added an indication that it's a test version, as that seems like a 
very good idea, though.

Re: setup 2.894 release candidate - please test

[Corinna Vinschen]

On Oct 14 19:26, Corinna Vinschen wrote:
> On Oct 13 19:49, Jon Turney wrote:
> > 
> > A new setup release candidate is available at:
> > 
> >   https://cygwin.com/setup/setup-2.894.x86_64.exe (64 bit version)
> >   https://cygwin.com/setup/setup-2.894.x86.exe(32 bit version)
> > 
> > Please test and report any problems here.
> > 
> > Changes compared to 2.893:
> > 
> > - Drag setup into the 1990s, by replacing the custom-drawn package chooser
> > with a ListView common control.
> > 
> > -- Use standard UI elements to choose an action to take on a package or
> > category, rather than the weird UX of clicking to cycle around a list of
> > options of undisclosed length.
> 
> That's what I like about the 90's, it looks really awesome.
> 
> The pulldown menu to change the version needs some getting used to, but
> it's worthwhile.  I just have a style nit:
> 
> The (by default) rightmost field, "Size", is so much to the right that
> the rightmost characters collide with the Window frame.  [bla]

Utter nonsense.  I must have looked cross-eyed or something.  "Size"
isn't the rightmost field, and in the default "Pending" view with
*my* default dialog size, the "Size" field is just a tiny tick too
far to the right.  Pure coincidence, nothing to worry about.


Sorry,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: setup 2.894 release candidate - please test

[Marco Atzeri]

Am 13.10.2018 um 20:49 schrieb Jon Turney:


A new setup release candidate is available at:

   https://cygwin.com/setup/setup-2.894.x86_64.exe (64 bit version)
   https://cygwin.com/setup/setup-2.894.x86.exe    (32 bit version)

Please test and report any problems here.



Noted an inconsistency in the action drop menu.
It proposes the available test version also when the test box is not 
checked.


Just noted on binutils 2.31.1-1

I think it should not report it, or highlight the "test" status

Regards
Marco


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Re: setup 2.894 release candidate - please test

[Mark Geisert]

Corinna Vinschen wrote:

On Oct 14 13:29, Achim Gratz wrote:

Marco Atzeri writes:

May I have a hippo for Jon ?


+1


+1


+1
Looks and works great in my limited testing.

..mark

Re: setup 2.894 release candidate - please test

[Corinna Vinschen]

On Oct 14 13:29, Achim Gratz wrote:
> Marco Atzeri writes:
> > May I have a hippo for Jon ?
> 
> +1

+1


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: setup 2.894 release candidate - please test

[Corinna Vinschen]

On Oct 13 19:49, Jon Turney wrote:
> 
> A new setup release candidate is available at:
> 
>   https://cygwin.com/setup/setup-2.894.x86_64.exe (64 bit version)
>   https://cygwin.com/setup/setup-2.894.x86.exe(32 bit version)
> 
> Please test and report any problems here.
> 
> Changes compared to 2.893:
> 
> - Drag setup into the 1990s, by replacing the custom-drawn package chooser
> with a ListView common control.
> 
> -- Use standard UI elements to choose an action to take on a package or
> category, rather than the weird UX of clicking to cycle around a list of
> options of undisclosed length.

That's what I like about the 90's, it looks really awesome.

The pulldown menu to change the version needs some getting used to, but
it's worthwhile.  I just have a style nit:

The (by default) rightmost field, "Size", is so much to the right that
the rightmost characters collide with the Window frame.  Looks like only
the "Size" field is affected by way of being right-justified.  Would
it perhaps make sense to append just a single space at the end of the
field (including the header) so the spacing looks more relaxed?

Thanks a lot for this change.  I'm pretty sure especially visually
impaired users will be most happy with this change.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: setup 2.894 release candidate - please test

[Achim Gratz]

Marco Atzeri writes:
> May I have a hippo for Jon ?

+1


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: setup 2.894 release candidate - please test

[Achim Gratz]

Jon Turney writes:
> A new setup release candidate is available at:
>
>   https://cygwin.com/setup/setup-2.894.x86_64.exe (64 bit version)
>   https://cygwin.com/setup/setup-2.894.x86.exe(32 bit version)
>
> Please test and report any problems here.

I've built both versions myself and everything is working smoothly.  Thanks!

One slight issue is with the UI: the selection box for the version is
hiding part of the version string even when the window is wide enough to
accomodate it fully while the column to the left is larger than it would
need to be.  I have no idea how difficult that'd be to fix.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: setup 2.894 release candidate - please test

[Thomas Wolff]

Am 13.10.2018 um 20:49 schrieb Jon Turney:


A new setup release candidate is available at:

  https://cygwin.com/setup/setup-2.894.x86_64.exe (64 bit version)
  https://cygwin.com/setup/setup-2.894.x86.exe    (32 bit version)

Please test and report any problems here.
There's one small but occasionally bothersome long-standing issue; may I 
ask for enhancement on this occasion:
If I click through the dialog quickly by consecutive Enter and hit one 
Enter too many, setup will be on one of the two download pages before I 
notice and will abort because initially only the "Cancel" button is 
activated as interactive default button. This could easily be prevented 
by not ever making "Cancel" the default, even when it is the only 
enabled button.

Thanks for considering
Thomas

Re: setup 2.894 release candidate - please test

[Marco Atzeri]

Am 13.10.2018 um 20:49 schrieb Jon Turney:


A new setup release candidate is available at:

   https://cygwin.com/setup/setup-2.894.x86_64.exe (64 bit version)
   https://cygwin.com/setup/setup-2.894.x86.exe    (32 bit version)

Please test and report any problems here.


very nice.

May I have a hippo for Jon ?

Regards
Marco


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Re: setup and 'provides:'

[Achim Gratz]

cyg Simple writes:
> I assumed that this was the case.  But the symlink is a conflict and I
> assume that if one exists already the package management system would
> not recreate one or would ask the user if it should be overwritten.

The symlink to the actual executable is not a conflict since it isn't
packaged.  It is created / altered via alternatives in a postinstall
script (and potentially altered and/or removed by a pre-remove script).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: setup and 'provides:'

[Achim Gratz]

Ken Brown writes:
>>>  So we'd need to bolt on a feature space in setup as well.
>
> I'm not sure what you mean by this.  setup doesn't need to know whether a 
> requirement is a feature or a package.  It simply passes the dependencies 
> (and 
> the provides) to libsolv, which handles them just fine.

If we have features, then setup would need to show them somewhere and it
would be awkward if that info was empty for most packages.  Then people
will want to install features instead of packages anyway, so that is
another nudge into "featurizing" the whole distribution.  In other
words, once we start using "provides:" in that way, I think it should
become mandatory.


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

Re: setup and 'provides:'

[Ken Brown]

On 10/9/2018 11:10 AM, cyg Simple wrote:
> On 10/8/2018 12:24 PM, Ken Brown wrote:
>> On 10/8/2018 11:17 AM, cyg Simple wrote:
>>> On 10/8/2018 11:05 AM, Ken Brown wrote:
 Here's an example (modeled on what Fedora does): Cygwin has four
 packages that provide emacs binaries: emacs, emacs-X11, emacs-lucid, and
 emacs-w32.  Users can install any or all of these if they want to be
 able to run emacs.  The differences are in the UI.  These packages don't
 conflict with one another.

>>>
>>> How do they overcome the conflict?
>>
>> They use different names for the emacs binaries: emacs-nox.exe,
>> emacs-X11.exe, emacs-lucid.exe, and emacs-w32.exe.  The "alternatives"
>> system then creates a symlink /usr/bin/emacs that resolves to whichever
>> binary the user wants to use by default.  It's been this way for many
>> years, with no problems.
>>
> 
> I assumed that this was the case.  But the symlink is a conflict and I
> assume that if one exists already the package management system would
> not recreate one or would ask the user if it should be overwritten.

No, that's not how it works.  The symlink is created and managed by the 
alternatives system via commands in postinstall/preremove scripts and in 
user-callable scripts /usr/bin/set-emacs-default-*.  There is no conflict.  The 
various emacs packages can happily coexist.

 If some other package requires an emacs binary, I would like it to be
 able to require "emacs-bin".  [This plays the role of "foo" in my test
 case.]  Then I would like to be able to say that all four emacs packages
 above provide "emacs-bin".

>>>
>>> That's fine but how do an installation of multiple emacs-bin not create
>>> a conflict?
>>
>> "emacs-bin" is not a thing that can be installed.  It's simply a name
>> for a requirement, and that requirement can be met by installing any
>> package that declares that it provides "emacs-bin".  At least that's my
>> understanding of how it works in package managers like rpm.  As I said
>> at the very beginning, it's quite possible that I'm misunderstanding how
>> 'provides:' is supposed to work.
> 
> And I understand that emacs-bin is a pseudo name identifying a class of
> product the package provides.  The RPM system allows for defining
> Requires, Provides, Conflicts and Obsoletes.

So does Cygwin's setup.

>  The Arch Linux pacman
> allows for depends, makedepends, checkdepends, optdepends, provides,
> replaces and conflicts.  As you can see other package managers see
> *conflicts* as an important item because of the global namespace issue.

I agree that it can be useful, and I'm glad setup supports it.

Ken

Re: setup and 'provides:'

[cyg Simple]

On 10/8/2018 12:24 PM, Ken Brown wrote:
> On 10/8/2018 11:17 AM, cyg Simple wrote:
>> On 10/8/2018 11:05 AM, Ken Brown wrote:
>>> Here's an example (modeled on what Fedora does): Cygwin has four
>>> packages that provide emacs binaries: emacs, emacs-X11, emacs-lucid, and
>>> emacs-w32.  Users can install any or all of these if they want to be
>>> able to run emacs.  The differences are in the UI.  These packages don't
>>> conflict with one another.
>>>
>>
>> How do they overcome the conflict?
> 
> They use different names for the emacs binaries: emacs-nox.exe, 
> emacs-X11.exe, emacs-lucid.exe, and emacs-w32.exe.  The "alternatives" 
> system then creates a symlink /usr/bin/emacs that resolves to whichever 
> binary the user wants to use by default.  It's been this way for many 
> years, with no problems.
> 

I assumed that this was the case.  But the symlink is a conflict and I
assume that if one exists already the package management system would
not recreate one or would ask the user if it should be overwritten.

>>> If some other package requires an emacs binary, I would like it to be
>>> able to require "emacs-bin".  [This plays the role of "foo" in my test
>>> case.]  Then I would like to be able to say that all four emacs packages
>>> above provide "emacs-bin".
>>>
>>
>> That's fine but how do an installation of multiple emacs-bin not create
>> a conflict?
> 
> "emacs-bin" is not a thing that can be installed.  It's simply a name 
> for a requirement, and that requirement can be met by installing any 
> package that declares that it provides "emacs-bin".  At least that's my 
> understanding of how it works in package managers like rpm.  As I said 
> at the very beginning, it's quite possible that I'm misunderstanding how 
> 'provides:' is supposed to work.

And I understand that emacs-bin is a pseudo name identifying a class of
product the package provides.  The RPM system allows for defining
Requires, Provides, Conflicts and Obsoletes.  The Arch Linux pacman
allows for depends, makedepends, checkdepends, optdepends, provides,
replaces and conflicts.  As you can see other package managers see
*conflicts* as an important item because of the global namespace issue.

-- 
cyg Simple

Re: setup and 'provides:'

[Ken Brown]

On 10/8/2018 4:04 PM, Achim Gratz wrote:
> Ken Brown writes:
>> I created a test repo with packages A, B, and C.  I made A require foo (not a
>> package), and I made B and C provide foo.  The attached script does all this
>> [**].  I then ran setup and selected A for installation.
> 
> That really only makes sense if several packages provide the same
> feature(s).

Right.  I gave a potential example elsewhere in this thread, in which the 
feature emacs-bin is provided by the packages emacs, emacs-X11, emacs-lucid, 
and 
emacs-w32.  Fedora does something like this, except that it calls the feature 
emacs(bin).

>>  So we'd need to bolt on a feature space in setup as well.

I'm not sure what you mean by this.  setup doesn't need to know whether a 
requirement is a feature or a package.  It simply passes the dependencies (and 
the provides) to libsolv, which handles them just fine.

The only thing that I thought wasn't working right is libsolv's behavior when 
more than one package provides a certain feature and libsolv has to choose one 
for installation.  But I realize now that libsolv just doesn't do what I 
expected, and some non-trivial work on setup would be required in order to get 
the behavior I was expecting.  See my other messages in this thread.

Ken

Re: setup and 'provides:'

[Achim Gratz]

Ken Brown writes:
> I created a test repo with packages A, B, and C.  I made A require foo (not a 
> package), and I made B and C provide foo.  The attached script does all this 
> [**].  I then ran setup and selected A for installation.

That really only makes sense if several packages provide the same
feature(s).  So we'd need to bolt on a feature space in setup as well.

> The result was that libsolv simply chose B for installation, and setup showed 
> this in the "Confirm" dialog.  What I expected was that libsolv would report 
> a 
> problem ("A requires foo but no selected or installed packages provide it"), 
> with two possible solutions ("Install B or C").  Is that expectation 
> unreasonable?

Zypper would present you with a list of several potential solutions and
let you (incrementally if necessary) pick one of them.  I doubt that
will work nicely with the current setup UI.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: setup and 'provides:'

[Ken Brown]

On 10/7/2018 6:02 PM, Ken Brown wrote:
> I've been experimenting with setup's support for the 'provides:' tag, and it's
> not behaving the way I expect [*].  I'm not sure if something in setup's
> interface with libsolv needs to be tweaked or if I'm just misunderstanding how
> this should work.  Here's what I tried:
> 
> I created a test repo with packages A, B, and C.  I made A require foo (not a
> package), and I made B and C provide foo.  The attached script does all this
> [**].  I then ran setup and selected A for installation.
> 
> The result was that libsolv simply chose B for installation, and setup showed
> this in the "Confirm" dialog.  What I expected was that libsolv would report a
> problem ("A requires foo but no selected or installed packages provide it"),
> with two possible solutions ("Install B or C").  Is that expectation 
> unreasonable?
> 
> I plan to look into the libsolv sources to see if I can fix this, but I'm 
> hoping
> that someone already knows the answer.

It turns out that this question has been asked before:

https://bugzilla.redhat.com/show_bug.cgi?id=1266761#c3
https://github.com/openSUSE/libsolv/issues/107

AFAICT, libsolv will by default pick the alphabetically first package 
when there are several equally good candidates to meet the requirements. 
  According to the second link I cited, "libsolv offers methods to query 
for the encountered ambiguities after the solving, so that the user can 
be presented with a list of choices and then select different packages."

I may look into this further, but I'm beginning to wonder if it's worth 
the trouble.

Ken

Re: setup and 'provides:'

[Ken Brown]

On 10/8/2018 11:17 AM, cyg Simple wrote:
> On 10/8/2018 11:05 AM, Ken Brown wrote:
>> Here's an example (modeled on what Fedora does): Cygwin has four
>> packages that provide emacs binaries: emacs, emacs-X11, emacs-lucid, and
>> emacs-w32.  Users can install any or all of these if they want to be
>> able to run emacs.  The differences are in the UI.  These packages don't
>> conflict with one another.
>>
> 
> How do they overcome the conflict?

They use different names for the emacs binaries: emacs-nox.exe, 
emacs-X11.exe, emacs-lucid.exe, and emacs-w32.exe.  The "alternatives" 
system then creates a symlink /usr/bin/emacs that resolves to whichever 
binary the user wants to use by default.  It's been this way for many 
years, with no problems.

>> If some other package requires an emacs binary, I would like it to be
>> able to require "emacs-bin".  [This plays the role of "foo" in my test
>> case.]  Then I would like to be able to say that all four emacs packages
>> above provide "emacs-bin".
>>
> 
> That's fine but how do an installation of multiple emacs-bin not create
> a conflict?

"emacs-bin" is not a thing that can be installed.  It's simply a name 
for a requirement, and that requirement can be met by installing any 
package that declares that it provides "emacs-bin".  At least that's my 
understanding of how it works in package managers like rpm.  As I said 
at the very beginning, it's quite possible that I'm misunderstanding how 
'provides:' is supposed to work.

Ken

Re: setup and 'provides:'

[cyg Simple]

On 10/8/2018 11:05 AM, Ken Brown wrote:
> On 10/8/2018 10:41 AM, cyg Simple wrote:
>> On 10/7/2018 6:02 PM, Ken Brown wrote:
>>> I've been experimenting with setup's support for the 'provides:' tag, and 
>>> it's
>>> not behaving the way I expect [*].  I'm not sure if something in setup's
>>> interface with libsolv needs to be tweaked or if I'm just misunderstanding 
>>> how
>>> this should work.  Here's what I tried:
>>>
>>
>> Shouldn't there be a need for a 'conflicts:' tag as well?
> 
> setup does support a 'conflicts:' tag, but I don't see why I should need 
> it here.
> 

You might not, others might.  See below ...

>>> I created a test repo with packages A, B, and C.  I made A require foo (not 
>>> a
>>> package), and I made B and C provide foo.  The attached script does all this
>>> [**].  I then ran setup and selected A for installation.
>>>
>>
>> So C:foo conflicts with B:foo.
> 
> I'm not sure what you mean by C:foo and B:foo.  My intention is that 
> "foo" is an identifier for a single requirement, which can be provided 
> by B or C or both.  I explicitly want to allow both to be installed, so 
> I don't want B and C to conflict with one another.

"A single requirement" is the issue.  B and C both provide foo but the
foo in B and C are different and conflict with one another so which one
is correct to satisfy the package A requirement?

> 
> Here's an example (modeled on what Fedora does): Cygwin has four 
> packages that provide emacs binaries: emacs, emacs-X11, emacs-lucid, and 
> emacs-w32.  Users can install any or all of these if they want to be 
> able to run emacs.  The differences are in the UI.  These packages don't 
> conflict with one another.
> 

How do they overcome the conflict?

> If some other package requires an emacs binary, I would like it to be 
> able to require "emacs-bin".  [This plays the role of "foo" in my test 
> case.]  Then I would like to be able to say that all four emacs packages 
> above provide "emacs-bin".
> 

That's fine but how do an installation of multiple emacs-bin not create
a conflict?

>>> The result was that libsolv simply chose B for installation, and setup 
>>> showed
>>> this in the "Confirm" dialog.  What I expected was that libsolv would 
>>> report a
>>> problem ("A requires foo but no selected or installed packages provide it"),
>>> with two possible solutions ("Install B or C").  Is that expectation 
>>> unreasonable?
>>>
>>
>> Not unreasonable but what happens if B:foo is already installed and
>> C:foo is the required because the functionality is slightly different?
> 
> See above.

You're above didn't answer the question.

-- 
cyg Simple

Re: setup and 'provides:'

[Ken Brown]

On 10/8/2018 10:41 AM, cyg Simple wrote:
> On 10/7/2018 6:02 PM, Ken Brown wrote:
>> I've been experimenting with setup's support for the 'provides:' tag, and 
>> it's
>> not behaving the way I expect [*].  I'm not sure if something in setup's
>> interface with libsolv needs to be tweaked or if I'm just misunderstanding 
>> how
>> this should work.  Here's what I tried:
>>
> 
> Shouldn't there be a need for a 'conflicts:' tag as well?

setup does support a 'conflicts:' tag, but I don't see why I should need 
it here.

>> I created a test repo with packages A, B, and C.  I made A require foo (not a
>> package), and I made B and C provide foo.  The attached script does all this
>> [**].  I then ran setup and selected A for installation.
>>
> 
> So C:foo conflicts with B:foo.

I'm not sure what you mean by C:foo and B:foo.  My intention is that 
"foo" is an identifier for a single requirement, which can be provided 
by B or C or both.  I explicitly want to allow both to be installed, so 
I don't want B and C to conflict with one another.

Here's an example (modeled on what Fedora does): Cygwin has four 
packages that provide emacs binaries: emacs, emacs-X11, emacs-lucid, and 
emacs-w32.  Users can install any or all of these if they want to be 
able to run emacs.  The differences are in the UI.  These packages don't 
conflict with one another.

If some other package requires an emacs binary, I would like it to be 
able to require "emacs-bin".  [This plays the role of "foo" in my test 
case.]  Then I would like to be able to say that all four emacs packages 
above provide "emacs-bin".

>> The result was that libsolv simply chose B for installation, and setup showed
>> this in the "Confirm" dialog.  What I expected was that libsolv would report 
>> a
>> problem ("A requires foo but no selected or installed packages provide it"),
>> with two possible solutions ("Install B or C").  Is that expectation 
>> unreasonable?
>>
> 
> Not unreasonable but what happens if B:foo is already installed and
> C:foo is the required because the functionality is slightly different?

See above.

Ken

Re: setup and 'provides:'

[cyg Simple]

On 10/7/2018 6:02 PM, Ken Brown wrote:
> I've been experimenting with setup's support for the 'provides:' tag, and 
> it's 
> not behaving the way I expect [*].  I'm not sure if something in setup's 
> interface with libsolv needs to be tweaked or if I'm just misunderstanding 
> how 
> this should work.  Here's what I tried:
> 

Shouldn't there be a need for a 'conflicts:' tag as well?

> I created a test repo with packages A, B, and C.  I made A require foo (not a 
> package), and I made B and C provide foo.  The attached script does all this 
> [**].  I then ran setup and selected A for installation.
> 

So C:foo conflicts with B:foo.

> The result was that libsolv simply chose B for installation, and setup showed 
> this in the "Confirm" dialog.  What I expected was that libsolv would report 
> a 
> problem ("A requires foo but no selected or installed packages provide it"), 
> with two possible solutions ("Install B or C").  Is that expectation 
> unreasonable?
> 

Not unreasonable but what happens if B:foo is already installed and
C:foo is the required because the functionality is slightly different?

-- 
cyg Simple

Re: collecting information for versioned dependencies (was Re: setup -g ???)

[Achim Gratz]

Jon Turney writes:
>> The attached cygport patch attempts to address this by requiring,
>> for each dependency of a package, a version >= the version installed
>> at the time the package was built.  It treats only dependencies
>> found by 
>
> Thanks.  This is an interesting approach to automatically collecting
> this information I hadn't considered.

Recording that information is a good thing.  Making these a (hard)
dependency is probably not very helpful.

> Problems are that (i) it makes package builds less reproducible (as
> these dependencies will depend on the currently installed version of
> them, which might well change over time), and (ii) it will tend of
> over-estimate the version required.

Yes.  I'd rather not go there.

> I don't know how these problems are solved in other distros, but
> that's probably worth looking at...

I can only (barely) tell how openSUSE Tumbleweed does it.  The first
part is that the dependencies are using capabilities, not versions
(i.e. required API level) and those requirements are part of the spec
files.  The second part is that the package dependencies are organized
in "rings" so that outer rings can only start building when the inner
ones are finished.  The third part is that the build is fully automated
via OBS, so if anything changes that somebody else depends on, those
builds are automatically triggered.  There is some extensive scripted
and sometimes manual intervention to prevent certain known false
positives from re-building the whole distro.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

collecting information for versioned dependencies (was Re: setup -g ???)

[Jon Turney]

On 02/04/2018 18:03, Ken Brown wrote:
[Redirected to cygwin-apps from 
https://cygwin.com/ml/cygwin/2018-03/msg00365.html.]


On 3/22/2018 6:46 PM, Jon Turney wrote:

[...]


This is basically correct.

setup is now capable of being told about dependencies where upgrading 
an already installed package is required, but this information isn't 
currently collected


(For example, some packages now exist (e.g. vim [1]), which were built 
with gcc 6.4.0-5 and cygport 0.31.0-1.  These packages almost 
certainly use ssp/fortify functions in the cygwin DLL, and so require 
a cygwin package >=2.10.0-1 (technically, the requirement is cygwin 
API >=0.320), but the dependency recorded is only on the cygwin 
package at any version)


(The example given is kind of incomplete, in that we could define an 
additional provides: to record that API version.)


That's something someone could usefully work on, if they were so 
inclined.


The attached cygport patch attempts to address this by requiring, for 
each dependency of a package, a version >= the version installed at the 
time the package was built.  It treats only dependencies found by 


Thanks.  This is an interesting approach to automatically collecting 
this information I hadn't considered.


Problems are that (i) it makes package builds less reproducible (as 
these dependencies will depend on the currently installed version of 
them, which might well change over time), and (ii) it will tend of 
over-estimate the version required.


I don't know how these problems are solved in other distros, but that's 
probably worth looking at...


cygport, not those added via REQUIRES in the cygport file.  My thinking 
is that the cygport user should be in control of added dependencies; 
s/he can add version numbers if desired.


mksetupini would need to be updated to parse versioned dependencies. (Or 
maybe it's expecting a different syntax; I didn't check.)

Re: setup -g ???

[Ken Brown]

On 4/23/2018 4:45 PM, Ken Brown wrote:

On 4/2/2018 1:03 PM, Ken Brown wrote:
[Redirected to cygwin-apps from 
https://cygwin.com/ml/cygwin/2018-03/msg00365.html.]


On 3/22/2018 6:46 PM, Jon Turney wrote:

On 14/03/2018 15:26, David Allsopp wrote:

[reformatted for top-posting]

Lee wrote:

-- Forwarded message --
From: Jon Turney
Date: Fri, 3 Nov 2017 15:26:27 +
Subject: Re: Problem running the latest python2-2.7.14-1 under 
AppVeyor

To: The Cygwin Mailing List 

On 03/11/2017 14:45, Vadim Zeitlin wrote:
Our build has started on AppVeyor, a continuous integration 
provider,
started failing since a couple of days as a makefile command 
running a

Python script started failing with exit code 127 without any more
information. This is a strange situation as I can't reproduce the
problem locally, but something definitely seems to be wrong with 
this

package on the AppVeyor machine as Python just doesn't seem to be
executable, e.g. the output of these commands in our batch file

driving the build:

Perhaps you need to provide the -g (--upgrade-also) flag to cygwin's
setup.

Due to setup terribleness, without this flag, it will install the
requested packages, and any missing dependencies of them, but not
upgrade any of the dependencies which are already installed to the
current (and perhaps needed) version...

See also [1].

[1] https://sourceware.org/ml/cygwin/2017-03/msg00365.html


Should we still be using the -g (--upgrade-also) flag on setup?


I believe so (or at least hope so). I think it's the case that setup 
should now know to upgrade a dependency if you install a new package 
which requires a newer version of it, but I hope that's not become 
the same as setup effectively acting with --upgrade-also every time 
you run it (that would be a real nuisance, unless the entire Cygwin 
package universe is going to be recompiled on every new Cygwin 
release).


This is basically correct.

setup is now capable of being told about dependencies where upgrading 
an already installed package is required, but this information isn't 
currently collected


(For example, some packages now exist (e.g. vim [1]), which were 
built with gcc 6.4.0-5 and cygport 0.31.0-1.  These packages almost 
certainly use ssp/fortify functions in the cygwin DLL, and so require 
a cygwin package >=2.10.0-1 (technically, the requirement is cygwin 
API >=0.320), but the dependency recorded is only on the cygwin 
package at any version)


That's something someone could usefully work on, if they were so 
inclined.


The attached cygport patch attempts to address this by requiring, for 
each dependency of a package, a version >= the version installed at 
the time the package was built.  It treats only dependencies found by 
cygport, not those added via REQUIRES in the cygport file.  My 
thinking is that the cygport user should be in control of added 
dependencies; s/he can add version numbers if desired.


mksetupini would need to be updated to parse versioned dependencies. 
(Or maybe it's expecting a different syntax; I didn't check.)


I finally got around to checking this, and it seems that mksetupini 
already recognizes dependencies with version relations, provided that 
the hint file uses "depends:" instead of "requires:".


I've just sent a patch series that does this, among other things.

Ken

Re: setup: uninstalling an orphaned package

[Jon Turney]

On 27/03/2018 20:04, Ken Brown wrote:

On 3/26/2018 1:55 PM, Ken Brown wrote:
In ChooserPage::applyCommandLinePackageSelection() we have the 
following code:


   bool wanted    = pkg.isManuallyWanted();
   bool deleted   = pkg.isManuallyDeleted();
   bool basemisc  = (pkg.categories.find ("Base") != 
pkg.categories.end ()
  || pkg.categories.find ("Orphaned") != 
pkg.categories.end ());

[...]
   bool reinstall = (wanted  || basemisc) && deleted;

One strange consequence of this is that if the user tries to uninstall 
an orphaned package on the command line, then setup will instead try 
to reinstall it.



[...]


Patch attached.


Applied, thanks.

Re: setup -g ???

[Ken Brown]

On 4/2/2018 1:03 PM, Ken Brown wrote:
[Redirected to cygwin-apps from 
https://cygwin.com/ml/cygwin/2018-03/msg00365.html.]


On 3/22/2018 6:46 PM, Jon Turney wrote:

On 14/03/2018 15:26, David Allsopp wrote:

[reformatted for top-posting]

Lee wrote:

-- Forwarded message --
From: Jon Turney
Date: Fri, 3 Nov 2017 15:26:27 +
Subject: Re: Problem running the latest python2-2.7.14-1 under 
AppVeyor

To: The Cygwin Mailing List 

On 03/11/2017 14:45, Vadim Zeitlin wrote:

Our build has started on AppVeyor, a continuous integration provider,
started failing since a couple of days as a makefile command 
running a

Python script started failing with exit code 127 without any more
information. This is a strange situation as I can't reproduce the
problem locally, but something definitely seems to be wrong with this
package on the AppVeyor machine as Python just doesn't seem to be
executable, e.g. the output of these commands in our batch file

driving the build:

Perhaps you need to provide the -g (--upgrade-also) flag to cygwin's
setup.

Due to setup terribleness, without this flag, it will install the
requested packages, and any missing dependencies of them, but not
upgrade any of the dependencies which are already installed to the
current (and perhaps needed) version...

See also [1].

[1] https://sourceware.org/ml/cygwin/2017-03/msg00365.html


Should we still be using the -g (--upgrade-also) flag on setup?


I believe so (or at least hope so). I think it's the case that setup 
should now know to upgrade a dependency if you install a new package 
which requires a newer version of it, but I hope that's not become 
the same as setup effectively acting with --upgrade-also every time 
you run it (that would be a real nuisance, unless the entire Cygwin 
package universe is going to be recompiled on every new Cygwin release).


This is basically correct.

setup is now capable of being told about dependencies where upgrading 
an already installed package is required, but this information isn't 
currently collected


(For example, some packages now exist (e.g. vim [1]), which were built 
with gcc 6.4.0-5 and cygport 0.31.0-1.  These packages almost 
certainly use ssp/fortify functions in the cygwin DLL, and so require 
a cygwin package >=2.10.0-1 (technically, the requirement is cygwin 
API >=0.320), but the dependency recorded is only on the cygwin 
package at any version)


That's something someone could usefully work on, if they were so 
inclined.


The attached cygport patch attempts to address this by requiring, for 
each dependency of a package, a version >= the version installed at the 
time the package was built.  It treats only dependencies found by 
cygport, not those added via REQUIRES in the cygport file.  My thinking 
is that the cygport user should be in control of added dependencies; 
s/he can add version numbers if desired.


mksetupini would need to be updated to parse versioned dependencies. (Or 
maybe it's expecting a different syntax; I didn't check.)


I finally got around to checking this, and it seems that mksetupini 
already recognizes dependencies with version relations, provided that 
the hint file uses "depends:" instead of "requires:".


Unfortunately, changing cygport to use "depends:" instead of "requires:" 
might confuse maintainers, given that cygport files currently use 
"DEPEND" for build dependencies.


An alternative would be for cygport to start using commas rather than 
spaces to separate dependencies.  mksetupini could then parse 
"requires:" the same way it now parses "depends:" if it finds commas in 
the "requires:" list.


Ken

Re: setup: uninstalling an orphaned package

[Ken Brown]

On 3/26/2018 1:55 PM, Ken Brown wrote:
In ChooserPage::applyCommandLinePackageSelection() we have the following 
code:


   bool wanted    = pkg.isManuallyWanted();
   bool deleted   = pkg.isManuallyDeleted();
   bool basemisc  = (pkg.categories.find ("Base") != 
pkg.categories.end ()
  || pkg.categories.find ("Orphaned") != pkg.categories.end 
());

[...]
   bool reinstall = (wanted  || basemisc) && deleted;

One strange consequence of this is that if the user tries to uninstall 
an orphaned package on the command line, then setup will instead try to 
reinstall it.


This behavior was introduced in the following commit:

commit a667a8b289ccb6e70ec6bf4c70cceeca4d3fb5d3
Author: Corinna Vinschen 
Date:   Thu Jul 25 12:03:49 2013 +

[...]
Uninstalled packages in categories "Base" or "Misc" are always selected 
for installation; installed packages in these categories are not 
eligible for deletion and will be reinstalled or upgraded instead.

[...]

I can't understand the rationale for this.  Did "Misc" (which has since 
been renamed to "Orphaned") used to have a different meaning?


I found it very surprising when I tried to uninstall a bunch of packages 
in unattended mode, and setup failed with download errors because it 
tried to reinstall orphaned packages.


Patch attached.

Ken

From 3a78453fd8a3b5d9734a11b839f13e68c84d1c05 Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Tue, 27 Mar 2018 13:56:27 -0400
Subject: [PATCH setup] Allow command-line uninstallation of specific orphaned
 packages

Also change the implementation of the "--delete-orphans" option to use
the same definition of "orphaned" that's used elsewhere in the code.
---
 choose.cc | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/choose.cc b/choose.cc
index 5a4d3ad..1249efa 100644
--- a/choose.cc
+++ b/choose.cc
@@ -295,13 +295,13 @@ ChooserPage::applyCommandLinePackageSelection()
   packagemeta  = *(i->second);
   bool wanted= pkg.isManuallyWanted();
   bool deleted   = pkg.isManuallyDeleted();
-  bool basemisc  = (pkg.categories.find ("Base") != pkg.categories.end ()
-|| pkg.categories.find ("Orphaned") != pkg.categories.end 
());
-  bool upgrade   = wanted || (!pkg.installed && basemisc);
+  bool base  = pkg.categories.find ("Base") != pkg.categories.end ();
+  bool orphaned  = pkg.categories.find ("Orphaned") != pkg.categories.end 
();
+  bool upgrade   = wanted || (!pkg.installed && base);
   bool install   = wanted  && !deleted && !pkg.installed;
-  bool reinstall = (wanted  || basemisc) && deleted;
-  bool uninstall = (!(wanted  || basemisc) && (deleted || 
PruneInstallOption))
-|| (!pkg.curr && CleanOrphansOption);
+  bool reinstall = (wanted  || base) && deleted;
+  bool uninstall = (!(wanted  || base) && (deleted || PruneInstallOption))
+|| (orphaned && CleanOrphansOption);
   if (install)
pkg.set_action (packagemeta::Install_action, pkg.curr);
   else if (reinstall)
-- 
2.16.2

Re: setup: problems with local install

[Jon Turney]

On 14/03/2018 19:24, Ken Brown wrote:

On 3/14/2018 12:07 PM, Jon Turney wrote:

On 12/03/2018 13:22, Ken Brown wrote:

On 3/8/2018 4:59 PM, Ken Brown wrote:

On 3/8/2018 10:59 AM, Ken Brown wrote:

On 3/7/2018 4:52 PM, Ken Brown wrote:

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for 
install, even if there's no archive available.  As a result, the 
current version will get uninstalled, and then setup will discover 
that it doesn't have the archive to install the new version.


Thanks very much for finding this.

The problem occurs because packagedb::defaultTrust() is called 
after ScanDownloadedFiles() has already done its work. 
solution.update() and solution.trans2db() are called, and 
pkg->desired is set equal to an inaccessible version pv (which has 
been previously removed from pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to 
make sure to ignore the erase transaction for the current version 
of pkg.


Alternatively, can we just remove an inaccessible packageversion 
from the libsolv pool, or at at least just tell libsolv that we 
don't want to install it?


Attached is an attempt at that.

I think this is preferable, if it works correctly, as I think avoiding 
solutions with these unavailable versions is better than trying to 
massage the solution afterwards.


I agree, and it does seem to work correctly.  But there's one other case 
that it doesn't cover:  Suppose there's no archive for the installed 
version.  Even with your patch, the user can still choose 'Reinstall', 
which will fail.  The first of the patches from my previous email fixes 
this case.


Yes.  I applied that as well.

The subtlety I'd failed to grasp when I wrote that comment is that 
ScanDownloadedFiles() prunes versions which aren't available locally, 
*except* if they are already installed.


Thanks.

Re: setup: problems with local install

[Ken Brown]

On 3/14/2018 12:07 PM, Jon Turney wrote:

On 12/03/2018 13:22, Ken Brown wrote:

On 3/8/2018 4:59 PM, Ken Brown wrote:

On 3/8/2018 10:59 AM, Ken Brown wrote:

On 3/7/2018 4:52 PM, Ken Brown wrote:

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() 
would work, or perhaps the attached?  (This doesn't do the right 
thing for a few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages 
with no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
    if (!pkg)
-    return;
+    return true;


So, this needs to be 'return false', as the empty version is 
always inaccessible, to get the same behaviour as before.


I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for 
install, even if there's no archive available.  As a result, the 
current version will get uninstalled, and then setup will discover 
that it doesn't have the archive to install the new version.


Thanks very much for finding this.

The problem occurs because packagedb::defaultTrust() is called 
after ScanDownloadedFiles() has already done its work.  
solution.update() and solution.trans2db() are called, and 
pkg->desired is set equal to an inaccessible version pv (which has 
been previously removed from pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to 
make sure to ignore the erase transaction for the current version 
of pkg.


Alternatively, can we just remove an inaccessible packageversion 
from the libsolv pool, or at at least just tell libsolv that we 
don't want to install it?


Attached is an attempt at that.

I think this is preferable, if it works correctly, as I think avoiding 
solutions with these unavailable versions is better than trying to 
massage the solution afterwards.


I agree, and it does seem to work correctly.  But there's one other case 
that it doesn't cover:  Suppose there's no archive for the installed 
version.  Even with your patch, the user can still choose 'Reinstall', 
which will fail.  The first of the patches from my previous email fixes 
this case.


Ken

Re: setup: problems with local install

[Jon Turney]

On 12/03/2018 13:22, Ken Brown wrote:

On 3/8/2018 4:59 PM, Ken Brown wrote:

On 3/8/2018 10:59 AM, Ken Brown wrote:

On 3/7/2018 4:52 PM, Ken Brown wrote:

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() 
would work, or perhaps the attached?  (This doesn't do the right 
thing for a few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages 
with no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
    if (!pkg)
-    return;
+    return true;


So, this needs to be 'return false', as the empty version is always 
inaccessible, to get the same behaviour as before.


I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for 
install, even if there's no archive available.  As a result, the 
current version will get uninstalled, and then setup will discover 
that it doesn't have the archive to install the new version.


Thanks very much for finding this.

The problem occurs because packagedb::defaultTrust() is called after 
ScanDownloadedFiles() has already done its work.  solution.update() 
and solution.trans2db() are called, and pkg->desired is set equal to 
an inaccessible version pv (which has been previously removed from 
pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to 
make sure to ignore the erase transaction for the current version of 
pkg.


Alternatively, can we just remove an inaccessible packageversion 
from the libsolv pool, or at at least just tell libsolv that we 
don't want to install it?


Attached is an attempt at that.

I think this is preferable, if it works correctly, as I think avoiding 
solutions with these unavailable versions is better than trying to 
massage the solution afterwards.


Still another alternative, and maybe the simplest, is to make sure 
that the chooser never shows a version that is not in pkg->versions. 
packagemeta::set_action (trusts const trust) almost does this, except 
for one useless desired.accessible() call.  So that should be fixed, 
as well as the setting of the initial action.


Sorry for this stream of consciousness series of posts, but I'll stop 
after this one.  I think it's possible that restoring the previous 
meaning of 'accessible()', at least for local installs, might solve 
this problem.


Thanks for the patches.


From 2ec3a89555409b43b35a2d5a8f161c41c1a993d9 Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Wed, 14 Mar 2018 14:52:57 +
Subject: [PATCH setup] Remove packages not found by scan from solver

Remove (not installed) packages not found by scan from solver, as well as
from packagemeta, to avoid solutions including them from being proposed.

Signed-off-by: Jon Turney 
---
 libsolv.cc  | 10 ++
 libsolv.h   |  2 ++
 package_meta.cc |  3 +++
 3 files changed, 15 insertions(+)

diff --git a/libsolv.cc b/libsolv.cc
index 674d576..fc4e5ec 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -304,6 +304,16 @@ SolvableVersion::compareVersions(const SolvableVersion ,
   return pool_evrcmp(pool, evra, evrb, EVRCMP_COMPARE);
 }
 
+void
+SolvableVersion::remove() const
+{
+  if (!id)
+return;
+
+  Solvable *solvable = pool_id2solvable(pool, id);
+  repo_free_solvable(solvable->repo, id, 0);
+}
+
 // ---
 // implements class SolverPool
 //
diff --git a/libsolv.h b/libsolv.h
index fc68895..7bb0be2 100644
--- a/libsolv.h
+++ b/libsolv.h
@@ -88,6 +88,8 @@ class SolvableVersion
   bool operator > (SolvableVersion const &) const;
   bool operator >= (SolvableVersion const &) const;
 
+  void remove() const;
+
  private:
   Id id;
   Pool *pool;
diff --git a/package_meta.cc b/package_meta.cc
index 8a33bcb..7f8110d 100644
--- a/package_meta.cc
+++ b/package_meta.cc
@@ -724,7 +724,10 @@ packagemeta::ScanDownloadedFiles (bool mirror_mode)
pkg.curr = packageversion ();
  if (pkg.exp == *i)
pkg.exp = packageversion ();
+
+ i->remove();
  pkg.versions.erase (i++);
+
  /* For now, leave the source version alone */
}
  else
-- 
2.16.2

Re: setup: problems with local install

[Ken Brown]

On 3/8/2018 4:59 PM, Ken Brown wrote:

On 3/8/2018 10:59 AM, Ken Brown wrote:

On 3/7/2018 4:52 PM, Ken Brown wrote:

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() would 
work, or perhaps the attached?  (This doesn't do the right thing 
for a few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages 
with no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
    if (!pkg)
-    return;
+    return true;


So, this needs to be 'return false', as the empty version is always 
inaccessible, to get the same behaviour as before.


I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for 
install, even if there's no archive available.  As a result, the 
current version will get uninstalled, and then setup will discover 
that it doesn't have the archive to install the new version.


The problem occurs because packagedb::defaultTrust() is called after 
ScanDownloadedFiles() has already done its work.  solution.update() 
and solution.trans2db() are called, and pkg->desired is set equal to 
an inaccessible version pv (which has been previously removed from 
pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to 
make sure to ignore the erase transaction for the current version of 
pkg.


Alternatively, can we just remove an inaccessible packageversion from 
the libsolv pool, or at at least just tell libsolv that we don't want 
to install it?


Still another alternative, and maybe the simplest, is to make sure 
that the chooser never shows a version that is not in pkg->versions. 
packagemeta::set_action (trusts const trust) almost does this, except 
for one useless desired.accessible() call.  So that should be fixed, 
as well as the setting of the initial action.


Sorry for this stream of consciousness series of posts, but I'll stop 
after this one.  I think it's possible that restoring the previous 
meaning of 'accessible()', at least for local installs, might solve this 
problem.


Patches attached (for the topic/fix-local-install branch).

From 1645f2b13616ec71054a5ad35bce864f1f3e0dca Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Sun, 11 Mar 2018 10:43:06 -0400
Subject: [PATCH 1/2] Make SolvableVersion::accessible() useful for local
 installs

For a local install, make SolvableVersion::accessible() indicate
whether or not there is an archive available in the local cache.  This
is used in packagemeta::set_action() to prevent the chooser from
offering unavailable versions.
---
 libsolv.cc | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/libsolv.cc b/libsolv.cc
index 0dc7557..604ff7e 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -14,6 +14,7 @@
 #include "libsolv.h"
 #include "package_db.h"
 #include "package_meta.h"
+#include "resource.h"
 
 #include "solv/solver.h"
 #include "solv/solverdebug.h"
@@ -239,21 +240,16 @@ SolvableVersion::source() const
   return (packagesource *)repo_lookup_num(solvable->repo, id, psrc_attr, 
(unsigned long long)_source);
 }
 
+// If we're doing a locall install, is there an archive available?
+// This assumes that ScanDownloadedFiles() has already been called.
 bool
 SolvableVersion::accessible () const
 {
-  // The 'accessible' check used to test if an archive was available locally or
-  // from a mirror.
-  //
-  // This seems utterly pointless. as binary packages which aren't 'accessible'
-  // never get to appear in the package list.
-  //
-  // For source packages, it's equivalent to the bool conversion operator.)
-  //
-  if (id != 0)
-return TRUE;
-  else
-return FALSE;
+  if (id == 0)
+return false;
+  if (::source == IDC_SOURCE_LOCALDIR)
+return source ()->Cached ();
+  return true;
 }
 
 package_stability_t
-- 
2.16.2

From 365fa9afb8a49c2360bf7cfd2a2c2557522f85e5 Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Mon, 12 Mar 2018 09:13:41 -0400
Subject: [PATCH 2/2] Don't put inaccessible packageversions in the package
 database

In a local install, libsolv might choose an inaccessible version for
install.  Change SolverSolution::trans2db() so that such a version is
never used.
---
 libsolv.cc | 12 
 1 file changed, 12 insertions(+)

diff --git a/libsolv.cc b/libsolv.cc
index 604ff7e..1342f3b 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -637,6 +637,8 @@ void
 SolverSolution::trans2db() const
 {
   packagedb db;
+  std::vector inaccessible;
+
   // First reset all packages to the "no change" state
   for (packagedb::packagecollection::iterator i = db.packages.begin();
i != db.packages.end(); i++)
@@ -667,6 

Re: setup: problems with local install

[Ken Brown]

On 3/8/2018 10:59 AM, Ken Brown wrote:

On 3/7/2018 4:52 PM, Ken Brown wrote:

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() would 
work, or perhaps the attached?  (This doesn't do the right thing for 
a few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages 
with no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
    if (!pkg)
-    return;
+    return true;


So, this needs to be 'return false', as the empty version is always 
inaccessible, to get the same behaviour as before.


I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for 
install, even if there's no archive available.  As a result, the 
current version will get uninstalled, and then setup will discover 
that it doesn't have the archive to install the new version.


The problem occurs because packagedb::defaultTrust() is called after 
ScanDownloadedFiles() has already done its work.  solution.update() 
and solution.trans2db() are called, and pkg->desired is set equal to 
an inaccessible version pv (which has been previously removed from 
pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to 
make sure to ignore the erase transaction for the current version of pkg.


Alternatively, can we just remove an inaccessible packageversion from 
the libsolv pool, or at at least just tell libsolv that we don't want 
to install it?


Still another alternative, and maybe the simplest, is to make sure that 
the chooser never shows a version that is not in pkg->versions. 
packagemeta::set_action (trusts const trust) almost does this, except 
for one useless desired.accessible() call.  So that should be fixed, as 
well as the setting of the initial action.


Sorry for this stream of consciousness series of posts, but I'll stop 
after this one.  I think it's possible that restoring the previous 
meaning of 'accessible()', at least for local installs, might solve this 
problem.


Ken

Re: setup: problems with local install

[Ken Brown]

On 3/7/2018 4:52 PM, Ken Brown wrote:

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() would 
work, or perhaps the attached?  (This doesn't do the right thing for 
a few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages 
with no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
    if (!pkg)
-    return;
+    return true;


So, this needs to be 'return false', as the empty version is always 
inaccessible, to get the same behaviour as before.


I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for install, 
even if there's no archive available.  As a result, the current version 
will get uninstalled, and then setup will discover that it doesn't have 
the archive to install the new version.


The problem occurs because packagedb::defaultTrust() is called after 
ScanDownloadedFiles() has already done its work.  solution.update() and 
solution.trans2db() are called, and pkg->desired is set equal to an 
inaccessible version pv (which has been previously removed from 
pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to make 
sure to ignore the erase transaction for the current version of pkg.


Alternatively, can we just remove an inaccessible packageversion from 
the libsolv pool, or at at least just tell libsolv that we don't want to 
install it?


Still another alternative, and maybe the simplest, is to make sure that 
the chooser never shows a version that is not in pkg->versions. 
packagemeta::set_action (trusts const trust) almost does this, except 
for one useless desired.accessible() call.  So that should be fixed, as 
well as the setting of the initial action.


Ken

Re: setup: problems with local install

[Ken Brown]

On 3/6/2018 1:47 PM, Jon Turney wrote:

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() would 
work, or perhaps the attached?  (This doesn't do the right thing for a 
few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages with 
no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
    if (!pkg)
-    return;
+    return true;


So, this needs to be 'return false', as the empty version is always 
inaccessible, to get the same behaviour as before.


I've found another problem with local installs: If a package needs 
upgrading, then the chooser will offer the upgraded version for install, 
even if there's no archive available.  As a result, the current version 
will get uninstalled, and then setup will discover that it doesn't have 
the archive to install the new version.


The problem occurs because packagedb::defaultTrust() is called after 
ScanDownloadedFiles() has already done its work.  solution.update() and 
solution.trans2db() are called, and pkg->desired is set equal to an 
inaccessible version pv (which has been previously removed from 
pkg->versions).


I guess trans2db() should check that pv is in pkg->versions before 
acting on an install transaction for pv.  And then we also have to make 
sure to ignore the erase transaction for the current version of pkg.


Alternatively, can we just remove an inaccessible packageversion from 
the libsolv pool, or at at least just tell libsolv that we don't want to 
install it?


Ken

Re: setup: problems with local install

[Achim Gratz]

Ken Brown writes:
> I think this one might be OK.  If I'm not mistaken,
> pkg.versions.erase(i++) passes a copy of i to erase, and then
> increments i before erase() has done its work.  But I'm no expert on
> this.

I can't cite chapter and verse right now, but AFAIK iterators over sets
are explicitly OK'ed for deleting the current element of the set
iterated over (that may be restricted to not changing direction of
iteration depending on which version of the standard the implementation
conforms to).


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

Re: setup: problems with local install

[Jon Turney]

On 06/03/2018 19:31, Ken Brown wrote:

On 3/6/2018 10:18 AM, Jon Turney wrote:
(I also note we have also have another 'erase an element from a vector 
while we are iterating over it' here, so that needs fixing, as well)


I think this one might be OK.  If I'm not mistaken, 
pkg.versions.erase(i++) passes a copy of i to erase, and then increments 
i before erase() has done its work.  But I'm no expert on this.


I think that's still not ok for a vector, but this is actually a set, so 
there's actually no problem.


See e.g. [1], or refer to your copy of the C++ standard :)

[1] https://stackoverflow.com/questions/6438086/iterator-invalidation-rules

Re: setup: problems with local install

[Ken Brown]

On 3/6/2018 10:18 AM, Jon Turney wrote:
(I also note we have also have another 'erase an element from a vector 
while we are iterating over it' here, so that needs fixing, as well)


I think this one might be OK.  If I'm not mistaken, 
pkg.versions.erase(i++) passes a copy of i to erase, and then increments 
i before erase() has done its work.  But I'm no expert on this.


Ken

Re: setup: problems with local install

[Jon Turney]

On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible() would 
work, or perhaps the attached?  (This doesn't do the right thing for a 
few packages, for reasons I'm still looking into...)


To be specific it was doing the wrong thing for those few packages with 
no source



  /* scan for local copies of package */
-void
+bool
  packagemeta::scan (const packageversion , bool mirror_mode)
  {
-  /* Already have something */
+  /* empty version */
if (!pkg)
-return;
+return true;


So, this needs to be 'return false', as the empty version is always 
inaccessible, to get the same behaviour as before.

Re: setup: problems with local install

[Jon Turney]

On 06/03/2018 02:18, Ken Brown wrote:

On 3/5/2018 1:34 PM, Ken Brown wrote:

This is a followup to the thread started here:

   https://cygwin.com/ml/cygwin/2018-03/msg00027.html

There are two problems with installing from a local directory.

1. In the Category view, "No packages found" is displayed where it 
should say "All" in the first line of the list.  This is probably just 
a cosmetic issue, and I haven't tried to track it down yet.


This actually happens in all setup runs, not just local installs.  It 
looks like it was caused by the rearranging that was done in the 
following commit:


commit 0c539f7f7d86fb100f260f21367682fa2c0bb529
Author: Jon Turney 
Date:   Sat Nov 4 18:01:49 2017 +

     Correctly order preparing packagedb for chooser

I think the problem might be that createListview() is now called too 
early in ChooserPage::OnInit().  But it's not immediately obvious to me 
how to fix this without breaking something else.
I'm kind of inclined to fix this with the attached: I think we only ever 
got "No packages found" before if there were 0 packages, which 
presumably doesn't happen very often :)


We don't update this header if a search reduces the number of packages 
shown to 0, which might make some sort of sense.


(Also, weirdly, we don't remove empty categories from view, except if we 
are doing a search, but this seems to be deliberate? (PickView.cc:311))
From 1a0cf0a86088b4aae7d5a18953f7c214b07d8a03 Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Tue, 6 Mar 2018 16:17:30 +
Subject: [PATCH setup] Always give the fake root category the name 'All'

After we rearranged things in 0c539f7f, it's now too early to tell if we
have any packages or not.

The only thing about this category that is ever used is it's name, so we
don't acually need to use the real 'All' category here.

Saying 'No packages found' was never particularly helpful here, so just use
a fake category with the fixed name 'All'.
---
 choose.cc | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/choose.cc b/choose.cc
index 9cf3a50..5a4d3ad 100644
--- a/choose.cc
+++ b/choose.cc
@@ -137,11 +137,8 @@ ChooserPage::createListview ()
 {
   SetBusy ();
   static std::vector empty_cat;
-  static Category dummy_cat (std::string ("No packages found."), empty_cat);
-  packagedb db;
-  packagedb::categoriesType::iterator it = db.categories.find("All");
-  Category  = (it == db.categories.end ()) ? dummy_cat : *it;
-  chooser = new PickView (cat);
+  static Category dummy_cat (std::string ("All"), empty_cat);
+  chooser = new PickView (dummy_cat);
   RECT r = getDefaultListViewSize();
   if (!chooser->Create(this, WS_CHILD | WS_HSCROLL | WS_VSCROLL | 
WS_VISIBLE,))
 throw new Exception (TOSTRING(__LINE__) " " __FILE__,
-- 
2.16.2

Re: setup: problems with local install

[Jon Turney]

On 05/03/2018 18:34, Ken Brown wrote:

This is a followup to the thread started here:

   https://cygwin.com/ml/cygwin/2018-03/msg00027.html

There are two problems with installing from a local directory.


Thanks very much for looking into these.

2. In several of the views, all packages from setup.ini are listed, even 
if there is no corresponding archive in the local directory.  What 
happens is that packagemeta::scan() calls pkg.source()->sites.clear() 
for such packages, but this information is never used to prevent the 
package from appearing in the list.


It used to be that such packages would be declared inaccessible, but 
SolvableVersion::accessible() no longer does this.


Jon, you wrote the following comment in the definition of 
SolvableVersion::accessible():


"The 'accessible' check used to test if an archive was available locally 
or from a mirror.  This seems utterly pointless as binary packages which 
aren't 'accessible' never get to appear in the package list."


Do we need to reinstate the old function of the accessibility check?


I guess I looked at packagemeta::ScanDownloadedFiles() and saw that it 
was removing versions, and thought everything was good.


I didn't notice accessible() was indirectly how the result of scan() was 
returned :S


So yeah, I guess putting some complexity back in accessible() would 
work, or perhaps the attached?  (This doesn't do the right thing for a 
few packages, for reasons I'm still looking into...)


(I also note we have also have another 'erase an element from a vector 
while we are iterating over it' here, so that needs fixing, as well)


I'm kind of uncertain what the side-effects of this code are when source 
!= IDC_SOURCE_LOCALDIR, or if they are desired?  Perhaps it's removing 
packages which have corrupt local copies or something?  It would be 
clearer to omit the whole thing in that case.


From d8aac08cf3d1ddf98ab9a6a8706b2c7b8bdfd7ad Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Tue, 6 Mar 2018 14:56:40 +
Subject: [PATCH setup] Fix packagemeta::ScanDownloadedFiles

packagemeta::scan clears the site list if the package was not found, and
packagemeta::ScanDownloadedFiles uses packageversion::accessible() to check
that.

Instead communicate via a return value
---
 package_meta.cc | 27 ---
 package_meta.h  |  2 +-
 2 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/package_meta.cc b/package_meta.cc
index c488e35..f0a0c20 100644
--- a/package_meta.cc
+++ b/package_meta.cc
@@ -664,33 +664,30 @@ packagemeta::logSelectionStatus() const
 }
 
 /* scan for local copies of package */
-void
+bool
 packagemeta::scan (const packageversion , bool mirror_mode)
 {
-  /* Already have something */
+  /* empty version */
   if (!pkg)
-return;
+return true;
 
-  /* Remove mirror sites.
-   * FIXME: This is a bit of a hack.
-   */
   try
 {
   if (!check_for_cached (*(pkg.source ()), NULL, mirror_mode, false)
- && ::source == IDC_SOURCE_LOCALDIR)
-   pkg.source ()->sites.clear ();
+  && ::source == IDC_SOURCE_LOCALDIR)
+return false;
 }
   catch (Exception * e)
 {
   // We can ignore these, since we're clearing the source list anyway
   if (e->errNo () == APPERR_CORRUPT_PACKAGE)
-   {
- pkg.source ()->sites.clear ();
- return;
-   }
+return false;
+
   // Unexpected exception.
   throw e;
 }
+
+  return true;
 }
 
 void
@@ -712,15 +709,15 @@ packagemeta::ScanDownloadedFiles (bool mirror_mode)
   && (*i != pkg.installed
   || pkg.installed == pkg.curr
   || pkg.installed == pkg.exp);
- scan (*i, lazy_scan);
+ bool accessible = scan (*i, lazy_scan);
  packageversion foo = *i;
  packageversion pkgsrcver = foo.sourcePackage ();
- scan (pkgsrcver, lazy_scan);
+ bool src_accessible = scan (pkgsrcver, lazy_scan);
 
  /* For local installs, if there is no src and no bin, the version
   * is unavailable
   */
- if (!i->accessible () && !pkgsrcver.accessible ()
+ if (!accessible && !src_accessible
  && *i != pkg.installed)
{
  if (pkg.curr == *i)
diff --git a/package_meta.h b/package_meta.h
index 32372e2..600a163 100644
--- a/package_meta.h
+++ b/package_meta.h
@@ -170,7 +170,7 @@ protected:
 private:
   std::string trustLabel(packageversion const &) const;
   std::vector 

Re: setup: problems with local install

[Ken Brown]

On 3/5/2018 1:34 PM, Ken Brown wrote:

This is a followup to the thread started here:

   https://cygwin.com/ml/cygwin/2018-03/msg00027.html

There are two problems with installing from a local directory.

1. In the Category view, "No packages found" is displayed where it 
should say "All" in the first line of the list.  This is probably just a 
cosmetic issue, and I haven't tried to track it down yet.


This actually happens in all setup runs, not just local installs.  It 
looks like it was caused by the rearranging that was done in the 
following commit:


commit 0c539f7f7d86fb100f260f21367682fa2c0bb529
Author: Jon Turney 
Date:   Sat Nov 4 18:01:49 2017 +

Correctly order preparing packagedb for chooser

I think the problem might be that createListview() is now called too 
early in ChooserPage::OnInit().  But it's not immediately obvious to me 
how to fix this without breaking something else.


Ken

Re: setup 2.888 crashes on --prune-install

[Jon Turney]

On 24/02/2018 14:58, Jon Turney wrote:

On 20/02/2018 18:33, Andrew Schulman wrote:




[...]

Problem 1/97


!


Augmented Transaction List:
    0   erase    base 0.0-0


!!

Yeah, that's not working right... :(

I fixed the crash problem in 2.889, but there's other things wrong here: 
for starters, the default solution we are picking aren't the best.


Attached is a patch which tries to improve the default solution 
selection (although this could be still better, and of course a UI to 
actually let solutions be chosen would also be good)


From f6903b67f3728f9c77eb4a2942fe3eb7268737f2 Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Wed, 21 Feb 2018 16:28:48 +
Subject: [PATCH setup] Improve default solution selection

Pick a solution which looks like it removes non-lock tasks from the task
list.  This kind of works because lock tasks are usually created from a
default keep choice, rather than from an explicit selection, although really
we need to track somehow if the task was created from a user choice and use
that as the criteria here...
---
 libsolv.cc | 37 ++---
 libsolv.h  |  1 +
 2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/libsolv.cc b/libsolv.cc
index 32d60e6..140ace9 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -922,8 +922,8 @@ void SolverSolution::applyDefaultProblemSolutions()
   int pcnt = solver_problem_count(solv);
   for (Id problem = 1; problem <= pcnt; problem++)
 {
-  int scnt = solver_solution_count(solv, problem);
-  solver_take_solution(solv, problem, scnt, );
+  int default_soln = guessDefaultSolution(problem);
+  solver_take_solution(solv, problem, default_soln, );
 }
 
   // re-solve
@@ -937,6 +937,36 @@ SolverSolution::transactions() const
   return trans;
 }
 
+// pick a default solution
+Id SolverSolution::guessDefaultSolution(Id problem) const
+{
+  int scnt = solver_solution_count(solv, problem);
+
+  // search backwards for the first solution which only consists of
+  // SOLVER_SOLUTION_JOB solution elements pointing to SOLVER_INSTALL or
+  // SOLVER_ERASE jobs (i.e. only removes install or erase tasks from task 
list)
+  for (Id solution = scnt; solution > 0; solution--)
+{
+  Id p, rp, element;
+  element = 0;
+  while ((element = solver_next_solutionelement(solv, problem, solution, 
element, , )) != 0)
+{
+  if (p != SOLVER_SOLUTION_JOB)
+break;
+
+  Id j = job.elements[rp-1] & SOLVER_JOBMASK;
+  if (!(j == SOLVER_INSTALL || j == SOLVER_ERASE))
+break;
+}
+
+  if (element == 0)
+return solution;
+}
+
+  // failing that, pick the last solution
+  return scnt;
+}
+
 // Construct a string reporting the problems and solutions
 std::string
 SolverSolution::report() const
@@ -959,10 +989,11 @@ SolverSolution::report() const
   r += "\n";
 
   int scnt = solver_solution_count(solv, problem);
+  Id default_soln_id = guessDefaultSolution(problem);
   for (Id solution = 1; solution <= scnt; solution++)
 {
   r += "Solution " + std::to_string(solution) + "/" + 
std::to_string(scnt);
-  if (solution == scnt) r += " (default)";
+  if (solution == default_soln_id) r += " (default)";
   r += "\n";
 
   Id p, rp, element;
diff --git a/libsolv.h b/libsolv.h
index 6a6e0b3..3066fea 100644
--- a/libsolv.h
+++ b/libsolv.h
@@ -266,6 +266,7 @@ class SolverSolution
   bool solve();
   void tasksToJobs(SolverTasks , updateMode update, Queue );
   void solutionToTransactionList();
+  Id guessDefaultSolution(Id problem) const;
 
   SolverPool 
   Solver *solv;
-- 
2.16.2

Re: setup 2.888 crashes on --prune-install

[Jon Turney]

On 20/02/2018 18:33, Andrew Schulman wrote:

When I run setup-x86_64.exe or setup-x86.exe with --prune-install as shown
below, it crashes. An error dialog pops up saying "setup-x86.exe has
stopped working". No other debug information appears on the console - the
whole session is shown below.

When I run the same command without --prune-install, it completes normally.

Poor setup seems to be having trouble solving all of the dependencies. Not
surprising, as my installation is old and crufty. Of course that's what I
was hoping --prune-install would help to dig me out of.



Thanks for reporting this problem.


c:\Users\x\Downloads\utilities\cygwin32>setup-x86.exe --no-shortcuts
--quiet-mode --prune-install --packages
atool,autoconf,automake,autossh,bc,bind-utils,byacc,bzr,curl,cygport,discus,dos2unix,doxygen,emacs,file,fish,flexdll,gcc-core,gcc-g++,gettext-devel,git,gnupg2,gsl-devel,help2man,lftp,libargp,libargp-devel,libcrypt-devel,libgd-devel,libiconv,libintl-devel,libncurses-devel,libneon-devel,libpcre2-devel,libpng-devel,libreadline-devel,libwrap-devel,libX11-devel,links,lndir,m4,make,multitail,ncurses,nosleep,ocaml,ocaml-camlp4,openssh,openssl-devel,orpie,p7zip,par2,patch,patchutils,pdftk,perl,pinentry,pinfo,pkg-config,procps-ng,psmisc,readline,rebase,robodoc,rsync,screen,sitecopy,sng,socat,stow,stunnel,time,tree,unison2.27,unison2.32,unison2.40,unison2.45,unison2.48,unison2.49,unison2.51,util-linux,wget,zip,


[...]

Problem 1/97


!


Augmented Transaction List:
0   erasebase 0.0-0


!!

Yeah, that's not working right... :(

I fixed the crash problem in 2.889, but there's other things wrong here: 
for starters, the default solution we are picking aren't the best.

Re: setup 2.888 crashes on --prune-install

[Andrew Schulman]

> Andrew Schulman writes:
> > When I run setup-x86_64.exe or setup-x86.exe with --prune-install as shown
> > below, it crashes. An error dialog pops up saying "setup-x86.exe has
> > stopped working". No other debug information appears on the console - the
> > whole session is shown below.
> 
> That option, as I originally implemented it, should actually leave your
> system exactly with those packages requested, without diving into
> dependencies.  In other words, that list should be self-contained, like
> you'd get from copying an existing installation from a different
> machine.  From what you were saying I guess that you rather want to use
> --delete-orphans.

Thanks. Yes, --delete-orphans is what I wanted.

And sadly I just found out that pdftk is gone :(

Andrew

Re: setup 2.888 crashes on --prune-install

[Achim Gratz]

Andrew Schulman writes:
> When I run setup-x86_64.exe or setup-x86.exe with --prune-install as shown
> below, it crashes. An error dialog pops up saying "setup-x86.exe has
> stopped working". No other debug information appears on the console - the
> whole session is shown below.

That option, as I originally implemented it, should actually leave your
system exactly with those packages requested, without diving into
dependencies.  In other words, that list should be self-contained, like
you'd get from copying an existing installation from a different
machine.  From what you were saying I guess that you rather want to use
--delete-orphans.


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

Re: setup 2.887 release candidate - please test

[Jon Turney]

On 14/02/2018 23:02, Ken Brown wrote:

On 2/6/2018 10:04 AM, Jon Turney wrote:


A new setup release candidate is available at:

   https://cygwin.com/setup/setup-2.887.x86_64.exe (64 bit version)
   https://cygwin.com/setup/setup-2.887.x86.exe    (32 bit version)

Please test and report any problems here.


This crashes in ConfirmPage::OnActivate() if a source package is being 
installed.  The problem is that 'pkg' is null, but it is dereferenced in 
confirm.cc:99.  The attached patch fixes this in the laziest possible 
way, but I'm not sure it's the best fix.  Maybe we should check whether 
'pkg' is NULL (both times it's defined) and throw an exception if so 
unless we're installing a source package.


Alternatively, maybe we should just make sure it's non-NULL (both times) 
before dereferencing it.  After all, we're only using 'pkg' to decide 
whether to say "automatically added", so if it's NULL, it might not be 
worth worrying about why.


Thanks. I also came across this, but you beat me to sending a patch :)

Re: setup 2.887 release candidate - please test

[Ken Brown]

On 2/6/2018 10:04 AM, Jon Turney wrote:


A new setup release candidate is available at:

   https://cygwin.com/setup/setup-2.887.x86_64.exe (64 bit version)
   https://cygwin.com/setup/setup-2.887.x86.exe    (32 bit version)

Please test and report any problems here.


This crashes in ConfirmPage::OnActivate() if a source package is being 
installed.  The problem is that 'pkg' is null, but it is dereferenced in 
confirm.cc:99.  The attached patch fixes this in the laziest possible 
way, but I'm not sure it's the best fix.  Maybe we should check whether 
'pkg' is NULL (both times it's defined) and throw an exception if so 
unless we're installing a source package.


Alternatively, maybe we should just make sure it's non-NULL (both times) 
before dereferencing it.  After all, we're only using 'pkg' to decide 
whether to say "automatically added", so if it's NULL, it might not be 
worth worrying about why.


Ken

From c860c1ce6045d6c42f0207f5977a269cbf48c53e Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Wed, 14 Feb 2018 17:48:44 -0500
Subject: [PATCH] Avoid crash if a source package is installed

If a source package is installed, setup crashed in
ConfirmPage::OnActivate() when a null pointer 'pkg' was dereferenced.
Check that it is non-NULL before dereferencing.
---
 confirm.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/confirm.cc b/confirm.cc
index 7e949d8..df9b4f9 100644
--- a/confirm.cc
+++ b/confirm.cc
@@ -96,7 +96,7 @@ ConfirmPage::OnActivate()
 s += i->version.Name();
 s += " ";
 s += i->version.Canonical_version();
-if (!pkg->desired)
+if (pkg && !pkg->desired)
   s += " (automatically added)";
 s += "\r\n";
   }
-- 
2.16.1

Re: setup 2.886 release candidate - please test

[Achim Gratz]

Jon Turney writes:
>>> Which I can easily believe happens, due to the rather weird way that
>>> the data from a parser reduction is transferred into the package
>>> database.
>
> Can you test the attached patch, please?

Thanks, this works for the last package problem, although I can't
account for all the possible corner cases that may exist elsewhere.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: setup 2.886 release candidate - please test

[Jon Turney]

On 02/02/2018 19:38, Achim Gratz wrote:

Jon Turney writes:

Do you have an idea yet why the last package gets orphaned (or did, if


'Yet'?  This is the first time I've heard of this!


Right you are.  I thought I had mentioned it already, but forgot since I
can't post from work.


Is this regression?


Yes.


it's already fixed)?  I will need to remove my workaround of placing an
empty dummy at the end to try.


I guess you are saying that the last package listed in setup.ini
appears as orphaned, when you have a re-written setup.ini which only
contains one version per package?


I've tested that again today.  The last package gets orphaned if there
is only a current section.  I believe that the last section is also not
processed, so in the standard Cygwin installation you'd not be able to
see the previous version of _update-info-dir.


Which I can easily believe happens, due to the rather weird way that
the data from a parser reduction is transferred into the package
database.


Can you test the attached patch, please?

From 467a8839a34b6bc7e88ad181bb5c4b089f297d47 Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Fri, 2 Feb 2018 19:41:58 +
Subject: [PATCH setup] Make sure we process the last version description in
 setup.ini

---
 IniDBBuilderPackage.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/IniDBBuilderPackage.cc b/IniDBBuilderPackage.cc
index 4169634..8fa6ad9 100644
--- a/IniDBBuilderPackage.cc
+++ b/IniDBBuilderPackage.cc
@@ -36,6 +36,7 @@ currentSpec (0), _feedback (aFeedback){}
 
 IniDBBuilderPackage::~IniDBBuilderPackage()
 {
+  process();
 }
 
 void
-- 
2.16.1

Re: setup 2.886 release candidate - please test

[Achim Gratz]

Jon Turney writes:
>> Do you have an idea yet why the last package gets orphaned (or did, if
>
> 'Yet'?  This is the first time I've heard of this!

Right you are.  I thought I had mentioned it already, but forgot since I
can't post from work.

> Is this regression?

Yes.

>> it's already fixed)?  I will need to remove my workaround of placing an
>> empty dummy at the end to try.
>
> I guess you are saying that the last package listed in setup.ini
> appears as orphaned, when you have a re-written setup.ini which only
> contains one version per package?

I've tested that again today.  The last package gets orphaned if there
is only a current section.  I believe that the last section is also not
processed, so in the standard Cygwin installation you'd not be able to
see the previous version of _update-info-dir.

> Which I can easily believe happens, due to the rather weird way that
> the data from a parser reduction is transferred into the package
> database.

All my packages only have a single (curr) version in the rewritten
setup.ini as I have different setup.ini files (or rather directories
they are in) for keeping older states of the installation around.  Some
of the processing seems to be associated with seeing the start of a new
package or a new section as I can make it process the last package
correctly if I either start a dummy package with absolutely no content
(just the "@ packagename" line) or a dummy section (either [prev] or
[test] works, again with no content).



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: setup 2.886 release candidate - please test

[Jon Turney]

On 01/02/2018 20:21, Achim Gratz wrote:

Jon Turney writes:

A new setup release candidate is available at:

   https://cygwin.com/setup/setup-2.886.x86.exe(32 bit version)
   https://cygwin.com/setup/setup-2.886.x86_64.exe (64 bit version)


Locally compiled, but not well tested yet.


Changes compared to 2.885:
- Apply default problem solutions in unattended mode
- Make --include-source work correctly in unattended mode
- Allow parser to accept an empty depends: list (2.885 (only) will
report syntax errors when parsing setup.ini containing these, when the
corresponding change to calm is deployed)


Do you have an idea yet why the last package gets orphaned (or did, if


'Yet'?  This is the first time I've heard of this!

Is this regression?


it's already fixed)?  I will need to remove my workaround of placing an
empty dummy at the end to try.


I guess you are saying that the last package listed in setup.ini appears 
as orphaned, when you have a re-written setup.ini which only contains 
one version per package?


Which I can easily believe happens, due to the rather weird way that the 
data from a parser reduction is transferred into the package database.

Re: setup 2.886 release candidate - please test

[Achim Gratz]

Jon Turney writes:
> A new setup release candidate is available at:
>
>   https://cygwin.com/setup/setup-2.886.x86.exe(32 bit version)
>   https://cygwin.com/setup/setup-2.886.x86_64.exe (64 bit version)

Locally compiled, but not well tested yet.

> Changes compared to 2.885:
> - Apply default problem solutions in unattended mode
> - Make --include-source work correctly in unattended mode
> - Allow parser to accept an empty depends: list (2.885 (only) will
> report syntax errors when parsing setup.ini containing these, when the
> corresponding change to calm is deployed)

Do you have an idea yet why the last package gets orphaned (or did, if
it's already fixed)?  I will need to remove my workaround of placing an
empty dummy at the end to try.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: setup 2.885 release candidate - please test

[Jon Turney]

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

[Jon Turney]

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...

Re: setup 2.885 release candidate - please test

[Achim Gratz]

Jon Turney writes:
> Sure. I uploaded calm-20180130-1.

Thanks.  Maybe I will actually do another update rollout this week,
then.

> I really need to automate that as part of the deploy :)

One step after the other.  :-)

> Yeah, I think we are reversing the order given by the solver.  This
> should be benign, as we do all the uninstalls before installs.

OK, so let's see what blows up when I hit the red button tomorrow.
It'll be my own 32bit installation first, followed by the 64bit one and
then if I still live I'll update the Cygwin server.  If that works I'll
roll out for my users and duck for cover.

> I'll fix that :)

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: setup 2.885 release candidate - please test

[Jon Turney]

On 30/01/2018 18:49, Achim Gratz wrote:

Achim Gratz writes:

- 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]?


…and of course these are a result of the latest officially available
calm version not having those changes, so my local packages are still
using requires: lines.  Any chance you could relese a new calm version?


Sure. I uploaded calm-20180130-1.

I really need to automate that as part of the deploy :)


Other than that I think I've fixed up my setup rewriter so it can deal
with the new format correctly now and I've even managed to implement
explicit version pinning (which I had on TODO for almost three years,
but since before I've only had test, curr and prev for testing I've put
it up each time I looked at it).

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 :)

Re: setup 2.885 release candidate - please test

[Jon Turney]

On 29/01/2018 19:19, Achim Gratz wrote:

Jon Turney writes:

Since this contains many internal changes, I think this could use some
wider testing before being deployed. Please test and report any
problems here.


I've built these myself, but I don't think that changes anything below.


Thanks for taking a look.


User visible changes:
- 'Current' is replaced by 'Best' (which is slightly different in ways
it's difficult to summarize briefly) and 'Sync' (which exposes the
--force-current option through the UI).  These are modified by a
'Test' checkbox, which allows test packages to be used.


I am always running setup with options to install a selected category w/
orphan removal and removal of non-selected packages.  The selected
category comprises _all_ packages that are supposed to be installed, so
no dependencies need to be found.

In order to see what's going on I also selected chooser mode (the normal
install just does whatever it's told to do).  That still works
apparently, but whenever I click anywhere to change the mode from "Best"
to something else and then back the transaction list gets emptied.  As I
said, I normally don't do this and clicking on those buttons serves no
useful purpose for me in that situation, but I think the result is still
wrong.  I think that maybe the command line parameters are forgotten
when doing this.


I think this is the behaviour in previous versions, as well.

When command line and UI settings are in conflict, I don't think it's 
unreasonable that the last one changed wins.



- 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.



- 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)



I don't like the syntax with the commas, could we just drop the space
between the package name and the paren for the version expression and
keep the version-relations separated by plain whitespace?


- Add support for 'obsoletes:' in setup.ini, likewise


These don't appear to be produced by calm yet.  Also, it would be useful


calm can write these lines, if obsoletes: is present in the .hint, but 
cygport is not yet capable of generating those.



if the obsoleted package showed the replacement package more explicitly,
so maybe "obsoleted-by:" instead of requires:/depends2:


- Add support for 'replace-versions:' in a package section setup.ini,
to indicate problematic versions.


Any examples for this yet?


A separate email on this is in the works.


As you surely know, all the new syntax is not yet described in
https://sourceware.org/cygwin-apps/setup.ini.html


Thanks for the reminder,  I pushed the update I wrote for this.

Re: setup 2.885 release candidate - please test

[Achim Gratz]

Achim Gratz writes:
>> - 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]?

…and of course these are a result of the latest officially available
calm version not having those changes, so my local packages are still
using requires: lines.  Any chance you could relese a new calm version?

Other than that I think I've fixed up my setup rewriter so it can deal
with the new format correctly now and I've even managed to implement
explicit version pinning (which I had on TODO for almost three years,
but since before I've only had test, curr and prev for testing I've put
it up each time I looked at it).

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
positiviely wierd on screen.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: setup 2.885 release candidate - please test

[Achim Gratz]

Jon Turney writes:
> Since this contains many internal changes, I think this could use some
> wider testing before being deployed. Please test and report any
> problems here.

I've built these myself, but I don't think that changes anything below.

> User visible changes:
> - 'Current' is replaced by 'Best' (which is slightly different in ways
> it's difficult to summarize briefly) and 'Sync' (which exposes the
> --force-current option through the UI).  These are modified by a
> 'Test' checkbox, which allows test packages to be used.

I am always running setup with options to install a selected category w/
orphan removal and removal of non-selected packages.  The selected
category comprises _all_ packages that are supposed to be installed, so
no dependencies need to be found.

In order to see what's going on I also selected chooser mode (the normal
install just does whatever it's told to do).  That still works
apparently, but whenever I click anywhere to change the mode from "Best"
to something else and then back the transaction list gets emptied.  As I
said, I normally don't do this and clicking on those buttons serves no
useful purpose for me in that situation, but I think the result is still
wrong.  I think that maybe the command line parameters are forgotten
when doing this.

> - 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?

> - 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]?

I don't like the syntax with the commas, could we just drop the space
between the package name and the paren for the version expression and
keep the version-relations separated by plain whitespace?

> - Add support for 'obsoletes:' in setup.ini, likewise

These don't appear to be produced by calm yet.  Also, it would be useful
if the obsoleted package showed the replacement package more explicitly,
so maybe "obsoleted-by:" instead of requires:/depends2:

> - Add support for 'replace-versions:' in a package section setup.ini,
> to indicate problematic versions.

Any examples for this yet?

As you surely know, all the new syntax is not yet described in
https://sourceware.org/cygwin-apps/setup.ini.html


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: setup with experimental libsolv-based dependency solving

[Ken Brown]

On 1/18/2018 2:15 PM, Jon Turney wrote:

On 23/11/2017 18:08, Jon Turney wrote:
I'm interested in opinion on what else is needed, before this can be 
released as 2.885


I think we're in pretty good shape except for the issue of letting the 
user see what's about to be done before we do it.  My latest attempt, 
sent a few minutes ago, may or may not be good enough.


Ken

Re: setup libsolv UI: Silently install dependencies?

[Ken Brown]

On 1/15/2018 12:31 PM, Ken Brown wrote:

On 1/9/2018 8:32 AM, Jon Turney wrote:
I'm not sure it's ideal to make a text report of this, though. 
Displaying it in the chooser somehow seems a better fit.


(i.e. after you've made your selections, you get something like the 
"pending" view in the chooser again, showing what will be done, which 
you can either confirm or go back from)


Here's another attempt, lightly tested, which might still need some 
improvements.  It goes back to the chooser, but it doesn't set the 
pending view.


I've added code that allows the PrereqChecker to set the pending view 
before going back.  I'll send a revised patch shortly.


Ken

Re: setup with experimental libsolv-based dependency solving

[Jon Turney]

On 23/11/2017 18:08, Jon Turney wrote:

On 30/10/2017 15:52, Jon Turney wrote:

On 25/10/2017 20:18, Jon Turney wrote:


This has a lot of internal changes, so could use some wider testing. 
Please test.

[...]

I've replaced these with:

[...]
I've replaced these with:

[...]

I've replaced these with:

 https://cygwin.com/setup/setup-2.884-45-gb87162.x86.exe
 https://cygwin.com/setup/setup-2.884-45-gb87162.x86_64.exe

Changes compared to setup-2.882-62-g75a2e0:

libsolv related:
- When test versions are enabled, a test version is no longer preferred 
over a non-test version with a higher version
- Default solutions are now identified in the problem report, and 
applied if the user chooses to accept them
- Meaningless '.any' arch suffix to package names is suppressed in the 
problem report
- Reinstall tasks are preserved in the chooser when going back from the 
dependency problem page


other:
- Query the user for action to take if a corrupt local file is found
- Validate package hash after download
- Rebase to include changes in 2.883 and 2.884

I'm interested in opinion on what else is needed, before this can be 
released as 2.885

Re: setup libsolv UI: Silently install dependencies?

[Ken Brown]

On 1/9/2018 8:32 AM, Jon Turney wrote:
I'm not sure it's ideal to make a text report of this, though. 
Displaying it in the chooser somehow seems a better fit.


(i.e. after you've made your selections, you get something like the 
"pending" view in the chooser again, showing what will be done, which 
you can either confirm or go back from)


Here's another attempt, lightly tested, which might still need some 
improvements.  It goes back to the chooser, but it doesn't set the 
pending view.  I'm not sure how to do that without a lot of refactoring, 
but maybe I'm missing something easy.


Ken
From d183ee53ff0471f22fe2412381e8507e4c109b1e Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Mon, 15 Jan 2018 12:18:30 -0500
Subject: [PATCH] Let the user review added dependencies

If the solver finds no problems but added packages to resolve
dependencies, give the user a chance to go back to the chooser and
review what's about to happen.
---
 prereq.cc | 46 --
 1 file changed, 40 insertions(+), 6 deletions(-)

diff --git a/prereq.cc b/prereq.cc
index a03e79b..4053373 100644
--- a/prereq.cc
+++ b/prereq.cc
@@ -140,13 +140,18 @@ PrereqPage::whatNext ()
   return IDD_INSTATUS;
 }
 
-long
-PrereqPage::OnBack ()
+static void
+prepBack ()
 {
   // Reset the package database to correspond to the solver's solution
   packagedb db;
   db.solution.trans2db();
+}
 
+long
+PrereqPage::OnBack ()
+{
+  prepBack ();
   return IDD_CHOOSE;
 }
 
@@ -213,6 +218,23 @@ PrereqChecker::getUnmetString (std::string )
 // progress page glue
 // ---
 
+static bool
+added_deps ()
+{
+  packagedb db;
+  const SolverTransactionList & trans = db.solution.transactions ();
+  for (SolverTransactionList::const_iterator i = trans.begin ();
+   i != trans.end (); i++)
+if (i->type == SolverTransaction::transInstall)
+  {
+   packageversion pv = i->version;
+   packagemeta *pkg = db.findBinary (PackageSpecification (pv.Name ()));
+   if (!pkg->desired)
+ return true;
+  }
+  return false;
+}
+
 static int
 do_prereq_check_thread(HINSTANCE h, HWND owner)
 {
@@ -223,11 +245,23 @@ do_prereq_check_thread(HINSTANCE h, HWND owner)
 {
   p.finalize();
 
-  if (source == IDC_SOURCE_LOCALDIR)
-   Progress.SetActivateTask (WM_APP_START_INSTALL);  // install
+  if (added_deps () && !unattended_mode
+ && MessageBox (owner, "Packages were added to resolve dependencies.  "
+"Do you want to review them before proceeding?",
+"Added Dependencies",
+MB_YESNO | MB_DEFBUTTON2) == IDYES)
+   {
+ prepBack ();
+ retval = IDD_CHOOSE;
+   }
   else
-   Progress.SetActivateTask (WM_APP_START_DOWNLOAD); // start download
-  retval = IDD_INSTATUS;
+   {
+ if (source == IDC_SOURCE_LOCALDIR)
+   Progress.SetActivateTask (WM_APP_START_INSTALL);  // install
+ else
+   Progress.SetActivateTask (WM_APP_START_DOWNLOAD); // start download
+ retval = IDD_INSTATUS;
+   }
 }
   else
 {
-- 
2.15.1

Re: setup libsolv UI: Silently install dependencies?

[Ken Brown]

On 1/9/2018 8:32 AM, Jon Turney wrote:

On 05/01/2018 16:04, Ken Brown wrote:

On 1/5/2018 10:48 AM, Jon Turney wrote:

On 24/12/2017 23:23, Ken Brown wrote:
Currently the libsolv version of setup silently installs added 
dependencies.  The user gets a chance to review them first only if 
libsolv finds problems and has to display the prerequisite page.


I'm not sure if this was a deliberate design decision, though I 
personally like it.  On the other hand, I suspect that some users 
won't like it because they're used to seeing a report about missing 
dependencies.  So I think we should make this behavior optional.


Yeah.  Ideally we'd show what we're going to do, before we do it.

This is a bit more complex than before, as the solver might decide to 
remove or upgrade packages, rather than just install extra ones.


The attached patch is a start in that direction.  But it needs a 
followup patch to implement the mechanism for selecting the option. 
One possibility is a checkbox on the chooser page, which then gets 
saved in setup.rc as a user option.  Are there other suggestions?


But, somewhat confused by this.  Isn't this just going to show the 
(empty) problem report?


No, it shows a report that says, "Click Back and select the Pending 
view to review the default problem solutions, including packages that 
were added to resolve dependencies."  This isn't ideal, because it 
forces the user to select 'Back', and even then the user can't see 
explicitly why packages were added.  It would be better if we could 
get libsolv to give 


Ah, right.


us a report about added dependencies.  Do you know if this is possible?


Hmmm.. there's the SOLVER_USERINSTALLED flag we can apply to a task. 
Perhaps that is passed through, so we can see what's been installed 
directly vs. dependencies.


Otherwise I guess you could to compare input and output task lists to 
see what has been added by the solver?


I'm not sure it's ideal to make a text report of this, though. 
Displaying it in the chooser somehow seems a better fit.


(i.e. after you've made your selections, you get something like the 
"pending" view in the chooser again, showing what will be done, which 
you can either confirm or go back from)


Yes, that does seem better.

Ken

Re: setup libsolv UI: Silently install dependencies?

[Jon Turney]

On 05/01/2018 16:04, Ken Brown wrote:

On 1/5/2018 10:48 AM, Jon Turney wrote:

On 24/12/2017 23:23, Ken Brown wrote:
Currently the libsolv version of setup silently installs added 
dependencies.  The user gets a chance to review them first only if 
libsolv finds problems and has to display the prerequisite page.


I'm not sure if this was a deliberate design decision, though I 
personally like it.  On the other hand, I suspect that some users 
won't like it because they're used to seeing a report about missing 
dependencies.  So I think we should make this behavior optional.


Yeah.  Ideally we'd show what we're going to do, before we do it.

This is a bit more complex than before, as the solver might decide to 
remove or upgrade packages, rather than just install extra ones.


The attached patch is a start in that direction.  But it needs a 
followup patch to implement the mechanism for selecting the option. 
One possibility is a checkbox on the chooser page, which then gets 
saved in setup.rc as a user option.  Are there other suggestions?


But, somewhat confused by this.  Isn't this just going to show the 
(empty) problem report?


No, it shows a report that says, "Click Back and select the Pending view 
to review the default problem solutions, including packages that were 
added to resolve dependencies."  This isn't ideal, because it forces the 
user to select 'Back', and even then the user can't see explicitly why 
packages were added.  It would be better if we could get libsolv to give 


Ah, right.


us a report about added dependencies.  Do you know if this is possible?


Hmmm.. there's the SOLVER_USERINSTALLED flag we can apply to a task. 
Perhaps that is passed through, so we can see what's been installed 
directly vs. dependencies.


Otherwise I guess you could to compare input and output task lists to 
see what has been added by the solver?


I'm not sure it's ideal to make a text report of this, though. 
Displaying it in the chooser somehow seems a better fit.


(i.e. after you've made your selections, you get something like the 
"pending" view in the chooser again, showing what will be done, which 
you can either confirm or go back from)

Re: setup libsolv UI: Silently install dependencies?

[Jon Turney]

On 25/12/2017 19:18, Ken Brown wrote:
[Side comment: Jon, in v2 of commit 9367283, you removed some newlines, 
saying that they weren't needed because wrapping would be done.  But I'm 
not seeing that wrapping; I have to scroll horizontally to see the whole 
text.]


Yeah, what I wrote was nonsense.

I think it's a bit visually inconsistent to put fixed linebreaks into 
this text.  I think it would be more consistent to either (i) wrap at 
the width of the edittext control, or (ii) not wrapped at all (like the 
problems)


I'm not sure if (ii) is achievable, though (perhaps with an 
EditWordBreakProc function?).


Or maybe just remove the hscroll style so everything gets wrapped?

I think I'll just put it back the way you had it, for the moment.

Re: setup libsolv UI: Silently install dependencies?

[Ken Brown]

On 1/5/2018 10:48 AM, Jon Turney wrote:

On 24/12/2017 23:23, Ken Brown wrote:
Currently the libsolv version of setup silently installs added 
dependencies.  The user gets a chance to review them first only if 
libsolv finds problems and has to display the prerequisite page.


I'm not sure if this was a deliberate design decision, though I 
personally like it.  On the other hand, I suspect that some users 
won't like it because they're used to seeing a report about missing 
dependencies.  So I think we should make this behavior optional.


Yeah.  Ideally we'd show what we're going to do, before we do it.

This is a bit more complex than before, as the solver might decide to 
remove or upgrade packages, rather than just install extra ones.


The attached patch is a start in that direction.  But it needs a 
followup patch to implement the mechanism for selecting the option.  
One possibility is a checkbox on the chooser page, which then gets 
saved in setup.rc as a user option.  Are there other suggestions?


But, somewhat confused by this.  Isn't this just going to show the 
(empty) problem report?


No, it shows a report that says, "Click Back and select the Pending view 
to review the default problem solutions, including packages that were 
added to resolve dependencies."  This isn't ideal, because it forces the 
user to select 'Back', and even then the user can't see explicitly why 
packages were added.  It would be better if we could get libsolv to give 
us a report about added dependencies.  Do you know if this is possible?


Ken

Re: setup libsolv UI: Silently install dependencies?

[Jon Turney]

On 24/12/2017 23:23, Ken Brown wrote:
Currently the libsolv version of setup silently installs added 
dependencies.  The user gets a chance to review them first only if 
libsolv finds problems and has to display the prerequisite page.


I'm not sure if this was a deliberate design decision, though I 
personally like it.  On the other hand, I suspect that some users won't 
like it because they're used to seeing a report about missing 
dependencies.  So I think we should make this behavior optional.


Yeah.  Ideally we'd show what we're going to do, before we do it.

This is a bit more complex than before, as the solver might decide to 
remove or upgrade packages, rather than just install extra ones.


The attached patch is a start in that direction.  But it needs a 
followup patch to implement the mechanism for selecting the option.  One 
possibility is a checkbox on the chooser page, which then gets saved in 
setup.rc as a user option.  Are there other suggestions?


But, somewhat confused by this.  Isn't this just going to show the 
(empty) problem report?

Re: setup libsolv: getting rid of ".any"

[Jon Turney]

On 13/12/2017 00:04, Ken Brown wrote:
I've been trying to think of a way to get rid of the suffix ".any" that 
gets appended to package names.  I think users will be confused by this 
when they see it in log files and, more importantly, in problem reports. 
  The only thing I can come up with is patching libsolv so that 
pool_solvable2str() suppresses 'arch' when arch == ARCH_ANY.  Can you 
think of a better way?


Ideally, we'd have the actual archness of the package, but we don't have 
that information for installed packages, so I didn't bother with keeping 
it around for anything.


I'm not too worried about this appearing in the log file, but we could 
post-process problem strings in SolverSolution::report() to remove '.any'

Re: setup libsolv UI: Silently install dependencies?

[Ken Brown]

On 12/24/2017 6:23 PM, Ken Brown wrote:
Currently the libsolv version of setup silently installs added 
dependencies.  The user gets a chance to review them first only if 
libsolv finds problems and has to display the prerequisite page.


I'm not sure if this was a deliberate design decision, though I 
personally like it.  On the other hand, I suspect that some users won't 
like it because they're used to seeing a report about missing 
dependencies.  So I think we should make this behavior optional.


The attached patch is a start in that direction.  But it needs a 
followup patch to implement the mechanism for selecting the option.  One 
possibility is a checkbox on the chooser page, which then gets saved in 
setup.rc as a user option.


And here's a followup patch that implements that possibility.

[Side comment: Jon, in v2 of commit 9367283, you removed some newlines, 
saying that they weren't needed because wrapping would be done.  But I'm 
not seeing that wrapping; I have to scroll horizontally to see the whole 
text.]


Ken

From f3aadfead49f9ec17f04e0051d6d58f619c5092b Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Mon, 25 Dec 2017 14:04:20 -0500
Subject: [PATCH setup libsolv] Implement user option to report added
 dependencies

Add a checkbox IDC_CHOOSE_REPORT to IDD_CHOOSE_DIALOG that determines
the value of PrereqChecker::report_added_deps.  Save the user's choice
in a new user setting "report_user_deps".
---
 choose.cc  | 14 ++
 prereq.cc  |  2 +-
 prereq.h   |  2 ++
 res.rc |  4 
 resource.h |  2 ++
 5 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/choose.cc b/choose.cc
index ff57d85..d5e55b8 100644
--- a/choose.cc
+++ b/choose.cc
@@ -83,6 +83,7 @@ static ControlAdjuster::ControlInfo ChooserControlsInfo[] = {
   {IDC_CHOOSE_VIEWCAPTION, CP_LEFT,CP_TOP},
   {IDC_CHOOSE_LIST,CP_STRETCH, CP_STRETCH},
   {IDC_CHOOSE_HIDE, CP_LEFT,CP_BOTTOM},
+  {IDC_CHOOSE_REPORT,   CP_LEFT,CP_BOTTOM},
   {0, CP_LEFT, CP_TOP}
 };
 
@@ -128,6 +129,8 @@ ChooserPage::~ChooserPage ()
}
   UserSettings::instance().set ("chooser_window_settings", toset);
 }
+  UserSettings::instance().set ("report_added_deps",
+   PrereqChecker::reportAddedDeps () ? "yes" : 
"no");
 }
 
 void
@@ -255,6 +258,13 @@ ChooserPage::OnInit ()
 {
   CheckDlgButton (GetHWND (), IDC_CHOOSE_HIDE, BST_CHECKED);
 
+  const char *fg_ret =
+UserSettings::instance().get ("report_added_deps");
+  bool report_added_deps = !fg_ret || strcmp (fg_ret, "no" ) != 0;
+  PrereqChecker::setAddedDeps (report_added_deps);
+  CheckDlgButton (GetHWND (), IDC_CHOOSE_REPORT,
+ report_added_deps ? BST_CHECKED : BST_UNCHECKED);
+
   /* Populate view dropdown list with choices */
   HWND viewlist = GetDlgItem (IDC_CHOOSE_VIEW);
   SendMessage (viewlist, CB_RESETCONTENT, 0, 0);
@@ -279,6 +289,7 @@ ChooserPage::OnInit ()
   AddTooltip (IDC_CHOOSE_VIEW, IDS_VIEWBUTTON_TOOLTIP);
   AddTooltip (IDC_CHOOSE_HIDE, IDS_HIDEOBS_TOOLTIP);
   AddTooltip (IDC_CHOOSE_SEARCH_EDIT, IDS_SEARCH_TOOLTIP);
+  AddTooltip (IDC_CHOOSE_REPORT, IDS_REPORTDEPS_TOOLTIP);
 
   /* Set focus to search edittext control. */
   PostMessage (GetHWND (), WM_NEXTDLGCTL,
@@ -536,6 +547,9 @@ ChooserPage::OnMessageCmd (int id, HWND hwndctl, UINT code)
 case IDC_CHOOSE_HIDE:
   chooser->setObsolete (!IsButtonChecked (id));
   break;
+case IDC_CHOOSE_REPORT:
+  PrereqChecker::setAddedDeps (IsButtonChecked (id));
+  break;
 default:
   // Wasn't recognized or handled.
   return false;
diff --git a/prereq.cc b/prereq.cc
index 0c06a32..231e6dc 100644
--- a/prereq.cc
+++ b/prereq.cc
@@ -159,7 +159,7 @@ PrereqPage::OnUnattended ()
 
 // instantiate the static members
 bool PrereqChecker::use_test_packages;
-bool PrereqChecker::report_added_deps = true;
+bool PrereqChecker::report_added_deps;
 
 static bool
 added_deps ()
diff --git a/prereq.h b/prereq.h
index a14789a..c79d306 100644
--- a/prereq.h
+++ b/prereq.h
@@ -41,6 +41,8 @@ public:
   void getUnmetString (std::string );
 
   static void setTestPackages (bool t) { use_test_packages = t; };
+  static void setAddedDeps (bool t) { report_added_deps = t; };
+  static bool reportAddedDeps () { return report_added_deps; };
 
 private:
   static bool use_test_packages;
diff --git a/res.rc b/res.rc
index ee4270a..7d0de79 100644
--- a/res.rc
+++ b/res.rc
@@ -363,6 +363,8 @@ BEGIN
 WS_VISIBLE, 7, 45, SETUP_STANDARD_DIALOG_W - 14, 122
 CONTROL " obsolete packages", IDC_CHOOSE_HIDE,
 "Button", BS_AUTOCHECKBOX | WS_TABSTOP, 7, 167, 160, 14
+CONTROL " added dependencies", IDC_CHOOSE_REPORT,
+"Button", BS_AUTOCHECKBOX | WS_TABSTOP, 167, 167, 160, 14
 ICONIDI_CYGWIN, IDC_HEADICON, SETUP_HEADICON_X, 0, 21, 20
 LTEXT   "Select the packages you want setup to install.",
 

Re: setup with experimental libsolv-based dependency solving

[Jon Turney]

On 30/10/2017 15:52, Jon Turney wrote:

On 25/10/2017 20:18, Jon Turney wrote:


This has a lot of internal changes, so could use some wider testing. 
Please test.

[...]

I've replaced these with:

[...]

I've replaced these with:

 https://cygwin.com/setup/setup-2.882-62-g75a2e0.x86.exe
 https://cygwin.com/setup/setup-2.882-62-g75a2e0.x86_64.exe

Changes compared to setup-2.882-49-gcc8b05:

libsolv related:
- Fix crash after incomplete download
- Handle going backwards to mirror selection correctly

other:
- Improve behaviour after download error
- Don't fatal() on unexpected early window messages
- Make 'System Proxy Settings' the default, rather than 'Direct'
- Remove support from installing from a local directory which doesn't 
contains a setup.ini file


I'm kind of tempted to tag this, stick a fork in it, and call it done, 
but I don't think we are quite there yet...

Re: [setup topic/libsolv] Crash after incomplete download

[Ken Brown]

On 11/7/2017 1:15 PM, Jon Turney wrote:

On 02/11/2017 19:25, Ken Brown wrote:

On 11/2/2017 1:22 PM, Jon Turney wrote:

On 01/11/2017 20:38, Ken Brown wrote:
If there is a download failure and the user clicks Yes in response 
to "Download Incomplete.  Try again?", then setup will crash.  The 
crash occurs at PickView.cc:447 because i->source() is NULL.


Thanks for finding all these problems!

I haven't yet analyzed this in further detail, but the crux of the 
issue seems to be that we call do_ini_thread a second time without 
having cleaned out the package database and the libsolv pool.


This is probably a symptom of a more general problem, which is that 
we haven't thought carefully (or at least I haven't) about what 
happens when we visit certain pages for a second time, after the 
libsolv pool has been created.


The fact that this isn't considered at all at the moment makes me 
wonder if it's working correctly in this situation currently.  But, 
yeah, I agree that packagedb state should be cleared in this case.


I tried with the attached, but it still segfaults at the same place.

This seems to be because all the packagedb prep (including 
fixup_source_package_ids) is in OnInit() (which is only called once 
per page, but lazily), rather than OnActivate(), so probably some 
more restructuring is needed there :(


I guess we could move all that prep to OnActivate() but make sure it's 
only run when we've gotten to the chooser page from the site page (and 
not because the user pressed Back on the prereq page).  What about 
adding a 'prepped' data member to packagedb and using this to decide 
whether to run the prep code?


An attempt at this to follow, but this ended up touching rather more 
stuff than I wanted to, so I'm sure something else has broken :(


Well, at least the crash is gone.

Ken

Re: [setup topic/libsolv] Crash after incomplete download

[Jon Turney]

On 02/11/2017 19:25, Ken Brown wrote:

On 11/2/2017 1:22 PM, Jon Turney wrote:

On 01/11/2017 20:38, Ken Brown wrote:
If there is a download failure and the user clicks Yes in response to 
"Download Incomplete.  Try again?", then setup will crash.  The crash 
occurs at PickView.cc:447 because i->source() is NULL.


Thanks for finding all these problems!

I haven't yet analyzed this in further detail, but the crux of the 
issue seems to be that we call do_ini_thread a second time without 
having cleaned out the package database and the libsolv pool.


This is probably a symptom of a more general problem, which is that 
we haven't thought carefully (or at least I haven't) about what 
happens when we visit certain pages for a second time, after the 
libsolv pool has been created.


The fact that this isn't considered at all at the moment makes me 
wonder if it's working correctly in this situation currently.  But, 
yeah, I agree that packagedb state should be cleared in this case.


I tried with the attached, but it still segfaults at the same place.

This seems to be because all the packagedb prep (including 
fixup_source_package_ids) is in OnInit() (which is only called once 
per page, but lazily), rather than OnActivate(), so probably some more 
restructuring is needed there :(


I guess we could move all that prep to OnActivate() but make sure it's 
only run when we've gotten to the chooser page from the site page (and 
not because the user pressed Back on the prereq page).  What about 
adding a 'prepped' data member to packagedb and using this to decide 
whether to run the prep code?


An attempt at this to follow, but this ended up touching rather more 
stuff than I wanted to, so I'm sure something else has broken :(



+void
+packagedb::init ()
+{
+  installeddbread = 0;
+  installeddbver = 0;
+  packages.clear();
+  sourcePackages.clear();
+  categories.clear();
+  solver.clear();
+  basepkg = packageversion();
+  dependencyOrderedPackages.clear();


I think you also need solution.clear(), where the latter does 
essentially what SolverSolution::~SolverSolution() does.  (Or is it 
enough to just set solv = NULL?)  Otherwise, solv will be an invalid 
pointer when update is next called.


Yes, you're right, of course.

The initialization all gets a bit obscure, maybe making solver and 
solversolution directly members of this singleton isn't the right 
approach...

Re: [setup topic/libsolv] Crash after incomplete download

[Ken Brown]

On 11/2/2017 1:22 PM, Jon Turney wrote:

On 01/11/2017 20:38, Ken Brown wrote:
If there is a download failure and the user clicks Yes in response to 
"Download Incomplete.  Try again?", then setup will crash.  The crash 
occurs at PickView.cc:447 because i->source() is NULL.


Thanks for finding all these problems!

I haven't yet analyzed this in further detail, but the crux of the 
issue seems to be that we call do_ini_thread a second time without 
having cleaned out the package database and the libsolv pool.


This is probably a symptom of a more general problem, which is that we 
haven't thought carefully (or at least I haven't) about what happens 
when we visit certain pages for a second time, after the libsolv pool 
has been created.


The fact that this isn't considered at all at the moment makes me wonder 
if it's working correctly in this situation currently.  But, yeah, I 
agree that packagedb state should be cleared in this case.


I tried with the attached, but it still segfaults at the same place.

This seems to be because all the packagedb prep (including 
fixup_source_package_ids) is in OnInit() (which is only called once per 
page, but lazily), rather than OnActivate(), so probably some more 
restructuring is needed there :(


I guess we could move all that prep to OnActivate() but make sure it's 
only run when we've gotten to the chooser page from the site page (and 
not because the user pressed Back on the prereq page).  What about 
adding a 'prepped' data member to packagedb and using this to decide 
whether to run the prep code?


Before I work further on this, I have a UI question.  Is it really 
reasonable that we go back to the mirror selection page after 
"Download incomplete"?  I understand the rationale, which is that the 
user might want to try a different mirror after a download failure.  
But I personally have always found this annoying.  I would rather just 
retry the download, which is what the message ("Download Incomplete.  
Try again?") suggests is going to happen.


This makes perfect sense to me.

The path that an unattended install takes out of there is particularly 
convoluted, as well.


I suspect there's other terribleness in this area, like if you choose 
"No", the incomplete package download is left in the local package cache 
to fail it's checksum check on the next run...


+void
+packagedb::init ()
+{
+  installeddbread = 0;
+  installeddbver = 0;
+  packages.clear();
+  sourcePackages.clear();
+  categories.clear();
+  solver.clear();
+  basepkg = packageversion();
+  dependencyOrderedPackages.clear();


I think you also need solution.clear(), where the latter does 
essentially what SolverSolution::~SolverSolution() does.  (Or is it 
enough to just set solv = NULL?)  Otherwise, solv will be an invalid 
pointer when update is next called.


Ken

Re: [setup topic/libsolv] Crash after incomplete download

[Jon Turney]

On 01/11/2017 20:38, Ken Brown wrote:
If there is a download failure and the user clicks Yes in response to 
"Download Incomplete.  Try again?", then setup will crash.  The crash 
occurs at PickView.cc:447 because i->source() is NULL.


Thanks for finding all these problems!

I haven't yet analyzed this in further detail, but the crux of the issue 
seems to be that we call do_ini_thread a second time without having 
cleaned out the package database and the libsolv pool.


This is probably a symptom of a more general problem, which is that we 
haven't thought carefully (or at least I haven't) about what happens 
when we visit certain pages for a second time, after the libsolv pool 
has been created.


The fact that this isn't considered at all at the moment makes me wonder 
if it's working correctly in this situation currently.  But, yeah, I 
agree that packagedb state should be cleared in this case.


I tried with the attached, but it still segfaults at the same place.

This seems to be because all the packagedb prep (including 
fixup_source_package_ids) is in OnInit() (which is only called once per 
page, but lazily), rather than OnActivate(), so probably some more 
restructuring is needed there :(


Before I work further on this, I have a UI question.  Is it really 
reasonable that we go back to the mirror selection page after "Download 
incomplete"?  I understand the rationale, which is that the user might 
want to try a different mirror after a download failure.  But I 
personally have always found this annoying.  I would rather just retry 
the download, which is what the message ("Download Incomplete.  Try 
again?") suggests is going to happen.


This makes perfect sense to me.

The path that an unattended install takes out of there is particularly 
convoluted, as well.


I suspect there's other terribleness in this area, like if you choose 
"No", the incomplete package download is left in the local package cache 
to fail it's checksum check on the next run...
From baec018e93c0e7cea7993c22a5e32f2065a1e7ae Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Thu, 2 Nov 2017 14:15:04 +
Subject: [PATCH setup] Empty packagedb and underlying solver pool if we go
 back to WM_APP_START_SETUP_INI_DOWNLOAD

XXX: this is probably still wrong as we can bypass this state?
---
 ini.cc|  3 +++
 libsolv.cc| 15 +++
 libsolv.h |  2 ++
 package_db.cc | 13 +
 package_db.h  |  1 +
 5 files changed, 34 insertions(+)

diff --git a/ini.cc b/ini.cc
index 0f8b927..e2ab08f 100644
--- a/ini.cc
+++ b/ini.cc
@@ -346,6 +346,9 @@ do_remote_ini (HWND owner)
 static bool
 do_ini_thread (HINSTANCE h, HWND owner)
 {
+  packagedb db;
+  db.init();
+
   size_t ini_count = 0;
   if (source == IDC_SOURCE_LOCALDIR)
 ini_count = do_local_ini (owner);
diff --git a/libsolv.cc b/libsolv.cc
index 9dd1eeb..7eecc29 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -316,6 +316,12 @@ void debug_callback(Pool *pool, void *data, int type, 
const char *str)
 }
 
 SolverPool::SolverPool()
+{
+  init();
+}
+
+void
+SolverPool::init()
 {
   /* create a pool */
   pool = pool_create();
@@ -333,6 +339,15 @@ SolverPool::SolverPool()
   pool_set_installed(pool, installed->repo);
 }
 
+void
+SolverPool::clear()
+{
+  repos.clear();
+  pool_free(pool);
+
+  init();
+}
+
 SolvRepo *
 SolverPool::getRepo(const std::string , bool test)
 {
diff --git a/libsolv.h b/libsolv.h
index 65e1610..366cd59 100644
--- a/libsolv.h
+++ b/libsolv.h
@@ -130,6 +130,7 @@ class SolverPool
 {
 public:
   SolverPool();
+  void clear();
   SolvRepo *getRepo(const std::string , bool test = false);
 
   // Utility class for passing arguments to addPackage()
@@ -158,6 +159,7 @@ public:
 
 
 private:
+  void init();
   Id makedeps(Repo *repo, PackageDepends *requires);
   Pool *pool;
 
diff --git a/package_db.cc b/package_db.cc
index 66e7f0a..5bf9009 100644
--- a/package_db.cc
+++ b/package_db.cc
@@ -47,6 +47,19 @@ packagedb::packagedb ()
 {
 }
 
+void
+packagedb::init ()
+{
+  installeddbread = 0;
+  installeddbver = 0;
+  packages.clear();
+  sourcePackages.clear();
+  categories.clear();
+  solver.clear();
+  basepkg = packageversion();
+  dependencyOrderedPackages.clear();
+}
+
 void
 packagedb::read ()
 {
diff --git a/package_db.h b/package_db.h
index d7127a6..a26c387 100644
--- a/package_db.h
+++ b/package_db.h
@@ -64,6 +64,7 @@ class packagedb
 {
 public:
   packagedb ();
+  void init();
   void read();
   void makeBase();
   /* 0 on success */
-- 
2.15.0

Re: setup with experimental libsolv-based dependency solving

[Jon Turney]

On 25/10/2017 20:18, Jon Turney wrote:


This has a lot of internal changes, so could use some wider testing. 
Please test.


   https://cygwin.com/setup/setup-2.882-41-g4cbfa1.x86.exe
   https://cygwin.com/setup/setup-2.882-41-g4cbfa1.x86_64.exe


I've replaced these with:

   https://cygwin.com/setup/setup-2.882-49-gcc8b05.x86.exe
   https://cygwin.com/setup/setup-2.882-49-gcc8b05.x86_64.dbg

Changes compared to 2.882-41-g4cbfa1:

- Fix installed.db getting emptied if installing from a local directory, 
which didn't contain a setup.ini

- Read epochal version numbers correctly from installed.db
- Remove the ability to install package files from a local directory 
which didn't contain a setup.ini

- Updated build instructions

Re: setup with experimental libsolv-based dependency solving

[Jon Turney]

On 28/10/2017 13:31, Ken Brown wrote:

On 10/27/2017 3:52 PM, Ken Brown wrote:

On 10/27/2017 2:57 PM, Ken Brown wrote:

On 10/25/2017 3:18 PM, Jon Turney wrote:


This has a lot of internal changes, so could use some wider testing. 
Please test.


I've just discovered a serious bug.  When installing from a local 
directory that either doesn't exist or isn't a valid repository, 
setup doesn't correctly read/write the installed file database 
(/etc/setup/installed.db).


I *think* the problem is that packagedb::read is never called.  Since 
do_local_dir returns false, LocalDirPage::OnNext takes us directly to 
the chooser.  This means that do_ini_thread never gets to the line 
that calls db.read.


Yeah, my mistake.


I just submitted two patches that seem to fix this.


Thanks.

Re: setup with experimental libsolv-based dependency solving

[Ken Brown]

On 10/27/2017 2:57 PM, Ken Brown wrote:

On 10/25/2017 3:18 PM, Jon Turney wrote:


This has a lot of internal changes, so could use some wider testing. 
Please test.


I've just discovered a serious bug.  When installing from a local 
directory that either doesn't exist or isn't a valid repository, setup 
doesn't correctly read/write the installed file database 
(/etc/setup/installed.db).


I *think* the problem is that packagedb::read is never called.  Since 
do_local_dir returns false, LocalDirPage::OnNext takes us directly to 
the chooser.  This means that do_ini_thread never gets to the line that 
calls db.read.


I could be completely wrong, but I'm throwing this out there because I 
don't have time to look at this any more right now.


Ken

Re: setup with experimental libsolv-based dependency solving

[Ken Brown]

On 10/25/2017 3:18 PM, Jon Turney wrote:


This has a lot of internal changes, so could use some wider testing. 
Please test.


I've just discovered a serious bug.  When installing from a local 
directory that either doesn't exist or isn't a valid repository, setup 
doesn't correctly read/write the installed file database 
(/etc/setup/installed.db).


Until we get this fixed, please backup installed.db before running setup 
(or just don't proceed with the installation if setup doesn't correctly 
show your installed packages).


Ken

Re: setup and colons in filenames

[Corinna Vinschen]

On Oct 27 11:20, Ken Brown wrote:
> On 10/27/2017 9:44 AM, Jon Turney wrote:
> > I've worked on [1] a bit so it now contains some instructions how to do
> > this, rather than the previous state of affairs, which was "genini
> > exists, work it out yourself"
> > 
> > [1] https://cygwin.com/package-server.html#overlay
> > 
> > > > (*) Or better: A user version of calm, packaged in the distro.
> > 
> > Um, we have had this for a while [2], mksetupini is the tool to use if
> > you don't need all the extra stuff which calm does.
> > 
> > [2] https://cygwin.com/ml/cygwin-apps/2016-07/msg00047.html
> > 
> > I guess mksetupini could have more friendly defaults to make the command
> > lines in [1] shorter if that really scares people off (e.g. default
> > --inifile to stdout, --releasearea to '.' and to
> > --okmissing=required-package (then need a way to turn it back on,
> > though))
> 
> I don't see why this should be necessary.  You've written out the command
> line for people to copy and paste.
> 
> With [1] available, I think it should be OK to rip out ScanFindVisitor.
> 
> Ken

ACK


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: setup and colons in filenames

[Jon Turney]

On 26/10/2017 19:25, Achim Gratz wrote:

Jon Turney writes:

Achim Gratz wrote:

Jon Turney writes:

This seems a really odd thing to do, as we've no idea about the
dependencies of these packages, so installing them is unlikely work
well.


This particular code path was vetoed from getting thrown out last time I
worked in that area since it would break long-standing expectations
w.r.t. local package archives that have no setup.ini or even *.hint. 



Can we have a link to that discussion, please?


It's somewhere in that thread from June 2015 related to the changes
between 2.871 and 2.873.  Also one of the intermediate versions got
complaints due to that code path not working correctly.


Using your clues, the only seemingly relevant discussion I found was 
starting at [1], but I can't find where it says anything like that.


https://cygwin.com/ml/cygwin-apps/2015-06/msg00091.html

Re: setup and colons in filenames

[Jon Turney]

On 27/10/2017 11:40, Achim Gratz wrote:

Corinna Vinschen writes:

It would be pretty neat if genini could be simplified(*), so a mortal user
can just run it with a directory as parameter and it creates a setup.ini
file at the top-level of that dir without too much complaining about
missing sources etc.


I've worked on [1] a bit so it now contains some instructions how to do 
this, rather than the previous state of affairs, which was "genini 
exists, work it out yourself"


[1] https://cygwin.com/package-server.html#overlay


(*) Or better: A user version of calm, packaged in the distro.


Um, we have had this for a while [2], mksetupini is the tool to use if 
you don't need all the extra stuff which calm does.


[2] https://cygwin.com/ml/cygwin-apps/2016-07/msg00047.html

I guess mksetupini could have more friendly defaults to make the command 
lines in [1] shorter if that really scares people off (e.g. default 
--inifile to stdout, --releasearea to '.' and to 
--okmissing=required-package (then need a way to turn it back on, though))



For better or worse, genini is dead and replaced by mksetupini.  The
latter is way more picky with having the correct hint files around and
often refuses to create a setup.ini if it finds something it doesn't
like.


Not dead, just resting.  Until someone patches it to understand pvr.hint 
files.


I make no apologies for mksetupini being more strict, though.

Re: setup and colons in filenames

[Achim Gratz]

Corinna Vinschen writes:
> It would be pretty neat if genini could be simplified(*), so a mortal user
> can just run it with a directory as parameter and it creates a setup.ini
> file at the top-level of that dir without too much complaining about
> missing sources etc.
>
> (*) Or better: A user version of calm, packaged in the distro.

For better or worse, genini is dead and replaced by mksetupini.  The
latter is way more picky with having the correct hint files around and
often refuses to create a setup.ini if it finds something it doesn't
like.


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

Re: setup and colons in filenames

[Corinna Vinschen]

On Oct 26 20:25, Achim Gratz wrote:
> Jon Turney writes:
> > Can we have a link to that discussion, please?
> 
> It's somewhere in that thread from June 2015 related to the changes
> between 2.871 and 2.873.  Also one of the intermediate versions got
> complaints due to that code path not working correctly.

I'm totally willing to retry.  A real mirror, even a local one, won't
have any problems because it has a setup.ini.

It would be pretty neat if genini could be simplified(*), so a mortal user
can just run it with a directory as parameter and it creates a setup.ini
file at the top-level of that dir without too much complaining about
missing sources etc.

(*) Or better: A user version of calm, packaged in the distro.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: setup and colons in filenames

[Achim Gratz]

Jon Turney writes:
> Can we have a link to that discussion, please?

It's somewhere in that thread from June 2015 related to the changes
between 2.871 and 2.873.  Also one of the intermediate versions got
complaints due to that code path not working correctly.


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