TOMAS FABRIZIO ORSI writes:
> 2. Add a way to use the "real" upstream sources instead of our mirrored
> ones
>
>
> Isn't this eselect repository's default behaviour? Or am I misunderstanding?
> When I run "eselect repository list" I get the source repositories, not the
> mirrored ones.
>
>
> 2. Add a way to use the "real" upstream sources instead of our mirrored
> ones
Isn't this eselect repository's default behaviour? Or am I misunderstanding?
When I run "eselect repository list" I get the source repositories, not the
mirrored ones.
Is it using the mirrored one behind the
Florian Schmaus writes:
> [[PGP Signed Part:Undecided]]
> On 21/06/2023 17.56, Mike Gilbert wrote:
>> On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus wrote:
>>>
>>> On 20.06.23 19:26, Mike Gilbert wrote:
On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus wrote:
>
> On 20.06.23
>
> I think flow's idea to make the sync command configurable somehow
> would be sufficient, assuming there is demand for it.
I agree.
I'm glad Flow has their ideas straight.
By the way Flow, could you share the links of the repo/PR so that we can
follow the development along? I would love to
On Wed, Jun 21, 2023 at 12:47 PM TOMAS FABRIZIO ORSI wrote:
> I had not considered that possibility either. In that case, could not the
> overlay
> dependency resolution be handled as a module?
> Said module could be a common interface for different package managers.
> Then, the execution of
On Wed, Jun 21, 2023 at 12:49 PM Florian Schmaus wrote:
>
> On 21/06/2023 17.56, Mike Gilbert wrote:
> > On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus wrote:
> >>
> >> On 20.06.23 19:26, Mike Gilbert wrote:
> >>> On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus wrote:
>
> On
On 21/06/2023 17.56, Mike Gilbert wrote:
On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus wrote:
On 20.06.23 19:26, Mike Gilbert wrote:
On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus wrote:
On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
Isn't that duplicating the information of
>
> 1. As a developer, I might just want to create the repos.conf config
> snippet and sync the repo manually.
> 2. As a user, I might have any arbitrary reason for not wanting to
> sync immediately.
As a matter of fact, Michał Górny raised the same questions:
"A bit of a problem is how to design
On Wed, 21 Jun 2023 16:23:38 +0200
Jaco Kroon wrote:
> Hi Hans,
>
> On 2023/06/17 10:12, Hans de Graaff wrote:
> > After migrating to Wayland I no longer have a need for these X
> > packages. I have already removed myself as maintainer.
> >
> > x11-misc/xautolock
> >
> > Has one open bug that
On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus wrote:
>
> On 20.06.23 19:26, Mike Gilbert wrote:
> > On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus wrote:
> >>
> >> On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
> >>> Isn't that duplicating the information of metadata/layout.conf's
> >>>
On 20.06.23 19:26, Mike Gilbert wrote:
On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus wrote:
On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
Isn't that duplicating the information of metadata/layout.conf's
'master' key-value pair [1]?
Yes, I agree that it would be duplicating that
>
> $ sudo emerge --sync
> Unavailable repository 'foo' referenced by masters entry in
> '/var/db/repos/gentoo/metadata/layout.conf'
Oh! I was not aware of this feature. I apologize.
So, in theory, could '%s' be used to automatically enable the missing
repository
(if available in
On Wed, Jun 21, 2023 at 10:43 AM TOMAS FABRIZIO ORSI wrote:
>>
>> Sure, I think it could work.
>
> Great to hear.
> In that case I could try to give it a try and make a pull request to the
> emerge --sync with a basic idea.
> Any tips?
So emerge already emits a warning message when a repo is
>
> Sure, I think it could work.
Great to hear.
In that case I could try to give it a try and make a pull request to the
emerge --sync with a basic idea.
Any tips?
If anyone else is interested/free (I'm guessing the latter is unlikely
haha.) I'd love to have a helping hand!
Thank you for your
On 21/06/2023 16:12, TOMAS FABRIZIO ORSI wrote:
In any case, this is just something to keep in mind when writing this
check. It is not fully guaranteed that eselect repository can find the
repository that is requested in some master= entry.
Great point.
Btw, in your opinion, do you
Hi Hans,
On 2023/06/17 10:12, Hans de Graaff wrote:
After migrating to Wayland I no longer have a need for these X
packages. I have already removed myself as maintainer.
x11-misc/xautolock
Has one open bug that should be addressed upstream, but upstream is
pretty much dead:
>
> I just checked the internal overlays team guide[1] and it does
> explicitly say that repo_name should match the repositories.xml .
Oh, great news then. Thanks for checking. Also thank you overlays team!
That being said it is possible for the
> owner to change repo_name and (accidentally) not
On 21/06/2023 15:40, TOMAS FABRIZIO ORSI wrote:
What I meant is that emerge --sync/eix --sync does this check
instead of
eselect repository. To me this makes sense since we can only do this
check *after* syncing.
That is a great point; I had not considered it.
So, you are
>
> What I meant is that emerge --sync/eix --sync does this check instead of
> eselect repository. To me this makes sense since we can only do this
> check *after* syncing.
That is a great point; I had not considered it.
So, you are saying to have emerge --sync/eix --sync check the masters
key
# Fabian Groffen (2023-06-21)
# Ancient OSX integration package, not keyworded for any current arch
# Removal on 2023-07-21. Bug #908938.
x11-themes/gtk-engines-quartz
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
On 21/06/2023 04:17, TOMAS FABRIZIO ORSI wrote:
A warning could be a great way of making the user aware of this situation.
Having said that, if eselect repository is able to check and warn the
user of a not synced overlay(ies) dependency, then the hard bit is done
What I meant is that emerge
21 matches
Mail list logo
