On 20/11/2022 17:16, Jon Turney wrote:
On 13/11/2022 12:47, Achim Gratz wrote:
The problem is actually a more knotty than you seem to think:
prominently ca-certificates and man-db get their knickers in a twist
when the group during post-install is different from the group of the
installed files
Christian Franke writes:
> Anything installed with "All Users" option should IMO be protected
> against modifications by any regular non-elevated user.
Yes.
> This is not the case if the RID=513 group ("HOST\None",
> "DOMAIN\Domain-Users") is used. Many upstream projects install
> directories and
Jon Turney wrote:
On 20/11/2022 19:05, Achim Gratz wrote:
Jon Turney writes:
I believe that the intent of the code in setup is that there should
only be two modes:
USER: install "for me", with the users primary group
As I understand it, the intention here was that the user can have a
"single
On 20/11/2022 19:05, Achim Gratz wrote:
Jon Turney writes:
I believe that the intent of the code in setup is that there should
only be two modes:
USER: install "for me", with the users primary group
As I understand it, the intention here was that the user can have a
"single user installation"
On Nov 21 13:39, ASSI wrote:
> Corinna Vinschen writes:
> > The idea is that the installation tree has POSIXy permissions and
> > administrative users have the right to change stuff. The administrators
> > group is part of the user's token if the process has been started
> > elevated, so, to me, t
Corinna Vinschen writes:
> The idea is that the installation tree has POSIXy permissions and
> administrative users have the right to change stuff. The administrators
> group is part of the user's token if the process has been started
> elevated, so, to me, this looks like a natural choice.
As I
On Nov 20 20:05, Achim Gratz wrote:
> Jon Turney writes:
> > I believe that the intent of the code in setup is that there should
> > only be two modes:
> >
> > USER: install "for me", with the users primary group
>
> As I understand it, the intention here was that the user can have a
> "single use
Jon Turney writes:
> I believe that the intent of the code in setup is that there should
> only be two modes:
>
> USER: install "for me", with the users primary group
As I understand it, the intention here was that the user can have a
"single user installation" in a place that they have access to
On 13/11/2022 12:47, Achim Gratz wrote:
The problem is actually a more knotty than you seem to think:
prominently ca-certificates and man-db get their knickers in a twist
when the group during post-install is different from the group of the
installed files and I suspect some other packages will r
Jon Turney writes:
> On 08/10/2022 17:56, Achim Gratz wrote:
>> I think that setup was essentially treating the install as "for this
>> user only" since it was created and maintained by a script that can't
>> affect that option and the fact it was also in group Adminsitroators
>> didn't actually re
Jon Turney writes:
> On 08/10/2022 17:56, Achim Gratz wrote:
>> I think that setup was essentially treating the install as "for this
>> user only" since it was created and maintained by a script that can't
>> affect that option and the fact it was also in group Adminsitroators
>> didn't actually re
On 08/10/2022 17:56, Achim Gratz wrote:
I think that setup was essentially treating the install as "for this
user only" since it was created and maintained by a script that can't
affect that option and the fact it was also in group Adminsitroators
didn't actually register until now.
Yeah, that
Jon Turney writes:
> On 03/10/2022 20:23, Achim Gratz wrote:
>> Jon Turney writes:
>>> This problem is with files created by setup, or by post-install scripts?
>> I think both, although the problematic symlinks were created through
>> alternatives.
>
> That's pretty baffling.
Even more baffling is
On 03/10/2022 20:23, Achim Gratz wrote:
Jon Turney writes:
This problem is with files created by setup, or by post-install scripts?
I think both, although the problematic symlinks were created through
alternatives.
That's pretty baffling.
I don't see how any of those commits would change th
Achim Gratz writes:
>> Can you confirm if this fixes package selection for you?
>
> I'll have to setup a test installation to check this. I am currently
> short on time, but I will try to wedge it in somehow.
I wasn't able to do an exhaustive test, but the fix seems to be
effective for the two sc
Jon Turney wrote:
On 27/09/2022 14:51, Christian Franke wrote:
Christian Franke wrote:
...
I made the false assumption that default_version=empty in
set_action() always implies that the default version is not
accessible. This is not the case for packages selected for
installation before choo
Jon Turney writes:
> This problem is with files created by setup, or by post-install scripts?
I think both, although the problematic symlinks were created through
alternatives.
> (I'm not sure how these commits could have caused the former, if the
> latter then reverting 45d8e84e "Drop group chan
Jon Turney writes:
> Achim,
>
> Can you confirm if this fixes package selection for you?
I'll have to setup a test installation to check this. I am currently
short on time, but I will try to wedge it in somehow.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofe
On 22/09/2022 18:14, Achim Gratz wrote:
The release_2.91 comes with another regression that still puzzles me.
In a nutshell, the three commits that deal with setting up the groups
during / after installation
2022-08-27 Jon Turney Drop setting root_scope as a side-effect of
read_mount
On 27/09/2022 14:51, Christian Franke wrote:
Christian Franke wrote:
...
I made the false assumption that default_version=empty in set_action()
always implies that the default version is not accessible. This is not
the case for packages selected for installation before chooser is
visible.
I
Christian Franke wrote:
...
I made the false assumption that default_version=empty in set_action()
always implies that the default version is not accessible. This is not
the case for packages selected for installation before chooser is
visible.
I'm working on a new fix for the "Ctrl+I presse
Jon Turney wrote:
On 22/09/2022 17:56, Achim Gratz wrote:
Achim Gratz writes:
Achim Gratz writes:
I had updated setup to 2.921 recently, so I rolled it back to 2.920
and
this version does the package selection correctly. I haven't yet
looked
what commit is responsible, but whatever the cause
On 22/09/2022 17:56, Achim Gratz wrote:
Achim Gratz writes:
Achim Gratz writes:
I had updated setup to 2.921 recently, so I rolled it back to 2.920 and
this version does the package selection correctly. I haven't yet looked
what commit is responsible, but whatever the cause of the regression i
The release_2.91 comes with another regression that still puzzles me.
In a nutshell, the three commits that deal with setting up the groups
during / after installation
2022-08-27 Jon Turney Drop setting root_scope as a side-effect of
read_mounts()
2022-08-16 Jon Turney Defer
Achim Gratz writes:
> Achim Gratz writes:
>> I had updated setup to 2.921 recently, so I rolled it back to 2.920 and
>> this version does the package selection correctly. I haven't yet looked
>> what commit is responsible, but whatever the cause of the regression is
>> still in 2.922 as well.
>
>
Achim Gratz writes:
> I had updated setup to 2.921 recently, so I rolled it back to 2.920 and
> this version does the package selection correctly. I haven't yet looked
> what commit is responsible, but whatever the cause of the regression is
> still in 2.922 as well.
The most likely change respon
Today I did a new installation of Cygwin @work and setup correctly
registered around 1500 packages as "manually selected" (I have a
setup.ini that has all packages to be installed in one group and setup
gets asked to install this group), then somehow decided to only install
75 of those. In other
27 matches
Mail list logo
