Looking for co-maintainers: zookeeper, bookkeeper, curator
I intend to orphan, and I simply don't have the bandwidth to maintain these packages. -- Cheers, Timothy St. Clair tstcl...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mongo client in Rawhide
condor is broken due to this issue as well, it's due to monogo shift. - Original Message - From: Pete Zaitcev zait...@redhat.com To: devel@lists.fedoraproject.org Sent: Tuesday, August 26, 2014 4:57:52 PM Subject: Mongo client in Rawhide Guys, does anyone know what's up with this (in mock_output.log): ... Start: build setup for iwhd-1.6-12.fc22.src.rpm ERROR: Exception(/var/tmp/koji/tasks/6322/7456322/local/work/cli-build/1409089719.76847.osWulSbq/iwhd-1.6-12.fc22.src.rpm) Config(f22-build-2326357-414230) 0 minutes 1 seconds INFO: Results and/or logs in: /var/lib/mock/f22-build-2326357-414230/result ERROR: Command failed: # ['/usr/bin/yum-builddep', '--installroot', '/var/lib/mock/f22-build-2326357-414230/root/', '/var/lib/mock/f22-build-2326357-414230/root///builddir/build/SRPMS/iwhd-1.6-12.fc22.src.rpm', '--setopt=tsflags=nocontexts'] Getting requirements for iwhd-1.6-12.fc22.src -- autoconf-2.69-15.fc21.noarch -- automake-1.14.1-4.fc21.noarch -- bison-3.0.2-3.fc22.x86_64 -- boost-devel-1.55.0-4.fc22.x86_64 -- boost-filesystem-1.55.0-4.fc22.x86_64 -- flex-2.5.37-8.fc22.x86_64 -- gc-devel-7.4.2-2.fc22.x86_64 -- hail-devel-0.8-0.16.gf9c5b967.fc22.x86_64 -- help2man-1.46.1-1.fc22.noarch -- jansson-devel-2.6-4.fc21.x86_64 -- libcurl-devel-7.37.1-3.fc22.x86_64 -- libmicrohttpd-devel-0.9.34-4.fc22.x86_64 -- liboauth-devel-1.0.3-3.fc22.x86_64 -- libuuid-devel-2.25-4.fc22.x86_64 -- libxml2-devel-2.9.1-5.fc22.x86_64 -- mongodb-server-2.6.3-2.fc22.x86_64 -- systemd-216-2.fc22.x86_64 Error: No Package found for mongodb-devel I didn't see any changes in Mongo announced for F22, am I missing something? -- Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Cheers, Timothy St. Clair Red Hat Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedoras default cflags clang
I'm primarily referring to development compilation, not necessarily packaging. The default CFLAGS cause clang to fail 'out of the gate'. Given the popularity rise in the compiler, and the increase # of open tickets upstream around this issue, I think it prudent that we address. Not to change the whole packaging infrastructure, just so developers can install the tools and test their builds. Cheers, Tim - Original Message - From: Jakub Jelinek ja...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Discussion of RPM packaging standards and practices for Fedora packag...@lists.fedoraproject.org Sent: Friday, May 30, 2014 4:03:57 AM Subject: Re: fedoras default cflags clang On Fri, May 30, 2014 at 10:25:28AM +0200, Ralf Corsepius wrote: On 05/29/2014 10:28 PM, Tim St Clair wrote: I've been seeing this bug crop up in many circles: https://bugzilla.redhat.com/show_bug.cgi?id=1099282 Many folks like to use clang as their primary compiler for various reasons, is there anyone who knows a workaround or fix? I think FPC (and/or FESCO) should decide on whether we want to allow/disallow using clang for official Fedora rpms. https://fedorahosted.org/fesco/ticket/847 http://meetbot.fedoraproject.org/fedora-meeting/2012-05-14/fesco.2012-05-14-17.00.log.html ? Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Cheers, Tim Freedom, Features, Friends, First - Fedora https://fedoraproject.org/wiki/SIGs/bigdata -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
fedoras default cflags clang
I've been seeing this bug crop up in many circles: https://bugzilla.redhat.com/show_bug.cgi?id=1099282 Many folks like to use clang as their primary compiler for various reasons, is there anyone who knows a workaround or fix? -- Cheers, Tim Freedom, Features, Friends, First - Fedora https://fedoraproject.org/wiki/SIGs/bigdata -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Systemd Slices and cgroups freezer controller
Greetings folks - I have 2 applications under my purview that rely on freezer controller behavior, but there is no clear route on how to enable the freezer for applications that are started under a Systemd.Slice. -- Cheers, Tim Freedom, Features, Friends, First - Fedora https://fedoraproject.org/wiki/SIGs/bigdata -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Systemd cgroups NWO
What is the status of fedora systemd cgroup integration outlined here: http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ Current build is 211-1. The reason for asking is in the document: short-term, medium-term, long-term are not fully defined. We all know Fedora lives on the tip of the spear. -- Cheers, Tim Freedom, Features, Friends, First - Fedora https://fedoraproject.org/wiki/SIGs/bigdata -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fwd: mesos-0.18.0-rc3 rawhide build available.
Bindings now available as sub-package(s). This enables frameworks such as Spark and Aurora. For a full list of Frameworks see: http://mesos.apache.org/documentation/latest/mesos-frameworks/ Cheers, Tim - Forwarded Message - From: Tim St Clair tstcl...@redhat.com To: u...@mesos.apache.org Cc: mesos-devel d...@mesos.apache.org Sent: Wednesday, March 5, 2014 2:38:33 PM Subject: mesos-0.18.0-rc3 Fedora Build available. Folks - Re-base to 0.18.0-rc3 available in rawhide channels: http://koji.fedoraproject.org/koji/packageinfo?packageID=17691 Change log: * Wed Mar 05 2014 Timothy St. Clair tstcl...@redhat.com - 0.18.0-1.a411a4b - Updated to 0.18.0-rc3 - Included sub-packaging around language bindings (Java Python) - Improved systemd integration - Iteration to rebuild libev-source w/-DEV_CHILD_ENABLE=0 With modifications around the build, and alignment on dependencies, only test failures are around system integration vs. sandbox_env. On Deck: - Deeper system integration (clean-er systemd cgroup setup OOTB) - Eval containerization work - Further un-bundling where possible Other Noteworthy/Related Fedora changes: - Docker on Fedora (http://goldmann.pl/blog/2013/09/25/docker-and-fedora/) - Systemd Cgroup New World Order: (http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/) - Spark in-flight, will verify integration (https://bugzilla.redhat.com/show_bug.cgi?id=1071495) -- Cheers, Tim Freedom, Features, Friends, First - Fedora https://fedoraproject.org/wiki/SIGs/bigdata -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unresponsive reviewer, glusterfs-openstack-swift,
Kaleb - If you're looking for a new reviewer, feel free to CC: bigd...@lists.fedoraproject.org As I'm sure there will be interest. Cheers, Tim - Original Message - From: Rex Dieter rdie...@math.unl.edu To: devel@lists.fedoraproject.org Sent: Thursday, February 13, 2014 10:34:48 AM Subject: Re: Unresponsive reviewer, glusterfs-openstack-swift, Kaleb KEITHLEY wrote: Is there anything that can be done to wrap up this package review so that we can move forward? Given sufficient non-responsiveness, sounds like there has been... Remove the reviewer, so someone else can step in. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Cheers, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libev - bundling - expected
Greetings folks - It appears that I've run into a conundrum: libev upstream developer(s) actually encourage (re)bundling of libev, see - https://bugzilla.redhat.com/show_bug.cgi?id=1049554 I was wondering if there was president for how to handle *this. In groking the code, it's not run-time configurable, but alas it's a dependency on one of my packages. Thoughts? Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libev - bundling - expected
Thanks Adam, that was the reference I was looking for. Cheers, Tim - Original Message - From: Adam Williamson awill...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Wednesday, January 8, 2014 1:39:41 PM Subject: Re: libev - bundling - expected On Wed, 2014-01-08 at 13:09 -0500, Tim St Clair wrote: Greetings folks - It appears that I've run into a conundrum: libev upstream developer(s) actually encourage (re)bundling of libev, see - https://bugzilla.redhat.com/show_bug.cgi?id=1049554 I was wondering if there was president for how to handle *this. In groking the code, it's not run-time configurable, but alas it's a dependency on one of my packages. The bundling policy has an exception for 'copylibs', which *may* apply here: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs this is the clause you would need to check to see if your case matches it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Cheers, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Introduction
Feel free to ping me on freenode #fedora-devel, or #fedora-bigdata. We've been doing a fair amount of packaging lately, and could offer up tips where needed. I often find the best starting point is here: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers You will want to also read: https://fedoraproject.org/wiki/Packaging:Java Cheers, Tim - Original Message - From: Tako Schotanus tscho...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, November 22, 2013 6:58:03 AM Subject: Introduction Hi, I read that somebody wanting to be a package maintainer should introduce themselves, well here goes. I'm Tako, a Software Engineer for Red Hat working on a new language, Ceylon (http://ceylon-lang.org), that runs on top of the Java and Javascript VMs. We just published out first 1.0.0 and although we already had RPMs (and ZIPs and DEBs) that could be downloaded from our website for a while now we'd like to add the package to the official Fedora repositories now that we're at 1.0.0 (also because Ubuntu is working on getting the package into their repos and as a RedHat sponsored project it would be weird if we didn't do the same for Fedora, right?) So I'm completely new to this packaging business, I managed to piece together a SPEC file that results in an actually working RPM for our project and even Koji seems to accept it, but there's so much information to absorb that I'm feeling a bit out of my depth. (Our project being a programming language we're dealing with some difficult issues with respect to versioning and such, for now I've copied Java's with alternatives and such which might or not be a good idea). So if there are some friendly people here that can guide me through my first real submission that would be great! Cheers, Tako Schotanus Senior Software Developer Ceylon Language Project www.ceylon-lang.org RedHat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Cheers, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
+1 to everything kevin just said. Just because other folks are employing bad practices, doesn't mean we should. If that means dependent packages need to add an extra -I location, that is a far better solution then polluting causing potential conflicts. Cheers, Tim - Original Message - From: Kevin Kofler kevin.kof...@chello.at To: devel@lists.fedoraproject.org Sent: Friday, November 22, 2013 9:06:07 AM Subject: Re: Packaging changes for libev in Rawhide Mathieu Bridon wrote: * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) -1 Conflicts are evil, and this pointless conflict is very easily avoided by moving the header to a subdirectory as the package now does. +1 (I actually think that BOTH libev and libevent should use a subdirectory for their headers. event.h is a very generic header name that doesn't belong in /usr/include at all.) +1 Upstream needs to comprehend that they cannot just spam their headers directly into /usr/include; if they don't, we have no other choice than moving them without their consent. +1 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Cheers, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
Sorry to disagree, but segregation is standard practice and is far better then polluting /usr/include. Also, I have a package which has separate patches which I'm uncertain if upstream has adopted. https://github.com/apache/mesos/blob/master/3rdparty/libprocess/3rdparty/libev-4.15.patch Cheers, Tim - Original Message - From: Mathieu Bridon boche...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, November 19, 2013 1:30:46 AM Subject: Packaging changes for libev in Rawhide Hi, I would like to finally fix this bug in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=985610 Basically, our libev package diverges from upstream in two ways: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ 2. we ship a pkgconfig file, which upstream does not want I'm not happy with these Fedora-specific changes, and upstream is completely uninterested in them. It's confusing users who don't find the headers where they expect them, as demonstrated by this bug report. Worst of all, it's causing changes in software consuming libev, which have often had to be modified for the Fedora-specific change in libev. Those changes were sometimes made in the respective upstreams, but most often in additional Fedora-specific changes. I've been talking to upstream libev, and they really don't want the changes we made. They'd be much happier if we were packaging libev the way Debian is, as that's how they intended libev to be used. So I'd like to follow upstream libev wishes, and stop confusing everybody with our Fedora-only changes. My plan is to do the following in Rawhide (the future Fedora 21) : * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) * Drop our pkgconfig file. Here is the list of packages I could find with a build requirement on libev: $ repoquery --enablerepo=\*source --archlist=src --whatrequires 'pkgconfig(libev)' libev-devel awesome-0:3.5.1-8.fc20.src i3-0:4.6-1.fc20.src i3lock-0:2.5-2.fc20.src libverto-0:0.2.5-3.fc20.src ocaml-lwt-0:2.4.2-3.fc20.src picviz-0:0.6-12.fc20.src rubygem-passenger-0:4.0.18-2.fc20.src rubygem-passenger-0:4.0.18-4.fc20.src spectrum-0:1.4.8-11.fc20.src stud-0:0.3-4.20120814git.fc20.src weighttp-0:0.3-5.fc20.src I'll fix weighttp, as it is my package, but I can't do much about the other ones. I'm adding a breakdown of how these packages use libev and what needs to be done for them at the end of this email. Does anybody have any comment, or objection? Cheers, -- Mathieu awesome --- Our package has some downstream patches to require our Fedora-only pkgconfig file for libev. Making it build-require libev-devel instead and dropping this downstream patch should be enough. i3 -- Nothing should need to be done here. Upstream checks for libev with pkg-config, but it ignores errors. And once I move the libev headers in /usr/include, then they'll be found anyway. i3lock -- The spec file calls pkgconfig to find the libev headers. This should just be removed, and the package should build just fine, as intended by upstream. libverto Upstream itself requires the pkgconfig file for libev. That's just a terrible idea, as it means libverto won't build on e.g Debian, or with the upstream libev. libverto should be fixed upstream here IMHO. ocaml-lwt - The package has a patch to make it find the headers int he Fedora-specific location. It should be dropped, and that should be it. picviz -- The package has a patch to make it find the headers int he Fedora-specific location. It should be dropped, and that should be it. rubygem-passenger - Upstream hardcodes -I/usr/include/libev in the cflags, which is only needed with our current libev package in Fedora, nowhere else. Anyway, the package should just build without any change once I move the libev headers to /usr/include. spectrum Upstream searches for the ev.h header in various folders, so things should continue to work without a change. stud Our package has a patch to hardcode -I/usr/include/libev in the CFLAGS. That can be dropped. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Cheers, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
review swap: amplab-tachyon
Folks - I've put amplab-tachyon up for review (https://bugzilla.redhat.com/show_bug.cgi?id=1029142) and would be happy to review in exchange. -- Cheers, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Bug 1010512 - Review Request: mesos - Cluster Manager (Primarily C++)
Any takers? https://bugzilla.redhat.com/show_bug.cgi?id=1010512 Depends on: https://bugzilla.redhat.com/show_bug.cgi?id=994152 -- Cheers, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)
+1 Trying to continually level set to the HEAD of Fedora has introduced patch sets which only continue to diverge over time. Upstream(s) have expressed little/no interest in accepting some of these patches, and I can hardly blame them. Cheers, Tim - Original Message - From: Peter MacKinnon pmack...@redhat.com To: devel@lists.fedoraproject.org Sent: Monday, July 22, 2013 4:54:27 PM Subject: Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk) Shout out to my fellow Flocker, Matt... Original Message Subject: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk) Date: Mon, 22 Jul 2013 09:38:54 -0400 From: Matthew Miller mat...@fedoraproject.org Reply-To: Development discussions related to Fedora devel@lists.fedoraproject.org To: Fedora Development List devel@lists.fedoraproject.org snip Obviously, no-bundled-libs is a crucial part of the packaging guidelines today. As a sysadmin, I know why it's important. This is not just a noble goal, but also something that pragmatically makes systems better. But, it's also keeping us from having software that people really use in Fedora. Chef and Hadoop are two big examples. This hurts us more than it helps the world. So, in some areas, we need a different approach. The Big Data SIG is trying to adapt Hadoop 2.x into Fedora for F20 , and I'll be sharing our insights on this at Flock in a couple of weeks. In Matt's conceptual architecture I suppose Hadoop Common would live in the Ring 2-to-3 orbit somewhere. It is a core in it's own right (it provides a distributed, replicated file system) in that there is an every growing software ecosystem that has emerged around it, and the SIG would like Fedora to be the OS of choice for that ecosystem. Stable enough for deployment but a feature-rich, current and productive environment for the developers in that evolving ecosystem. The Hadoop runtime is an orchestration of JVM-based daemons which can be viewed as system-level services, thus an obvious candidate for well-defined integration with Fedora via packaging: correct permissions, systemd scripts, logs, etc. However, the root of that core is a set of older and deprecated Java dependencies (e.g., Jetty 6, Tomcat 5.5) which are expressed via the Apache Maven build tool. The quick and dirty label used by another poster of a VERY popular build tool like Maven does it a disservice. The fact is that it is exceedingly popular in the Java development community and has been for some time. Anyway, the challenge for this project is the reconciliation of it's stable dependencies versus the ever-changing bleeding edge that is typically found in the latest Fedora release. A lot of our efforts so far have been the various API and build specification changes necessary to try to make Hadoop fit into Fedora. So far, so good...sort of. We can make the basic use case and tests work with the modified dependencies but in doing so we risk giving up parity with the Apache baseline (including the JRE) and potentially lose out to other so-called dirty RPMs. Ideally, we wouldn't be forced into some of these adaptations and compromises if there were Fedora packaging alternatives that would give us (a SIG ring?) more control over the bundles needed by Hadoop as opposed to the ones mandated by the latest Fedora release. Make no mistake: patches are fed from the SIG to the Hadoop community to try to bump the versions there. But the upstream project can't and won't chase an ever-vanishing point in the distance. They view their lower dependencies much like a stable OS such as RHEL and change should be deliberated there. I feel like Matt has at least kick-started the discussion around how Fedora could evolve to support orthogonal dependency models that more readily adapt to external projects like Hadoop. Not that our SIG has any profound answers. :-) Thus, we are very interested in any packaging architecture proposals that could help relieve our initiative's pain points, and look forward to further constructive discussion of the same. My $0.02, \Pete -- Peter MacKinnon MRG Grid/Big Data Red Hat Inc. Raleigh, NC -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mesos Packaging
irc freenode #fedora-bigdata, or #fedora-devel - Original Message - From: Igor Gnatenko i.gnatenko.br...@gmail.com To: devel@lists.fedoraproject.org Sent: Tuesday, July 23, 2013 4:06:27 AM Subject: Re: Mesos Packaging On Mon, 2013-07-22 at 09:52 -0400, Tim St Clair wrote: Thanks Igor! Currently we'll need to bundle their dependencies prior to the main package. I'm just about done with stout, but I could use some help with their (libprocess https://github.com/3rdparty) library prior to mundging the mesos package. of course the main mesos package too, but we have a couple of preliminary specs already. Cheers, Tim - Original Message - From: Igor Gnatenko i.gnatenko.br...@gmail.com To: devel@lists.fedoraproject.org Sent: Saturday, July 20, 2013 1:35:27 AM Subject: Re: Mesos Packaging On Fri, 2013-07-19 at 15:14 -0400, Tim St Clair wrote: For folks who are watching, we are assisting the upstream Mesos project(https://issues.apache.org/jira/browse/MESOS-543) and there is interest from multiple parties to get the package and it's dependencies into the Fedora | EPEL channels. If you are interested, please feel free to ping me and we can coordinate, as there is a fair amount to be done. Cheers, Tim I would gladly to packaging it or help to packaging. -- Igor Gnatenko Fedora release 19 (Schrödinger’s Cat) Linux 3.9.9-302.fc19.x86_64 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Hey Tim! Where we can talk online ? irc, jabber, google ? I have many questions. -- Igor Gnatenko Fedora release 19 (Schrödinger’s Cat) Linux 3.9.9-302.fc19.x86_64 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mesos Packaging
Thanks Igor! Currently we'll need to bundle their dependencies prior to the main package. I'm just about done with stout, but I could use some help with their (libprocess https://github.com/3rdparty) library prior to mundging the mesos package. of course the main mesos package too, but we have a couple of preliminary specs already. Cheers, Tim - Original Message - From: Igor Gnatenko i.gnatenko.br...@gmail.com To: devel@lists.fedoraproject.org Sent: Saturday, July 20, 2013 1:35:27 AM Subject: Re: Mesos Packaging On Fri, 2013-07-19 at 15:14 -0400, Tim St Clair wrote: For folks who are watching, we are assisting the upstream Mesos project(https://issues.apache.org/jira/browse/MESOS-543) and there is interest from multiple parties to get the package and it's dependencies into the Fedora | EPEL channels. If you are interested, please feel free to ping me and we can coordinate, as there is a fair amount to be done. Cheers, Tim I would gladly to packaging it or help to packaging. -- Igor Gnatenko Fedora release 19 (Schrödinger’s Cat) Linux 3.9.9-302.fc19.x86_64 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mesos Packaging
Thanks Mikolaj, That is good to know, b/c I know some folks in their community would like to bring it to EPEL, but my first step will be Fedora, then let the community drive. Cheers, Tim - Original Message - From: Mikolaj Izdebski mizde...@redhat.com To: devel@lists.fedoraproject.org Sent: Monday, July 22, 2013 12:07:08 AM Subject: Re: Mesos Packaging On 07/19/2013 09:14 PM, Tim St Clair wrote: For folks who are watching, we are assisting the upstream Mesos project(https://issues.apache.org/jira/browse/MESOS-543) and there is interest from multiple parties to get the package and it's dependencies into the Fedora | EPEL channels. If you are interested, please feel free to ping me and we can coordinate, as there is a fair amount to be done. If you need any help with the Java parts, feel free to contact me. There is no Maven in EPEL so the Java parts would need to be disabled in EPEL or built with a different build system (like Ant). -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Mesos Packaging
For folks who are watching, we are assisting the upstream Mesos project(https://issues.apache.org/jira/browse/MESOS-543) and there is interest from multiple parties to get the package and it's dependencies into the Fedora | EPEL channels. If you are interested, please feel free to ping me and we can coordinate, as there is a fair amount to be done. Cheers, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package Review Requests for Hadoop dependencies
Many thanks Björn! It looks like we are green on dependencies! for now ;-) Cheers, Tim - Original Message - From: Björn Esser bjoern.es...@gmail.com To: gil punto...@libero.it Cc: devel@lists.fedoraproject.org Sent: Tuesday, June 11, 2013 1:35:50 PM Subject: Re: Package Review Requests for Hadoop dependencies Am Dienstag, den 11.06.2013, 20:16 +0200 schrieb gil: hi yes , many thanks Björn have some trouble with boost with bookkeeper data.cpp:249:3: error: 'lock_guard' is not a member of 'boost' boost::lock_guardboost::mutex lock(mutex); ^ data.cpp:249:33: error: expected primary-expression before '' token boost::lock_guardboost::mutex lock(mutex); ^ data.cpp:249:45: error: 'lock' was not declared in this scope boost::lock_guardboost::mutex lock(mutex); channel.cpp:705:43: error: 'shared_dynamic_cast' is not a member of 'boost' boost::shared_dynamic_castAsioSSLDuplexChannel(shared_from_this()), ^ channel.cpp:705:90: error: expected primary-expression before '' token boost::shared_dynamic_castAsioSSLDuplexChannel(shared_from_this()), ^ channel.cpp: In member function 'void Hedwig::AsioSSLDuplexChannel::sslShutdown()': channel.cpp:752:42: error: 'shared_dynamic_cast' is not a member of 'boost' boost::shared_dynamic_castAsioSSLDuplexChannel(shared_from_this()), ^ channel.cpp:752:89: error: expected primary-expression before '' token boost::shared_dynamic_castAsioSSLDuplexChannel (shared_from_this()), boost problems any ideas? thanks Which boost version resp. which fedora-release? I think it would be the best to join #fedora-devel irc and and have our discussion there, wouldn't it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package Review Requests for Hadoop dependencies
Many thanks Björn! - Original Message - From: Björn Esser bjoern.es...@gmail.com To: Robert Rati rr...@redhat.com Cc: devel@lists.fedoraproject.org, bigd...@lists.fedoraproject.org Sent: Tuesday, June 11, 2013 10:23:12 AM Subject: Re: Package Review Requests for Hadoop dependencies Hi Rob! You're welcome. Just approved ZooKeeper; BookKeeper is last to be reviewed (and currently FTBFS) on the list. So hadoop should reach it's target F20 in time :) Cheers, Björn Am Dienstag, den 11.06.2013, 10:21 -0400 schrieb Robert Rati: Hi Bjorn, Thanks so much for picking these up and reviewing them! Rob On 06/11/2013 03:04 AM, Björn Esser wrote: Am Montag, den 10.06.2013, 15:42 -0400 schrieb Robert Rati: I'm working with the Big Data SIG to package hadoop for Fedora. We're targeting Fedora 20, but right now there are a number of packages that hadoop will depend upon that are awaiting review. All dependent packages have review BZs logged. Packages needing review for inclusion into Fedora: bookkeeper (BZ948589) groovy (BZ858127) jets3t (BZ847109) jspc-compiler (BZ960720) maven-native (BZ864084) zookeeper (BZ823122) One of those packages also has a dependency which also needs to be reviewed: jtoaster (zookeeper, BZ957337) If we are to get hadoop into Fedora 20 we need some movement on the review requests for these packages. Would anyone, or a group of people, be willing to review these packages and help us get them into Fedora? Rob Hello Rob! I'll take them one by one during this week. Would be fine if another volunteer will join-in, though. Cheers, Björn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
