Hi all,
Per the Fedora 30 schedule[1] we started a mass rebuild for Fedora 30
on Jan 31st 2019. We did a mass rebuild for Fedora 30 for the changes
listed in:
https://pagure.io/releng/issue/8086
Mass rebuild was done in a side tag (f30-rebuild) and are now getting moved
over to f30.
Failures ca
Dear Fedora mailing list community,
I am Sören alias Valor Naram and I founded the project "goeasyLinux". I will
help to make linux more user friendly.
A short introduction to "goeasyLinux" can be found at
https://github.com/ValorNaram/goeasylinux/blob/master/README.md
The specification I wrot
On 2/4/19 4:03 PM, Neal Gompa wrote:
> Aside from the times when it falls over for various reasons, I've had
> entire days where I wait for a build to even start, because people who
> use it for doing things like building KDE, chromium, or the Linux
> kernel occupy literally all the available buil
Dear all,
You are kindly invited to the meeting:
Modularity WG (weekly) on 2019-02-05 from 15:00:00 to 16:00:00 UTC
At fedora-meetin...@irc.freenode.net
The meeting will be about:
Meeting of the Modularity Working Group.
More information available at: [Modularity Working Group wiki
page](
On 2/4/19 6:38 PM, Dominique Martinet wrote:
It's the second time I read wireguard would be coming in the 5.0 kernel
here - what makes you folk say that?
I certainly haven't seen anything to that extent lately and 5.0 is petty
well under way, something as big a zinc likely won't make the cut this
Hi,
The recent bump of proj in Rawhide from 4.9.3 to 5.2.0 also bumped the
soname from libproj.so.12 to libproj.so.13.
The bump of geos in Rawhide from 3.6.1 to 3.7.1 also bumped the soname
from libgeos-3.6.1.so to libgeos-3.7.1.so.
These bumps should be announced *before* the build has been mad
Joe Doss wrote on Mon, Feb 04, 2019 at 03:43:59PM +:
> I know what akmods are and I don't have the bandwidth on my end to
> switch to them with WireGuard coming in the 5.0 kernel.
It's the second time I read wireguard would be coming in the 5.0 kernel
here - what makes you folk say that?
I ce
On Mon, Feb 4, 2019 at 5:14 AM Kevin Fenzi wrote:
>
> On 1/31/19 4:52 PM, Neal Gompa wrote:
>
> ...snip...
>
> > COPR was supposed to be that outlet, but no one gives a damn about it.
> > Everyone complains that the service is "bad" and that the design is
> > "bad" but no one wants to actually con
On 05. 02. 19 0:44, Eli Young wrote:
Python packages can specify extras dependencies, which are sets of dependencies not
required for core functionality, and which generally correspond to some feature. These
can then be specified by downstream consumers of the package. For example, requests has
Python packages can specify extras dependencies, which are sets of dependencies
not required for core functionality, and which generally correspond to some
feature. These can then be specified by downstream consumers of the package.
For example, requests has an entry in extras called security[1]
On 02/02/19 23:17 -0500, Rich Mattes wrote:
On 1/30/19 7:31 AM, Jonathan Wakely wrote:
The following packages use Boost.Signals which is been REMOVED from
Boost. The packages must be updated to use Boost.Signals2 (or bundle
an old Boost).
Maintainers by package:
ekiga mcrha pbrob
On 31/01/19 12:55 -0600, Patrick Diehl wrote:
Hi,
I maintain the hpx package, which links against boost. I would prefer to
build my package by myself, since we will need to update it to compile/link
with boost 1.69. I tested it yesterday and we need to patch our last stable
release to work with
On 04/02/19 12:49 +0100, Vít Ondruch wrote:
Hi,
It seems that since CMake 3.13, it is required to invoke the cmake
command explicitly with path to source, which was not required
previously. IOW in F29 was enough to call:
~~~
$ cmake
~~~
while F30+ requires:
~~~
$ cmake .
~~~
Unfortun
On Mon, Feb 4, 2019 at 9:27 PM Samuel Rakitničan
wrote:
>
> Hi,
>
> Got via e-mail that libdxflib's ABI changed in comparison to previous
> release, yet nothing changed in the package except version bump for the mass
> rebuild. Why is that?
Got that for a package too, and the major thing that c
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
I plan to
On Mon, 2019-02-04 at 13:35 +0100, Nils Philippsen wrote:
> On Sat, 2019-02-02 at 09:30 +0100, Miro Hrončok wrote:
> > Hi,
> >
> > it seems system-config-users is broken [1],
> > and appears to have no upstream [2].
> >
> > Do we maintain it at this point at all? Should it be retired "for
> > saf
On 2/4/19 11:27 AM, Stephen John Smoogen wrote:
> On Mon, 4 Feb 2019 at 12:14, Mátyás Selmeci wrote:
>>
>> On 1/31/19 1:05 PM, Kevin Fenzi wrote:
>>> On 1/30/19 1:39 PM, Adam Williamson wrote:
>>>
Question: how plausibly can we sort of "test retire" yum? i.e. just
somehow run a single co
Hi,
Got via e-mail that libdxflib's ABI changed in comparison to previous release,
yet nothing changed in the package except version bump for the mass rebuild.
Why is that?
Digest Summary:
1. dist.abicheck FAILED for libdxflib-3.17.0-8.fc30
2. dist.abicheck FAILED for libdxflib-3.17.
On Thu, Jan 31, 2019 at 07:08:14PM +0100, Miro Hrončok wrote:
> On 31. 01. 19 16:32, Michal Domonkos wrote:
> >On Wed, Jan 30, 2019 at 6:46 PM Miro Hrončok wrote:
> >>Based on the entire discussion so far, here's my proposal:
> >>
> >> - we change this to a system wide change
> >> - we move it
On Mon, 4 Feb 2019 at 12:14, Mátyás Selmeci wrote:
>
> On 1/31/19 1:05 PM, Kevin Fenzi wrote:
> > On 1/30/19 1:39 PM, Adam Williamson wrote:
> >
> >> Question: how plausibly can we sort of "test retire" yum? i.e. just
> >> somehow run a single compose process without it included, and see what
> >>
Was dkms working before you did the upgrade or was it already in a broken
state? wireguard-dkms-0.0.20190123-2.fc29.noarch won't fix an already broken
install, so you need to remove it and then install the new version. It should
hopefully fix it moving forward.
I started a thread on the WireGua
(nirik, 15:23:18)
* LINK:
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190204.n.0/logs/depcheck
(nirik, 15:23:49)
* #2060 F30 System-Wide Change: DNF Better Counting (mhroncok,
15:39:02)
* LINK: https://pagure.io/fesco/issue/2060 (mhroncok, 15:39:02)
* ACTION
Find below a list of topics which are planned to be discussed in the
Fedora Modularity Team 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):
https://apps.fed
On 1/31/19 1:05 PM, Kevin Fenzi wrote:
> On 1/30/19 1:39 PM, Adam Williamson wrote:
>
>> Question: how plausibly can we sort of "test retire" yum? i.e. just
>> somehow run a single compose process without it included, and see what
>> breaks?
>
> Well, we could block yum in koji and remove it from
On 2/1/19 10:23 AM, Neal Gompa wrote:
> On Fri, Feb 1, 2019 at 10:23 AM Sérgio Basto wrote:
>>
>> koji-builder, mash and repoview are ready to work without yum ?
>>
>
> There's a pending PR for fixing koji-builder:
> https://pagure.io/koji/pull-request/1117
>
> Mash is dead and not used in infra
No missing expected images.
Compose FAILS proposed Rawhide gating check!
9 of 47 required tests failed, 12 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 23/132 (x86_64), 4/24 (i386), 1/2 (arm)
New failures (same test not f
OLD: Fedora-Rawhide-20190203.n.0
NEW: Fedora-Rawhide-20190204.n.0
= SUMMARY =
Added images:0
Dropped images: 2
Added packages: 2
Dropped packages:0
Upgraded packages: 63
Downgraded packages: 0
Size of added packages: 3.94 MiB
Size of dropped packages:0 B
I know what akmods are and I don't have the bandwidth on my end to switch to
them with WireGuard coming in the 5.0 kernel.
Joe
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
On Mon, Feb 4, 2019 at 5:44 PM Mamoru TASAKA
wrote:
> Guido Aulisi wrote on 2019/02/03 20:31:
> > Hi,
> > I'm trying to debug a FTBFS in rawhide:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=32412101
> >
> > Apparently it fails because of library ordering, but it works in f29.
> >
Guido Aulisi wrote on 2019/02/04 22:23:
Il giorno lun 4 feb 2019 alle ore 13:14 Mamoru TASAKA
ha scritto:
Guido Aulisi wrote on 2019/02/03 20:31:
Hi,
I'm trying to debug a FTBFS in rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32412101
Apparently it fails because of library o
On Sun, Feb 03, 2019 at 05:27:45PM -0500, Neal Gompa wrote:
> On Sat, Feb 2, 2019 at 3:51 PM Adam Williamson
> wrote:
> >
> > On Wed, 2019-01-30 at 15:37 +0100, Michal Schorm wrote:
> > > Right.
> > >
> > > Yes, I'm trying to test the installation from the mirrors. There will
> > > be a delay.
> >
Il giorno lun 4 feb 2019 alle ore 13:14 Mamoru TASAKA
ha scritto:
>
> Guido Aulisi wrote on 2019/02/03 20:31:
> > Hi,
> > I'm trying to debug a FTBFS in rawhide:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=32412101
> >
> > Apparently it fails because of library ordering, but it wor
02.02.2019, 15:54, "Rex Dieter" :
> Rolling back is still probably the "right thing to do(tm)"
Completely agree. Thanks for fixing it, Caolán!
Pete
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists
Hi folks! I'm proposing we cancel the QA meeting today. Apologies for
the late notice. I actually meant to run a meeting this week to finish
up the topics from last week, but I'm officially on vacation right now
and forgot about sending out the announcement! Sorry.
I think everything on the list w
On Sat, 2019-02-02 at 09:30 +0100, Miro Hrončok wrote:
> Hi,
>
> it seems system-config-users is broken [1],
> and appears to have no upstream [2].
>
> Do we maintain it at this point at all? Should it be retired "for
> safety"?
IIRC, Moez picked up maintenance from me long ago when I wanted to
Actually, it seems this error was relaxed to warning in 3.13.4, which is
in Rawhide since yesterday:
https://github.com/Kitware/CMake/commit/2395b1b244743aaf28426a72f37d1aac96e3db9e
Vít
Dne 04. 02. 19 v 12:49 Vít Ondruch napsal(a):
> Hi,
>
> It seems that since CMake 3.13, it is required to in
The most naive grep identifies at least 23 packages:
~~~
$ grep -R -e '^%cmake$' | wc -l
23
~~~
Vít
Dne 04. 02. 19 v 12:49 Vít Ondruch napsal(a):
> Hi,
>
> It seems that since CMake 3.13, it is required to invoke the cmake
> command explicitly with path to source, which was not required
> pr
Hi,
It seems that since CMake 3.13, it is required to invoke the cmake
command explicitly with path to source, which was not required
previously. IOW in F29 was enough to call:
~~~
$ cmake
~~~
while F30+ requires:
~~~
$ cmake .
~~~
Unfortunately, neither upstream nor Fedora packagers p
Guido Aulisi wrote on 2019/02/03 20:31:
Hi,
I'm trying to debug a FTBFS in rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32412101
Apparently it fails because of library ordering, but it works in f29.
g_object_unref is defined in gobject-2.0 and it gets surely added by
the 'pkgcon
On Sun, 3 Feb 2019 at 16:43, Neal Gompa wrote:
>
> On Sun, Feb 3, 2019 at 6:19 AM Miroslav Suchý wrote:
> >
> > Dne 01. 02. 19 v 13:21 Mikolaj Izdebski napsal(a):
> > > - builds failing due to failure to download packages from official
> > > Fedora mirror dl.fedoraproject.org
> >
> > This is not
Hello, Guido Aulisi.
Mon, 4 Feb 2019 09:48:40 +0100 you wrote:
> I don't want to modify or patch upstream's Makefile...
Why? Patching of Makefile/cmake manifests is fine.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list --
Il giorno dom 3 feb 2019 alle ore 23:17 Kalev Lember
ha scritto:
>
>
> On 2/3/19 12:31, Guido Aulisi wrote:
> > Hi,
> > I'm trying to debug a FTBFS in rawhide:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=32412101
> >
> > Apparently it fails because of library ordering, but it works
42 matches
Mail list logo
