On 11. 08. 19 2:31, Christopher wrote:
On Sat, Aug 10, 2019 at 7:33 PM Miro Hrončok wrote:
On 11. 08. 19 0:34, Kevin Kofler wrote:
Miro Hrončok wrote:
Obviously, we can prevent this by only orphaning packages with NEW bugz,
but that doesn't really solve anything, because lot of the retired
p
On 11. 08. 19 8:14, Elliott Sales de Andrade wrote:
# python-cligj
python-rasterio and python-fiona depend on that.
I can take this one, since my packages depend on it.
Done. Thanks.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel
On 11. 08. 19 10:05, Miro Hrončok wrote:
My package doesn't help, I have no idea what to do now.
My package doesn't build I have no idea what to do now.
(I'll try to read my next e-mail before posting it.)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
__
On 11. 08. 19 3:45, Kevin Kofler wrote:
Nico Kadel-Garcia wrote:
Maintaining python 2 requires maintaining a*lot* of infrastructure.
What kind of infrastructure do you need to maintain a package that is (will
be) no longer updated upstream? This takes almost no work. The only thing to
do is to
On Wed, Aug 07, 2019 at 07:46:06AM -0700, Adam Williamson wrote:
> Listing some-but-not-all non-blocking deliverables doesn't make any
> sense at all.
+1. A full list is very useful.
What about https://fedoraproject.org/wiki/Changes/AArch64_Xfce_Desktop_image?
I assume it's non-blocking, but it'd
On Sun, Aug 11, 2019 at 01:12:20AM +0200, Kevin Kofler wrote:
> Miro Hrončok wrote:
> > What would you want to do instead? Keep shipping th Fedora 26 package
> > forever?
>
> Since this is actually an MSI blob that is a drop-in replacement for the MSI
> blob from WINE upstream (where the version
Hey, I have noticed that anaconda-core has a runtime dependency on
python3-coverage.
Is it some weird error, or does anaconda actually need a test coverage measuring
tool at runtime?
Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
Zbigniew Jędrzejewski-Szmek wrote:
> Right. So it sounds like the package could be made to "build" very easily.
By shipping the upstream blob as is? That would not really be compliant to
Fedora packaging guidelines, would it? At least I would hope it would not
be! (This is not really firmware, W
Miro Hrončok wrote:
> I hear that this was not properly communicated. I am already trying to
> figure out how to make that better -see my e-mail that started this thread
> or https://pagure.io/releng/issue/8599
IMHO, proper communication would have been to at least add another reminder
comment wi
Kevin Fenzi wrote:
> I'm not sure what else you would like me to do here...
How about changing the Bodhi rules to allow stable pushes 7 days after
update submission rather than 7 days after the push to testing actually
happens? That would make things much more predictable for maintainers and
no
Kevin,
I didn't see your comment until after I opened
https://pagure.io/fesco/issue/2207 - would love your feedback on that.
regards,
bex
On Sun, Aug 11, 2019 at 1:01 PM Kevin Kofler wrote:
>
> Kevin Fenzi wrote:
> > I'm not sure what else you would like me to do here...
>
> How about changing
On Sun, Aug 11, 2019 at 4:33 AM Miro Hrončok wrote:
> > I also think that there ought to be more cooperation from the maintainers of
> > individual python2-* modules. The approved Fedora 31 Change makes it way too
> > easy for maintainers to just drop Python 2 support for no reason.
>
> When a pa
Devel team,
I am interested in creating a package group specific for Fedora amateur/ham
radio users. I know people in my local area who have interest in such a
group, and surely others out there, that could bring more ham radio users
to Fedora, if the ability to install all the packages needed for
Brian (bex) Exelbierd wrote:
> I didn't see your comment until after I opened
> https://pagure.io/fesco/issue/2207 - would love your feedback on that.
https://pagure.io/fesco/issue/2207#comment-589009
Kevin Kofler
___
devel mailing list -- devel
On Thursday, 08 August 2019 at 08:19, Benson Muite wrote:
> Hi,
>
> Beignet has been deprecated, might it be possible to put Intel(R) Graphics
> Compute Runtime for OpenCL(TM) in the Fedora repositories? There is a COPR
> repository at:
>
> https://copr.fedorainfracloud.org/coprs/jdanecki/intel-op
Miro Hrončok wrote:
> We are still planning to maintain the interpreter. As is documented in the
> change. So can we please stop arguing about maintaining the interpreter
> over and over? It is staying and our team will maintain it at least until
> RHEL 7 EOL, possibly longer.
Then why do you requ
Dominik 'Rathann' Mierzejewski wrote:
> Unfortunately the one above is for Broadwell and newer, which means
> it doesn't work with any of my machines.
Don't you love planned obsolescence? A whopping 3 CPU/IGP generations from
https://wiki.freedesktop.org/www/Software/Beignet/#supportedtargets got
Can someone from releng re-tag these packages and push them to stable?
https://koji.fedoraproject.org/koji/buildinfo?buildID=1344119
https://koji.fedoraproject.org/koji/buildinfo?buildID=1344089
https://koji.fedoraproject.org/koji/buildinfo?buildID=1344114
https://koji.fedoraproject.org/koji/build
On Sat, Aug 10, 2019 at 3:07 AM Jan Kratochvil
wrote:
>
> On Fri, 09 Aug 2019 23:50:43 +0200, Chris Murphy wrote:
> > $ cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja
>
> RelWithDebInfo is -O2 -g build. That is not suitable for debugging, for
> debugging you should use -DCMAKE_BUILD_T
On Sun, Aug 11, 2019 at 10:50 AM, Chris Murphy
wrote:
Let's take another argument. If the user manually specifies 'ninja -j
64' on this same system, is that sabotage? I'd say it is. And
therefore why isn't it sabotage that the ninja default computes N jobs
as nrcpus + 2? And also doesn't take a
On 8/9/19 8:56 PM, Adam Williamson wrote:
> Hey folks! I'm starting a new thread for this to trim the recipient
> list a bit and include devel@ and coreos@.
Hey Adam!
>
> The Story So Far: there is a Fedora release criterion which requires
> Fedora to boot on Xen:
>
> "The release must boot s
On Sun, 11 Aug 2019 17:50:17 +0200, Chris Murphy wrote:
> I don't follow. You're saying RelWithDebInfo is never suitable for a
> local build?
Most of the time. What is your use case for it?
> isn't relevant to getting a successful build.
With powerful enough machine everything is possible. Jus
On Sun, Aug 11, 2019 at 11:21 AM Jan Kratochvil
wrote:
>
> On Sun, 11 Aug 2019 17:50:17 +0200, Chris Murphy wrote:
> > I don't follow. You're saying RelWithDebInfo is never suitable for a
> > local build?
>
> Most of the time. What is your use case for it?
My use case is testing the responsivenes
On Sun, Aug 11, 2019 at 10:36 AM wrote:
>
> On Sun, Aug 11, 2019 at 10:50 AM, Chris Murphy
> wrote:
> > Let's take another argument. If the user manually specifies 'ninja -j
> > 64' on this same system, is that sabotage? I'd say it is. And
> > therefore why isn't it sabotage that the ninja defaul
On Sun, 11 Aug 2019 20:54:28 +0200, Chris Murphy wrote:
> and likely experiences data loss and possibly even file system
> corruption as a direct consequence of having to force power off on the
> machine because for all practical purposes normal control has been
> lost.
Not really, this is what jo
On Sun, Aug 11, 2019 at 1:02 PM Jan Kratochvil
wrote:
>
> On Sun, 11 Aug 2019 20:54:28 +0200, Chris Murphy wrote:
> > and likely experiences data loss and possibly even file system
> > corruption as a direct consequence of having to force power off on the
> > machine because for all practical purp
I've noticed that recently, I see this with repoquery regardless of the query:
$ repoquery --repo=rawhide ...
Modular dependency problems:
Problem 1: conflicting requests
- nothing provides module(platform:f30) needed by module
exa:latest:3020190721165838:a23e773d-0.x86_64
Problem 2: confl
No missing expected images.
Compose FAILS proposed Rawhide gating check!
2 of 45 required tests failed, 6 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
MISSING: fedora.Wor
You need to explicitly set --setopt=module_platform_id=platform:F31
I thought itvwas fixed, but probably it does not work for repoquery.
On Sun, Aug 11, 2019, 23:07 Miro Hrončok wrote:
> I've noticed that recently, I see this with repoquery regardless of the
> query:
>
> $ repoquery --repo=rawh
I've dropped beignet a while ago since I was getting bugs, but upstream is
dead. Also many times, POCL performed better than beignet.
And after all, if you want to do something complicated with OpenCL, you
already have high-end AMD or latest Intel card..
However, anyone is free to unretire it.
O
> On 11. Aug 2019, at 23:05, Chris Murphy wrote:
>
> I think the point at which the mouse pointer has frozen, the user has
> no practical means of controlling or interacting with the system, it's
> a failure.
>
> In the short term, is it reasonable and possible, to get the oom
> killer to trig
On 8/11/19 3:19 PM, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 08 August 2019 at 08:19, Benson Muite wrote:
Hi,
Beignet has been deprecated, might it be possible to put Intel(R) Graphics
Compute Runtime for OpenCL(TM) in the Fedora repositories? There is a COPR
repository at:
https://
32 matches
Mail list logo
