Do you mean STIBP?
It is alreasy disabled by default in 4.19 and 4.20.
ср, 9 янв. 2019 г. в 01:55, Joseph D. Wagner :
>
> IIRC, there is major performance degradation (anti-Spectre) in 4.20 that will
> be turned off by default 4.21.
>
> Will it be turned off by default in the 4.20 rebase?
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=1627091
Petr Pisar changed:
What|Removed |Added
Summary|perl-Tk-804.034-4.fc29 will |perl-Tk-804.034-4.fc29 will
On 1/8/19 6:51 PM, Tim Landscheidt wrote:
Petr Šabata wrote:
Adding
BuildRequires: glibc-all-langpacks
to all the *.specs obviously fixes this issue. However, I doubt this is
right, because I think these warnings originate from some rpm-internal
scripts and not from the packages.
I suspect
https://fedorapeople.org/groups/389ds/ci/nightly/2019/01/09/report-389-ds-base-1.4.0.20-20190109gita9ed1e6.fc29.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
Hi,
I was looking at the installer inf file, and noticed a new parameter:
[backend-userroot]
# require_index (bool)
# Description: Sets this parameter to "True" to refuse unindexed searches in
this database.
# Default value: False
;require_index = False
What does this feature relate to and how
Dear all,
You are kindly invited to the meeting:
Fedora koji outage on 2019-01-11 from 00:00:00 to 00:00:00 UTC
The meeting will be about:
Planned Outage - Koji Services - 2019-01-11 22:00 UTC
There will be an koji outage starting at 2019-01-11 22:00 UTC,
which will last approximately
IIRC, there is major performance degradation (anti-Spectre) in 4.20 that
will be turned off by default 4.21.
Will it be turned off by default in the 4.20 rebase?
Joseph D. Wagner
On 2019-01-08 14:31, Justin Forbes wrote:
> The 4.20 kernel was released just before the end of the year, but
> "RH" == Robbie Harwood writes:
RH> Ah, I see, you're talking about the case when the enctype is already
RH> not permitted. That all makes sense then.
Right. Basically, if any one of these:
* Warnings in previous versions about principals without modern etypes
* Logging in the new
The 4.20 kernel was released just before the end of the year, but the
first stable update should be dropping in the next day or two. We
have a 4.20 test day scheduled for Tuesday, January 15th. Depending
on the results of that test day, Fedora 29 will be rebased very
shortly afterwards, followed
On Tue, Jan 8, 2019 at 8:50 AM Matthew Miller wrote:
>
> On Tue, Jan 08, 2019 at 04:22:39PM +0100, Lennart Poettering wrote:
> > > The additional information could be
> > > 10.5.124.209 - - [31/Dec/2018:09:07:21 +] "GET
> > > /metalink?repo=fedora-28=x86_64==
> > > HTTP/1.1" 200 62200 "-"
Jason L Tibbitts III writes:
>> "RH" == Robbie Harwood writes:
>>>
>>> Well certainly there isn't much you can do to fix old principals on
>>> existing systems. But the current versions should be complaining
>>> loudly when it has to issue a ticket for a principal that lacks a
>>> modern
On Tue, Jan 08, 2019 at 12:28:51PM -0500, Owen Taylor wrote:
> * Reduce some confusion. A Flatpak is a module, but it’s *also* a
> container, and the dist-git repository will include files for both.
I'm +1 to this for this reason. I think it's less confusing than the
downside loose-module
This is a reminder that this begins this Friday and will probably be in
place for 4 days. If there are increased downtimes, we will update the data
when we know it.
On Fri, 7 Dec 2018 at 14:51, Stephen John Smoogen wrote:
> Planned Outage - Koji Services - 2019-01-11 22:00 UTC
>
> There will be
On Tue, 2019-01-08 at 09:59 -0500, Owen Taylor wrote:
> On Tue, Jan 8, 2019 at 7:17 AM Benjamin Berg wrote:
> > On Tue, 2019-01-08 at 12:33 +0100, Miroslav Suchý wrote:
> > > Dne 08. 01. 19 v 11:35 Nicolas Mailhot napsal(a):
> > > > *which* *do* *not* *permit* *or* *no* *longer* *permit* *the*
>
Upstream changed [1] from GPLv3 to dual licenses, MIT or BSD, which is
now released and in rawhide: rust-lru_time_cache-0.8.1-1.fc30
[1]: https://github.com/maidsafe/lru_time_cache/pull/103
___
devel mailing list -- devel@lists.fedoraproject.org
To
On Mon, Jan 07, 2019 at 09:42:00AM -0500, Ben Cotton wrote:
> Update GNOME to the latest upstream release, 3.32.
Does this release feature the new lockscreen Allan Day was working on?
https://blogs.gnome.org/aday/2018/05/09/redesigning-the-lock-screen/
I hope so because I love it, but, also:
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags
== Summary ==
The build flags (CFLAGS, CXXFLAGS and
LDFLAGS) saved in the Python's distutils module for
building extension modules are switched from:
* %{build_cflags},
* %{build_cxxflags} and
* %{build_ldflags}
to:
*
https://fedoraproject.org/wiki/Changes/Reset-locale-if-not-available
== Summary ==
When logging in over ssh or another mechanism, locale settings are
forwarded. If the destination does not support that locale, C.UTF-8
will be used instead.
== Owner ==
* Name: [[User:Zbyszek | Zbigniew
https://fedoraproject.org/wiki/Changes/Reset-locale-if-not-available
== Summary ==
When logging in over ssh or another mechanism, locale settings are
forwarded. If the destination does not support that locale, C.UTF-8
will be used instead.
== Owner ==
* Name: [[User:Zbyszek | Zbigniew
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags
== Summary ==
The build flags (CFLAGS, CXXFLAGS and
LDFLAGS) saved in the Python's distutils module for
building extension modules are switched from:
* %{build_cflags},
* %{build_cxxflags} and
* %{build_ldflags}
to:
*
I wrote:
> […]
> Adding:
> | config_opts['environment']['LANG'] = 'C'
> to ~/.config/mock.cfg seems to solve that.
That was meant to say:
| config_opts['environment']['LANG'] = 'LANG=C.UTF-8'
Tim
___
perl-devel mailing list --
Dear all,
You are kindly invited to the meeting:
EPEL Steering Co on 2019-01-09 from 18:00:00 to 19:00:00 GMT
At freenode@fedora-meeting
The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. Agenda is in the
Petr Šabata wrote:
>> > Adding
>> > BuildRequires: glibc-all-langpacks
>> > to all the *.specs obviously fixes this issue. However, I doubt this is
>> > right, because I think these warnings originate from some rpm-internal
>> > scripts and not from the packages.
>> I suspect you're running
On Tue, Jan 08, 2019 at 06:02:48PM +0100, Petr Šabata wrote:
> On Tue, Jan 08, 2019 at 05:58:35PM +0100, Emmanuel Seyman wrote:
> > * Ralf Corsepius [08/01/2019 17:33] :
> > >
> > > Adding
> > > BuildRequires: glibc-all-langpacks
> > > to all the *.specs obviously fixes this issue. However, I
On Tue, Jan 8, 2019, at 11:15 AM, Stephen Gallagher wrote:
> On Tue, Jan 8, 2019 at 10:50 AM Matthew Miller
> wrote:
> >
> > On Tue, Jan 08, 2019 at 04:22:39PM +0100, Lennart Poettering wrote:
> > > > The additional information could be
> > > > 10.5.124.209 - - [31/Dec/2018:09:07:21 +] "GET
Currently, the content for a Flatpak in Fedora can be found in
modules/. E.g.:
https://src.fedoraproject.org/modules/quadrapassel/tree/master - I’d
like to propose creating a separate namespace in src.fedoraproject.org
- flatpaks/
Benefits:
* Allow automation to easily distinguish Flatpaks from
OLD: Fedora-Rawhide-20190107.n.0
NEW: Fedora-Rawhide-20190108.n.0
= SUMMARY =
Added images:5
Dropped images: 4
Added packages: 2
Dropped packages:3
Upgraded packages: 142
Downgraded packages: 0
Size of added packages: 1.68 MiB
Size of dropped packages
On 1/7/19 2:28 PM, Matthew Miller wrote:
On Mon, Jan 07, 2019 at 06:24:14PM +0100, Lennart Poettering wrote:
* The Fedora community cares about privacy and is adverse to tracking
measures. We don't want to track; just count.
Uh, so what's the story there? i mean, if you pass over the uuid you
On Tue, Jan 08, 2019 at 05:58:35PM +0100, Emmanuel Seyman wrote:
> * Ralf Corsepius [08/01/2019 17:33] :
> >
> > Adding
> > BuildRequires: glibc-all-langpacks
> > to all the *.specs obviously fixes this issue. However, I doubt this is
> > right, because I think these warnings originate from some
* Ralf Corsepius [08/01/2019 17:33] :
>
> Adding
> BuildRequires: glibc-all-langpacks
> to all the *.specs obviously fixes this issue. However, I doubt this is
> right, because I think these warnings originate from some rpm-internal
> scripts and not from the packages.
I suspect you're running
On Tue, Jan 8, 2019 at 12:52 PM wrote:
>
> A new Fedora Atomic Host update is available via an OSTree update:
>
> Version: 29.20190107.0
> Commit(x86_64):
> 822093aa47c985d24d5f3a40ad213d68f7734be3bff872c757d39315048691a4
> Commit(aarch64):
>
On Tue, Jan 8, 2019 at 11:42 AM Benjamin Berg wrote:
>
> Hi,
>
> On Tue, 2019-01-08 at 10:49 -0500, Matthew Miller wrote:
> > On Tue, Jan 08, 2019 at 04:22:39PM +0100, Lennart Poettering wrote:
> > > > The additional information could be
> > > > 10.5.124.209 - - [31/Dec/2018:09:07:21 +] "GET
Hi,
On Tue, 2019-01-08 at 10:49 -0500, Matthew Miller wrote:
> On Tue, Jan 08, 2019 at 04:22:39PM +0100, Lennart Poettering wrote:
> > > The additional information could be
> > > 10.5.124.209 - - [31/Dec/2018:09:07:21 +] "GET
> > > /metalink?repo=fedora-28=x86_64==
> > > HTTP/1.1" 200 62200
Hi,
ATM, many (all?) of my perl packages raise several warnings of the kind
below, when building them in mock:
...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
On Tue, 8 Jan 2019 at 00:30, Christopher Tubbs
wrote:
> A few concerns/comments (inline):
>
> > === The problem ===
> >
> > * A. Currently, we can only count Fedora OS use by observing IP
> > addresses. This is subject to undercounting due to NAT — and to
> > overcounting due to short DHCP
On Tue, Jan 8, 2019 at 10:50 AM Matthew Miller wrote:
>
> On Tue, Jan 08, 2019 at 04:22:39PM +0100, Lennart Poettering wrote:
> > > The additional information could be
> > > 10.5.124.209 - - [31/Dec/2018:09:07:21 +] "GET
> > > /metalink?repo=fedora-28=x86_64==
> > > HTTP/1.1" 200 62200 "-"
On Tue, Jan 08, 2019 at 04:25:25PM +0100, Lennart Poettering wrote:
> And let me also stress that if you do it this way there's a better
> chance that people will leave this on, since you won't raise red flags
> all over the place that you can track individual users with this.
Yeah, absolutely!
No missing expected images.
Compose FAILS proposed Rawhide gating check!
3 of 47 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 13/131 (x86_64), 2/24 (i386), 1/2 (arm)
New failures (same test not
On Tue, Jan 08, 2019 at 04:22:39PM +0100, Lennart Poettering wrote:
> > The additional information could be
> > 10.5.124.209 - - [31/Dec/2018:09:07:21 +] "GET
> > /metalink?repo=fedora-28=x86_64==
> > HTTP/1.1" 200 62200 "-" "dnf/2.7.5"
> If all you want to do is count, then it should be
=
#fedora-meeting-3: Weekly Meeting of the Modularity Working Group
=
Meeting started by nils at 15:00:06 UTC.
Minutes:
On Thu, 2018-11-08 at 09:41 -0500, Randy Barlow wrote:
> FWIW, I am beginning to work on a proposal for a new updates policy
> and
> I plan for this to be part of it - the update will by default go
> stable
> unless a human stops it.
I have filed a FESCo ticket to request this change to the
On Di, 08.01.19 16:22, Lennart Poettering (mzerq...@0pointer.de) wrote:
> On Di, 08.01.19 07:49, Stephen John Smoogen (smo...@gmail.com) wrote:
>
> > The additional information could be
> >
> > 10.5.124.209 - - [31/Dec/2018:09:07:21 +] "GET
> > /metalink?repo=fedora-28=x86_64==
> > HTTP/1.1"
On Di, 08.01.19 07:49, Stephen John Smoogen (smo...@gmail.com) wrote:
> The additional information could be
>
> 10.5.124.209 - - [31/Dec/2018:09:07:21 +] "GET
> /metalink?repo=fedora-28=x86_64==
> HTTP/1.1" 200 62200 "-" "dnf/2.7.5"
If all you want to do is count, then it should be entirely
On Tue, Jan 8, 2019 at 7:17 AM Benjamin Berg wrote:
>
> On Tue, 2019-01-08 at 12:33 +0100, Miroslav Suchý wrote:
> > Dne 08. 01. 19 v 11:35 Nicolas Mailhot napsal(a):
> > > *which* *do* *not* *permit* *or* *no* *longer* *permit* *the*
> > > *identification* *of* *data* *subjects*
> >
> > How do
On Tue, 8 Jan 2019 at 06:23, Miroslav Suchý wrote:
>
> Dne 08. 01. 19 v 11:14 Reindl Harald napsal(a):
> > but the UUID is sent over TCP and so you receive the current IP at the
> > same time with the UUID and that way you can even pofile how that
> > machine is moved around the country
>
> But
On Tue, 8 Jan 2019 at 03:43, Lennart Poettering wrote:
>
> On Mo, 07.01.19 16:58, Stephen John Smoogen (smo...@gmail.com) wrote:
>
> > > I wonder if it is worth introducing an entirely new tracking concept
> > > here if you actually don't want to track but just count. The NTP
> > > approach has
On 1/7/19 8:56 AM, Miro Hrončok wrote:
> On 07. 01. 19 15:52, Gwyn Ciesla wrote:>>
> pygtk2 alexl, alt-gtk-de-sig, 0
>>> weeks ago
>>> caillon, caolanm, gnome-sig,
>>> johnp, orphan,
https://pagure.io/389-ds-base/pull-request/50131
--
Marc Muehlfeld (Senior Technical Writer)
Customer Content Services
___
Red Hat GmbH, Werner-von-Siemens-Ring 14, 85630 Grasbrunn, Germany
http://www.de.redhat.com/,
On Tue, Jan 08, 2019 at 09:30:56AM +0100, Miroslav Suchý wrote:
> How Mock should handle this? DNF executed by Mock cannot send VERSION_ID
> and VARIANT_ID of chroot(ed) environment because they are not know yet.
> I think the question in general is - how to put tracking of build systems
> aside?
Le 2019-01-08 13:42, Kevin Kofler a écrit :
Nicolas Mailhot wrote:
1. it needs to be opt-out not opt-in (ie an explicit question in the
installer, with no tracking unless the user says yes)
I think you mean "opt-in not opt-out". (At least, that's what your
explanation in the parentheses
On Mon, 7 Jan 2019 at 22:47, Kevin Kofler wrote:
>
> Matthew Miller wrote:
> > Since there is no personal information attached, I don't see how on the
> > face of it this is a privacy violation. I want to take this concern
> > seriously, but I need more to go on than "this is inherent". Can you
>
Nicolas Mailhot wrote:
> 1. it needs to be opt-out not opt-in (ie an explicit question in the
> installer, with no tracking unless the user says yes)
I think you mean "opt-in not opt-out". (At least, that's what your
explanation in the parentheses describes.)
Other than that apparent typo, I
Le 2019-01-08 12:33, Miroslav Suchý a écrit :
Dne 08. 01. 19 v 11:35 Nicolas Mailhot napsal(a):
*which* *do* *not* *permit* *or* *no* *longer* *permit* *the*
*identification* *of* *data* *subjects*
How do you identify data subject solely on UUID?
Art 26 makes it pretty clear that reversing
On Tue, 2019-01-08 at 12:33 +0100, Miroslav Suchý wrote:
> Dne 08. 01. 19 v 11:35 Nicolas Mailhot napsal(a):
> > *which* *do* *not* *permit* *or* *no* *longer* *permit* *the*
> > *identification* *of* *data* *subjects*
>
> How do you identify data subject solely on UUID?
You also inherently
Hello everyone,
FOSDEM[0], the biggest free and non-commercial event organized by and for the
community in Europe, is less than a month away. The conference will be held in
Brussels, Belgium, on February 2 & 3. As every year, EMEA Ambassadors organize
the booth at FOSDEM, where many
Dne 08. 01. 19 v 11:35 Nicolas Mailhot napsal(a):
> *which* *do* *not* *permit* *or* *no* *longer* *permit* *the*
> *identification* *of* *data* *subjects*
How do you identify data subject solely on UUID?
Miroslav
___
devel mailing list --
On 1/8/19 1:06 PM, Peter Robinson wrote:
Dne 08. 01. 19 v 10:10 Zbigniew Jędrzejewski-Szmek napsal(a):
I an IP address qualifies as "personal data", then an installation UUID does
too.
IANAL but I disagree. With IP address, I can very easily guess your
town/village. With more effort I can
Dne 08. 01. 19 v 11:14 Reindl Harald napsal(a):
> but the UUID is sent over TCP and so you receive the current IP at the
> same time with the UUID and that way you can even pofile how that
> machine is moved around the country
But it is not - or to be precise - will not be stored as couple, so
> Dne 08. 01. 19 v 10:10 Zbigniew Jędrzejewski-Szmek napsal(a):
> > I an IP address qualifies as "personal data", then an installation UUID
> > does too.
>
> IANAL but I disagree. With IP address, I can very easily guess your
> town/village. With more effort I can track you to
> individual house
Find below a list of topics which are planned to be discussed in the
Fedora Modularity Working Group meeting on Tuesday at 15:00 UTC in
#fedora-meeting-3 on irc.freenode.net.
To find out when this is in your local time zone, check the Fedora
Calendar (if you've set it and are logged in):
On 08/01/2019 10:38, Lennart Poettering wrote:
Also, you want to use standard primitives, and a HMAC is one that is
designed for purposes like this. For the reasons why a HMAC is
constructed the way it is, read the wikipedia page.
Well it's constructed the way it is (as wikipedia explains) to
https://bugzilla.redhat.com/show_bug.cgi?id=1664256
Paul Howarth changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
On Di, 08.01.19 10:11, Richard Hughes (hughsi...@gmail.com) wrote:
> On Tue, 8 Jan 2019 at 08:57, Lennart Poettering wrote:
> > Yes, Tom's proposal makes sense. Calculate the UUID you submit as
> > HMAC(machined_id, CONCAT(fixedappuuid, unixtime/432000))
>
> Out of interest, how is using a
Le 2019-01-08 11:17, Miroslav Suchý a écrit :
Dne 08. 01. 19 v 11:04 Miroslav Suchý napsal(a):
IANAL but I disagree. With IP address, I can very easily guess your
town/village. With more effort I can track you to
individual house and individual device.
You cannot say the same about UUID.
I
Dne 08. 01. 19 v 11:04 Miroslav Suchý napsal(a):
> IANAL but I disagree. With IP address, I can very easily guess your
> town/village. With more effort I can track you to
> individual house and individual device.
> You cannot say the same about UUID.
I just checked and UUID is definitelly under
On Tue, 8 Jan 2019 at 08:57, Lennart Poettering wrote:
> Yes, Tom's proposal makes sense. Calculate the UUID you submit as
> HMAC(machined_id, CONCAT(fixedappuuid, unixtime/432000))
Out of interest, how is using a HMAC different to just using the
machine-id appended with a salt, sha256'd?
Hi,
On Tue, 2019-01-08 at 10:06 +0100, Nicolas Mailhot wrote:
> You can turn it all the way you like getting accurate counts means
> disambiguating systems which means tracking, regardless if you do it
> in a central way or via system agents.
No, you do not need to track individual machines.
Dne 08. 01. 19 v 10:10 Zbigniew Jędrzejewski-Szmek napsal(a):
> I an IP address qualifies as "personal data", then an installation UUID does
> too.
IANAL but I disagree. With IP address, I can very easily guess your
town/village. With more effort I can track you to
individual house and
https://bugzilla.redhat.com/show_bug.cgi?id=1664253
--- Comment #3 from Fedora Update System ---
perl-File-Temp-0.230.900-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-e5b3682470
--
You are receiving this mail because:
You are on the
https://bugzilla.redhat.com/show_bug.cgi?id=1664253
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|
Le 2019-01-08 04:00, Matthew Miller a écrit :
On Mon, Jan 07, 2019 at 11:09:48PM +0100, Kevin Kofler wrote:
Please no! This is an inherent privacy violation. I hate software
doing this
and I always opt out of it. I find it especially worrying that Free
Software
is now doing this more and more
On Mon, Jan 07, 2019 at 10:00:25PM -0500, Matthew Miller wrote:
> On Mon, Jan 07, 2019 at 11:09:48PM +0100, Kevin Kofler wrote:
> > Please no! This is an inherent privacy violation. I hate software doing
> > this
> > and I always opt out of it. I find it especially worrying that Free
> >
Le 2019-01-07 23:44, John Harris a écrit :
On Monday, January 7, 2019 5:20:55 PM EST Bruno Wolff III wrote:
On Mon, Jan 07, 2019 at 22:54:46 +0100, Tom Gundersen
wrote:
So this allows better tracking than if you just had to go by IP, time
and
other information in the requests.
Keep in
Dne 08. 01. 19 v 0:11 Miro Hrončok napsal(a):
> On 07. 01. 19 18:13, Vít Ondruch wrote:
>> Nice, so the script is broken and does not report the dependencies
>> correctly [1] and now js-jquery2 went unnoticed and get retired although
>> it is required by rubygem-jquery-rails, similarly to
On Mo, 07.01.19 22:54, Tom Gundersen (t...@jklm.no) wrote:
> On Mon, Jan 7, 2019, 7:31 PM Matthew Miller
> wrote:
>
> > On Mon, Jan 07, 2019 at 06:24:14PM +0100, Lennart Poettering wrote:
> > > > * The Fedora community cares about privacy and is adverse to tracking
> > > > measures. We don't
https://bugzilla.redhat.com/show_bug.cgi?id=1664256
Bug ID: 1664256
Summary: Upgrade perl-Test-Simple to 1.302156
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Test-Simple
Assignee: p...@city-fan.org
https://bugzilla.redhat.com/show_bug.cgi?id=1664253
Bug ID: 1664253
Summary: Upgrade perl-File-Temp to 0.2309
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-File-Temp
Assignee: ppi...@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1664255
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=1664255
Bug ID: 1664255
Summary: Upgrade perl-File-Temp to 0.2309
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-File-Temp
Assignee: ppi...@redhat.com
On Mo, 07.01.19 16:58, Stephen John Smoogen (smo...@gmail.com) wrote:
> > I wonder if it is worth introducing an entirely new tracking concept
> > here if you actually don't want to track but just count. The NTP
> > approach has the benefit that you introduce no new tracking concept at
> > all,
> > Not if we don't keep them for long. One idea is to rotate them fairly
> > frequently. But this is mostly a statement of intent and might be more about
> > how we build the backend than about what we force in the client.
>
> My understanding is that the Fedora project does not control how much
Dne 07. 01. 19 v 17:34 Ben Cotton napsal(a):
> * We need to be able to distinguish between short-lived instances
> (like temporary containers or test machines) and actual installations.
How Mock should handle this? DNF executed by Mock cannot send VERSION_ID and
VARIANT_ID of chroot(ed)
* Matthew Miller:
> Not if we don't keep them for long. One idea is to rotate them fairly
> frequently. But this is mostly a statement of intent and might be more about
> how we build the backend than about what we force in the client.
My understanding is that the Fedora project does not control
83 matches
Mail list logo
