Ah thanks so much! This is my first time unretiring something :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
I recently requested to unretire rocm-smi, but after it was completed I tried
to rebuild and I get this:
BuildError: package rocm-smi is blocked for tag f39-updates-candidate
See: https://koji.fedoraproject.org/koji/taskinfo?taskID=103328747
So I'm not sure if a) it was not unretired
+1
Yes this has been mentioned many times on the thread. You can't say the user
has consented but also have it opt-out.
Saying that opt-in data isn't useful because most users won't opt-in is
implying the desire of a dark pattern to encourage more data collection.
Agreed 100%. Dark patterning or similar isn't the way to go.
If telemetry is included, it should be opt-in with very clear explanation of
why opt-ing in is important and beneficial.
Opt-out and "by consent" are mutually exclusive in most circumstances.
Unfortunately this might just be what happens.
I know that I would personally always opt out on principle, and would vote for
opt-in or dropping the proposal. I am under the impression that most Fedora
users are in the same boat as me.
___
devel
Thanks Luya! I've landed rocm-opencl in rawhide, with epel8/9 and Fedora 36
pending :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
I'm looking to see if anyone wants to review swap with me:
https://bugzilla.redhat.com/show_bug.cgi?id=2090823
Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
I made a ticket for request for advise:
https://pagure.io/epel/issue/185
But I wanted to post here to give more visibility.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to
Fantastic idea, I've just created a new page. I'll update it as I have time:
https://fedoraproject.org/wiki/SIGs/HC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
A few people contact me directly trying to run things like PyTorch, which
requires large amounts of ROCm to get working (most of which Fedora does not
have yet).
I feel like a SIG, or at least some wiki page would help organize things a bit
for those who want to tackle it but are unaware of
Thanks Felix,
An open concern that I have been discussing with the ROCm guys is that HIP
(used for things like pytorch) requires rocm-opencl source code to compile.
It seems they want to go with the llvm-project approach in the longterm, having
opencl, hip, and the common static lib "ROCclr"
I'm up for a review swap if there's no takers.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
For anyone interested I made a review request:
https://bugzilla.redhat.com/show_bug.cgi?id=2090823
I'm not 100% sure what to do with some of the debug related rpmlint errors. Any
help would be much appreciated.
___
devel mailing list --
As far as I know, RedHat is working with Nvidia to get this upstream and
working with nouveau.
I'm sure there's a bunch of challenges around that though, so I don't expect
much over the next few quarters.___
devel mailing list --
+1 to using an rpm macro to avoid adding an external script, if spectool can
work with it.
Something like:
%global source0_generate_script ( \
curl ... \
rm -rf ... \
tar ... )
I'm not sure if that syntax is correct.___
devel mailing list --
> Nice work!
Thanks :)
> The only x86 32-bit use I can think of would be wine if it supports ROCm.
Yeah I looked into it, and it looks like rocm-runtime fails on 32bit due to
some assumptions for 64bit in the code.
I don't think there's too much value to 32bit, so it's not really worth trying
I made a thread late last year inquirying about interest in ROCm packaging; in
that time I've introduced a few packages amd updated a few existing packages to
the latest version.
Right now, Fedora is just short of making good use of ROCm, as it needs a
frontend like OpenCL or HIP. I have a COPR
It seems like my needs are pretty common: Steam, Wine, misc games (OpenGL, SDL,
maybe vulkan, XWayland).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Quick update, I've made some new package reviews:
ROCm-Device-Libs: https://bugzilla.redhat.com/show_bug.cgi?id=2044664
ROCm-CompilerSupport: https://bugzilla.redhat.com/show_bug.cgi?id=2045955
ROCm-Device-Libs is needed to update "rocm-runtime" and for
ROCm-CompilerSupport.
I created a new review request, hopefully that encourages some conversation on
the topic :)
https://bugzilla.redhat.com/show_bug.cgi?id=2044664
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
In order to update "rocm-runtime" to the latest, it requires a new package
"ROCm-Device-Libs" as a build requirement.
The issue is that the project installs files into /usr/amdgcn, which seems
incorrect to me based on the FHS and Fedora guidelines. Here's the upstream for
reference:
Yes, this can't be updated until someone packages ROCM-Device-Libs
unfortunately.
If anyone volunteers, I'm happy to help review.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
> On Thu, Dec 16, 2021 at 05:07:10PM -0000, Jeremy Newton wrote:
>
> I think that'd be awesome -- and those internal clean-ups are really
> appreciated. Having the infrastructure there is nice, but I'm also curious:
> are there any application-level tools that are in Fedor
Yeah I think the technical leads are mostly on board with following FHS as
close as possible, which is an obvious plus for Fedora.
I think the biggest issue is the scale of the problem, and it almost feel likes
they need to work component by component, but [2] will definitely be fixed for
all
Full disclosure, I am both a Fedora packager and an employee at AMD.
To be clear, the following is not at all endorsed by my employer; my interest
and use of Fedora is purely a personal hobby and I would like to keep it that
way.
There has been a recent effort to step up Debian packaging of
Indeed, but they should add the provides: bundled(cubeb) in the spec
Anyway, I made a review request for anyone interested:
https://bugzilla.redhat.com/show_bug.cgi?id=1826034
I plan to make a pull request to Firefox later if I can get it to unbundle.
Good to know, thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
I package dolphin-emu, which bundled libcubeb in the latest version.
I've built it in rawhide and I'm trying to systematically unbundle things.
Looks like cubeb is apart of the Firefox source tree (./meda/libcubeb/). Should
I email gecko-bugs-nob...@fedoraproject.org or make a bug report?
It
I feel like the batched update makes a lot of sense, providing the same amount
of QA/testing time is still provided and some rules are set on what can and
cannot be pushed in that update. E.g., since GTK now has a LTS model, I would
assume major release updates would only ever be pushed to
Thanks! I'll take a look into the port guide.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Anyone have any idea what causes these errors? Trying to update a package and
it failed during a local test build in mock (f25):
In file included from /usr/include/c++/6.2.1/stdlib.h:36:0,
from expr.ypp:5:
/usr/include/c++/6.2.1/cstdlib:124:11: error: '::div_t' has not been
:28:26 PM CET Jeremy Newton wrote:
> > Hi,
> > I was wondering if any of the RPM guru's know how to fix an issue I'm
> having.
> >
> > I keep getting this email:
> > >orthorobot has broken dependencies in the rawhide tree:
> > >On ppc64le:
> > >
Hi,
I was wondering if any of the RPM guru's know how to fix an issue I'm having.
I keep getting this email:
>orthorobot has broken dependencies in the rawhide tree:
>On ppc64le:
>orthorobot-1.1-4.fc26.noarch requires love
>Please resolve this as soon as possible.
This is because it's
At risk of asking a redundant question, I'm assuming Wayland is still a go?
IIRC the contingency deadline was the beta.
I ask because it does not appear to be a part of the changeset, yet this FEDCo
ticket seems to suggest otherwise:
https://fedorahosted.org/fesco/ticket/1615
* Do you think that the average user with a clicking sound card or disk
** corruption when suspending would be able to make the link to this new
** package?*
Even better ... the integrated mouse pointer on my external ThinkPad USB
keyboard stops working if USB suspend is enabled for this device.
35 matches
Mail list logo
