Re: question regarding Fedora packaging

Hello Olivier, 2011/8/21 > I want to package an application that depends on jets3t. It is packaged in > Jpackage. I see in fact that many Java packages are available in JPackage. > > What is the usual behavior in this case ? As I understand from the following: https://fedoraproject.org/wiki/Ja

emacs and libotf.so.0

Hello, I just came onto a tricky dependency issue, and thought it could be of interest to the list. emacs requires libotf.so.0, which is the library handling Open Type Fonts (OTF), provided by the libotf package. Well, fine enough. But libotf.so.0 is also provided by the OpenMPI package (not in /u

[Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide

Hi, according to the dedicated Bugzilla feature request, Boost has just been upgraded (from 1.47.0

Re: [Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide

2011/11/20 Bruno Wolff III > Is there any expected semantic change for using BOOST_FOREACH? > I am having trouble rebuilding Wesnoth and get an error: > foreach.hpp:6:17: error: 'boost::BOOST_FOREACH' has not been declared > and foreach.hpp is: > #ifndef FOREACH_HPP > #define FOREACH_HPP > > #inc

Re: [Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide

2011/11/21 Bruno Wolff III > I talked to some of the active Wesnoth developers and they told me it (the > BOOST_FOREACH problem affecting Wesnoth) is an upstream bug with a fix > already. > Can we get this fix cherry picked for rawhide? > Yes, we shall add the patch into the Boost package. I wou

Re: boost soname bump

2011/11/22 Adam Williamson > [...] > Surprising, no, but it could certainly handled better. > You are absolutely right. I fully agree, but what's done is done: I made that mistake, Petr did not. I intended to perform a scratch-build, but omitted the "scratch" work... Sorry for that. I have learn

Re: boost soname bump

2011/11/23 Adam Williamson > > Is https://fedorahosted.org/rel-eng/ticket/4975 an example of such a > > ticket? > > No; that's someone using the old buildroot override process. You used to > have to file a ticket to request a buildroot override. > Yes, I saw that. But I did not find any ticket f

Re: Regex replace help

Hi Richard, Date: Sat, 3 Dec 2011 17:07:37 -0600 > From: Richard Shaw > Subject: Regex replace help > To: Development discussions related to Fedora > > Message-ID: > > > Content-Type: text/plain; charset=ISO-8859-1 > > I'm writing my own cmake module for finding TinyXML and I'm tr

P2P Packaging/Koji Cloud

Hello, RedHat-hosted Koji servers offer an invaluable service by allowing all of us, package maintainers, to build all of "our" Fedora packages. I guess that that infrastructure is not cost-less for RedHat and and the quality of service is great (for instance, the wait in the queues, before Koji a

Re: P2P Packaging/Koji Cloud

2011/12/7 seth vidal > I've looked into spawning virt instances to do building and it is pretty > doable. The problem with them being offered by volunteers is trust > [...] > You are right. I had not thought at that... how naive of me :( The volunteers/trustees would sign the builds with their

Re: P2P Packaging/Koji Cloud

2011/12/7 Nicolas Mailhot > Concerning trust, the classic way it has been solved before (by seti…) > is to farm the same build to several independant nodes, cheksum results > and make sure they all agree > Again, we could use that P2P build system just to alleviate the centralised Koji servers f

Re: P2P Packaging/Koji Cloud

> > Date: Wed, 07 Dec 2011 16:01:06 +0100 > From: Richard Marko > > I'm currently writing a proposal of similar architecture for testing > purposes. Looks like the core -- community provided virtual machines is > the common component for all this stuff so if designed correctly it can > be shared f

Re: devel Digest, Vol 94, Issue 22

> Date: Thu, 08 Dec 2011 04:34:57 +0900 > From: 夜神 岩男 > > Each time a build is made, the building system makes a hash of the set > of RPMs in $wherever/mock/result/{foo,bar} and sends the completed data > back to the Fedora build system. > [...] > This system depends chiefly on one thing: Having a

Re: P2P Packaging/Koji Cloud

> Date: Thu, 8 Dec 2011 12:33:38 -0500 > From: seth vidal > > I answered Denis immediately at the first post and he concurred it was > a problem. I like to think the conversation evolved as we discussed. > Yes, the conversation has shifted... Indeed, I mixed two distinct ideas: 1. One correspondi

Re: Starting mysql

Date: Mon, 12 Dec 2011 17:15:25 + > From: "Paul F. Johnson" > > Removed the entire mysql* rpms, installed fresh via yum, rm > -rf /var/lib/mysql, enabled the service, did the mysql_install_db and > all is good. > > Trying to start the server gives me this though... > > 111212 07:49:18 mysqld

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17

Hi Jim, 2012/1/3 > > Is there some sort of reminder service that could be configured to nag the > maintainers of a package in a situation like this? Personally, I would > appreciate it, and I think Fedora would benefit if we could do something to > minimize reverse-version skew between Fedora-la

Re: devel Digest, Vol 133, Issue 13

Hi, Date: Tue, 03 Mar 2015 21:27:42 -0700 > From: Orion Poplawski > Message-ID: <54f689be.8080...@cora.nwra.com> > > I'm orphaning the following R packages as we don't use them anymore and > I don't have the time for them: > > [...] R-mvtnorm -- Multivariate normal and T distribution R Package (

Re: Packages that failed to build with Python 3.9

Thanks for the follow up! | airinv airrac airtsp rmol sevmgr trademgen All those packages have been successfully rebuilt (after upstream upgrade): * airinv: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d6b3c81762 * airrac: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bd268627aa * ai

Re: Packages that failed to build with Python 3.9

h confused with it at the beginning (but it's all crystal clear by now). Thanks! Kind regards Denis Le mar. 2 juin 2020 à 17:46, Jonathan Wakely a écrit : > On 01/06/20 02:14 -, Denis Arnaud wrote: > >Thanks for the follow up! > > > >| airinv airrac airtsp rm

Re: Searching a new home for my packages

Thanks Thomas for the great work in the past! If nobody else is interested, I can take ZeroMQ ones. Kind regards Denis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Co

Re: *countable infinities only

The discussion has been very interesting, and it is probably being followed by a lot of non-Fedora developers as well. [To be honest, I first bought the pro-"find-a-simple-enough-work-around-to-SecureBoot-issue" arguments. But, reading through the arguments from KK, Adam and some others, I must ad

Re: *countable infinities only

Though most of you already certainly know about it, Linus Torvalds has expressed his point of view about that story: http://www.zdnet.com/blog/open-source/linus-torvalds-on-windows-8-uefi-and-fedora/11187 Kinds regards D -- devel mailing list devel@lists.fedoraproject.org https://admin.fedorapro

Re: *countable infinities only

Hmm. Sorry, that is the only article I found on the subject (having searched for "Linus Torvalds Fedora" on search engines). There was also a summary on LinuxToday, which then linked the same ZDnet article. 2012/6/12 Peter Jones > Aside Linus being incorrect, the rest of the article is also full

Packaging Hypertable

Hi, has anyone already attempted to package Hypertable ( http://hypertable.com/community/source_code/) for Fedora/RedHat/CentOS? Does anyone know whether there are current initiatives around it? Would someone be interested in starting such a project? Upstream already delivers RPM packages (http://

Re: Rolling release model philosophy

Date: Sun, 04 Nov 2012 14:07:02 +0100 Simon Lukasik wrote: > Currently, each Fedora release is kept alive for 13(+/-) months. There > were dozens of threads about shortening or prolonging period -- but I am > not sure if something like the following has been ever discussed: > Each N-th Fedora rel

Re: boost141 and stability of Boost API?

Hi Dave, note that Boost-1.48 has been packaged for EPEL 5 and 6, but not yet approved: http://bugzilla.redhat.com/show_bug.cgi?id=921134 In case it is useful to anyone, do not hesitate to approve it :) And if there is more love, we could even embark on the way to package Boost-1.54 for EPEL... Bu

Re: boost141 and stability of Boost API?

/plain; charset="iso-8859-1" > > On Sat, Oct 5, 2013 at 2:12 PM, Denis Arnaud >wrote: > > > Hi Dave, > > > > note that Boost-1.48 has been packaged for EPEL 5 and 6, but not yet > > approved: http://bugzilla.redhat.com/show_bug.cgi?id=921134 > > In ca

[Heads Up][Boost] Build of dependent packages before the massive rebuild

Hi! AFAIK, the next massive rebuild is scheduled for the 12th February, 2013. Moreover, as you may know, Boost-1.53.0 has been successfully built already (thanks to Petr!) on Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=382788 So, as a few of you have already suggested, it may be a

Re: Obsolete packages still included in Fedora 19 development

> I have retired fcitx-keyboard. > > > > But Denis Arnaud cleaned up all code for fcitx(1). I think it should be > > wrong. I have reverted the code back to git repo just now. Fcitx is > still > > fine and is widely used in CJK community. > > > > 1. > >

Re: [Heads Up][Boost] Build of dependent packages before the massive rebuild

​Yes, the massive rebuilds have occured. AFAIU, if Koji keeps reporting unresolved dependencies, it means that the corresponding packages FTBFS. So, if you are the owner or a co-maintainer, it would be nice to browse through the root.log/build.log and see why those packages are failing to build. H

Re: Boost packages conflict

> No one try to install it now. New boost will be in F33 only. > > But if boost not installed in system and user want install for example > libreoffice he will get this error and can't install any package > requires boost. > > boost169 must be removed from F32 repos at all. > > чт, 14 мая 2020 г

Re: Boost packages conflict

> No one try to install it now. New boost will be in F33 only. > > But if boost not installed in system and user want install for example > libreoffice he will get this error and can't install any package > requires boost. > > boost169 must be removed from F32 repos at all. > > чт, 14 мая 2020 г

Re: Boost packages conflict

So, should I add the obsoletes clauses for every package, or is it fine to leave it as it is now? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https:/

Re: Boost packages conflict

* boost-1.69.0-18.fc32, obsoleting boost169 on Fedora 32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8770cfebcd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Co

Re: EPEL-8 builds

Date: Thu, 7 Nov 2019 11:23:11 -0500 > Message-ID: > sjrbn+...@mail.gmail.com> > > On Thu, 7 Nov 2019 at 05:13, Peter Robinson wrote: > > I'd like to know why people are pushing EPEL-8 builds without engaging > > with the maintainers of the packages. I've had a few packages where > > I'm

Python bindings for protobuf on RHEL/CentOS/EPEL 8

Hi, the Python (3) bindings are missing on RHEL/CentOS/EPEL 8 for the protobuf package (https://src.fedoraproject.org/rpms/protobuf). A bug request has been created on Bugzilla ( https://bugzilla.redhat.com/show_bug.cgi?id=1765844), but as no status has been given, I was wondering whether someone

Re: devel Digest, Vol 192, Issue 85

There are still some tricky issues (related to OpenMPI and Python) making the build fail. I've integrated the latest changes ( https://github.com/fedorapackaging/fedorareviews/tree/trunk/reviews/boost /boost_xxx_boost172) and made a first attempt at building on COPR ( https://copr.fedorainfracloud

Re: Unannounced soname bump in libre2

Thanks for the heads up (!)... and sorry for the unannounced bump. I totally overlooked that this package had so many dependencies, direct or indirect. As you have suggested on another channel, I feel it is the moment for me to handover the ownership of that package to anyone having more time to t

Re: Unannounced soname bump in libre2

Thanks for having caught that one! Fixed. The Fedora update for that mtxclient package for Fedora Rawhide (F42) is https://bodhi.fedoraproject.org/updates/FEDORA-2024-e9e992dd11 I take that opportunity for a quick status/reference of the rebuilding on some of the dependent packages: * perl-Regex

Re: Unannounced soname bump in libre2

A dedicated page was created on the Fedora wiki to coordinate the various builds: https://fedoraproject.org/wiki/User:Denisarnaud/Tasks/Ongoing/2024-08-re2 Most of the dependent packages have been successfully rebuilt (thanks to all the contributors!), or will soon be. The only one to keep fai

Re: Unannounced soname bump in libre2

Thanks Sandro! qt5-qtwebengine seems to be the last package to rebuild after the re2 upgrade [1]. On my Fedora Rawhide VM, on which I still have Python2.7 (as it is a rollover rawhide in my case, which I upgrade regularly to keep in sync with the upstream Rawhide), qt5-qtwebengine builds almost