On Fri, Mar 8, 2019 at 8:20 PM Sérgio Basto wrote:
>
> Hello,
>
> :P I just found a weird bug :
>
> dnf repoquery --available --whatrequires python2-mlt
> flowblade-0:1.16.0-2.gitd2f153f.fc28.noarch
> flowblade-0:2.0-1.fc28.noarch
>
> dnf repoquery --disablerepo='*' --enablerepo=rawhide
> --ena
On 3/8/19 5:11 PM, Miro Hrončok wrote:
> On 08. 03. 19 18:39, Miro Hrončok wrote:
>> On 08. 03. 19 18:26, Kevin Fenzi wrote:
>>> On 3/7/19 12:30 PM, Miro Hrončok wrote:
On 07. 03. 19 21:19, Kevin Fenzi wrote:
> On 3/7/19 11:35 AM, Tomasz Kłoczko wrote:
>> On Thu, 7 Mar 2019 at 12:17, F
On 3/8/19 6:01 PM, Chris wrote:
> Hi guys,
>
> I apologize if this is a bit premature to revisit this subject. The thing
> is, the releng ticket Stephen created (https://pagure.io/releng/issue/8185)
> based on my Bugzilla ticket (
> https://bugzilla.redhat.com/show_bug.cgi?id=1684830) got closed
Vít Ondruch wrote on 2019/03/09 8:03:
Hi,
Running `dnf update`, it tries to install:
Installing weak dependencies:
mkpasswd x86_64 5.4.1-3.fc31
rawhide 39 k
Trying to query for weak dependencies, nothing requires it:
$ sudo dnf repoquery --whatrecomm
Hi guys,
I apologize if this is a bit premature to revisit this subject. The thing
is, the releng ticket Stephen created (https://pagure.io/releng/issue/8185)
based on my Bugzilla ticket (
https://bugzilla.redhat.com/show_bug.cgi?id=1684830) got closed and marked
resolved, but the build process s
On 08. 03. 19 18:39, Miro Hrončok wrote:
On 08. 03. 19 18:26, Kevin Fenzi wrote:
On 3/7/19 12:30 PM, Miro Hrončok wrote:
On 07. 03. 19 21:19, Kevin Fenzi wrote:
On 3/7/19 11:35 AM, Tomasz Kłoczko wrote:
On Thu, 7 Mar 2019 at 12:17, Fedora Rawhide Report
wrote:
OLD: Fedora-Rawhide-20190217.
> "MH" == Miro Hrončok writes:
MH> One thing to consider here is other packages that have Requires
MH> etc. on something like "foo > 1:1.2", so if it is automated, this
MH> part needs to be automated as well.
Indeed. And of course this breaks any such dependency outside of Fedora
as well.
On 08. 03. 19 23:19, Jason L Tibbitts III wrote:
"MH" == Miro Hrončok writes:
MH> On 08. 03. 19 21:16, Neal Gompa wrote:
I really wish we'd allow Epochs to be reset on distribution upgrades.
With dnf distro-sync (which is used by system-upgrade) Epochs don't
really matter and upgrades work as
Hi,
Running `dnf update`, it tries to install:
~~~
... snip ...
Installing weak dependencies:
mkpasswd x86_64 5.4.1-3.fc31
rawhide 39 k
... snip ...
~~~
Trying to query for weak dependencies, nothing requires it:
~~~
$ sudo dnf repoquer
> "MH" == Miro Hrončok writes:
MH> On 08. 03. 19 21:16, Neal Gompa wrote:
>> I really wish we'd allow Epochs to be reset on distribution upgrades.
>> With dnf distro-sync (which is used by system-upgrade) Epochs don't
>> really matter and upgrades work as intended anyway...
MH> Let's do a Fe
On Fri, 2019-03-08 at 15:07 -0500, Kaleb Keithley wrote:
> The epoch was inadvertently bumped (not by me) when ceph was rebased to
> 14.x in f30/rawhide.
>
> I reset it to 1 in subsequent builds. Now adamwill is running builds with
> it bumped to 2 again.
>
> I would prefer that it not be bumped.
On 08. 03. 19 21:16, Neal Gompa wrote:
On Fri, Mar 8, 2019 at 3:08 PM Kaleb Keithley wrote:
The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x in
f30/rawhide.
I reset it to 1 in subsequent builds. Now adamwill is running builds with it
bumped to 2 again.
I would p
On Fri, Mar 8, 2019 at 1:38 PM Chris Murphy wrote:
>
> On Fri, Mar 8, 2019 at 12:56 PM wrote:
> >
> > On Fri, Mar 8, 2019 at 1:18 PM, Adam Williamson
> > wrote:
> > > I requested testing on desktop@ and test@ lists earlier this week; so
> > > far that seems to suggest that this is failing for a
On 3/8/19 12:47 PM, Vít Ondruch wrote:
>
> Dne 08. 03. 19 v 21:27 Kevin Fenzi napsal(a):
>> On 3/8/19 12:19 PM, Vít Ondruch wrote:
>>> I wonder why different builders has different version of mock and why
>>> the build result differs?
>>>
>>> The scratch build passes:
>>>
>>> https://koji.fedorapr
I'm working on getting PySide2 into Fedora which gives you python bindings
for Qt5.
It uses some code specific to Clang so I can't use gcc. I've got everything
building but for some reason the 64bit builds fail for two binaries which
rpmbuild can't link back to build-ids.
BUILDSTDERR: error: Miss
# F30 Blocker Review meeting
# Date: 2019-03-11
# Time: ** 16:00 ** UTC
# Location: #fedora-blocker-review on irc.freenode.net
Hi folks! We have 3 proposed Beta blockers and 3 proposed Beta FEs
to review, so let's have a Fedora 30 blocker review meeting on Monday!
Please note that the meeting tim
# Fedora Quality Assurance Meeting
# Date: 2019-03-11
# Time: ** 15:00 ** UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net
Greetings testers!
We didn't get through the whole agenda last week, so let's meet up
again this week and finish i
Dne 08. 03. 19 v 21:27 Kevin Fenzi napsal(a):
> On 3/8/19 12:19 PM, Vít Ondruch wrote:
>> I wonder why different builders has different version of mock and why
>> the build result differs?
>>
>> The scratch build passes:
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=33303459
>>
>> Whil
On vendredi 8 mars 2019 21:19:57 CET Vít Ondruch wrote:
> I wonder why different builders has different version of mock and why
> the build result differs?
>
> The scratch build passes:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=33303459
>
> While the official fails:
>
> https://ko
On Fri, Mar 8, 2019 at 12:56 PM wrote:
>
> On Fri, Mar 8, 2019 at 1:18 PM, Adam Williamson
> wrote:
> > I requested testing on desktop@ and test@ lists earlier this week; so
> > far that seems to suggest that this is failing for a lot of people on
> > a
> > lot of hardware...but it also fails the
On 3/8/19 12:19 PM, Vít Ondruch wrote:
> I wonder why different builders has different version of mock and why
> the build result differs?
>
> The scratch build passes:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=33303459
>
> While the official fails:
>
> https://koji.fedoraproject.
There is probably also different version of DNF used to install the
buildroot or otherwise I don't understand the differences in the root.log.
V.
Dne 08. 03. 19 v 21:19 Vít Ondruch napsal(a):
> I wonder why different builders has different version of mock and why
> the build result differs?
>
>
I wonder why different builders has different version of mock and why
the build result differs?
The scratch build passes:
https://koji.fedoraproject.org/koji/taskinfo?taskID=33303459
While the official fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=33303270
Also, I wonder what is
On Fri, Mar 8, 2019 at 3:08 PM Kaleb Keithley wrote:
>
> The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x
> in f30/rawhide.
>
> I reset it to 1 in subsequent builds. Now adamwill is running builds with it
> bumped to 2 again.
>
> I would prefer that it not be bumped.
On Thu, Mar 07, 2019 at 06:49:12PM +, Michael Zhang wrote:
> So after tinkering around, I can incorporate the building of the
> openliberty.zip into the Travis CI build but I cannot directly add it
> into the %install phase of the rpm spec file. Would that be fine?
It should be in the %build s
The epoch was inadvertently bumped (not by me) when ceph was rebased to
14.x in f30/rawhide.
I reset it to 1 in subsequent builds. Now adamwill is running builds with
it bumped to 2 again.
I would prefer that it not be bumped. Ceph has their own builds (for Fedora
even I think) where they have ep
On Fri, Mar 8, 2019 at 1:18 PM, Adam Williamson
wrote:
I requested testing on desktop@ and test@ lists earlier this week; so
far that seems to suggest that this is failing for a lot of people on
a
lot of hardware...but it also fails the same way on F29 in most cases,
suggesting we shipped F29
Hello,
:P I just found a weird bug :
dnf repoquery --available --whatrequires python2-mlt
flowblade-0:1.16.0-2.gitd2f153f.fc28.noarch
flowblade-0:2.0-1.fc28.noarch
dnf repoquery --disablerepo='*' --enablerepo=rawhide
--enablerepo=rpmfusion-{,non}free-rawhide --available --requires flowblade
On Fri, 2019-03-08 at 13:49 -0500, Ben Cotton wrote:
>
> Accepted blockers
> -
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1656509 - libdnf - POST
> F29 to Rawhide (F30) upgrades fail, seems to be modularity-related
>
> Reassigned to DNF. Patch merged upstream to fix the issu
Due to https://fedoraproject.org/wiki/Changes/Sphinx2 we will be removing
python2-sphinx and other related packages on Monday (2019-03-11).
If you are Bcc'ed, your package still uses python2-sphinx on build time and will
start to FTBFS. A fix is to stop BuildRequiring it. For your documentation
On 08. 03. 19 18:26, Kevin Fenzi wrote:
On 3/7/19 12:30 PM, Miro Hrončok wrote:
On 07. 03. 19 21:19, Kevin Fenzi wrote:
On 3/7/19 11:35 AM, Tomasz Kłoczko wrote:
On Thu, 7 Mar 2019 at 12:17, Fedora Rawhide Report
wrote:
OLD: Fedora-Rawhide-20190217.n.0
NEW: Fedora-Rawhide-20190306.n.1
Hi,
I don't have any use for rubygem-multipart, therefore I orpahned the
package. There was no upstream change past 10 years and nobody is
probably using the package.
Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an em
On 3/7/19 12:30 PM, Miro Hrončok wrote:
> On 07. 03. 19 21:19, Kevin Fenzi wrote:
>> On 3/7/19 11:35 AM, Tomasz Kłoczko wrote:
>>> On Thu, 7 Mar 2019 at 12:17, Fedora Rawhide Report
>>> wrote:
OLD: Fedora-Rawhide-20190217.n.0
NEW: Fedora-Rawhide-20190306.n.1
= SUMMARY
I guess this depends on the status of the Apache httpd workers. Like are
they stuck in IO to the /mnt/koji scratch location, or something else?
Unfortunately it's not secure to publicly display Koji's in-flight HTTP
requests with mod_status, since the URLs contain the authenticated session
informa
Dne 08. 03. 19 v 16:57 Vít Ondruch napsal(a):
> Hi,
>
> I have orphaned most of the Fog stack [1, 2]. Fog is the Ruby cloud
> services library, top to bottom, collections provide a simplified
> interface, making clouds easier to work with and switch between.
>
> Fog was originally introduced into
Hi,
I have orphaned most of the Fog stack [1, 2]. Fog is the Ruby cloud
services library, top to bottom, collections provide a simplified
interface, making clouds easier to work with and switch between.
Fog was originally introduced into Fedora just as a dependency of
Vagrant. Since that time, fo
On Fri, 8 Mar 2019 at 02:42, Tomasz Kłoczko wrote:
>
> On Fri, 8 Mar 2019 at 00:37, Stephen John Smoogen wrote:
> [..]
> > We don't push to mirrors. They sync from either our main servers or a
> > tier 1 or tier 2 mirror which also pull/rsync from the master mirrors.
> > This means it will take t
On 3/8/19 2:52 PM, Panu Matilainen wrote:
On 3/8/19 2:29 PM, Panu Matilainen wrote:
On 3/8/19 1:54 PM, Florian Weimer wrote:
* Panu Matilainen:
On 3/7/19 5:52 PM, Florian Weimer wrote:
* Panu Matilainen:
On 3/7/19 1:13 PM, Florian Weimer wrote:
* Richard W. M. Jones:
$ sudo dnf install
On Thu, Mar 7, 2019, at 10:53 AM, Florian Weimer wrote:
>
> > The %transfiletriggerpostun would've probably fixed it if it used -p
> > instead of shell.
>
> We switched to the shell for the benefit of rpm-ostree.
Short answer:
https://github.com/projectatomic/rpm-ostree/issues/749#issuecomm
On 3/8/19 2:29 PM, Panu Matilainen wrote:
On 3/8/19 1:54 PM, Florian Weimer wrote:
* Panu Matilainen:
On 3/7/19 5:52 PM, Florian Weimer wrote:
* Panu Matilainen:
On 3/7/19 1:13 PM, Florian Weimer wrote:
* Richard W. M. Jones:
$ sudo dnf install glibc-headers.i686
…
Downgrading:
That
On 3/8/19 1:54 PM, Florian Weimer wrote:
* Panu Matilainen:
On 3/7/19 5:52 PM, Florian Weimer wrote:
* Panu Matilainen:
On 3/7/19 1:13 PM, Florian Weimer wrote:
* Richard W. M. Jones:
$ sudo dnf install glibc-headers.i686
…
Downgrading:
That looks like a bug in itself.
The last time
* Panu Matilainen:
> On 3/7/19 5:52 PM, Florian Weimer wrote:
>> * Panu Matilainen:
>>
>>> On 3/7/19 1:13 PM, Florian Weimer wrote:
* Richard W. M. Jones:
> $ sudo dnf install glibc-headers.i686
…
> Downgrading:
That looks like a bug in itself.
The last t
There is a FedoraReview port to Python 3 that needs real word testing by
packagers.
When you use FedoraReview, please use the Python 3 port instead to help us find
bugs.
Instructions are at https://pagure.io/FedoraReview/pull-request/312 -> the first
comment of my Pull Request is updated wit
On 07/03/19 17:36, Tomas Tomecek wrote:
Hi Miro, sorry for a late reply: I wanted to think it through. Comments inline.
On Tue, Feb 26, 2019 at 4:43 PM Miro Hrončok wrote:
On 20. 02. 19 23:24, Tomas Tomecek wrote:
Hello,
at DevConf.cz, we have introduced a new project: packit [1] [2].
[1]
On Fri, Mar 8, 2019 at 3:21 AM Panu Matilainen wrote:
>
> On 3/7/19 5:52 PM, Florian Weimer wrote:
> > * Panu Matilainen:
> >
> >> On 3/7/19 1:13 PM, Florian Weimer wrote:
> >>> * Richard W. M. Jones:
> >>>
> $ sudo dnf install glibc-headers.i686
> >>> …
> Downgrading:
> >>>
> >>> That l
On 3/7/19 5:52 PM, Florian Weimer wrote:
* Panu Matilainen:
On 3/7/19 1:13 PM, Florian Weimer wrote:
* Richard W. M. Jones:
$ sudo dnf install glibc-headers.i686
…
Downgrading:
That looks like a bug in itself.
The last time I looked at something similar, I saw this: RPM would not
adjust
46 matches
Mail list logo
