HEADS UP : mysql++ version 3.1.0 - ABI broken without soname bump
Hi, I've just build latest version of mysql++ in rawhide. This version breaks ABI. Report: http://blog.famillecollet.com/public/reports/mysql__-3.0.9-3.1.0.html Reported upstream: http://lists.mysql.com/plusplus/8973 Of course, no update to fedora /EPEL stable repo planned. At least "sems" need a rebuild. Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gethostbyname() and resolv.conf updates
2010/6/17 Bernie Innocenti : > 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 : > 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: To construct a Zope skyscraper on Fedora
On 06/20/2010 12:31 AM, Chen Lei wrote: > 2010/6/20 Rakesh Pandit: > >> Thanks for clarification. I will see whether I can help with some >> dependencies and zope3 part (review as well). >> >> -- >> -- >> > The original zope/plone in Fedora/EPEL bundles dozens of third party > python modules, nearly all of those modules need review if we want to > revive long retired zope and plone in the cvs. It will be much easier > if we have an atuomatic spec generation tool like cpan2spec, it's > entirely possible to write a such tool for python modules that using > setuptools in setup.py. > > Chen Lei > The spec file for each per-module package I just created is generated through a little and nasty script which converts spec files generated by setuptools to ones complying with Fedora standards. (The script is too nasty to open its source.) A better solution is to hack setuptools, and/or distutils, itself to generate standard-complying spec files directly. But this may take some time. -- 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:02 AM, Rakesh Pandit wrote: > On 19 June 2010 19:31, Robin 'cheese' Lee wrote: > >> On 06/19/2010 09:21 PM, Rakesh Pandit wrote: >> > [..] > >> In rpmfusion, Zope is an out-dated version, 2.10.x, which works with >> Python 2.4 only. >> >> My package here is the latest version of Zope, 2.12.7, which works with >> Python 2.6, and so no compat-python needed. >> >> x86_64 builds may come in next week. >> >> > Thanks for nice work. > > >> And it should be easy to rebuild binary packages from the srpms. All the >> packages can be compiled with just python2-devel, python-setuptools and >> python-sphinx installed. >> > [..] > > Thanks for clarification. I will see whether I can help with some > dependencies and zope3 part (review as well). > > You're welcome. So we may start a Zope SIG. https://fedoraproject.org/wiki/SIGs/Zope -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ownership of DMitry
Thanks for taking the time to clarify the procedure. It's nice to find a friendly list! Thanks. Ian - Reply message - From: "Rakesh Pandit" Date: Sun, Jun 20, 2010 05:42 Subject: Ownership of DMitry To: "ianrichardba...@gmail.com" Cc: "Development discussions related to Fedora" On 20 June 2010 10:10, Rakesh Pandit wrote: [..] > > In case this package has not been update since last 3 months you can > resubmit it for review. But if it has been updated recently (in last 3 > months) you will have to get sponsored first and then later claim it > (or ask for co-maintainership in case it is already taken by someone > during that period). > In both cases pre-condition is you will need to get sponsorship. -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- 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 : > 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 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 :
> > 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 softwar
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
Update on packages violating the Static Library guidelines
* 19 packages fixed since May 21st. Tom Callaway has done almost all of the work. * 2 packages left to be fixed. * "gcc" has returned due to another static library in its packages, and no news on "binutils-devel". It still enforces static linkage by using ld scripts. The following source rpms don't "BuildRequires: binutils-static" but binutils-devel: alleyoop-0:0.9.7-1.fc13.src avarice-0:2.10-1.fc13.src CodeAnalyst-gui-0:2.8.54-21.fc13.src kernel-0:2.6.34-43.fc14.src ksplice-0:0.9.9-1.fc12.src latrace-0:0.5.7-1.fc12.src libdwarf-0:0.20090324-5.fc12.src lush-0:1.2.1-6.fc12.src mutrace-0:0.2-1.fc13.src sblim-wbemcli-0:1.6.0-5.fc12.src stapitrace-0:2.0.0-0.20090304cvs_alpha.fc12.1.src sysprof-0:1.1.6-1.fc14.src * Bugzilla status for packages violating the Static Library guidelines: http://mschwendt.fedorapeople.org/staticbugstat.html acl 556036 -> CLOSED atlas 556037 -> CLOSED attr556038 -> CLOSED audit 556039 -> CLOSED binutils556040 brltty 556041 -> CLOSED Canna 556034 -> CLOSED cdparanoia 547682 -> CLOSED comedilib 556043 -> CLOSED dnssec-tools556044 -> CLOSED e2fsprogs 545144 -> CLOSED expat 556046 -> CLOSED fftw2 556047 -> CLOSED file556048 -> CLOSED gcc 556049 gdbm556050 -> CLOSED ghostscript 556051 -> CLOSED gnutls 556052 -> CLOSED gpsim 556053 -> CLOSED gtk+extra 556054 -> CLOSED hpic556055 -> CLOSED isdn4k-utils556056 -> CLOSED js 556057 -> CLOSED ldns556058 -> CLOSED libaio 556059 -> CLOSED libannodex 556060 -> CLOSED libbtctl556061 -> CLOSED libcaca 556062 -> CLOSED libcddb 556063 -> CLOSED libcdio 556064 -> CLOSED libcmml 556065 -> CLOSED libdnet 556066 -> CLOSED libevent556067 -> CLOSED libftdi 556068 -> CLOSED libnl 556069 -> CLOSED liboggz 556070 -> CLOSED libotr 556071 -> CLOSED librx 556072 -> CLOSED libsemanage 556073 -> CLOSED libsndfile 556074 -> CLOSED libstatgrab 556075 -> CLOSED libtranslate556076 -> CLOSED libtwin 556077 -> CLOSED libuninameslist 556078 -> CLOSED libxslt 556079 -> CLOSED link-grammar556080 -> CLOSED linux-atm 556081 -> CLOSED linuxwacom 556082 -> CLOSED lockdev 556083 -> CLOSED meanwhile 556084 -> CLOSED mpich2 545149 -> CLOSED munipack556086 -> CLOSED nfs-utils-lib 556087 -> CLOSED numactl 556088 -> CLOSED opencdk 556089 -> CLOSED openldap556090 -> CLOSED proj556091 -> CLOSED python 556092 -> CLOSED QuantLib556035 -> CLOSED rubberband 556093 -> CLOSED shapelib556094 -> CLOSED syck556095 -> CLOSED sysfsutils 556096 -> CLOSED texlive 556097 -> CLOSED torque 556098 -> CLOSED util-vserver556099 -> CLOSED xbsql 556100 -> CLOSED xen 556101 -> CLOSED xfsprogs556102 -> CLOSED xmlsec1 556103 -> CLOSED xqilla 562566 -> CLOSED -- devel maili
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 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 wrote: > On Sat, Jun 19, 2010 at 17:07:02 -0400, > Digimer 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)" Date: Sun, Jun 20, 2010 22:41 Subject: DMitry To: "Development discussions related to Fedora" 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 : > 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 #startmeeting FESCO (2010-06-15) 19:35:11 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:35:17 #meetingname fesco 19:35:17 The meeting name has been set to 'fesco' 19:35:36 #chair mjg59 mclasen notting SMParrish_mobile ajax pjones cwickert 19:35:36 Current chairs: SMParrish_mobile ajax cwickert mclasen mjg59 notting pjones 19:35:52 We're missing kyle and nirik 19:36:01 #topic init process 19:36:05 zodbot uses LC_COLLATE=en_US . Ew. 19:36:13 kyle said he might not make it (still in UK) 19:36:20 Yeah 19:36:22 Ok 19:36:30 #info kylem and nirik unable to attend today 19:36:37 Ok, shall we start? 19:36:47 #topic #351 Create a policy for updates - status report on implementation 19:36:48 oh, wait, I'm backwards. 19:36:50 .fesco 351 19:36:51 mjg59: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:37:02 Anyone got anything to say on this this week? 19:37:15 no change on my end from this week. jlaska was doing some critpath documentation 19:37:51 Anyone else? 19:37:57 did lukes bodhi update happen ? 19:38:06 lmacken: Around? 19:38:10 * mclasen should know this, but doesn't... 19:38:17 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 mclasen: thx 19:40:18 #action mclasen to look over critpath documentation 19:40:33 Anyone else? Or shall we move on? 19:40:57 (going once.. twice...) 19:41:12 #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 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 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 mjg59: well, the Xfce critpath covers half of Xfce, the LXDE one too 19:42:44 cwickert: sure, but those are both smaller than kde, right? 19:43:07 yes, but the percentage is way higher 19:43:12 anyway, lets move on 19:43:45 Ok, so we have the wiki page at https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas 19:43:56 We haven't really added much to that 19:44:29 I'm not convinced that IRC is the best way
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 - 1.5.1-2
> -- rebuilt with new openssl
> -
> * Tue Jul 28 2009 Antti Andreimann 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 : > 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
