There is a further optimization for file dependencies not in some whitelist
that might be undertaken by depsolvers like dnf: lookup the path in the already
installed packages.
The fundamental need for depsolvers resolving a dependency is the ability to
traverse a mapping from path to package in
On 08/08/2018 11:45 PM, Samuel Sieb wrote:
Except that it doesn't quite solve it. What happens if a third party
repo package depends on a file that is not included in the Fedora
whitelist? It doesn't help that the other repo has that file path in
its whitelist, dnf won't be able to resolve t
Perhaps you do not understand the implications of "maintained" wrto a whitelist.
A cross repository file dependency should lead to a request to add a path or
pattern to a whitelist for the other repository to provide a file path, not to
a lazy download of megabytes of mostly unused data "just in
On Wed, Aug 8, 2018 at 7:09 PM Pascal Terjan wrote:
>
> On 7 August 2018 at 09:50, Michael Schroeder wrote:
> > On Mon, Aug 06, 2018 at 04:36:07PM +, Zbigniew J??drzejewski-Szmek
> > wrote:
> >> this mail is a continuation of an FPC [1] and a FESCo [2] tickets.
> >>
> >> A proposal was made
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-08-09 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. uitime):
= Day: Thursday ==
2018-08-09 09:00 PDT US/Pacific
2018-08-0
The Fedora today, there was a presentation about a vision for how
applications should have a different life cycle than the operating system:
https://flock2018.sched.com/event/Fjdk/at-long-last-rings-split-lifecycles
For Flatpaks, the future is now - as soon as we start building them, I'd
like to
Michael Schroeder wrote:
> I don't think this is hard to implement, but there's a little detail
> that needs to be discussed: what should happen if the filelists.xml
> download fails? This can happen because the metadata has been rewritten
> in the meantime.
Doesn't that race condition already ex
On 08/08/2018 01:48 PM, Jeff Johnson wrote:
Adding -- and maintaining -- patterns or whitelist exceptions, which moves file
dependencies into primary.xml is actually an approach that solves the problem,
and scales to multiple repos as well, each of which also will have their own
patterns and w
On Wednesday, August 08 2018, I wrote:
> On Wednesday, August 08 2018, I wrote:
>
>> Hi,
>>
>> libipt v2.0 has been released yesterday and there was an SONAME bump
>> (from 1.6 to 2.0). According to 'dnf repoquery --whatrequires libipt',
>> only two packages depend on it:
>>
>> - GDB
>> - Insight
My issue is the misdirection discussing lazy filelist downloading as a
"solution" to the "problem" of huge amounts of data that is forced to be
downloaded and loaded.
The issue has been discussed repeatedly without a solution.
Adding -- and maintaining -- patterns or whitelist exceptions, which
On Wednesday, August 08 2018, I wrote:
> Hi,
>
> libipt v2.0 has been released yesterday and there was an SONAME bump
> (from 1.6 to 2.0). According to 'dnf repoquery --whatrequires libipt',
> only two packages depend on it:
>
> - GDB
> - Insight
>
> I am the Fedora GDB maintainer and will rebuil
On 07/11/2018 04:07 AM, Peter Robinson wrote:
On Tue, Jul 10, 2018 at 9:51 PM, Cole Robinson wrote:
On 07/10/2018 04:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jul 03, 2018 at 10:14:43PM -0700, Thomas Daede wrote:
On 07/03/2018 05:15 AM, Jan Kurik wrote:
Move to uEFI as the default bo
Hi,
libipt v2.0 has been released yesterday and there was an SONAME bump
(from 1.6 to 2.0). According to 'dnf repoquery --whatrequires libipt',
only two packages depend on it:
- GDB
- Insight
I am the Fedora GDB maintainer and will rebuild it now. I am also
Cc'ing the insight maintainer in thi
On 08/08/2018 11:04 AM, Jeff Johnson wrote:
But "occasionally" downloading file lists does not solve the problems stated,
either then, or now.
I haven't been able to figure out what your problem is with this. Do
you think that "occasionally" is incorrect and it will be "usually"? Or
you ju
On Wed, 2018-08-08 at 16:43 +, Zbigniew Jędrzejewski-Szmek wrote:
> That's a good question. The time window where this can happen is not
> be that big, because without filelists the loading of metadata is
> quicker. But it's still non-zero, so given enough machines and enough
> updates, it'll b
> On Tue, Aug 07, 2018 at 08:50:25AM +, Michael Schroeder wrote:
>
> Yep, that sounds like an excellent idea.
>
>
> That's a good question. The time window where this can happen is not
> be that big, because without filelists the loading of metadata is
> quicker. But it's still non-zero, so
No missing expected images.
Passed openQA tests: 2/2 (x86_64)
--
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorap
On Tue, Aug 07, 2018 at 08:50:25AM +, Michael Schroeder wrote:
> On Mon, Aug 06, 2018 at 04:36:07PM +, Zbigniew J??drzejewski-Szmek wrote:
> > this mail is a continuation of an FPC [1] and a FESCo [2] tickets.
> >
> > A proposal was made is to disallow packages in Fedora from using file
>
No missing expected images.
Passed openQA tests: 2/2 (x86_64)
Installed system changes in test x86_64 AtomicHost-dvd_ostree-iso
install_default:
Filesystem for mount /sysroot changed from
/dev/mapper/fedora--atomic_ibm--p8--kvm--03--guest--02-root to
/dev/mapper/fedora_ibm--p8--kvm--03--g
On Wed, Aug 8, 2018 at 3:29 PM, wrote:
>
> A new Fedora Atomic Host update is available via an OSTree update:
>
> Version: 28.20180804.0
> Commit(x86_64): 5633f5b369b166d104720a4da31da1
> ac6b5e3c0de5c5bae70cb40a850dede502
> Commit(aarch64): 99267073f82f4d7161bb36c5229d4d
> cf0518503ea8eda1614832
On Wed, 08 Aug 2018 02:11:08 +0200, Andrey Ponomarenko wrote:
> 2) The -get-inventory-id option creates a new inventory id (or 'group') to
> mark new probes by this id. You've created too many inventory ids per day
> and received an error when trying to create more. Usually it's enough to
> have on
On Tue, Aug 7, 2018 at 2:19 PM Adam Williamson
wrote:
> I'm taking a look through these and updating ones that clearly *are*
> testable already to MODIFIED.
>
You're awesome!
> surely the BINUTILS231 change supersedes the BINUTILS230 change?
> Shouldn't the bugs be duped and the wiki pages clean
On Tue, Aug 07, 2018 at 11:19:30AM -0700, Adam Williamson wrote:
> On Tue, 2018-08-07 at 10:42 -0400, Ben Cotton wrote:
> > Greetings!
> >
> > In on week, on 2018-08-14, we will reach Fedora 29 Change
> > Checkpoint:Completion deadline (testable) [1].
> >
> > At this point, all accepted changes [
W dniu 07.08.2018 o 15:12, Florian Weimer pisze:
> On 08/06/2018 09:58 PM, Marcin Juszkiewicz wrote:
>> From what I remember there is no architecture supported by Fedora
>> without Valgrind support. We got rid of s390 (32bit) and risc-v does not
>> count yet.
>
> valgrind support is not monotonic
A new Fedora Atomic Host update is available via an OSTree update:
Version: 28.20180804.0
Commit(x86_64): 5633f5b369b166d104720a4da31da1ac6b5e3c0de5c5bae70cb40a850dede502
Commit(aarch64):
99267073f82f4d7161bb36c5229d4dcf0518503ea8eda161483278053a68df10
Commit(ppc64le):
6b4f16f98c5609629bb1bac2f
Cython-0.28.4-3.fc29 has landed in rawhide.
It moves all stuff in /usr/bin to pytyon3 package only, because the
functionality is the same on whatever Python version.
This might break your package if you BR Cython.
Here are some tips that should be Fedora/EPEL version agnostic:
If you need to
Probably a good idea to cc: this to the kernel list :-)
I suspect it's intentional but with the planned changes for iptables
etc to be backed by bpf in the upstream kernel sometime in the future
it's likely going to need to be reviewed.
Peter
On Tue, Aug 7, 2018 at 10:25 PM, Timothée Ravier wro
On Tue, Aug 7, 2018 at 11:05 PM, Dominik 'Rathann' Mierzejewski
wrote:
> On Tuesday, 07 August 2018 at 11:05, Gerd Hoffmann wrote:
>> Hi,
>>
>> > Gerd Hoffman has a nightly edk2 repo which builds arm32 images. If
>> > someone can figure out the magic qemu incantation to get those working
>> > wi
28 matches
Mail list logo