No missing expected images.
Failed openQA tests: 28/129 (x86_64), 11/24 (i386), 1/2 (arm)
New failures (same test did not fail in Rawhide-20180116.n.0):
ID: 186693 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/186693
ID: 186694 Test: x86_
Announcing the creation of a new nightly release validation test event
for Fedora 28 Rawhide 20180117.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki
Missing expected images:
Atomic qcow2 x86_64
Atomic raw-xz x86_64
Failed openQA tests: 27/129 (x86_64), 11/24 (i386), 1/2 (arm)
New failures (same test did not fail in Rawhide-20180115.n.0):
ID: 186259 Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.or
I wanted to share with you that the Fedora Council has approved[0] the
latest installment of the Modularity Objective during today's meeting. The
new Objective is "Fedora Modularization — The Release[1]" and the first
"implementation vehicle" is captured in the F28 Addon Modularity Change[2].
As y
ohh okz. i guess the real questrion is, will DNF3 be usable before Branching
point?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
On Wed, 2018-01-17 at 23:08 +, Greg Evenden wrote:
> igor as long as DNF3 is working/stable before Beta Freeze im sure
> DNF3 can still make it into F28,
Christ, no. DNF's behaviour has consequences just about *everywhere*
you look in the distro. A major new DNF release needs to be landed
*wel
igor as long as DNF3 is working/stable before Beta Freeze im sure DNF3 can
still make it into F28, however there does need to be a system-wide change made
for it for f28 IMO
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
The only package I am aware of using it was OpenColorIO but the new 1.1.0
release now uses 5.x.
Fedora 27:
# for lib in "libyaml-cpp.so.0.3" "libyaml-cpp.so.0.3()(64bit)"; do
repoquery --source --whatrequires "$lib"; done
Last metadata expiration check: 0:00:00 ago on Wed 17 Jan 2018 02:57:49 PM
C
On Wed, Jan 17, 2018 at 11:25:43AM -0600, Mátyás Selmeci wrote:
> My name is Matyas Selmeci and I work for the Open Science Grid, a
> collaboration of ~100 universities and research labs around the US
> that share batch computing resources with each other. We've been
> developing an RPM-based softw
Hello Matyas and welcome!
- Original Message -
> From: "Mátyás Selmeci"
> To: "Development discussions related to Fedora"
>
> Sent: Wednesday, January 17, 2018 6:25:43 PM
> Subject: Self Introduction: Matyas (Mat) Selmeci
>
> Hi all,
>
> My name is Matyas Selmeci and I work for the Op
Hi all,
My name is Matyas Selmeci and I work for the Open Science Grid, a
collaboration of ~100 universities and research labs around the US that
share batch computing resources with each other. We've been developing
an RPM-based software stack for our users, some of which are based on
EPEL p
On Tue, Jan 16, 2018 at 08:18:42AM -0500, Josh Boyer wrote:
> - Better Git frontend for CentOS
> - Possibility to submit PRs against RHEL branches
> - Easy to see changes from RHEL and Fedora (and CentOS).
> What are some others?
I'd like to see these branches as candidates for inclusion in module
More or less, yes, but you should add the dependent package review requests
as blockers to the main package review request.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorapr
Hello,
Let's say I want to package a program depending on libraries which are
not (yet) part of Fedora. Is the following procedure correct ?
1) Submit a review for the original package, and a review for each
dependency. Mention into the reviews how they are linked to the original
submission.
2)
On 01/09/2018 04:51 PM, David Kaspar [Dee'Kej] wrote:
Initial NOTE: I have made some bigger changes in Ghostscript package during the
cleanup, which should be self-contained. In my opinion those changes are not so
significant to create "self-contained change" wiki page for it (for F28), but if
Hello Fedora developers,
I know some of you may not be familiar with me[1] unless you’re also
working with CentOS or EPEL, but I’d like to take this opportunity to
introduce myself a bit more formally on the list.
As of 1 February, I’ll be the reporting manager for the Fedora
Infrastructure Admin
On 01/17/2018 08:47 AM, mcatanz...@gnome.org wrote:
> Clearly what we have now is, in practice, not working as intended.
The original intent as I understood it from the thread long ago[0] was
to reduce the number of updates that go out on non-Tuesdays, and make
most updates happen on Tuesdays. The
On 03/01/18 14:07 +, Jonathan Wakely wrote:
On 03/01/18 12:55 +, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jan 03, 2018 at 11:43:34AM +, Jonathan Wakely wrote:
On 02/01/18 12:45 +, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 01, 2018 at 10:13:15PM +, Fedora Rawhide Repo
Thanks, Kevin. Knowing when the updates are actually going out adds
important context to this discussion.
On Wed, Jan 17, 2018 at 7:30 AM, Kevin Kofler
wrote:
I don't see how this is helpful.
Kevin has a point here. Clearly what we have now is, in practice, not
working as intended.
Micha
Kevin Fenzi wrote:
> On 01/09/2018 12:57 PM, Kevin Kofler wrote:
>> Kevin Fenzi wrote:
>>> If we update a repo for some minor enhancements it means everyone in the
>>> world has to pay for that. If we just push all those out every tuesday
>>> and don't update those unless there's something urgent w
On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:
> Hello,
> Python3 will be in the next major RHEL release. I don't mean RHEL
> 7.6, but with numbers higher than 7.
> There are many, many packages with something like the following
>
> if 0%{?fedora}
>%define with_python3 1
> %
On 01/09/2018 04:16 PM, Tomasz Torcz 👁️ wrote:
I'm a bit perplexed by this change. It looks like minor version
update, in such case it need no to be announced so widely.
On the other hand, you are changing the source. According to the
guidelines, changing source requires re-review.
Hi Igor,
On Wed, Jan 17, 2018 10:52:50 +0100, Igor Gnatenko wrote:
> > to the rpmfusion appstream data spec files. However, based on my
> > understanding of how these things work, this implies that the rpmfusion
> > appstream data packages are pulled into a transaction only if the fedora
> > appst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, 2018-01-16 at 18:08 +, Ankur Sinha wrote:
> Hello,
>
> We're generating appstream data for rpmfusion packages nowadays to
> enable users to install packages from there using gnome-software and
> friends too.
>
> Is there a way to automa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, 2018-01-17 at 09:33 +, Eduard Cuba wrote:
> Hello,
>
> SWDB is in DNF upstream since October 19. However, it's not released yet
> and it's being reworked due to changes in database design and performance
> issues. Also, the GObject-intro
Hello,
SWDB is in DNF upstream since October 19. However, it's not released yet
and it's being reworked due to changes in database design and performance
issues. Also, the GObject-introspection bindings are being dropped and
replaced by C++ API with SWIG bindings to match long-term libdnf
developm
= Proposed Self Contained Change: Chinese Default Fonts to Google Noto =
https://fedoraproject.org/wiki/Changes/ChineseDefaultFontsToNoto
Change owner(s):
* Peng Wu
Changes the default fonts for Chinese to Google Noto.
== Detailed Description ==
Changes the default fonts for Chinese to Google
No missing expected images.
Failed openQA tests: 12/129 (x86_64), 5/24 (i386), 1/2 (arm)
Old failures (same test failed in Rawhide-20180114.n.0):
ID: 185983 Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/185983
ID: 185984 Test: x86_64 Serv
28 matches
Mail list logo
