Hello,
I am resending this email to devel, because I did not get a reply on the
ARM list.
https://lists.fedoraproject.org/archives/list/a...@lists.fedoraproject.org/thread/6DO5RTOBNB6RYY4VS3Z5RMWVVNEK5AF3/
Since August 2020 we have an issue with Mono Segfault on armv7hl.
This is one bug
Hi all,
I will be updating libkolabxml from 1.1.6 to 1.2.0 in Rawhide in 7 days.
The only dependency is kdepim, as far as I can see.
Let me know in the bug
https://bugzilla.redhat.com/show_bug.cgi?id=1869138 if you see any issues.
I have already committed the change in git, but not built the
Hello all,
We currently still have Mono 4.6 in Epel7, and no Mono in Epel8 yet [1].
I suggest that I bootstrap Mono 5.18 for Epel8. [4]
That is the version that is delivered with Debian 10 "Buster" [2], and I
guess it will get some kind of long term support.
When that goes well, I would also
Hello Julian,
a bug was recently filed against gnome-subtitles [1] stating that
libenchant.so.1 dependency is missing. While I could easily fix this
with explicit Requires, my concern is why wasnt't this depencency picked
up automatically in the first place. Do you have any suggestions? Thank
Thanks for letting me know!
On 12.09.19 10:06, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Sep 11, 2019 at 05:18:36PM +0100, chedi toueiti wrote:
Error:
Problem 1: problem with installed package
mono-tools-gendarme-4.2-12.fc30.x86_64
- mono-tools-gendarme-4.2-12.fc30.x86_64 does not belong
Hello Vitaly,
Update the Mono stack in Fedora from 5.18 to 5.20.
Also please update NuGet package. It was not updated for ages and cannot
install modern dotnet dependencies.
I have now written a reply to that bug 1722217 for nuget.
Timotheus
___
Hello all,
Yes, mono is behind, but it isn't a simple reason. The way mono is
bootstrapped and compiled has changed starting with version 5.0. The
Roslyn compiler is now the default and requires bootstrapping from
binary-only sources provided by upstream. This is a no-no in Fedora.
There was an
Hello Thomas,
I am posted to ask if anybody knows how to contact Christian Krause
who is currently the maintainer of Anki in Fedora.
I have sent him an e-mail to his personal address, and I hope he will
respond to this thread soon.
Timotheus
Hello Farhad,
https://www.spinics.net/lists/fedora-devel/threads.html#241887
Please do something for this problem, it is really bad situation you
are waiting for e-mails and check the web page several times but you
don't see anything! |:
I don't think that spinics.net is the official
Hello,
I have pushed the Mono 4.6 package to epel-testing on EL7.
This update will sit in epel-testing for a significant period of time to
allow adequate notice and time for testing. I hope to push the update to
stable at around the time when CentOS 7.4 is released.
As far as I can see, no
Hello,
following up on my email concerning Mono in Epel6:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/QZLKV6KRKNWW4QVMNLL4TY2GYDGYZBWL/
I did not get any response.
But given the little amount of work necessary, I thought I might still
push Mono 4.2
Hello,
now that Mono 4.2 is in Epel7, we should look at Mono in Epel5 and Epel6.
Laxathom aka Smoother1rOgZ, the contact person for the Mono package,
agreed on IRC that we should retire Mono 1.2 on Epel5.
So I will work on this topic next week.
If someone has concerns, please let me know.
What
Hello,
> As previously agreed on epel-devel and by the EPEL Steering Committee,
> I have pushed the Mono 4.2 packages and packages depending on it to
> epel-testing on EL7.
>
> These updates will sit in epel-testing for a significant period of
> time to allow adequate notice and time for testing.
> Is it dependent on anything in the 7.3 release (bugfix or feature) to
> be usable? Or is it just an arbitrary date that was chosen? If the
> former I'd wait, if it's independent I'd push it.
Just an arbitrary date. It works fine in epel-testing already for about a month.
If I don't hear
> I hope to push them to stable at around the time when CentOS 7.3 is released.
I just wonder, what is the right time to push the mono packages to stable:
https://fedoraproject.org/wiki/EPEL_Updates_Policy says:
In cases of major disruption, EPEL updates will looked to be done
along with Red Hat
> I was searching for Libguestfs information and I came across
> https://lists.fedoraproject.org/archives/list/qa-de...@lists.fedoraproject.org/message/RX47AJOSD3QFO7SLVH4OH72MX47C3ZOR/,
> where you cover Libguestfs.
The thread he references is a AutoQA problem with the libguestfs package.
Hello,
As previously agreed on epel-devel and by the EPEL Steering Committee,
I have pushed the Mono 4.2 packages and packages depending on it to
epel-testing on EL7.
These updates will sit in epel-testing for a significant period of
time to allow adequate notice and time for testing.
I hope to
Hello,
just to give a quick update:
> Just to give a heads up: I am now working on this upgrade to Mono 4.2.
> I will build the mono package and the depending packages in a
> BuildRoot Override, and submit them for testing.
> They will sit in testing for a couple of months, and hopefully when
>
Hello Björn,
> Why am I getting this broken dependencies alert several times a day? I
> built a new AWS in Rawhide two days ago, but the program that sends
> these emails has apparently not noticed.
>
> I'd understand if it complained about F25, as I think I missed the
> alpha freeze deadline,
Hello Dave,
> Redhat for example has a very optimal tool chain which they use for
> their Enterprise product line and it is not available to other
> distributions (or rebuilds) and thus their resulting binaries and
> libraries have been more performant then other Linux distributions we
>
Hello Ilia,
>> > in monodevelop (f24,f25) don't work NUnit test. I can not create NUnit
>> > test
>> > from IDE.
I am one of the maintainers of the Fedora monodevelop package.
Please create a bug for it at https://bugzilla.redhat.com/
Product: Fedora, Component: monodevelop
I will try to have
Hello Christopher,
please check [1] if your bug has been reported already.
Or report new bugs at [2], and hopefully the maintainers (see list at
[3]) should reply on the bugs.
Timotheus
[1]: https://apps.fedoraproject.org/packages/xrdp/bugs
[2]: https://bugzilla.redhat.com
[3]:
> During his DevConf presentation, Ian mentioned that he had to recompile a lot
> of the base packages to get it working, so I'm guessing not. His presentation
> should be on YouTube by now if you're interested.
You might also want to have a look at "Fedora 23 Remix for Pi 2B" [1]
by Vaughan.
Hello,
we are discussing in this bug
https://bugzilla.redhat.com/show_bug.cgi?id=1220138 the work that
would be required to upgrade Mono in Epel.
I am aware that this is a major upgrade, and according to [1] it
should be avoided.
But Mono is that old in Epel7 already, so the discussion currently
> is deployed in probably half of the homes in Germany... Also I am
> pretty sure other routers form other manufacturers do the same
> thing. Now, if we default to DNSSEC validation soon, does this mean
Same for Vodafone Routers in Germany: I go to http://easy.box to
configure my router.
--
devel
DEBUG util.py:378: failure: repodata/repomd.xml from updates: [Errno 256]
No more mirrors to try.
DEBUG util.py:378:
http://infrastructure.fedoraproject.org/pub/fedora/linux/updates/20/i386/repodata/repomd.xml:
[Errno 14] HTTP Error 404 - Not Found
F20 has reached end of life:
Hello Dave,
You will get the option which platform you want to have the rebuild
for, when you click resubmit.
IIRC even the platforms where the last build was successful will not
be selected by default.
Timotheus
On 14 July 2015 at 07:05, Dave Johansen davejohan...@gmail.com wrote:
Hello Neal,
So we won't have mono stuff working for F22 then?
I have installed a fresh Fedora 21, and then upgraded to F22 according
to
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_21_-.3E_Fedora_22_.28not_yet_released.29
I then did dnf install mono-core.
rpm -qa | grep
Hello Peter,
I've rebuilt a few packages in the f23-mono4 side tag, some are broken
which causes some others to have failures, you'll need to fix/update
nant/dbus-sharp. I'm also rebuilding mono itself as a post boostrap
build.
Just for me as clarification: so is the bootstrap process
Do you intend to build and support mono4 in EPEL? Which versions. If
you've not done in EPEL it doesn't magically appear. Similarly you'll
need to file a ticket in the releng trac instance to get a side tag
for this.
I strongly suggest you get it built and all sorted out in rawhide with
all
Hello Peter,
It can, partially, but for the maintainers to know about your changes
you need to file bug reports in bugzilla, I suggest also you have a
mono4 tracking bug for all the bugs to block so it's easy for people
to track the status and help out as it's a central location.
Good to
Hello Peter,
Peter, do you have a list what will be rebuilt?
Not really, I would expect this to be provided by the Change owners.
The core bits I've looked at are:
graphviz
avahi
As they impact the rest of the distro.
and a few other packages. There appears to be problems with a number
Hello Dan,
first update
srpm builds fine on f22/s390x
mono segfaults when running monolite on f22/ppc64
build runs well on f22/ppc64le (new arch) after adding ppc64le to the
ExclusiveArch list
Thanks for trying it!
I have added ppc64le in the spec file to the ExclusiveArch list.
I wonder
Hello Dan,
I was made aware on IRC, that Claudio or myself should answer this question.
as Mono 4 adds support for the ppc64le architecture (and aarch64
support was probably added earlier), we (the Secondary arches team)
would like to see a full bootstrap and subsequent update of %mono_arches
Hello,
So, I guess the failure needs to be resolved first.
Upstream has fixed it and you can pull in their patch.
https://github.com/mono/mono/commit/16ee0252305fbd4f40ea39c3c4421dc7f103f8a0
I have now applied this patch, and it builds on Copr:
btw, the monolite binary is a native binary prebuilt for x86 only or
can it be easily built also for other arches?
according to http://www.mono-project.com/docs/compiling-mono/compiling-from-git/
this should work: make get-monolite-latest
Also have a look at
what we (in secondary arches) primarily need is the decision how to
proceed - incremental rebuild over 3.4 or complete rebootstrap.
Naturally we prefer the complete rebootstrap as it allows bringing up
new arches. And because we are in no way Mono experts, we would
appreciate the procedure
37 matches
Mail list logo
