Re: setup: --prune-install appears to be broken

[ASSI via Cygwin]

David McFarland via Cygwin writes:
> If I do a base install to a new root:
>
> setup-x86_64.exe --root "$(cygpath -wa .cygtest)" --no-admin \
> --no-shortcuts --no-replaceonreboot --no-version-check \
> --prune-install --verbose
>
> And then run the same install again, I get:

You are misunderstanding what prune-install does: it ensures that only
the exact list of groups/packages that you give it for installation
(plus their dependencies) is installed when it finishes and you
literally said you want to end up with no packages at all.


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Updated: program-2.11.0-2

[Federico Kircheis]

Version 2.11.0-2 of cmus has been uploaded.

cmus is a command line audio player

Contrary to 2.11.0-1, this release enables some optional feature to 
support additional formats, like opus, wav, mpc, and cdio


Federico


--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: No Native Language Support in browser started from shell prompt

[Dr Bean via Cygwin]

On Mon, 17 Jun 2024, Dr Bean via Cygwin wrote:

> On Sun, 16 Jun 2024, Thomas Wolff via Cygwin wrote:
> 
> > 
> > Am 14.06.2024 um 09:37 schrieb Dr Bean via Cygwin:
> > > With qutebrowser and Microsoft Edge started from a cygwin shell prompt,
> > > there is no Native Language Support.
> > > 
> > > Started from a cmd prompt,
> > > 
> > > "c:\Program Files\qutebrowser\qutebrowser.exe" 
> > > https://ja.wikipedia.org/wiki/%E8%A5%BF%E6%97%A5%E6%9C%AC%E3%81%AE%E5%A4%A7%E5%AD%A6%E4%B8%80%E8%A6%A7
> > > 
> > > qutebrowser has Chinese and Japanese support.
> > > 
> > > But in cygwin neither qutebrowser, started with cygstart or
> > > as /cygdrive/c/Program\ Files/qutebrowser/qutebrowser
> > > https://ja.wikipedia.org/wiki/%E8%A5%BF%E6%97%A5%E6%9C%AC%E3%81%AE%E5%A4%A7%E5%AD%A6%E4%B8%80%E8%A6%A7
> > > 
> > > nor Microsoft Edge as default browser started with cygstart, enjoy NLS 
> > > support.
> > That page displays fine for me, after starting /Program Files
> > (x86)/Microsoft/Edge/Application/msedge.exe with cygstart. What exactly
> > is the symptom of "no Japanese support"?
> 
> I spoke too soon. Microsoft Edge doesn't appear to lack NLS support when 
> started from a mintty window either with cygstart or the /cygdrive path.

I installed Google Chrome, and Japanese and Korean 
keyboard entry appear to be supported by both IME when it is started 
from a mintty window with cygstart or directly with the cygdrive 
path.

So this appears to be a limitation specifically of qutebrowser.

I will investigate.

> qutebrowser, started from a mintty window with both cygstart and the /cygdrive
> path, does lack support.
> 
> But when started from a 'cmd' prompt as "c:\Program
> Files\qutebrowser\qutebrowser.exe" qutebrowser's NLS support
> doesn't differ from Edge's.
> 
> The 3 Japanese, Korean and Traditional Chinese MS IME I have on this Japanese
> Windows 10 computer have various ways of switching between ASCII (I guess)
> keyboard entry and kana, hangul and bopomo entry modes.
> 
> The Japanese switch is via the CapsLock key.
> The Korean switch is via clicking a task bar toggle next to the IME icon (?) 
> in
> the lower right hand corner.  The Traditional Chinese switch is Ctrl-Space
> 
> None of these toggle switches are responsive with qutebrowser started from a
> mintty window, and I can only input ASCII. (But they are when it's started 
> from
> the 'cmd' prompt or desktop.)
> 
> The Korean switch has a pop-up message in Japanese saying the switch is
> inoperative (or disabled.)
> 
> > > Of course the IME are working in the mintty bash shell and 'screen' 
> > > sessions.
> > > 
> > > I don't understand.
> > > 
> 
> Thanks for your work with mintty.
> 
> > 
> > -- 
> > Problem reports:  https://cygwin.com/problems.html
> > FAQ:  https://cygwin.com/faq/
> > Documentation:https://cygwin.com/docs.html
> > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
> 
> -- 
> Greg "Dr Bean" Matheson   Some are born autonomous. Some achieve
> http://drbean.sdf.org autonomy. And some have autonomy thrust
> drb...@freeshell.org  upon them. --Dr Bean
>   
> 
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

-- 
Greg "Dr Bean" Matheson Failed to turn my reluctant students into
http://drbean.sdf.org   autonomous language learners, but it did
drb...@freeshell.orgwonders for my personal fitness program.


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

setup: --prune-install appears to be broken

[David McFarland via Cygwin]

If I do a base install to a new root:

setup-x86_64.exe --root "$(cygpath -wa .cygtest)" --no-admin \
--no-shortcuts --no-replaceonreboot --no-version-check \
--prune-install --verbose

And then run the same install again, I get:

libsolv: orphaned packages:
libsolv:   base-0.0-0.any (erased)
libsolv:   _windows-10.0.19045.any (kept)
libsolv:
libsolv: ordering transaction
libsolv: transaction elements: 33
libsolv: edges: 41, edge space: 70
libsolv: edge creation took 0 ms
libsolv: cycles broken: 0
libsolv: cycle breaking took 0 ms
libsolv: invedge space: 76
libsolv: creating new transaction took 0 ms
libsolv: transaction ordering took 0 ms
libsolv: 33 erased packages:
libsolv:   - base-0.0-0.any
libsolv:   - ca-certificates-2023.2.62_v7.0.401-2.any
libsolv:   - cygutils-1.4.17-1.any
libsolv:   - file-5.44-1.any
libsolv:   - gawk-5.3.0-1.any
libsolv:   - groff-1.23.0-1.any
libsolv:   - less-643-1.any
libsolv:   - libfdisk1-2.39.3-2.any
libsolv:   - libffi6-3.2.1-2.any
libsolv:   - libgdbm6-1.18.1-1.any
libsolv:   - liblz4_1-1.9.4-1.any
libsolv:   - liblzma5-5.6.2-1.any
libsolv:   - libmpfr6-4.2.1-1.any
libsolv:   - libp11-kit0-0.23.20-1.any
libsolv:   - libpcre1-8.45-1.any
libsolv:   - libpipeline1-1.5.6-1.any
libsolv:   - libpopt-common-1.19-1.any
libsolv:   - libpopt0-1.19-1.any
libsolv:   - libsmartcols1-2.39.3-2.any
libsolv:   - libssl1.1-1.1.1w-1.any
libsolv:   - libssl3-3.0.14-1.any
libsolv:   - libstdc++6-11.4.0-1.any
libsolv:   - libtasn1_6-4.14-1.any
libsolv:   - libuchardet0-0.0.8-1.any
libsolv:   - libuuid1-2.39.3-2.any
libsolv:   - man-db-2.12.1-1.any
libsolv:   - openssl-3.0.14-1.any
libsolv:   - p11-kit-0.23.20-1.any
libsolv:   - p11-kit-trust-0.23.20-1.any
libsolv:   - tar-1.35-2.any
libsolv:   - util-linux-2.39.3-2.any
libsolv:   - xz-5.6.2-1.any
libsolv:   - zstd-1.5.6-1.any
libsolv:
Can't happen.  No packagemeta for base

The "Can't happen" error results in all following transactions being skipped:

// Can't happen - throw an exception?
{
  Log (LOG_PLAIN) << "Can't happen.  No packagemeta for "
  << pv.Name() << endLog;
  return;
}

This results in setup always showing no pending changes, even if you
have installed additional packages that should be pruned by
--prune-install, or if setup.ini has different contents.

The problem seems to be that we use SOLVER_ERASE jobs to remove all
non-base installed packages, and they take precedence over keeping the
pseudo-package 'base' installed.

Making the erase jobs weak seems to solve the problem:

diff --git a/libsolv.cc b/libsolv.cc
index 3f083a4..95f21a2 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -850,7 +850,7 @@ SolverSolution::tasksToJobs(SolverTasks , updateMode 
update, Queue )
   queue_push2(, SOLVER_INSTALL | SOLVER_SOLVABLE_PROVIDES, 
sv.name_id());
   break;
 case SolverTasks::taskUninstall:
-  queue_push2(, SOLVER_ERASE | SOLVER_SOLVABLE, sv.id);
+  queue_push2(, SOLVER_ERASE | SOLVER_WEAK | SOLVER_SOLVABLE, 
sv.id);
   break;
 case SolverTasks::taskReinstall:
   // we don't know how to ask solver for this, so we just add the erase

However, I'm not sure if this is a good idea. Perhaps it should only be
done for pruned packages, and not explicitly uninstalled ones. I did try
various things to strengthen the requirement on 'base', but had no luck.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple