Re: [PATCH] make setup mirror list more like web page not just urls
On 2017-11-23 14:07, Ken Brown wrote: > On 11/22/2017 11:42 AM, Brian Inglis wrote: >> On 2017-11-20 15:59, Ken Brown wrote: >>> On 11/20/2017 4:30 PM, Brian Inglis wrote: On 2017-11-17 06:53, Jon Turney wrote: On 11/17/2017 8:48 AM, Ken Brown wrote: > On 15/11/2017 21:35, Brian Inglis wrote: >>> The issue of recognizing a URL that's already in the list is not fixed. >>> Here's >>> what I tried: >>> >>> I ran setup with the last mirror (as stored in /etc/setup/setup.rc) being >>> http://mirrors.kernel.org/sourceware/cygwin/. The resulting mirror list >>> display >>> contained the following, highlighted: >>> >>> Org - Kernel - http://mirrors.kernel.org >>> >>> So setup didn't recognize that http://mirrors.kernel.org/sourceware/cygwin/ >>> was >>> already in the list, displayed as >>> >>> United States - California - http://mirrors.kernel.org >> >> Should have been working so I added more LOG_BABBLE and it looks like >> setup.rc >> is processed at the start as you would expect, but it is merged into empty >> site >> lists, as mirrors.lst is downloaded only after you say you can, and proxy >> settings, in a separate download thread: see attached. >> And do you know where the cached list comes from - that seems to keep old >> mirrors around from testing, but I can't find any cached list with the test >> mirrors appearing in the list - I would expect that to come from setup.rc - >> but >> appears to be loaded when mirrors.lst is. >> So we need to defer adding the last mirror with some kind of lazy evaluation >> hooked after cached mirrors and/or mirrors.lst is available. >> If we have a setup.rc, I would expect the cached mirrors site list loaded >> from >> there at startup, before the last mirror is merged (and found!). >> Can make those changes but would like ny assumptions questioned, corrected, >> or >> validated! > > I'm not aware of any place previously used sites could come from other than > setup.rc. Are you sure your test mirrors aren't listed there? No - that's why I've been scratching or beating my head about cache location! > The fact that mirrors.lst is merged into all_site_list after the last-mirror > list shouldn't prevent a site in mirrors.lst from replacing one with the same > URL. load_site_list() tries to do exactly that. I think the problem is that > 'find (theSites.begin(), theSites.end(), newsite)' is using an operator== > based > on the key instead of the URL. Changing that as you suggested in a different > message might fix the problem, but I haven't thought about whether it could > cause problems elsewhere. That's why I suggested (string) constructor and/or operator== (string) overloads, to allow very selective behaviour change, without changing other uses. I have not used non-C-like OO C++ much, with too many casts required, but find that approach very natural using JS object prototypes to augment behaviour. Currently both the cached and downloaded mirror lists are set up after the download. It may be more obvious to set up the cached list (if there is one, which will be almost always, except brand new setups) at the start, before "merging" the last mirror, which currently just adds that entry to an empty cached list. If there is no cached list, there will be no last mirror to merge. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Re: [ANNOUNCEMENT] Cygnal 2.8.99.97.
On 2017-11-23 11:20, Yaakov Selkowitz wrote: > On 2017-11-23 10:28, Brian Inglis wrote: >> On 2017-11-20 08:42, Kaz Kylheku wrote: >>> Cygnal (http://www.kylheku.com/cygnal/) is a replacement for "cygwin1.dll" >>> which >>> provides native-Windows-app behaviors. >>> >>> The basic idea, scope and aim of the project is that programs built in the >>> Cygwin environment with its native compiler can be deployed with Cygnal as >>> native Windows programs. >>> >>> This is the first release of Cygnal since August 2016. >>> >>> In this release, Cygnal has been rebased to Cygwin 2.9.0, from the previous >>> 2.5.2. >> >> This notice did not appear on cygwin-announce list. > > Nor should it have, as this is really off topic for this list. Sorry, it was not obvious to me that this was *NOT* an official announcement, Cygnal is *NOT* a Cygwin package, and should *NOT* have been posted with that subject prefix: that post is deceptive. Could we possibly have sourceware filter or bounce announcement posts with that subject prefix, unless they come from the current maintainer(s), via the cygwin-announce list, or the package update process, or have posts signed with a key or cert, whichever is doable and secure? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH] make setup mirror list more like web page not just urls
On 11/22/2017 11:42 AM, Brian Inglis wrote: On 2017-11-20 15:59, Ken Brown wrote: On 11/20/2017 4:30 PM, Brian Inglis wrote: On 2017-11-17 06:53, Jon Turney wrote: On 11/17/2017 8:48 AM, Ken Brown wrote: On 15/11/2017 21:35, Brian Inglis wrote: The issue of recognizing a URL that's already in the list is not fixed. Here's what I tried: I ran setup with the last mirror (as stored in /etc/setup/setup.rc) being http://mirrors.kernel.org/sourceware/cygwin/. The resulting mirror list display contained the following, highlighted: Org - Kernel - http://mirrors.kernel.org So setup didn't recognize that http://mirrors.kernel.org/sourceware/cygwin/ was already in the list, displayed as United States - California - http://mirrors.kernel.org Should have been working so I added more LOG_BABBLE and it looks like setup.rc is processed at the start as you would expect, but it is merged into empty site lists, as mirrors.lst is downloaded only after you say you can, and proxy settings, in a separate download thread: see attached. And do you know where the cached list comes from - that seems to keep old mirrors around from testing, but I can't find any cached list with the test mirrors appearing in the list - I would expect that to come from setup.rc - but appears to be loaded when mirrors.lst is. So we need to defer adding the last mirror with some kind of lazy evaluation hooked after cached mirrors and/or mirrors.lst is available. If we have a setup.rc, I would expect the cached mirrors site list loaded from there at startup, before the last mirror is merged (and found!). Can make those changes but would like ny assumptions questioned, corrected, or validated! I'm not aware of any place previously used sites could come from other than setup.rc. Are you sure your test mirrors aren't listed there? The fact that mirrors.lst is merged into all_site_list after the last-mirror list shouldn't prevent a site in mirrors.lst from replacing one with the same URL. load_site_list() tries to do exactly that. I think the problem is that 'find (theSites.begin(), theSites.end(), newsite)' is using an operator== based on the key instead of the URL. Changing that as you suggested in a different message might fix the problem, but I haven't thought about whether it could cause problems elsewhere. Ken
Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP)
Jon Turney writes:
>>> You can give each repo a priority and it will pick the package from the
>>> one with the highest priority, even if another repo has a higher
>>> version.
>>
>> Yes, that works.
>
> It seems that, when test versions are enabled, a test version is
> preferred over a non-test version with a higher version
>
> I guess this is a consequence of:
>
>> void
>> SolverPool::use_test_packages(bool use_test_packages)
>> {
>> // Give repos containing test packages higher priority than normal
>> // if wanted, otherwise lower priority.
>> SolvRepo::priority_t p = use_test_packages ? SolvRepo::priorityHigh :
>> SolvRepo::priorityLow;
>
> I wonder if we just want to give test repos priorityNormal when they
> are wanted?
It really depends on what you are trying to achieve (and assuming you always
work on all enabled repositories instead of specifically selecting one).
1) To chose the highest version available among a set of repositories
(these need to be compatible in their versioning), then the priorities
of all those repos need to be the same.
2) To prefer one repo over the other regardless of versioning
(versioning need not be compatible), then raise the priority of the
preferred repo.
We currently can't use the difference between an update and
distribution upgrade in setup since we would have to record which repo
each package was originally installed from. If we had that, an update
would keep the repository selection (even if another repo has a higher
version) and a distribution upgrade would select the highest version,
switching repositories as necessary.
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: [PATCH setup] site.cc, site.h: code cleanup
On 11/22/2017 12:02 PM, Jon Turney wrote:
On 20/11/2017 01:26, Ken Brown wrote:
Remove site_list_type::init(), which was introduced to work around a
problem with gcc-2.95.
Please tell me we're not actually using a placement new for these things :S
Add a bool member 'is_official' to the site_list_type class. Use it
to distinguish official mirrors (listed in mirrors.lst) from
user-added sites. This replaces the (undocumented) use of
site_list_type::servername.size() for this purpose.
When registerSavedSite is called on a URL that's already in
'all_site_list', add the version from 'all_site_list' to 'site_list'
rather than adding a temporary version that contains no information
other than the URL.
Similarly, if the user adds a site that was already in
'all_site_list', don't replace the existent version with the new one
(which contains only the URL).
This is a nice bit of cleanup.
My only concern is with the terminology "is_offical".
In general, this code suffers from confusion between (i) package
repository [a set of packages], and (ii) mirrors [a set of sites
offering the same package repository]
(See also the musings in [1]. I have a vague recollection that I
actually started writing some code to do some of that, but that would be
in an old CVS checkout somewhere)
I agree with what you wrote there. A lot of things would be clearer if
we distinguished between mirrors of the Cygwin repo and general package
sources. Trying to use the two simultaneously is what's giving Brian a
headache in the "make setup mirror list..." thread.
We have the concept of a label for the package set ('release:' in
setup.ini [2])
To me "is_official" gives the idea that this flag means "the package set
at this URL is the package set with the label 'cygwin'", but actually it
just means "this URL was read from mirrors.lst", so maybe it could be
named something like that?
Yeah, maybe "from_mirrors_lst"?
Ken
Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP)
On 11/23/2017 1:10 PM, Jon Turney wrote:
On 06/09/2017 03:52, Ken Brown wrote:
On 9/5/2017 2:40 PM, Achim Gratz wrote:
Jon Turney writes:
Yeah, I'm not sure if putting the test packages into a separate repo
which is disabled unless explicitly enabled is the right approach.
(Instead, perhaps it is possible to tell the solver that certain
repositories are disfavoured)
At least for zypper, which is based on the same library:
You can give each repo a priority and it will pick the package from the
one with the highest priority, even if another repo has a higher
version.
Yes, that works.
It seems that, when test versions are enabled, a test version is
preferred over a non-test version with a higher version
I guess this is a consequence of:
void
SolverPool::use_test_packages(bool use_test_packages)
{
// Give repos containing test packages higher priority than normal
// if wanted, otherwise lower priority.
SolvRepo::priority_t p = use_test_packages ? SolvRepo::priorityHigh
: SolvRepo::priorityLow;
I wonder if we just want to give test repos priorityNormal when they are
wanted?
Yes, that sounds right to me.
Ken
Re: [ANNOUNCEMENT] Cygnal 2.8.99.97.
On 2017-11-23 10:28, Brian Inglis wrote: > On 2017-11-20 08:42, Kaz Kylheku wrote: >> Cygnal (http://www.kylheku.com/cygnal/) is a replacement for "cygwin1.dll" >> which >> provides native-Windows-app behaviors. >> >> The basic idea, scope and aim of the project is that programs built in the >> Cygwin environment with its native compiler can be deployed with Cygnal as >> native Windows programs. >> >> This is the first release of Cygnal since August 2016. >> >> In this release, Cygnal has been rebased to Cygwin 2.9.0, from the previous >> 2.5.2. > > This notice did not appear on cygwin-announce list. Nor should it have, as this is really off topic for this list. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP)
On 06/09/2017 03:52, Ken Brown wrote:
On 9/5/2017 2:40 PM, Achim Gratz wrote:
Jon Turney writes:
Yeah, I'm not sure if putting the test packages into a separate repo
which is disabled unless explicitly enabled is the right approach.
(Instead, perhaps it is possible to tell the solver that certain
repositories are disfavoured)
At least for zypper, which is based on the same library:
You can give each repo a priority and it will pick the package from the
one with the highest priority, even if another repo has a higher
version.
Yes, that works.
It seems that, when test versions are enabled, a test version is
preferred over a non-test version with a higher version
I guess this is a consequence of:
void
SolverPool::use_test_packages(bool use_test_packages)
{
// Give repos containing test packages higher priority than normal
// if wanted, otherwise lower priority.
SolvRepo::priority_t p = use_test_packages ? SolvRepo::priorityHigh :
SolvRepo::priorityLow;
I wonder if we just want to give test repos priorityNormal when they are
wanted?
Re: setup with experimental libsolv-based dependency solving
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: [ANNOUNCEMENT] Cygnal 2.8.99.97.
On 2017-11-20 08:42, Kaz Kylheku wrote: > Cygnal (http://www.kylheku.com/cygnal/) is a replacement for "cygwin1.dll" > which > provides native-Windows-app behaviors. > > The basic idea, scope and aim of the project is that programs built in the > Cygwin environment with its native compiler can be deployed with Cygnal as > native Windows programs. > > This is the first release of Cygnal since August 2016. > > In this release, Cygnal has been rebased to Cygwin 2.9.0, from the previous > 2.5.2. This notice did not appear on cygwin-announce list. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
