On Fri, 2019-03-01 at 16:19 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates
>
> == Summary ==
> We want to gate packages on test results before they can land in
> rawhide. This will reduce the amount of broken dependency,
> uninstallable packages
On 03/01/2019 01:19 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates
>
> == Summary ==
> We want to gate packages on test results before they can land in
> rawhide. This will reduce the amount of broken dependency,
> uninstallable packages and broken
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 2019-02-28 at 10:22 +0100, Miroslav Suchý wrote:
> Do you want to make Fedora 30 better? Please spend 1 minute of your time and
> try to run:
>
> sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --
> enablerepo=updates-testi
https://fedoraproject.org/wiki/Changes/Remove389Console
== Summary ==
Remove all the deprecated 389-console packages: 389-console,
389-ds-console, 389-admin-console, 389-dsgw, 389-admin, and
389-adminutil. These packages are for the old JAVA UI for 389
Directory Server. We have a new web UI tha
https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates
== Summary ==
We want to gate packages on test results before they can land in
rawhide. This will reduce the amount of broken dependency,
uninstallable packages and broken composes leading to a more stable
rawhide as well as
On Fri, Mar 1, 2019 at 4:25 AM Michal Domonkos wrote:
> On Fri, Mar 1, 2019 at 2:24 AM Dennis Gregorovic
> wrote:
> >
> > I have an update on the koji end. The 1.17 release will not only drop
> the yum dependency, it will also have full python 3 support (except for
> image building that uses oz
Hi folks! Here's this week's update on Fedora 30 Beta blocker bug status.
Action summary
Accepted blockers
-
1. https://bugzilla.redhat.com/show_bug.cgi?id=1672761
ACTION: Package owner to close BZ and move config file correctness to a new BZ
2. https://bugzi
Missing expected images:
Atomichost qcow2 x86_64
Atomichost raw-xz x86_64
Failed openQA tests: 13/141 (x86_64), 1/2 (arm), 1/24 (i386)
ID: 357451 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/357451
ID: 357479 Test: arm Minimal-raw_xz-raw.
Hello team,
f30-backgrounds package is ready for review needed for the beta release
of Fedora 30 as critical part.
https://bugzilla.redhat.com/show_bug.cgi?id=1684612
Luya
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
Sérgio Basto wrote:
> On Fri, 2019-03-01 at 14:04 +, Rex Dieter wrote:
>> Continuing work in master branch (aka fc31), pending
>
> I didn't understood , when or how can I test builds against Qt 5.12 ?
You can't ... yet. The work I'm doing is to import into rawhide (master
branch). Once t
On 01. 03. 19 16:36, Adam Williamson wrote:
On Fri, 2019-03-01 at 00:35 +0100, Miro Hrončok wrote:
More generally, the *flood* of Python 2 dep issues here is something I
was definitely concerned about with the Python 2 retirement policy
explicitly deciding not to say anything about obsoleting P
On Fri, 2019-03-01 at 00:35 +0100, Miro Hrončok wrote:
> > > > More generally, the *flood* of Python 2 dep issues here is something I
> > > > was definitely concerned about with the Python 2 retirement policy
> > > > explicitly deciding not to say anything about obsoleting Python 2
> > > > subpack
On Fri, 2019-03-01 at 14:04 +, Rex Dieter wrote:
> Continuing work in master branch (aka fc31), pending
I didn't understood , when or how can I test builds against Qt 5.12 ?
Thanks,
--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedorapro
Vascom wrote:
> Will it be in F29?
Undecided, we'll see how smoothly the upgrade goes in f30 first.
Ideally, yes.
-- Rex
> пт, 1 мар. 2019 г. в 17:05, Rex Dieter :
>>
>> Continuing work in master branch (aka fc31), pending
>>
>> fc30 work will continue when
>> https://pagure.io/releng/issue/79
Announcing the creation of a new nightly release validation test event
for Fedora 30 Branched 20190301.n.0. 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
Not replying to anyone in particular but just a nit for me...
I've been a Fedora packager for probably 10 years now (need to check!) but
I *STILL* don't really understand modules other than at a high level (it
lets you use dependencies that aren't available in the main repos). I've
read through so
Will it be in F29?
пт, 1 мар. 2019 г. в 17:05, Rex Dieter :
>
> Continuing work in master branch (aka fc31), pending
>
> fc30 work will continue when
> https://pagure.io/releng/issue/7966
> is processed for a f30-kde koji target. (Hopefully with enough time prior to
> beta freeze)
>
> -- Rex
> _
Continuing work in master branch (aka fc31), pending
fc30 work will continue when
https://pagure.io/releng/issue/7966
is processed for a f30-kde koji target. (Hopefully with enough time prior to
beta freeze)
-- Rex
___
devel mailing list -- devel@lis
Dne 01. 03. 19 v 12:59 Marcin Juszkiewicz napsal(a):
> My system was Fedora 19 when first time I installed Fedora. Now I have
> packages from
> each release from F20 to F29 ;d
In fedora-upgrade(8) I run
package-cleanup --orphans | grep -v kernel
which:
--orphans
List inst
W dniu 28.02.2019 o 10:22, Miroslav Suchý pisze:
> Do you want to make Fedora 30 better? Please spend 1 minute of your time and
> try to run:
>
> sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30
> --enablerepo=updates-testing distro-sync
On my system it had 13 problems, 3 of
Dne 01. 03. 19 v 12:11 Diogo Galvao napsal(a):
> Problem 4: package darktable-2.6.0-2.fc30.x86_64 requires
> libexiv2.so.26()(64bit), but none of the providers can be installed
> - problem with installed package darktable-2.6.0-2.fc29.x86_64
> - exiv2-libs-0.26-12.fc29.x86_64 does not belong t
Hi,
Last metadata expiration check: 0:05:26 ago on Fri Mar 1 12:17:22 2019.
Error:
Problem 1: package rpmfusion-free-release-29-1.noarch requires
system-release(29), but none of the providers can be installed
- fedora-release-29-7.noarch does not belong to a distupgrade repository
- problem w
On 01. 03. 19 12:11, Diogo Galvao wrote:
On Thu, Feb 28, 2019 at 6:23 AM Miroslav Suchý wrote:
But very likely you get some dependency problem now. In that case please report
it against appropriate package.
Could you please confirm if these two issues should really be reported
before I sub
On Thu, Feb 28, 2019 at 6:23 AM Miroslav Suchý wrote:
>
> But very likely you get some dependency problem now. In that case please
> report it against appropriate package.
>
Could you please confirm if these two issues should really be reported
before I submit them to Bugzilla?
Problem 3: pack
On Friday, March 1, 2019 9:56:48 AM CET Mikolaj Izdebski wrote:
> Koji doesn't use upstream mock configs. For each task it generates a
> new config dynamically. These generated configs don't include any
> modular repos.
Looks like a serious bug in Koji -> if modular repos are enabled by
default in
On Fri, Mar 1, 2019 at 11:39 AM Miroslav Suchý wrote:
>
> Dne 01. 03. 19 v 10:28 Fabio Valentini napsal(a):
> > Either way, I'm just strongly opposed to enable modular repos in mock
> > by default (yet).
>
> *nod*
> With the all issues it brought, it is pragmatic move to remove the modular
> repo
On Fri, Mar 1, 2019 at 11:31 AM Fabio Valentini wrote:
>
> On Fri, Mar 1, 2019 at 11:28 AM Mikolaj Izdebski wrote:
> >
> > On Fri, Mar 1, 2019 at 10:29 AM Fabio Valentini
> > wrote:
> > > I agree, this change to mock-core-configs seems to have been rushed
> > > and uncoordinated, since it's not
Dne 01. 03. 19 v 10:28 Fabio Valentini napsal(a):
> Either way, I'm just strongly opposed to enable modular repos in mock
> by default (yet).
*nod*
With the all issues it brought, it is pragmatic move to remove the modular
repo. In fact, I will just set enabled=0.
Done:
https://github.com/rpm-so
On 28. 02. 19 20:00, Till Maas wrote:
Hi friends,
Brian[0] made me think about my commitments and I realized that it is
time to step back from my FESCo seat.
Thank you for everything you've done in FESCo and beyond.
I always valued your opinions deeply and I will continue to do so.
I wish you
On Fri, Mar 1, 2019 at 11:28 AM Mikolaj Izdebski wrote:
>
> On Fri, Mar 1, 2019 at 10:29 AM Fabio Valentini wrote:
> > I agree, this change to mock-core-configs seems to have been rushed
> > and uncoordinated, since it's not possible to use modules in koji at
> > all.
>
> It is possible to use mo
On Fri, Mar 1, 2019 at 10:29 AM Fabio Valentini wrote:
> I agree, this change to mock-core-configs seems to have been rushed
> and uncoordinated, since it's not possible to use modules in koji at
> all.
It is possible to use modules in Koji. But Fedora Koji is not
configured to use modules.
--
M
On Fri, Mar 1, 2019 at 9:58 AM Adam Samalik wrote:
>
> I'm glad Modularity is getting popular, however, we should coordinate such
> big changes so we keep consistency among various build environments.
I'd call it "notorious" or "infamous" instead of "popular", but that's
just a difference perspe
On 01. 03. 19 9:58, Adam Samalik wrote:
I'm glad Modularity is getting popular, however, we should coordinate such big
changes so we keep consistency among various build environments.
Agreed.
The ability to enable modules in a Koji buildroot is being discussed in a FESCo
ticket [1] — although
On 01. 03. 19 8:59, Miroslav Suchý wrote:
Mock is in fact just easy tool to run 'rpmbuild' in minimal chroot of
Fedora/CentOS. So running
mock -r fedora-29-x86_64 foo.src
should give you the same results as running `rpmbuild --rebuild foo.src` on
normal installation of fedora-29 with only
On Fri, Mar 1, 2019 at 2:24 AM Dennis Gregorovic wrote:
>
> I have an update on the koji end. The 1.17 release will not only drop the
> yum dependency, it will also have full python 3 support (except for image
> building that uses oz / imagefactory). Unfortunately, there is only medium
> conf
On 01. 03. 19 8:26, Miroslav Suchý wrote:
Dne 28. 02. 19 v 18:55 Kalev Lember napsal(a):
It's difficult to obsolete subpackages correctly from
fedora-obsolete-packages when F29 keeps moving and bumping package
versions; the versioned obsoletes in fedora-obsolete-packages
The rule of versione
I'm glad Modularity is getting popular, however, we should coordinate such
big changes so we keep consistency among various build environments.
The ability to enable modules in a Koji buildroot is being discussed in a
FESCo ticket [1] — although that discussion is a bit longer than initially
antic
On Fri, Mar 1, 2019 at 9:00 AM Miroslav Suchý wrote:
>
> Dne 01. 03. 19 v 0:22 Miro Hrončok napsal(a):
> > On 01. 03. 19 0:05, Fabio Valentini wrote:
> > Mock should IMHO bring the exact same (or at least the most similar)
> > results as building in koji. I don't want to get
> > different package
On Fri, 1 Mar 2019 08:59:35 +0100
Miroslav Suchý wrote:
> Dne 01. 03. 19 v 0:22 Miro Hrončok napsal(a):
> > On 01. 03. 19 0:05, Fabio Valentini wrote:
> >> I don't want or need modules installed for this package to build.
>
> It may be true if your specific case. But generally this is not true.
Dne 01. 03. 19 v 0:22 Miro Hrončok napsal(a):
> On 01. 03. 19 0:05, Fabio Valentini wrote:
>> I don't want or need modules installed for this package to build.
It may be true if your specific case. But generally this is not true. AFAIK
Some packages are not available in normal
repo any more and a
40 matches
Mail list logo
