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
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 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]
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
* 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
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
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 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: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 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
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
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
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
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
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 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
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 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
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, 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
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 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.
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
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?
>
>
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.
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 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
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
# 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
# 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
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
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
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 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, 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.
> "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
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
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
> "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 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.
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
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
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
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 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
46 matches
Mail list logo
