Re: rpms/xml-security-c/EL-6 xml-security-c.spec,1.5,1.6
On Mon, Jun 21, 2010 at 3:34 AM, Dennis Gilmore wrote:
> 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
It's the same upstream software in devel as in EL-5.
However devel has some release bumps for .so updates to underlying
xerces 2 -> 3 that happened in Fedora but not RHEL.
The "devel" or F12 would have worked but EL-5 has a more consistent relevant
changelog with out a release bump which is irrelevant/misleading in this case.
Steve.
>>
>> 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)
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
--
Steve Traylen
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Package Review Stats for last week ending 20th June
Top three FAS account holders who have completed reviewing "Package review" components on bugzilla for last week ending 20th June were Ian Weller, Chen Lei and Mamoru Tasaka. Ian Weller : 4 https://bugzilla.redhat.com/show_bug.cgi?id=600270 libnmserver https://bugzilla.redhat.com/show_bug.cgi?id=603514 libmodman https://bugzilla.redhat.com/show_bug.cgi?id=603518 pyip https://bugzilla.redhat.com/show_bug.cgi?id=603521 pynetsnmp Chen Lei : 4 https://bugzilla.redhat.com/show_bug.cgi?id=590387 lcms2 https://bugzilla.redhat.com/show_bug.cgi?id=600243 libjpeg-turbo https://bugzilla.redhat.com/show_bug.cgi?id=603311 R-caTools https://bugzilla.redhat.com/show_bug.cgi?id=605784 googlecl Mamoru Tasaka : 3 https://bugzilla.redhat.com/show_bug.cgi?id=600638 seed https://bugzilla.redhat.com/show_bug.cgi?id=603269 rubygem-plist https://bugzilla.redhat.com/show_bug.cgi?id=601633 rubygem-sup Matthias Clasen : 2 https://bugzilla.redhat.com/show_bug.cgi?id=603846 libpeas https://bugzilla.redhat.com/show_bug.cgi?id=605329 gnome-desktop3 Stanislav Ochotnicky : 2 https://bugzilla.redhat.com/show_bug.cgi?id=594806 jbcrypt https://bugzilla.redhat.com/show_bug.cgi?id=603295 guava Alexander Kurtakov : 1 https://bugzilla.redhat.com/show_bug.cgi?id=602960 maven-eclipse-plugin Jonathan Steffan : 1 https://bugzilla.redhat.com/show_bug.cgi?id=577152 apiextractor Kalev Lember : 1 https://bugzilla.redhat.com/show_bug.cgi?id=521707 python-zc.buildout Leigh Scott : 1 https://bugzilla.redhat.com/show_bug.cgi?id=593841 wicd Peter Lemenkov : 1 https://bugzilla.redhat.com/show_bug.cgi?id=508351 josm Lubomir Rintel : 1 https://bugzilla.redhat.com/show_bug.cgi?id=561466 jnr-constants Martin Gieseking : 1 https://bugzilla.redhat.com/show_bug.cgi?id=599097 libgexiv2 Marcela Mašláňová : 1 https://bugzilla.redhat.com/show_bug.cgi?id=602767 perl-MooseX-MarkAsMethods Marcela Mašláňová : 1 https://bugzilla.redhat.com/show_bug.cgi?id=578480 spectrum Petr Pisar : 1 https://bugzilla.redhat.com/show_bug.cgi?id=592672 hct Randall Berry : 1 https://bugzilla.redhat.com/show_bug.cgi?id=605808 gtick Rex Dieter : 1 https://bugzilla.redhat.com/show_bug.cgi?id=591011 kfilefactory Robin Lee : 1 https://bugzilla.redhat.com/show_bug.cgi?id=563376 F11 Sandro Mathys : 1 https://bugzilla.redhat.com/show_bug.cgi?id=600682 R-GenomicFeatures Steve Traylen : 1 https://bugzilla.redhat.com/show_bug.cgi?id=602791 xrootd Thomas Spura : 1 https://bugzilla.redhat.com/show_bug.cgi?id=605853 python-snpp Yanko Kaneti : 1 https://bugzilla.redhat.com/show_bug.cgi?id=602703 perl-HTTP-Parser Total reviews modified: 32 Merge Reviews: 0 Review Requests: 32 This report by generated by bzReviewReport.py. The source is available at: https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py Please submit patches or bug reports at: https://fedorahosted.org/triage/ -- 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: Package Review Stats for last week ending 20th June
On 21 June 2010 13:04, Rakesh Pandit wrote: [..] > Robin Lee : 1 > > https://bugzilla.redhat.com/show_bug.cgi?id=563376 F11 > > [..] Minor correction: here package name is pcmanx-gtk2. I will fix script to fix this later. -- 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: To construct a Zope skyscraper on Fedora
Write access to the yum[1] and git[2] repos has been granted to Zope SIG members. [1] fedorapeople.org:/home/fedora/cheeselee/public_html/yum/zope/ ( http://cheeselee.fedorapeople.org/yum/zope/ ) [2] git://fedorapeople.org/home/fedora/cheeselee/public_git/zope-rpm.git ( I have cloned out this new git and removed unrelated packages. ) 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. >> > 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 > > > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package Review Stats for last week ending 20th June
On 06/21/2010 09:34 AM, Rakesh Pandit wrote: > Marcela Mašláňová : 1 > > https://bugzilla.redhat.com/show_bug.cgi?id=602767 > perl-MooseX-MarkAsMethods > > > Marcela Mašláňová : 1 > > https://bugzilla.redhat.com/show_bug.cgi?id=578480 spectrum > Here is another bug. I've done only the first review in this list. Regards, Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-06-01 x86_64
Am Donnerstag, den 03.06.2010, 09:42 -0500 schrieb Matt Domsch: > julian: diveintopython,sap I have already fixed sap, but I'm not able to do anything about diveintopython. The build process simply is too old to work with newer versions of the required libraries, and already worked only with patches before. I have already orphaned diveintopython about two weeks ago, any help/takeover would be greatly appreciated. Regards, Julian signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: give koji diff capabilities
On 21/06/10 09:38, Thomas Spura wrote: >> 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. Hi Thomas, good point. But reality might be different: http://koji.fedoraproject.org/koji/taskinfo?taskID=2260035 -> build.log The x86_64 build failed, and is says that the i686 was cancelled. However, the build.log shows that the package and -debuginfo .rpms were created, ie the build actually succeeded. This seems like a bug in the koji web interface. Having the non-failing build be cancelled may not be optimal; I have definitely found it helpful to compare the build logs of different archs, when one succeeds (or at least gets further). It helps to see the diff in log results to understand what is different about the process between each build. > 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.) That would be more bonus points for the diff to optionally ignore ! A decent visual diff will highlight lines that are different, but also show the actual characters that differ (I don't know if viewvc can do that). > What would be the benefit of such a feature? Resolving build problems more quickly: - what changed in the build process from arch to arch ... - what changed in the bp from fedora release to fedora release ... - what changed in the bp compare to an earlier version-release ... However, for the less experienced package maintainers: tell me shortest time for you to determine the cause for the failure in: http://koji.fedoraproject.org/koji/taskinfo?taskID=2260034 -> build.log Now, would these screen shots from a visual diff program have reduced the time for working out both the error, and the cause ? http://members.iinet.net.au/~timmsy/rakarrack/meld.rakarrack.diff1.png http://members.iinet.net.au/~timmsy/rakarrack/meld.rakarrack.diff2.png -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
perl 5.12.1 is in rawhide
Hello, as you might noticed, perl was pushed into rawhide. Test buildroot will be deleted, so since now all changes go to rawhide. It looks like nothing was broken, at least no new missing requirements or build requirements. Feel free to test and file bugs ;-) Happy hacking, Marcela -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: gethostbyname() and resolv.conf updates
On 06/20/2010 04:41 AM, Nicolas Chauvet wrote: > 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? You definitely still want to replace gethostbyname with getaddrinfo, because gethostbyname can't handle IPv6 addresses. But that's not relevant to this particular problem (noticing resolv.conf updates) because both functions use the same internal glibc methods, they just package the results differently. -- Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 592101] pls upgrade
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=592101 --- Comment #11 from Fedora Update System 2010-06-21 09:14:08 EDT --- mldonkey-3.0.2-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 592101] pls upgrade
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=592101 Fedora Update System changed: What|Removed |Added Fixed In Version|mldonkey-3.0.2-1.fc11 |mldonkey-3.0.2-1.fc13 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: gethostbyname() and resolv.conf updates
On Sat, Jun 19, 2010 at 10:54 PM, Dan Williams wrote:
>
> I'm just gonna make NM use a local caching nameserver (which means
> dnsmasq) by default at some point soon. People that don't want it can
> turn it off.
When thinking about this, there's a rather obvious patch here that
really should have been made 5+ years ago...make it an option! And
this actually makes some sense, e.g. if NetworkManager writes out a
static configuration, then there's no need to stat() on it since we
can assume it won't change. (This does still screw over server admins
who hand-edit it, but...)
glibc and NetworkManager patches attached.
(I'm totally in favor of the dnsmasq approach too since the OS
desperately needs DNS caching too, but this is a simple patch that
doesn't conceptually conflict).
From 464035fa03acd915c8cf460452d0dc6c031180ca Mon Sep 17 00:00:00 2001
From: Colin Walters
Date: Fri, 18 Jun 2010 16:19:12 -0400
Subject: [PATCH] [resolv.conf] Add a new "dynamic" option which tells us to re-stat the file
Various operating system vendors have been shipping variants of a
patch which stat()s resolv.conf on every gethostbyname() call. The
reason for this is simply that on mobile devices, nameservers can
change, and having to restart all applications and processes for this
is simply broken. (NSCD exists, but is considered unreliable)
The intent of this patch is that in e.g. Fedora, NetworkManager's
generated resolv.conf file will include this if it gets any of its
data from DHCP. Otherwise, it can omit the option, and processes
won't have to pay the cost of the stat() (assuming it was even a real
concern to begin with).
---
resolv/res_init.c |2 ++
resolv/res_libc.c | 26 ++
resolv/resolv.h |1 +
3 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/resolv/res_init.c b/resolv/res_init.c
index 40dbe7d..7b02e49 100644
--- a/resolv/res_init.c
+++ b/resolv/res_init.c
@@ -535,6 +535,8 @@ res_setoptions(res_state statp, const char *options, const char *source) {
statp->options &= ~RES_NOIP6DOTINT;
} else if (!strncmp(cp, "rotate", sizeof("rotate") - 1)) {
statp->options |= RES_ROTATE;
+ } else if (!strncmp(cp, "dynamic", sizeof("dynamic") - 1)) {
+ statp->options |= RES_DYNAMIC;
} else if (!strncmp(cp, "no-check-names",
sizeof("no-check-names") - 1)) {
statp->options |= RES_NOCHECKNAME;
diff --git a/resolv/res_libc.c b/resolv/res_libc.c
index 810fbc8..5dc4e3a 100644
--- a/resolv/res_libc.c
+++ b/resolv/res_libc.c
@@ -89,12 +89,38 @@ res_init(void) {
return (__res_vinit(&_res, 1));
}
+/* If the DYNAMIC option is set, we stat the file, and see if its
+ * mtime has changed. If so, request an initialization.
+ */
+static void
+_res_dynamic_check (void)
+{
+ static time_t last_mtime, last_check;
+ time_t now;
+ struct stat statbuf;
+
+ time (&now);
+ if (now != last_check) {
+ last_check = now;
+ if (stat (_PATH_RESCONF, &statbuf) == 0 && last_mtime != statbuf.st_mtime) {
+ last_mtime = statbuf.st_mtime;
+ atomicinclock (lock);
+ atomicinc (__res_initstamp);
+ atomicincunlock (lock);
+ }
+ }
+}
+
/* Initialize resp if RES_INIT is not yet set or if res_init in some other
thread requested re-initializing. */
int
__res_maybe_init (res_state resp, int preinit)
{
if (resp->options & RES_INIT) {
+ if (resp->options & RES_DYNAMIC) {
+ _res_dynamic_check ();
+ }
+
if (__res_initstamp != resp->_u._ext.initstamp) {
if (resp->nscount > 0)
__res_iclose (resp, true);
diff --git a/resolv/resolv.h b/resolv/resolv.h
index e49c29d..8f4a202 100644
--- a/resolv/resolv.h
+++ b/resolv/resolv.h
@@ -219,6 +219,7 @@ struct res_sym {
#define RES_SNGLKUPREOP 0x0040 /* -"-, but open new socket for each
request */
#define RES_USE_DNSSEC 0x0080 /* use DNSSEC using OK bit in OPT */
+#define RES_DYNAMIC 0x0100 /* check for changes in resolv.conf */
#define RES_DEFAULT (RES_RECURSE|RES_DEFNAMES|RES_DNSRCH|RES_NOIP6DOTINT)
--
1.7.0.1
From 09551d7225637d3b809ff78ab76739cd7b9d4f63 Mon Sep 17 00:00:00 2001
From: Colin Walters
Date: Mon, 21 Jun 2010 10:33:14 -0400
Subject: [PATCH] Add "options dynamic" to generated resolv.conf
---
src/named-manager/nm-named-manager.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/named-manager/nm-named-manager.c b/src/named-manager/nm-named-manager.c
index fc3b6e2..f9bb6fa 100644
--- a/src/named-manager/nm-named-manager.c
+++ b/src/named-manager/nm-named-manager.c
@@ -304,6 +304,10 @@ write_resolv_conf (FILE *f, const char *domain,
char **nameservers,
GError **error)
{
+ /* This tells glibc that we may rewrite the file at any time,
+ * so it should check with stat()
+ */
+ const char *options_str = "options dynamic\n";
char *domain_str = NULL;
char *searches_str = NULL;
char *nameservers_str = NULL;
@@ -354,8 +358,9 @@ write_resolv_conf (FILE *f, const char *domain,
nameservers_str =
Fedora, DNSSEC and GOST (ECC like) algorithms with openssl
On Mon, 21 Jun 2010, Tomas Mraz wrote: > Looking at it more closely actually for the DNSSEC GOST R 34.10-2001 it > will not be possible to include it as it is elliptic curve based and all > the ECC code is removed from our Openssl source and build. I do not know > much about the ECC except it is a patent minefield and I will not go > into details of the used algorithms and existing patents to examine > whether this particular implementation is affected or not. This would > have to be explicitly approved by Fedora Legal. There are no IPR disclosures on any of the GOST algorithms filed with the IETF, which is a strong signal that none of the patent holders of ECC related patents has any objection. But I understand this could be a matter for Fedora Legal. I could try and liason between Fedora Legal and IETF IPR WG in gathering information that might convince Fedora Legal all the due diligence is in place. > So I suppose somehow making the rest of the GOST algorithms compile > (which would require patching the source) would not help much in regards > to the DNSSEC support. This will become a serious issue once .ru starts deploying GOST based signatures in their TLD zone. I would be great if we could change the spec file to have a proper flag to enable/disable GOST/ECC so that people can easilly rebuild with GOST support if they need to (and it is legal for them). Would that be legally possible? Some references showing there should not be any known IPR issues filed with the IETF that would prevent implementing RFC standards using ECC: https://datatracker.ietf.org/iesg/ann/3304/ http://www.rfc-editor.org/info/rfc4357 http://www.rfc-editor.org/info/rfc4490 http://www.rfc-editor.org/info/rfc4491 http://www.rfc-editor.org/info/rfc5830 http://www.rfc-editor.org/info/rfc5831 All GOST / ECC IPR disclosures to IETF as per search on: https://datatracker.ietf.org/ipr/search/?option=ipr_title_search&ipr_title_search=ECC https://datatracker.ietf.org/ipr/search/?option=ipr_title_search&ipr_title_search=GOST https://datatracker.ietf.org/ipr/695/ https://datatracker.ietf.org/ipr/151/ https://datatracker.ietf.org/ipr/1094/ The latter IPR notes show that Certicom has given everyone the right to use ECC for IETF specifications for DNSSEC, IPsec, IKE, IKEv2 and TLS. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora, DNSSEC and GOST (ECC like) algorithms with openssl
On Mon, 2010-06-21 at 11:07 -0400, Paul Wouters wrote: > On Mon, 21 Jun 2010, Tomas Mraz wrote: > > > Looking at it more closely actually for the DNSSEC GOST R 34.10-2001 it > > will not be possible to include it as it is elliptic curve based and all > > the ECC code is removed from our Openssl source and build. I do not know > > much about the ECC except it is a patent minefield and I will not go > > into details of the used algorithms and existing patents to examine > > whether this particular implementation is affected or not. This would > > have to be explicitly approved by Fedora Legal. > > There are no IPR disclosures on any of the GOST algorithms filed with > the IETF, which is a strong signal that none of the patent holders of > ECC related patents has any objection. But I understand this could be > a matter for Fedora Legal. I could try and liason between Fedora Legal > and IETF IPR WG in gathering information that might convince Fedora Legal > all the due diligence is in place. > > > So I suppose somehow making the rest of the GOST algorithms compile > > (which would require patching the source) would not help much in regards > > to the DNSSEC support. > > This will become a serious issue once .ru starts deploying GOST based > signatures in their TLD zone. > > I would be great if we could change the spec file to have a proper flag > to enable/disable GOST/ECC so that people can easilly rebuild with GOST > support if they need to (and it is legal for them). Would that be > legally possible? This is not possible as the ECC algorithm sources are removed from the source tarball prior to adding it to the Fedora CVS. > Some references showing there should not be any known IPR issues filed > with the IETF that would prevent implementing RFC standards using ECC: > > https://datatracker.ietf.org/iesg/ann/3304/ > http://www.rfc-editor.org/info/rfc4357 > http://www.rfc-editor.org/info/rfc4490 > http://www.rfc-editor.org/info/rfc4491 > http://www.rfc-editor.org/info/rfc5830 > http://www.rfc-editor.org/info/rfc5831 > > All GOST / ECC IPR disclosures to IETF as per search on: > https://datatracker.ietf.org/ipr/search/?option=ipr_title_search&ipr_title_search=ECC > https://datatracker.ietf.org/ipr/search/?option=ipr_title_search&ipr_title_search=GOST > > https://datatracker.ietf.org/ipr/695/ > https://datatracker.ietf.org/ipr/151/ > https://datatracker.ietf.org/ipr/1094/ > > The latter IPR notes show that Certicom has given everyone the right to use > ECC for > IETF specifications for DNSSEC, IPsec, IKE, IKEv2 and TLS. This however does not give any guarantee of no patent litigation when it is included as a general purpose algorithm in Fedora I am afraid. But of course IANAL. Perhaps it would be possible to modify the source of ECC algorithms to include just the smallest possible sources needed just for the GOST R 34.10-2001 and make the calls to the general purpose algorithms needed for the implementation of the GOST signature algorithm not exported from the library. However this would be a fair amount of work and the resulting patch will not by trivial in any means. And moreover the patch would not guarantee that we would be shielded from the legal point of view. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gethostbyname() and resolv.conf updates
On 21/06/10 15:40, Colin Walters wrote: > On Sat, Jun 19, 2010 at 10:54 PM, Dan Williams wrote: >> >> I'm just gonna make NM use a local caching nameserver (which means >> dnsmasq) by default at some point soon. People that don't want it can >> turn it off. > > When thinking about this, there's a rather obvious patch here that > really should have been made 5+ years ago...make it an option! And > this actually makes some sense, e.g. if NetworkManager writes out a > static configuration, then there's no need to stat() on it since we > can assume it won't change. (This does still screw over server admins > who hand-edit it, but...) > > glibc and NetworkManager patches attached. > > (I'm totally in favor of the dnsmasq approach too since the OS > desperately needs DNS caching too, but this is a simple patch that > doesn't conceptually conflict). Sorry I haven't been following this really, but I loath config options that aren't absolutely required, and this seems like a place where we could just stat() (cache) always. What's the problem with doing that? Are we worried about the performance of doing time() for every request? I would never expect anything resembling efficiency from DHCP, never mind the overhead of a time() call. Has debian ever had complaints given that they patch glibc by default? cheers, Pádraig. p.s. not having looked at the code, the atomic ops seems unusual in the presence of the static last_... variables. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 14 Schedule
Start End Name Wed 26-May Tue 03-Aug Packaging and Development (precedes Alpha) Tue 22-Jun Tue 22-Jun Request Feature Status Updates + Remind Submit Deadline Tue 29-Jun Tue 29-Jun Feature Submission Deadline Two Weeks away Tue 06-Jul Tue 06-Jul Feature Submission Deadline One Week away -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Schedule
On Mon, 21 Jun 2010, John Poelstra wrote: > Tue 06-Jul Tue 06-Jul Feature Submission Deadline One Week away It would be good if we could get the issue of GOST support in openssl figured out in time for that deadline. Though I am not sure if that is possible. See my other msg to fedora-legal/fedora-devel an hour ago. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gethostbyname() and resolv.conf updates
2010/6/21 Pádraig Brady : > > Sorry I haven't been following this really, but I loath > config options that aren't absolutely required, and this > seems like a place where we could just stat() (cache) always. > What's the problem with doing that? I too would be really interested in any real-world application for which the cost of the stat() was any kind of major performance hit. > p.s. not having looked at the code, > the atomic ops seems unusual in the > presence of the static last_... variables. We are implicitly relying on aligned word size assignment atomicity here it looks like, yes. I haven't looked if there are other places in glibc doing this or if there's some infrastructure for it. To be clear this patch is derived from the OpenSUSE one; I didn't change the semantics there. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with createrepo for modified DVD ISO
On Sun, 2010-06-20 at 18:36 +0100, mike cloaked wrote: > 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? No - not 64 on 32 - but 32 on 64 works. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora, DNSSEC and GOST (ECC like) algorithms with openssl
On Mon, 21 Jun 2010, Tomas Mraz wrote: >> I would be great if we could change the spec file to have a proper flag >> to enable/disable GOST/ECC so that people can easilly rebuild with GOST >> support if they need to (and it is legal for them). Would that be >> legally possible? > This is not possible as the ECC algorithm sources are removed from the > source tarball prior to adding it to the Fedora CVS. Would it still be possible to have the define with a comment to grab the source outside the CVS repo? I am just trying to minimise the work that has to be done and maintained separately from the Fedora openssl.spec file. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 14 Feature Submission Deadline in Three Weeks
It is hard to believe, but it is true, we are almost a month into Fedora 14 development. This email serves as a friendly reminder that the deadline for submitting new features for Fedora 14 is Tuesday, July 13, 2010. After this date newly submitted features will be targeted for Fedora 15 unless an exception is granted by FESCo. Accepted Fedora 14 features so far: https://fedoraproject.org/wiki/Releases/14/FeatureList If you are are current feature page owner, thank you for already submitting your feature for Fedora 14 and contributing to the next release of Fedora. If you haven't updated your feature page in the last month it would be a great help to every one if you would do so. As we start to reach deadlines and test releases for Fedora 14, more and more people query the feature pages and we'd love to know that what they find is current and correct. Thank you! John More information: Fedora 14 Schedule: https://fedoraproject.org/wiki/Releases/14/Schedule Fedora Feature Process: https://fedoraproject.org/wiki/Features/Policy ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rfc: python2.7 for F14
I'm interested in python2.7 as a feature for F14. This will provide backports of some nice python3 features, but will work for those needing python2 environments. Many libraries are not available for python3 yet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: python2.7 for F14
On Mon, 2010-06-21 at 13:19 -0400, Neal Becker wrote: > I'm interested in python2.7 as a feature for F14. This will provide > backports of some nice python3 features, but will work for those > needing python2 environments. Many libraries are not available for > python3 yet. https://fedoraproject.org/wiki/Features/Python_2.7 I've been working on it (though have been on holiday for a week) I hope to have the latest upstream 2.7 release candidate in rawhide later this week. This will require a rebuild of all Python modules. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: python2.7 for F14
On Mon, Jun 21, 2010 at 01:19:17PM -0400, Neal Becker wrote: > I'm interested in python2.7 as a feature for F14. This will provide > backports of some nice python3 features, but will work for those > needing python2 environments. Many libraries are not available for > python3 yet. > https://fedoraproject.org/wiki/Features/Python_2.7 dmalcolm, you back from your holiday? I haven't seen you on freenode yet, today. -Toshio pgpEaef5BdIw4.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: python2.7 for F14
2010/6/22 David Malcolm : > On Mon, 2010-06-21 at 13:19 -0400, Neal Becker wrote: >> I'm interested in python2.7 as a feature for F14. This will provide >> backports of some nice python3 features, but will work for those >> needing python2 environments. Many libraries are not available for >> python3 yet. > > https://fedoraproject.org/wiki/Features/Python_2.7 > > I've been working on it (though have been on holiday for a week) > > I hope to have the latest upstream 2.7 release candidate in rawhide > later this week. This will require a rebuild of all Python modules. > > > -- Why not rebuild all python modules along with gcc 4.5? It may avoid of rebuild python-related packages twice? Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: python2.7 for F14
On Mon, 2010-06-21 at 13:50 -0400, Toshio Kuratomi wrote: > On Mon, Jun 21, 2010 at 01:19:17PM -0400, Neal Becker wrote: > > I'm interested in python2.7 as a feature for F14. This will provide > > backports of some nice python3 features, but will work for those > > needing python2 environments. Many libraries are not available for > > python3 yet. > > > https://fedoraproject.org/wiki/Features/Python_2.7 > > dmalcolm, you back from your holiday? I haven't seen you on freenode yet, > today. I'm back from holiday, and am on IRC; still wading through thousands of emails :-( -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
PulseAudio profile change upon plugging hardware
Hi Fedorians, Lately I've hit a Just-Works™ experience with Fedora and it rox. Basically, I purchased a Bluetooth headphone, paired to my fedora box, and boom it appears as an audio device inside pulseaudio. I was happy with how simple it was to use it to talk via skype .. Awesome! Then I wanted something more advanced, I wanted to only use the BT headphone's mic, while having audio output via the full laptop speakers. A couple of clicks inside pulseaudio GUI, and that works too .. very very cool ! Thank you Lennart and everyone who helped make this possible. Thanks for bringing the free desktop to the 21st Century. Now, what remains to be missing (at least I can't figure it out) is: Whenever I pair my BT headphone, I want PA to automatically use its mic, but audio output should remain on the main speakers. Basically, I want a certain PA "profile" to be applied whenever different audio devices are plugged in/out. I wonder if this functionality is already available. If not, I'd like to file an RFE. Thanks again for a nice surprise Best Regards -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: python2.7 for F14
On Tue, 2010-06-22 at 01:57 +0800, Chen Lei wrote: > 2010/6/22 David Malcolm : > > On Mon, 2010-06-21 at 13:19 -0400, Neal Becker wrote: > >> I'm interested in python2.7 as a feature for F14. This will provide > >> backports of some nice python3 features, but will work for those > >> needing python2 environments. Many libraries are not available for > >> python3 yet. > > > > https://fedoraproject.org/wiki/Features/Python_2.7 > > > > I've been working on it (though have been on holiday for a week) > > > > I hope to have the latest upstream 2.7 release candidate in rawhide > > later this week. This will require a rebuild of all Python modules. > > > > > > -- > Why not rebuild all python modules along with gcc 4.5? It may avoid of > rebuild python-related packages twice? Is there a Fedora feature page for gcc 4.5? I briefly searched, but didn't find one. I'm not sure that building things twice is a waste: if there are bugs, having intermediate builds may help us determine whether the problem relates to the Python or the GCC revision bump. It may be simpler to do a full rebuild of anything with: Requires: python(abi) = 2.6 as soon as python 2.7 hits rawhide. Is there a good (automated) way of doing this? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora, DNSSEC and GOST (ECC like) algorithms with openssl
On Mon, Jun 21, 2010 at 11:07:05 -0400, Paul Wouters wrote: > > Some references showing there should not be any known IPR issues filed > with the IETF that would prevent implementing RFC standards using ECC: DJB has made some public comments on why he doesn't think any patents apply to ECC work he has published at: http://cr.yp.to/ecdh/patents.html He isn't a lawyer, but his comments may still be useful. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
possibly rough day in rawhide
Just a quick warning: I have built a glib update that affects some users of GDbus and other new apis. We'll try to get everything straightened out by tomorrow, but you never know... Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: python2.7 for F14
On Mon, 2010-06-21 at 14:12 -0400, David Malcolm wrote: > I'm back from holiday, and am on IRC; still wading through thousands of > emails :-( I suggest email roulette. Write a simple script to mark 5/6ths of them as read. Reply to the other 1/6th as normal. =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: possibly rough day in rawhide
Thanks for the warning (they really are appreciated). I updated to koji from the last hour, just to be a bit insane. With all the gnome and glib changes in place, gnome gets to the point of displaying the desktop icons. The panel never appears and the three desktop icons keep flashing rapidly, like it is trying to restart. ctl-alt-backspace doesn't kill it. .xsession-errors says nm-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. polkit-gnome-authentication-agent-1: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. gnome-screensaver: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. gnome-volume-control-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. (gnome-panel:3972): EggSMClient-WARNING **: Failed to connect to the session manager: IO error occured opening connection The application 'gnome-panel' lost its connection to the display :0.0; most likely the X server was shut down or you killed/destroyed -- darrell On Mon, Jun 21, 2010 at 12:01, Matthias Clasen wrote: > Just a quick warning: > > I have built a glib update that affects some users of GDbus and other new > apis. We'll try to get everything straightened out by tomorrow, but you > never know... > > > Matthias > -- > 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
Plan for tomorrow's FESCo meeting (2010-06-22 at 19:30 UTC)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 19:30UTC (3:30pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #topic #351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #topic #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382 #topic #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13 https://fedorahosted.org/fesco/ticket/387 = New business = #topic #398 F14Feature: perl 5.12: https://fedoraproject.org/wiki/Features/perl5.12 https://fedorahosted.org/fesco/ticket/398 #topic #399 F14Feature: Erlang R14: https://fedoraproject.org/wiki/Features/Erlang_R14 https://fedorahosted.org/fesco/ticket/399 #topic #400 F14Feature: AtSpiTwo https://fedoraproject.org/wiki/Features/AtSpiTwo https://fedorahosted.org/fesco/ticket/400 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 605662] package needs to be upgraded
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=605662 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|ON_QA --- Comment #4 from Fedora Update System 2010-06-21 17:30:50 EDT --- perl-HTTP-DAV-0.40-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-HTTP-DAV'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/perl-HTTP-DAV-0.40-1.fc13 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Package Review Stats for last week ending 20th June
Dne 21.6.2010 10:46, Marcela Mašláňová napsal(a): >> Marcela Mašláňová : 1 >> >> https://bugzilla.redhat.com/show_bug.cgi?id=578480 spectrum >> > Here is another bug. I've done only the first review in this list. The other one was kindly provided to me by Michal Schmidt. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-06-22 at 19:30 UTC)
On Mon, 2010-06-21 at 15:30 -0600, Kevin Fenzi wrote: > Following is the list of topics that will be discussed in the FESCo > meeting tomorrow at 19:30UTC (3:30pm EDT) in #fedora-meeting on > irc.freenode.net. > > = Followups = > > #topic #351 Create a policy for updates - status report on implementation > https://fedorahosted.org/fesco/ticket/351 It occurred to me that QA may not have given you much if any feedback on this for a while. I haven't followed the FESCo logs closely, but if it helps as info for tomorrow's meeting, QA has been working on the proven testers system. There is now a proven testers policy in place: https://fedoraproject.org/wiki/QA/JoinProvenTesters and we are working on instructions for proven testers: https://fedoraproject.org/wiki/User:Dafrito/Draft_proventesters_instructions so things are progressing well on that side. As far as we can see, we're now waiting on release engineering to 'flip the switch' in Bodhi so that critpath package updates require proven tester feedback, as they did for F13 prior to release. The mechanisms for the testing to actually happen are now pretty much in place. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pxkxc - a simple utility to boot a PXE target with kexec
On Mon, 14 Jun 2010 16:50:06 +0300 Marko Myllynen wrote: > Hi all, > > announcing pxkxc - a simple utility to boot a PXE target with kexec. > > pxkxc combines the simplicity of PXE and the power of kexec to allow > booting of any kernel/initrd image from a PXE server without the need > for HW support, boot images, or even rebooting the system. For > example, one can initiate Fedora installation from BFO without any > boot media. Cool. This looks interesting... Have you considering setting up proper hosting for it at perhaps fedorahosted.org ? see: https://fedorahosted.org/web/new What distros ship with kexec support enabled these days? Most of them? A nice clean wiki page showing how to download, how to install (and list any prereqs) and run it might be good. It should be pretty simple to package up for fedora... but I think the best use would be other distros. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with createrepo for modified DVD ISO
On Sat, 2010-06-19 at 17:07 -0400, Digimer wrote: > On 10-06-19 08:51 AM, mike cloaked wrote: > > On Sat, Jun 19, 2010 at 5:37 AM, Bruno Wolff III wrote: > >> On Fri, Jun 18, 2010 at 09:15:09 -0400, > >> Digimer wrote: > >>> Hi all, > >>> > >>> I asked this on buildsys, so this is something of a repost. I'm not > >>> sure where to turn at this point, so if this isn't the right list, would > >>> anyone be able to point me in the right direction? > >> > >> Probably the question belongs on users. > >> > >>> I've been trying to create my own (minorly) custom distro for Fedora > >>> 13. All it really is is a custom kickstart and a changed up set of RPMs. > >> > >> I think revisor is the tool that is best for making custom install DVDs. > >> I usually make live images using livecd-creator and can't give you specific > >> information on using revisor. > >> > > > > Surely mock/pungi is the best tool chain for creating install isos? > > 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. > Creating the right metadata involves using the --baseurl directive, and something along the lines of --baseurl media:// That's what will make the repodata have the right urls listed. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: give koji diff capabilities
On Mon, 2010-06-21 at 22:20 +1000, David Timms wrote: > On 21/06/10 09:38, Thomas Spura wrote: > >> 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. > Hi Thomas, good point. But reality might be different: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2260035 -> build.log > > The x86_64 build failed, and is says that the i686 was cancelled. > > However, the build.log shows that the package and -debuginfo .rpms were > created, ie the build actually succeeded. This seems like a bug in the > koji web interface. > > Having the non-failing build be cancelled may not be optimal; I have > definitely found it helpful to compare the build logs of different > archs, when one succeeds (or at least gets further). It helps to see the > diff in log results to understand what is different about the process > between each build. > > > 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.) > That would be more bonus points for the diff to optionally ignore ! > A decent visual diff will highlight lines that are different, but also > show the actual characters that differ (I don't know if viewvc can do that). > > > What would be the benefit of such a feature? > Resolving build problems more quickly: > - what changed in the build process from arch to arch ... > - what changed in the bp from fedora release to fedora release ... > - what changed in the bp compare to an earlier version-release ... > > However, for the less experienced package maintainers: tell me shortest > time for you to determine the cause for the failure in: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2260034 -> build.log > > Now, would these screen shots from a visual diff program have reduced > the time for working out both the error, and the cause ? > http://members.iinet.net.au/~timmsy/rakarrack/meld.rakarrack.diff1.png > http://members.iinet.net.au/~timmsy/rakarrack/meld.rakarrack.diff2.png Something like this probably belongs in a consumer app, and not in Koji directly. You'd find it faster to develop and use something stand alone that consumed content from koji in order to do the comparisons, and then you'd have a better way of comparing different builds. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up! Erlang/OTP R14A will soon hit Rawhide near you.
Hello All! This is a release candidate to the forthcoming Erlang R14 release, which is scheduled on September 2010. I'm almost sure that no visible dependency issues will be introduced by this upgrade, although there may be some hidden issues, which I plan to track down and fix during consequent full rebuild of all Erlang-related packages. Objections, thoughts and comments are highly welcome, as usual. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
