Re: e2fsprogs 1.42 vs 1.42.2
On Fri, Apr 13, 2012 at 06:57:26PM -0500, Eric Sandeen wrote: On 4/13/12 5:52 PM, Chris Murphy wrote: e2fsprogs 1.42 is in RC4.1 but 1.42.2 is upstream current. Chances of rolling this in before final? http://e2fsprogs.sourceforge.net/ 1.42.2 is in rawhide... I'm a little leery of pushing it in at the last minute, since various bits like the installer depend on it. I figured I'd probably do an update to 1.42.2 post-release. If The Powers that Be (and the Anaconda People) are ok with a late update, I could push it to F17, but there was already one library breakage identified in 1.42.2, so I'm a little gunshy. It broke (ie. caused segfaults) in valid code in febootstrap, so I too would be uncertain about this one ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sudo and changes in packaging guidelines
Mattia Verga wrote: Greetings, I saw the changes in packaging guidelines related to PIE: /If your package meets the following criteria you *MUST* enable the PIE compiler flags: / * /Your package is long running. This means it's likely to be started and keep running until the machine is rebooted, not start on demand and quit on idle. / * /Your package has suid binaries, or binaries with capabilities. / * /Your package runs as root. / I maintain kde-partitionmanager and I wonder if I should apply PIE to that. It's not long running, so, I'd say no. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-17 Branched report: 20120414 changes
Compose started at Sat Apr 14 08:15:03 UTC 2012 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc17.noarch requires ruby-nokogiri [ale] ale-0.9.0.3-6.fc17.x86_64 requires libMagickCore.so.4()(64bit) [alexandria] alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8 [cuneiform] cuneiform-1.1.0-6.fc17.i686 requires libMagick++.so.4 cuneiform-1.1.0-6.fc17.x86_64 requires libMagick++.so.4()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [dmapd] dmapd-0.0.47-2.fc17.i686 requires libMagickWand.so.4 dmapd-0.0.47-2.fc17.i686 requires libMagickCore.so.4 dmapd-0.0.47-2.fc17.x86_64 requires libMagickWand.so.4()(64bit) dmapd-0.0.47-2.fc17.x86_64 requires libMagickCore.so.4()(64bit) [dogtag-pki] dogtag-pki-9.0.0-10.fc17.noarch requires pki-util-javadoc = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-util = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-tks = 0:9.0.9 dogtag-pki-9.0.0-10.fc17.noarch requires pki-symkey = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-silent = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-setup = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-selinux = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-ocsp = 0:9.0.9 dogtag-pki-9.0.0-10.fc17.noarch requires pki-native-tools = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-kra = 0:9.0.10 dogtag-pki-9.0.0-10.fc17.noarch requires pki-java-tools-javadoc = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-java-tools = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-common-javadoc = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-common = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-ca = 0:9.0.18 [drawtiming] drawtiming-0.7.1-5.fc17.x86_64 requires libMagickCore.so.4()(64bit) drawtiming-0.7.1-5.fc17.x86_64 requires libMagick++.so.4()(64bit) [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [dx] dx-4.4.4-21.fc17.x86_64 requires libMagickCore.so.4()(64bit) dx-libs-4.4.4-21.fc17.i686 requires libMagickCore.so.4 dx-libs-4.4.4-21.fc17.x86_64 requires libMagickCore.so.4()(64bit) [egoboo] egoboo-2.7.5-11.fc17.x86_64 requires libenet-1.2.1.so()(64bit) [entangle] entangle-0.3.2-1.fc17.x86_64 requires libgexiv2.so.0()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [i3] i3-4.0.1-2.fc17.x86_64 requires libxcb-property.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-icccm.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-event.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-aux.so.0()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-atom.so.1()(64bit) [ibus-gucharmap] ibus-gucharmap-1.4.0-4.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [ibus-panel-extensions] ibus-panel-extensions-1.4.99.20111207-2.fc17.i686 requires libibus-1.0.so.0 ibus-panel-extensions-1.4.99.20111207-2.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [imageinfo] imageinfo-0.05-14.fc17.x86_64 requires libMagickCore.so.4()(64bit) [inkscape] inkscape-0.48.2-4.fc17.x86_64 requires libMagickCore.so.4()(64bit) inkscape-0.48.2-4.fc17.x86_64 requires libMagick++.so.4()(64bit) inkscape-view-0.48.2-4.fc17.x86_64 requires libMagickCore.so.4()(64bit) inkscape-view-0.48.2-4.fc17.x86_64 requires libMagick++.so.4()(64bit) [jboss-as] jboss-as-7.1.0-2.fc17.noarch requires slf4j-jboss-logmanager [k3d] k3d-0.8.0.2-6.fc17.i686 requires libMagickCore.so.4 k3d-0.8.0.2-6.fc17.i686 requires libMagick++.so.4 k3d-0.8.0.2-6.fc17.x86_64 requires libMagickCore.so.4()(64bit) k3d-0.8.0.2-6.fc17.x86_64 requires libMagick++.so.4()(64bit) [kxstitch] kxstitch-0.8.4.1-8.fc17.x86_64 requires libMagickCore.so.4()(64bit)
RE: ( Was Provenpackager? Want to help out? )
On Tue, 2012-02-28 at 04:52 +, Jóhann B. Guðmundsson wrote: b) upstream wont accept submitted units with /etc/sysconfig/ files which means those that still want to do this will need start carrying patches in the form of EnvironmentFile=-/etc/sysconfig/$SERVICE against upstream units to add this behaviour to units. I hope that systemd always supports sysV, has part of specification of systemd. IMHO. Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ( Was Provenpackager? Want to help out? )
On 04/14/2012 12:26 PM, Sérgio Basto wrote: I hope that systemd always supports sysV, has part of specification of systemd. IMHO. It will for sometime due to 3rd parties but that does not give us an excuse to not migrate all our legacy sysv init scripts to native systemd units. Hopefully we manage to migrate all that stuff in F18 no later than F19 so if you have submitted units against your components please package them. Thanks JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Building the GNOME 3.4.1 Release
If you're maintaining a GNOMEish package and you want it included in the 3.4.1 release, please build the package like normal and then add the build ID to: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc Most of the packages released on ftp.gnome.org with the exact version 3.4.1 can be handled by the mclazy script, but I'm sure there are other packages that we'll need to do manually for the 3.4.1 mega-update. Thanks, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building the GNOME 3.4.1 Release
Richard Hughes wrote: If you're maintaining a GNOMEish package and you want it included in the 3.4.1 release, please build the package like normal and then add the build ID to: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc Can we not find a way to coordinate GNOME updates which does not rely on a proprietary web application? The workflow of a Free Software project should not rely on proprietary software. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: disruptive libffi upgrade
On Fri, 2012-04-13 at 20:58 -0400, Anthony Green wrote:
Sorry folks -- thanks for untagging. I'll ping the list again after May 9,
as was suggested earlier in this thread.
Here's a lightly tested patch which implements my suggestion of keeping
the symbols as empty stubs.
Incidentally - keeping the generated autotools stuff in git makes
tracking down what *really* changed extremely painful. It looks
like the ABI was bumped in ee6696fdf4768ba6dd037fb6dd99435afa13816e
but that commit has thousands of lines of generated code changes
too. It'd be better to either:
1) Do regenerate autotools as a separate commit
2) Keep a separate git repository with generated stuff
3) Don't commit the generated files, have consumers install
the autotools, and join the rest of the world
From 25d69ed1bee13fbe040f8ca223a6ddc05940be59 Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Sat, 14 Apr 2012 10:03:59 -0400
Subject: [PATCH] Revert to previous ABI
Bumping the SONAME just to delete 3 symbols that no one called anyways
is quite simply not worth the pain, given how many low-level modules
consume libffi.
Just keep the symbols around as empty stubs.
---
Makefile.am |6 +-
libtool-version |2 +-
src/debug.c | 12 ++--
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 4a855d7..0e9cabd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -96,11 +96,7 @@ libffi_la_SOURCES = src/prep_cif.c src/types.c \
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = libffi.pc
-nodist_libffi_la_SOURCES =
-
-if FFI_DEBUG
-nodist_libffi_la_SOURCES += src/debug.c
-endif
+nodist_libffi_la_SOURCES = src/debug.c
if MIPS
nodist_libffi_la_SOURCES += src/mips/ffi.c src/mips/o32.S src/mips/n32.S
diff --git a/libtool-version b/libtool-version
index 95f48c5..b8b80e0 100644
--- a/libtool-version
+++ b/libtool-version
@@ -26,4 +26,4 @@
#release, then set age to 0.
#
# CURRENT:REVISION:AGE
-6:0:0
+5:10:0
diff --git a/src/debug.c b/src/debug.c
index 51dcfcf..ae42afd 100644
--- a/src/debug.c
+++ b/src/debug.c
@@ -27,33 +27,41 @@
#include stdlib.h
#include stdio.h
-/* General debugging routines */
+/* General debugging routines; note these were accidentally
+ * made public, so we keep empty stubs in the case where
+ * we weren't compiled with FFI_DEBUG.
+ */
void ffi_stop_here(void)
{
+#ifdef FFI_DEBUG
/* This function is only useful for debugging purposes.
Place a breakpoint on ffi_stop_here to be notified of
significant events. */
+#endif
}
/* This function should only be called via the FFI_ASSERT() macro */
void ffi_assert(char *expr, char *file, int line)
{
+#ifdef FFI_DEBUG
fprintf(stderr, ASSERTION FAILURE: %s at %s:%d\n, expr, file, line);
ffi_stop_here();
abort();
+#endif
}
/* Perform a sanity check on an ffi_type structure */
void ffi_type_test(ffi_type *a, char *file, int line)
{
+#ifdef FFI_DEBUG
FFI_ASSERT_AT(a != NULL, file, line);
FFI_ASSERT_AT(a-type = FFI_TYPE_LAST, file, line);
FFI_ASSERT_AT(a-type == FFI_TYPE_VOID || a-size 0, file, line);
FFI_ASSERT_AT(a-type == FFI_TYPE_VOID || a-alignment 0, file, line);
FFI_ASSERT_AT(a-type != FFI_TYPE_STRUCT || a-elements != NULL, file, line);
-
+#endif
}
--
1.7.7.6
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building the GNOME 3.4.1 Release
On Sat, Apr 14, 2012 at 15:52:18 +0200, Kevin Kofler kevin.kof...@chello.at wrote: Richard Hughes wrote: If you're maintaining a GNOMEish package and you want it included in the 3.4.1 release, please build the package like normal and then add the build ID to: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc Can we not find a way to coordinate GNOME updates which does not rely on a proprietary web application? The workflow of a Free Software project should not rely on proprietary software. Presumably updating that document requires a gmail account which not everyone wants. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
On Wed, Apr 11, 2012 at 8:01 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Apr 11, 2012 at 03:53:18PM +0100, Daniel P. Berrange wrote: On Wed, Apr 11, 2012 at 03:49:29PM +0100, Richard W.M. Jones wrote: On Wed, Apr 11, 2012 at 10:11:40AM -0400, Adam Jackson wrote: So that's a factor of 25ish more data in the Requires list. No, thanks. I'm assuming your argument is that you don't want to ship RPMs or repositories where part of them grows to be 25x larger. But this need not be the case. Observe that the packages already contain the data (in the libraries and binaries themselves). That data is in the RPM payload though. The YUM depsolving code does not have any of the RPM payloads available - it is still trying to figure out which it needs. So at least the YUM repodata will grow in size significantly, even if the RPMs themselves did not. I'm not arguing that's how yum works now, but it doesn't have to work that way! It could incrementally download the RPMs during depsolving, test that they work together, and with that information download further packages as necessary ... Ugh no ... the whole point of the repodata is to avoid having to download the rpms to calculate deps. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
On Sat, Apr 14, 2012 at 06:21:15PM +0200, drago01 wrote: On Wed, Apr 11, 2012 at 8:01 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Apr 11, 2012 at 03:53:18PM +0100, Daniel P. Berrange wrote: On Wed, Apr 11, 2012 at 03:49:29PM +0100, Richard W.M. Jones wrote: On Wed, Apr 11, 2012 at 10:11:40AM -0400, Adam Jackson wrote: So that's a factor of 25ish more data in the Requires list. No, thanks. I'm assuming your argument is that you don't want to ship RPMs or repositories where part of them grows to be 25x larger. But this need not be the case. Observe that the packages already contain the data (in the libraries and binaries themselves). That data is in the RPM payload though. The YUM depsolving code does not have any of the RPM payloads available - it is still trying to figure out which it needs. So at least the YUM repodata will grow in size significantly, even if the RPMs themselves did not. I'm not arguing that's how yum works now, but it doesn't have to work that way! It could incrementally download the RPMs during depsolving, test that they work together, and with that information download further packages as necessary ... Ugh no ... the whole point of the repodata is to avoid having to download the rpms to calculate deps. Well the whole point is to get the best possible software quality, user experience and performance (accepting that we cannot maximize all of these at the same time). It's my personal opinion that yum does not do well on any of these three criteria. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
Am 14.04.2012 18:39, schrieb Richard W.M. Jones: On Sat, Apr 14, 2012 at 06:21:15PM +0200, drago01 wrote: On Wed, Apr 11, 2012 at 8:01 PM, Richard W.M. Jones rjo...@redhat.com wrote: I'm not arguing that's how yum works now, but it doesn't have to work that way! It could incrementally download the RPMs during depsolving, test that they work together, and with that information download further packages as necessary ... Ugh no ... the whole point of the repodata is to avoid having to download the rpms to calculate deps. Well the whole point is to get the best possible software quality, user experience and performance (accepting that we cannot maximize all of these at the same time). It's my personal opinion that yum does not do well on any of these three criteria. and you think performance and user experience will get better by downloading packages for dep-solve? are you aware that many people do not have endless bandwith, traffic-limuts and storage and can you imagine how slow this all would be? yum should not waste ressources which i did even in the recent past by consuming wy too much memory resulting get killed from oom-killer on machines with 512 MB RAM and yes, 512 MB RAM are really enough for many servers and there is no argumentation for a UPDATER eating more ressources as the whole server in normal operations signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
On Sat, Apr 14, 2012 at 6:39 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Sat, Apr 14, 2012 at 06:21:15PM +0200, drago01 wrote: On Wed, Apr 11, 2012 at 8:01 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Apr 11, 2012 at 03:53:18PM +0100, Daniel P. Berrange wrote: On Wed, Apr 11, 2012 at 03:49:29PM +0100, Richard W.M. Jones wrote: On Wed, Apr 11, 2012 at 10:11:40AM -0400, Adam Jackson wrote: So that's a factor of 25ish more data in the Requires list. No, thanks. I'm assuming your argument is that you don't want to ship RPMs or repositories where part of them grows to be 25x larger. But this need not be the case. Observe that the packages already contain the data (in the libraries and binaries themselves). That data is in the RPM payload though. The YUM depsolving code does not have any of the RPM payloads available - it is still trying to figure out which it needs. So at least the YUM repodata will grow in size significantly, even if the RPMs themselves did not. I'm not arguing that's how yum works now, but it doesn't have to work that way! It could incrementally download the RPMs during depsolving, test that they work together, and with that information download further packages as necessary ... Ugh no ... the whole point of the repodata is to avoid having to download the rpms to calculate deps. Well the whole point is to get the best possible software quality, user experience and performance (accepting that we cannot maximize all of these at the same time). It's my personal opinion that yum does not do well on any of these three criteria. OK, but your suggestion does not really make the overall experience any better (it does the opposite). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Introduction
Hello! I'm a 17 year old high school student living in the northeast United States. For the past two years I've been distro surfing and I think I've found a home in Fedora, and want to contribute. What better place to start than to package some of the missing software that I use? I'm starting with my window manager: https://bugzilla.redhat.com/show_bug.cgi?id=812538 I'll be working with the Font SIG to try and automate some things over the next few weeks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora-packaging] [Guidelines Change] Changes to the Packaging Guidelines
On Thursday, April 12, 2012 04:57:29 PM Tom Callaway wrote: A bundling exception for boost within Passenger was granted, due to the intrusive nature of the forked changes, the efforts of the maintainer to merge as many of them as possible into the upstream boost source tree, and the visible efforts of the upstream to keep the bundled copy of boost in sync with the current boost releases. The package must also include a Requires: bundled(boost) = $VERSION where $VERSION is the boost version being bundled. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_grant ed_exceptions While I appreciate the work Brett Lentz has been putting in upstream, why does this package have to be taken away from me? I'm already facing a thanks for your work but no thanks[1]. I respectfully request Uncle Shadowman *not* be forcefully made the owner of the package, and the reporter of the review request be granted ownership. Kind regards, Jeroen van Meeuwen [1] https://bugzilla.redhat.com/show_bug.cgi?id=470696#c114 -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 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: [Fedora-packaging] [Guidelines Change] Changes to the Packaging Guidelines
On 04/14/2012 02:32 PM, Jeroen van Meeuwen wrote: On Thursday, April 12, 2012 04:57:29 PM Tom Callaway wrote: A bundling exception for boost within Passenger was granted, due to the intrusive nature of the forked changes, the efforts of the maintainer to merge as many of them as possible into the upstream boost source tree, and the visible efforts of the upstream to keep the bundled copy of boost in sync with the current boost releases. The package must also include a Requires: bundled(boost) = $VERSION where $VERSION is the boost version being bundled. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_grant ed_exceptions While I appreciate the work Brett Lentz has been putting in upstream, why does this package have to be taken away from me? I'm already facing a thanks for your work but no thanks[1]. I respectfully request Uncle Shadowman *not* be forcefully made the owner of the package, and the reporter of the review request be granted ownership. Kind regards, Jeroen van Meeuwen [1] https://bugzilla.redhat.com/show_bug.cgi?id=470696#c114 No need for this to be mutually exclusive, unless one (or both) of you are averse to being comaintainers? -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora-packaging] [Guidelines Change] Changes to the Packaging Guidelines
On Saturday, April 14, 2012 03:11:46 PM Rex Dieter wrote: No need for this to be mutually exclusive, unless one (or both) of you are averse to being comaintainers? I'm objecting based on the matters of principle and due process. Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 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: Building the GNOME 3.4.1 Release
If you're maintaining a GNOMEish package and you want it included in the 3.4.1 release, please build the package like normal and then add the build ID to: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc Can we not find a way to coordinate GNOME updates which does not rely on a proprietary web application? The workflow of a Free Software project should not rely on proprietary software. Presumably updating that document requires a gmail account which not everyone wants. What about using a page on https://fedoraproject.org/wiki/ ? Cheers, Debarshi -- Give a man ssh access, he'll still need computer. Give him a computer, he'll give ssh access to you. -- Ashish Shukla pgp82juYrfvmd.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building the GNOME 3.4.1 Release
On 14 April 2012 22:31, Debarshi Ray rishi...@lostca.se wrote: What about using a page on https://fedoraproject.org/wiki/ ? Unless I'm mistaken, you can't have more than one person editing a wiki page at the same time. Seeing as there's normally 3 or 4 of us building packages simultaneously, it needs to be instant-apply. Does Fedora have an etherpad instance? Is that free enough? Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building the GNOME 3.4.1 Release
On Sun, 15 Apr 2012 00:04:05 +0100 Richard Hughes hughsi...@gmail.com wrote: On 14 April 2012 22:31, Debarshi Ray rishi...@lostca.se wrote: What about using a page on https://fedoraproject.org/wiki/ ? Unless I'm mistaken, you can't have more than one person editing a wiki page at the same time. Seeing as there's normally 3 or 4 of us building packages simultaneously, it needs to be instant-apply. Does Fedora have an etherpad instance? Is that free enough? We don't have etherpad, but we do have gobby: http://fedoraproject.org/wiki/Gobby kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: disruptive libffi upgrade
Colin Walters walt...@verbum.org wrote: [...] Incidentally - keeping the generated autotools stuff in git makes tracking down what *really* changed extremely painful. It looks like the ABI was bumped in ee6696fdf4768ba6dd037fb6dd99435afa13816e but that commit has thousands of lines of generated code changes too. It'd be better to either: 1) Do regenerate autotools as a separate commit 2) Keep a separate git repository with generated stuff 3) Don't commit the generated files, have consumers install the autotools, and join the rest of the world Please go with (3), keeping generated files in git is just dumb. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: disruptive libffi upgrade
Horst H. von Brand vonbr...@inf.utfsm.cl writes: [...] Please go with (3), keeping generated files in git is just dumb. Please don't demean those who do it for well-considered reasons. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 812521] New: perl-File-ChangeNotify-0.22 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-File-ChangeNotify-0.22 is available https://bugzilla.redhat.com/show_bug.cgi?id=812521 Summary: perl-File-ChangeNotify-0.22 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-File-ChangeNotify AssignedTo: robinlee.s...@gmail.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, robinlee.s...@gmail.com, psab...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Latest upstream release: 0.22 Current version in Fedora Rawhide: 0.21 URL: http://search.cpan.org/dist/File-ChangeNotify/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 812520] New: perl-Coro-6.08 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Coro-6.08 is available https://bugzilla.redhat.com/show_bug.cgi?id=812520 Summary: perl-Coro-6.08 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Coro AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, kwiz...@gmail.com, boche...@fedoraproject.org, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Latest upstream release: 6.08 Current version in Fedora Rawhide: 6.07 URL: http://search.cpan.org/dist/Coro/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-RPM2
perl-RPM2 has broken dependencies in the rawhide tree: On x86_64: perl-RPM2-1.0-2.fc17.x86_64 requires librpmio.so.2()(64bit) perl-RPM2-1.0-2.fc17.x86_64 requires librpm.so.2()(64bit) On i386: perl-RPM2-1.0-2.fc17.i686 requires librpmio.so.2 perl-RPM2-1.0-2.fc17.i686 requires librpm.so.2 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 811144] RPM description is not descriptive
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=811144 --- Comment #7 from Tim Landscheidt t...@tim-landscheidt.de 2012-04-14 14:10:38 EDT --- Thanks. Unfortunately I noticed just now that I filed the bug against F17 instead of F16. Could this patch of uttermost importance be backported there as well? :-) -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 810243] Upgrade to new upstream version
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=810243 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Config-Validator-0.4-1 |perl-Config-Validator-0.4-1 |.fc17 |.fc16 --- Comment #7 from Fedora Update System upda...@fedoraproject.org 2012-04-14 19:20:12 EDT --- perl-Config-Validator-0.4-1.fc16 has been pushed to the Fedora 16 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
