Re: gethostbyname() and resolv.conf updates
2010/6/17 Bernie Innocenti ber...@codewiz.org: Hello, xchat in Fedora needs to be restarted after switching to a different nameserver or it fails to resolve. The xchat developers say that all xchat does is call gethostbyname(). A There was a topic 3 years ago about replacing gethostby* functions by getaddrinfo Is this still relevant? http://lists.fedoraproject.org/pipermail/devel/2007-October/112483.html http://udrepper.livejournal.com/16116.html Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADS UP : mysql++ version 3.1.0 - ABI broken without soname bump
2010/6/20 Remi Collet fed...@famillecollet.com: Hi, I've just build latest version of mysql++ in rawhide. This version breaks ABI. Thanks for the notice! I'll take care of SEMS rebuild. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Hatari version: need help
2010/6/19 Alexander Boström a...@root.snowtree.se: lör 2010-06-19 klockan 19:32 +0200 skrev Andrea Musuruane: I do not know how should I threat those internal libraries. How should I package them? Because upstream uses static libraries the dynamic versions cmake creates are not versioned. https://fedoraproject.org/wiki/Packaging:Guidelines#Rpath_for_Internal_Libraries I fail to see how this is relevant. Hatari do not use Rpath. Regards, Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Hatari version: need help
On Sat, Jun 19, 2010 at 7:44 PM, Chen Lei supercyp...@gmail.com wrote: You can open a RFE report against this package in bugzilla for review. Can you point me to an example? For internal libs, if those libs are not libs from other project, you can simply use %cmake -DBUILD_SHARED_LIBS:BOOL=OFF to avoid generation of those shlibs. Default place for python ui don't need change. Internal libs are made by Hatari developers and therefore they haven't a different upstream. Thanks! Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Hatari version: need help
Andrea Musuruane píše v Ne 20. 06. 2010 v 11:25 +0200:
2010/6/19 Alexander Boström a...@root.snowtree.se:
lör 2010-06-19 klockan 19:32 +0200 skrev Andrea Musuruane:
I do not know how should I threat those internal libraries. How should
I package them? Because upstream uses static libraries the dynamic
versions cmake creates are not versioned.
https://fedoraproject.org/wiki/Packaging:Guidelines#Rpath_for_Internal_Libraries
I fail to see how this is relevant. Hatari do not use Rpath.
hatari could use %{_libdir}/hatari with a rpath set for the internal
parts built as shared libraries. The easiest way is to disable building
shared libs when calling cmake as suggested earlier.
Dan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To construct a Zope skyscraper on Fedora
On 06/20/2010 12:45 PM, Nathaniel McCallum wrote: On 06/20/2010 12:22 AM, Jonathan Steffan wrote: On Fri, 2010-06-18 at 21:08 +0800, Robin 'cheese' Lee wrote: The 'zope' package itself is most kept under the same conventions of the legacy 2.10.x 'zope' package. We have a unique opportunity to address many of the failings of the current zope namespace. We should get anyone interested (and willing to do the work) into a meeting soon. Every time I go back to building up zope again I run out of steam and end up just being frustrated. I foresee issues with splitting out every module in this stack but it just needs to be discussed. The current package layout is far from optimal and it's not the best idea to ship a default standalone instance with the package. Shipping standalone/zeo instance configs/etc. in subpackages is a far better idea. I've never been able to address this as there is just about no upgrade path (that I've been able to design) that would allow for a safe re-layout of the current package. We should consider the current zope namespace dead and start from scratch. It's far too complex of an application to be able to have everything in one namespace (speaking to zope2 vs zope3.) I've only briefly looked into all of the specs you've worked on and already can see we are going to run into issues with cross-product dependencies. I could be convinced that the zope namespace should be the latest 2.x and then address the need for zope 3 in the zope3 namespace. However, how do we distinguish a module built for zope 2 vs zope 3? This, again, could be solved but will need discussion. With zope 2.12 supporting py2.6, I think we might actually have a shot at making this work. However, immediately off the bat if we stick 2.12.x into zope what happens to grok? What packages are going to break? Too many things need zope 2.x so updating the zope namespace to zope 3 would break a lot of good software. What happens to plone? Do we just ditch Plone 3 and only support Plone 4?[2] We could also modularize everything and have things like zope, plone, grok and zenoss have dependencies based on their release recipes. There are a lot of common modules in these projects, but they all have their own specific version requirements. This would be a lot of work and could potentially cause us to package ourselves into a corner where we are having to do absolute requires or just end up with broken software when absolute requirements are not properly documented. I really look forward to others being involved with this. Count me in for the SIG.[2] - Jonathan Steffan [1] http://plone.org/documentation/faq/plone-versions [2] http://fedoraproject.org/wiki/SIGs/Zope I agree, we've got lots to talk about. The most important things are: 1. Packaging guidelines 2. Component upgrade guidelines 3. Namespace issues (addressed above) 4. Zope 2 vs Zope 3 (again, addressed above) Zope 3 seems no more going, and a new project named BlueBream[1][2] replacing it is being developed. There are also other blueprint-like and amazing projects[3][4] being worked on in the Zope world. But after all, the most productive and widely used is still Zope 2 which should gets higher priority. [1] http://en.wikipedia.org/wiki/BlueBream [2] https://launchpad.net/bluebream [2] http://codespeak.net/z3/five/ [3] http://repoze.org/ I think we should talk sooner rather than later. Anyone want to setup a meeting time? Just an FYI, it is my current plan (probably because I am completely ignorant as to how much pain this will cause) is to simply package the latest version of all Zenoss dependencies and then work through whatever bugs I find. I'm in a somewhat unique situation though in that I have the ability to commit to upstream. This may be a less than ideal plan for other applications. As I mentioned to Jonathan on IRC, I think the best plan is to try to get something working'ish as soon as possible and then try to shakedown the details from there. If we bog ourselves down in policy (an easy quagmire to get stuck in when in zopeland) we may get too discouraged to continue. Not to dismiss what will be the very needed policy, I just want to make sure no-one gets burned out. I agree with this. And so I packaged a working Zope2 before speaking anything publicly. One thing we may want to consider is a tenant policy. That is, the zope stack as a whole has tenants (Zenoss, Plone, etc). The tenants would be formally defined and any upgrade to any component in the platform would require signoff from all the tenants who depend on that component (or some derivation thereof). I suspect that the short-term trade-off of buildouts/bundling is not as valuable as the long-term value of testing a software product across multiple versions of its dependencies. Nathaniel -- devel mailing list devel@lists.fedoraproject.org
Re: To construct a Zope skyscraper on Fedora
On 06/20/2010 12:22 PM, Jonathan Steffan wrote: On Fri, 2010-06-18 at 21:08 +0800, Robin 'cheese' Lee wrote: The 'zope' package itself is most kept under the same conventions of the legacy 2.10.x 'zope' package. With zope 2.12 supporting py2.6, I think we might actually have a shot at making this work. However, immediately off the bat if we stick 2.12.x into zope what happens to grok? What packages are going to break? Too many things need zope 2.x so updating the zope namespace to zope 3 would break a lot of good software. What happens to plone? Do we just ditch Plone 3 and only support Plone 4?[2] This is really worrying. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update on packages violating the Static Library guidelines
util-vserver556099 - CLOSED FYI, util-vserver is re-enabled to ship static libraries again by the maintainer now after spot disabled it. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update on packages violating the Static Library guidelines
On Sun, 20 Jun 2010 19:56:23 +0800, Chen wrote: util-vserver556099 - CLOSED FYI, util-vserver is re-enabled to ship static libraries again by the maintainer now after spot disabled it. Not a problem as long as it packages them in adherence to the Packaging Guidelines (i.e. a separate -static package). The script I run has not suggested to reopen the util-vserver ticket, and in koji I see a util-vserver-static package. So, assumedly the packaging doesn't violate the guidelines. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with createrepo for modified DVD ISO
On Sat, Jun 19, 2010 at 17:07:02 -0400, Digimer li...@alteeve.com wrote: Perhaps they are, and I will look into them. However, my curiosity has been piqued, so I'd still like to know how it's supposed to be done. It seems to me like it should be a somewhat straight forward task, so I am curious about where my understanding has failed. I think pungi is used for official releases, but that Fedora Unity uses revisor for their respins. Either should be usable with mock to get reproduceable builds. For one offs on the same arch as the builder, you don't really need mock. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To construct a Zope skyscraper on Fedora
Am 18.06.2010 15:08, schrieb Robin 'cheese' Lee: And I hope for the co-maintainership of following packages, which are required by Zope2: (...) https://admin.fedoraproject.org/pkgdb/acls/name/python-zope-interface I'm happy to grant you these :-) fs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To construct a Zope skyscraper on Fedora
On 06/20/2010 07:00 AM, Robin 'cheese' Lee wrote: On 06/20/2010 12:22 PM, Jonathan Steffan wrote: On Fri, 2010-06-18 at 21:08 +0800, Robin 'cheese' Lee wrote: The 'zope' package itself is most kept under the same conventions of the legacy 2.10.x 'zope' package. With zope 2.12 supporting py2.6, I think we might actually have a shot at making this work. However, immediately off the bat if we stick 2.12.x into zope what happens to grok? What packages are going to break? Too many things need zope 2.x so updating the zope namespace to zope 3 would break a lot of good software. What happens to plone? Do we just ditch Plone 3 and only support Plone 4?[2] This is really worrying. For our own sanity we are going to have to make some tough choices. I don't think we can please everyone. I do however, think we can please most people. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To construct a Zope skyscraper on Fedora
On 06/20/2010 05:42 AM, Robin 'cheese' Lee wrote: On 06/20/2010 12:45 PM, Nathaniel McCallum wrote: On 06/20/2010 12:22 AM, Jonathan Steffan wrote: On Fri, 2010-06-18 at 21:08 +0800, Robin 'cheese' Lee wrote: The 'zope' package itself is most kept under the same conventions of the legacy 2.10.x 'zope' package. We have a unique opportunity to address many of the failings of the current zope namespace. We should get anyone interested (and willing to do the work) into a meeting soon. Every time I go back to building up zope again I run out of steam and end up just being frustrated. I foresee issues with splitting out every module in this stack but it just needs to be discussed. The current package layout is far from optimal and it's not the best idea to ship a default standalone instance with the package. Shipping standalone/zeo instance configs/etc. in subpackages is a far better idea. I've never been able to address this as there is just about no upgrade path (that I've been able to design) that would allow for a safe re-layout of the current package. We should consider the current zope namespace dead and start from scratch. It's far too complex of an application to be able to have everything in one namespace (speaking to zope2 vs zope3.) I've only briefly looked into all of the specs you've worked on and already can see we are going to run into issues with cross-product dependencies. I could be convinced that the zope namespace should be the latest 2.x and then address the need for zope 3 in the zope3 namespace. However, how do we distinguish a module built for zope 2 vs zope 3? This, again, could be solved but will need discussion. With zope 2.12 supporting py2.6, I think we might actually have a shot at making this work. However, immediately off the bat if we stick 2.12.x into zope what happens to grok? What packages are going to break? Too many things need zope 2.x so updating the zope namespace to zope 3 would break a lot of good software. What happens to plone? Do we just ditch Plone 3 and only support Plone 4?[2] We could also modularize everything and have things like zope, plone, grok and zenoss have dependencies based on their release recipes. There are a lot of common modules in these projects, but they all have their own specific version requirements. This would be a lot of work and could potentially cause us to package ourselves into a corner where we are having to do absolute requires or just end up with broken software when absolute requirements are not properly documented. I really look forward to others being involved with this. Count me in for the SIG.[2] - Jonathan Steffan [1] http://plone.org/documentation/faq/plone-versions [2] http://fedoraproject.org/wiki/SIGs/Zope I agree, we've got lots to talk about. The most important things are: 1. Packaging guidelines 2. Component upgrade guidelines 3. Namespace issues (addressed above) 4. Zope 2 vs Zope 3 (again, addressed above) Zope 3 seems no more going, and a new project named BlueBream[1][2] replacing it is being developed. There are also other blueprint-like and amazing projects[3][4] being worked on in the Zope world. But after all, the most productive and widely used is still Zope 2 which should gets higher priority. [1] http://en.wikipedia.org/wiki/BlueBream [2] https://launchpad.net/bluebream [2] http://codespeak.net/z3/five/ [3] http://repoze.org/ I suspect BlueBream solves our namespace issue; namely, the zope namespace will be zope2 only. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with createrepo for modified DVD ISO
On Sun, Jun 20, 2010 at 3:26 PM, Bruno Wolff III br...@wolff.to wrote: On Sat, Jun 19, 2010 at 17:07:02 -0400, Digimer li...@alteeve.com wrote: Perhaps they are, and I will look into them. However, my curiosity has been piqued, so I'd still like to know how it's supposed to be done. It seems to me like it should be a somewhat straight forward task, so I am curious about where my understanding has failed. I think pungi is used for official releases, but that Fedora Unity uses revisor for their respins. Either should be usable with mock to get reproduceable builds. For one offs on the same arch as the builder, you don't really need mock. Mock helps to keep things in their own chroot! By the way is there any way to build a 64 bit iso using mock/chroot running in a 32 bit version of Fedora? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DMitry
19.06.2010 20:34, Ian Baker ?: Hello to all. The subject package is currently orphaned and I'm thinking of taking it over. One problem I can foresee is that, as far as I can tell, there's no longer an upstream maintainer and at least one patch is required to fix compilation issues (warnings) and the code needs a general tidy-up. I could maintain the patches locally, or as a small pet project I could take over upstream maintenance which shouldn't require much work as the codebase is small. Any suggestions and advice would be appreciated and I'm new so please go easy! Thanks. Ian In the similar situation with dead upstream of trafshow I was told became upstream developer for it if I want see it in Fedora. https://bugzilla.redhat.com/show_bug.cgi?id=510651 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DMitry
Thanks for the information. I have tried to contact upstream with no success, their website hasn't been updated in a while, and the latest sources appear to be five years old. There hasn't been a package update in three months so I'll submit as new after I fix a few issues. Thanks. Ian - Reply message - From: Pavel Alexeev (aka Pahan-Hubbitus) fo...@hubbitus.com.ru Date: Sun, Jun 20, 2010 22:41 Subject: DMitry To: Development discussions related to Fedora devel@lists.fedoraproject.org 19.06.2010 20:34, Ian Baker ?: Hello to all. The subject package is currently orphaned and I'm thinking of taking it over. One problem I can foresee is that, as far as I can tell, there's no longer an upstream maintainer and at least one patch is required to fix compilation issues (warnings) and the code needs a general tidy-up. I could maintain the patches locally, or as a small pet project I could take over upstream maintenance which shouldn't require much work as the codebase is small. Any suggestions and advice would be appreciated and I'm new so please go easy! Thanks. Ian In the similar situation with dead upstream of trafshow I was told became upstream developer for it if I want see it in Fedora. https://bugzilla.redhat.com/show_bug.cgi?id=510651 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rfc: give koji diff capabilities
Probably thought of a million times, but was wondering whether it would be possible, and useful to give diff capabilities within the koji web interface. eg: x86_64 build ... Output build.log (tail) root.log (tail) state.log (tail) could become: Output build.log (tail) (diff) root.log (tail)(diff) state.log (tail) (diff) hovering over diff would cause a (json) load of options: - diff -u with other arch: i686, ppc, ppc64 - diff -u with other version: list other builds in this release (eg devel): 4.3-1, 4.3-4, - diff -u with other release: list other releases of same version that have been built: f12, f13 The diff could be generated to look like a viewvc side by side diff. Bonus points if the diff ignores things like: - tmp file names (/var/tmp/rpm-tmp.trZK8P) - log address: 0x2b9c82662f90 - builder: x86-05.phx2.fedoraproject.org Previously, I found the build logs rather boring; by saving each locally, then running meld on them, I immediately see what has changed between eg F12 and devel. Any comments (other than 'show me the money/code') ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: give koji diff capabilities
Am Mon, 21 Jun 2010 09:32:07 +1000 schrieb David Timms dti...@iinet.net.au: Probably thought of a million times, but was wondering whether it would be possible, and useful to give diff capabilities within the koji web interface. eg: x86_64 build ... Output build.log (tail) root.log (tail) state.log (tail) could become: Output build.log (tail) (diff) root.log (tail)(diff) state.log (tail) (diff) hovering over diff would cause a (json) load of options: - diff -u with other arch: i686, ppc, ppc64 - diff -u with other version: list other builds in this release (eg devel): 4.3-1, 4.3-4, - diff -u with other release: list other releases of same version that have been built: f12, f13 The diff could be generated to look like a viewvc side by side diff. Bonus points if the diff ignores things like: - tmp file names (/var/tmp/rpm-tmp.trZK8P) - log address: 0x2b9c82662f90 - builder: x86-05.phx2.fedoraproject.org Previously, I found the build logs rather boring; by saving each locally, then running meld on them, I immediately see what has changed between eg F12 and devel. Any comments (other than 'show me the money/code') ? I don't see a benefit of that... When a build fails, it kills all other current builds of other architectures, so you need to check that architecture, that fails first and the diff would not contain the error. Other that that. The diff would show, different which different packages are installed, e.g. gcc.i386 instead of gcc.x86_64, which doesn't interest me either... (And different requires etc.) What would be the benefit of such a feature? Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To construct a Zope skyscraper on Fedora
On 06/20/2010 11:08 PM, Felix Schwarz wrote: Am 18.06.2010 15:08, schrieb Robin 'cheese' Lee: And I hope for the co-maintainership of following packages, which are required by Zope2: (...) https://admin.fedoraproject.org/pkgdb/acls/name/python-zope-interface I'm happy to grant you these :-) fs Thanks! Robin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Minutes/Summary for the 2010-06-15 FESCo meeting
=== #fedora-meeting: FESCO (2010-06-15) === Meeting started by mjg59 at 19:35:11 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-06-15/fesco.2010-06-15-19.35.log.html Meeting summary --- * init process (mjg59, 19:36:01) * kylem and nirik unable to attend today (mjg59, 19:36:30) * #351 Create a policy for updates - status report on implementation (mjg59, 19:36:47) * ACTION: mclasen to look over critpath documentation (mjg59, 19:40:18) * #382 Implementing Stable Release Vision (mjg59, 19:41:12) * LINK: https://fedoraproject.org/wiki/Stable_release_updates_vision (mjg59, 19:49:10) * ACTION: fesco to continue to update https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas and aim to produce a comprehensive policy for the board (mjg59, 19:56:41) * #387 (mjg59, 19:57:18) * #387 compile list of supported CPUs and react to recent loss of support for Geode LX on F13 (mjg59, 19:57:24) * AGREED: dsd_ to post a patch to disable 686 assembler optimisations for glibc for f13 (mjg59, 20:39:30) * AGREED: more research on the details of building i586 separately to be carried out before deciding on f14 (mjg59, 20:40:18) * #394 F14Feature: MeeGo 1.0 https://fedoraproject.org/wiki/Features/MeeGo_1.0 (mjg59, 20:41:18) * AGREED: Meego 1.0 is an F14 feature (mjg59, 20:46:12) * #395 F14Feature: Sugar 0.90 https://fedoraproject.org/wiki/Features/Sugar_0.90 (mjg59, 20:46:27) * AGREED: Sugar 0.90 is an F14 feature (mjg59, 20:47:47) * #396 F14Feature: systemd - https://fedoraproject.org/wiki/Features/systemd (mjg59, 20:48:02) * AGREED: Systemd is a feature for F14 (mjg59, 21:00:57) * Open Floor (mjg59, 21:04:26) * FES ticket updates - https://fedorahosted.org/fedora-engineering-services/report/6 (mjg59, 21:05:07) * Open Floor (mjg59, 21:07:00) Meeting ended at 21:08:52 UTC. Action Items * mclasen to look over critpath documentation * fesco to continue to update https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas and aim to produce a comprehensive policy for the board -- 19:35:11 mjg59 #startmeeting FESCO (2010-06-15) 19:35:11 zodbot Meeting started Tue Jun 15 19:35:11 2010 UTC. The chair is mjg59. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:35:11 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:35:17 mjg59 #meetingname fesco 19:35:17 zodbot The meeting name has been set to 'fesco' 19:35:36 mjg59 #chair mjg59 mclasen notting SMParrish_mobile ajax pjones cwickert 19:35:36 zodbot Current chairs: SMParrish_mobile ajax cwickert mclasen mjg59 notting pjones 19:35:52 mjg59 We're missing kyle and nirik 19:36:01 mjg59 #topic init process 19:36:05 pjones zodbot uses LC_COLLATE=en_US . Ew. 19:36:13 mclasen kyle said he might not make it (still in UK) 19:36:20 mjg59 Yeah 19:36:22 mjg59 Ok 19:36:30 mjg59 #info kylem and nirik unable to attend today 19:36:37 mjg59 Ok, shall we start? 19:36:47 mjg59 #topic #351 Create a policy for updates - status report on implementation 19:36:48 pjones oh, wait, I'm backwards. 19:36:50 mjg59 .fesco 351 19:36:51 zodbot mjg59: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:37:02 mjg59 Anyone got anything to say on this this week? 19:37:15 notting no change on my end from this week. jlaska was doing some critpath documentation 19:37:51 mjg59 Anyone else? 19:37:57 mclasen did lukes bodhi update happen ? 19:38:06 mjg59 lmacken: Around? 19:38:10 * mclasen should know this, but doesn't... 19:38:17 jlaska notting: feel free to make suggestions, I'm missing important critpath information for maintainers -- http://fedoraproject.org/wiki/Critical_Path_Packages 19:39:06 * mclasen will look it over after the meeting too 19:39:32 * cwickert is here... 19:40:02 jlaska mclasen: thx 19:40:18 mjg59 #action mclasen to look over critpath documentation 19:40:33 mjg59 Anyone else? Or shall we move on? 19:40:57 mjg59 (going once.. twice...) 19:41:12 mjg59 #topic #382 Implementing Stable Release Vision 19:41:13 * cwickert thinks that the KDE list of critical path is way to short 19:41:34 mjg59 cwickert: We've had that conversation - unfortunately it seems difficult to come up with a better one that doesn't cover pretty much the entirity of KDE 19:42:18 mjg59 And an overly broad critpath would likely serve as a deterrent to maintainers at the moment. If KDE ends up looking bad compared to the rest of the distribution, then with luck that's something they'll pay attention to 19:42:32 cwickert mjg59: well, the Xfce critpath covers half of Xfce, the LXDE one too 19:42:44 pjones cwickert: sure, but those are both smaller than kde, right? 19:43:07 cwickert yes, but the percentage is way higher 19:43:12 cwickert anyway, lets move on 19:43:45 mjg59 Ok,
Re: rpms/xml-security-c/EL-6 xml-security-c.spec,1.5,1.6
umm why did you make that change?
On Sunday, June 20, 2010 03:06:32 pm stevetraylen wrote:
Author: stevetraylen
Update of /cvs/pkgs/rpms/xml-security-c/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv2536
Modified Files:
xml-security-c.spec
Log Message:
EPEL5 one better than F12 for EPEL6.
Index: xml-security-c.spec
===
RCS file: /cvs/pkgs/rpms/xml-security-c/EL-6/xml-security-c.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- xml-security-c.spec 21 Aug 2009 16:32:47 - 1.5
+++ xml-security-c.spec 20 Jun 2010 20:06:31 - 1.6
@@ -1,6 +1,6 @@
Name: xml-security-c
Version:1.5.1
-Release:2%{?dist}
+Release:1%{?dist}
Summary:C++ Implementation of W3C security standards for XML
Group: System Environment/Libraries
@@ -81,9 +81,6 @@ rm -rf $RPM_BUILD_ROOT
# %doc CHANGELOG.txt
%changelog
-* Fri Aug 21 2009 Tomas Mraz tm...@redhat.com - 1.5.1-2
-- rebuilt with new openssl
-
* Tue Jul 28 2009 Antti Andreimann antti.andreim...@mail.ee 1.5.1-1
- New upstream relase (#513078)
- Fixes CVE-2009-0217 (#511915)
signature.asc
Description: This is a digitally signed message part.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
headsup: ghc-6.12.3
I built ghc-6.12.3 for F14. This will require rebuilding all ghc library packages, which I and the Haskell SIG will be doing over the coming days - the meantime please bear with us with the broken dependencies... Thanks, Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-06-01 x86_64
On Thu, Jun 3, 2010 at 10:42 AM, Matt Domsch wrote: Fedora Fails To Build From Source Results for x86_64 using rawhide from 2010-06-01 [cut] Question 1: Suppose package A fails to build from source due to a bug in package B that is listed in package A's BuildRequires. Now that package B gets fixed, and it is possible to build package A from source without any modification. Do we need to bump A's release and do the rebuild in this case? Question 2: What is the likelihood of a mass rebuild in this cycle? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To construct a Zope skyscraper on Fedora
2010/6/21 Nathaniel McCallum nathan...@natemccallum.com: On 06/20/2010 05:42 AM, Robin 'cheese' Lee wrote: I suspect BlueBream solves our namespace issue; namely, the zope namespace will be zope2 only. Nathaniel -- Agree, all zope components won't have any namespace conflict issue now as I known. Packaging them as normal python modules is Okay, but since Zope2 contains more than 100 modules, packaging/maintaining so many modules is not easy work. Chen Lei Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-06-01 x86_64
On Sun, Jun 20, 2010 at 10:24:27PM -0400, Orcan Ogetbil wrote: On Thu, Jun 3, 2010 at 10:42 AM, Matt Domsch wrote: Fedora Fails To Build From Source Results for x86_64 using rawhide from 2010-06-01 [cut] Question 1: Suppose package A fails to build from source due to a bug in package B that is listed in package A's BuildRequires. Now that package B gets fixed, and it is possible to build package A from source without any modification. Do we need to bump A's release and do the rebuild in this case? No. List in bug A that it Depends on the bug number for B. Close the bug against A once package B is fixed and its own bug closed. Question 2: What is the likelihood of a mass rebuild in this cycle? I've heard rumors that it's likely, but I don't know for certain what the trigger would be this time. Likely a glibc or gcc change. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To construct a Zope skyscraper on Fedora
2010/6/20 Nathaniel McCallum nathan...@natemccallum.com: We have a unique opportunity to address many of the failings of the current zope namespace. We should get anyone interested (and willing to do the work) into a meeting I think we should talk sooner rather than later. Anyone want to setup a meeting time? Just an FYI, it is my current plan (probably because I am completely ignorant as to how much pain this will cause) is to simply package the latest version of all Zenoss dependencies and then work through whatever bugs I find. I'm in a somewhat unique situation though in that I have the ability to commit to upstream. This may be a less than ideal plan for other applications. As I mentioned to Jonathan on IRC, I think the best plan is to try to get something working'ish as soon as possible and then try to shakedown the details from there. If we bog ourselves down in policy (an easy quagmire to get stuck in when in zopeland) we may get too discouraged to continue. Not to dismiss what will be the very needed policy, I just want to make sure no-one gets burned out. One thing we may want to consider is a tenant policy. That is, the zope stack as a whole has tenants (Zenoss, Plone, etc). The tenants would be formally defined and any upgrade to any component in the platform would require signoff from all the tenants who depend on that component (or some derivation thereof). I suspect that the short-term trade-off of buildouts/bundling is not as valuable as the long-term value of testing a software product across multiple versions of its dependencies. Nathaniel I still suggest to do enough investigation first for two reason: 1.Packaging the whole zope stack is a heavy workload( we need some tools to simply our works) 2.Currently. no linux distributions include zope yet. I think we need to set up a third party repo first like texlive 2010 before finally determined to submit those components for package review. Chen Lei ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
