Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, 2014-06-09 at 14:18 -0400, Adam Jackson wrote:
libguestfs uses hfsplus-tools in order to provide some HFS+ filesystem
features (mainly for Mac filesystems and .DMG files). We can remove
this functionality from the Fedora version, but of course it means
people won't be able to perform some operations on Mac filesystems.
Yeah, I'd prefer if we didn't retire hfsplus-tools too. It'd be nice if
this got some attention from the arm guys, I tried to force llvm to
default to hard-float in 3.4-8 but it doesn't seem to have been enough
to fix this. I can keep poking at it but I'm assuredly not the best man
for the job.
Just to follow up on this:
Richard added an ExcludeArch: %{arm} in Release: 7, so that fixed the
FTBFS in a sense. Florian Weimer, in a comment on bug 803433, offered
to fix the source to not use clang's blocks feature (which was the only
reason it needed clang to build), but I beat him to it. With that, and
another fix for arm's stdarg implementation being (righteously) pickier
than others, Release: 8 of hfsplus-tools builds with gcc for all arches:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7055465
If I may vent for a moment, I'd like to point out exactly how spurious
the blocks usage was (and, implicitly, troll for code review):
http://pkgs.fedoraproject.org/cgit/hfsplus-tools.git/plain/hfsplus-tools-no-blocks.patch
That's right kids, the C89 version is less code even _before_ you count
the actual Blocks runtime.
clang remains slightly less than functional on arm. Patches welcome.
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On 06/18/2014 02:16 PM, Adam Jackson wrote: If I may vent for a moment, I'd like to point out exactly how spurious the blocks usage was (and, implicitly, troll for code review): http://pkgs.fedoraproject.org/cgit/hfsplus-tools.git/plain/hfsplus-tools-no-blocks.patch That's right kids, the C89 version is less code even _before_ you count the actual Blocks runtime. I should know better than start an argument about programming with you, but isn't your patch leaking memory? I don't know how often hfsplus tools allocate ctx-preMessage but just overwriting the pointer seems off. At least a comment, maybe? - if (bp) - ctx-postMessage = (fsckBlock_t)Block_copy(bp); + /* possible memory leak: unlinking old postMessage */ + ctx-postMessage = bp; -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Wed, 2014-06-18 at 15:24 -0400, Przemek Klosowski wrote: On 06/18/2014 02:16 PM, Adam Jackson wrote: If I may vent for a moment, I'd like to point out exactly how spurious the blocks usage was (and, implicitly, troll for code review): http://pkgs.fedoraproject.org/cgit/hfsplus-tools.git/plain/hfsplus-tools-no-blocks.patch That's right kids, the C89 version is less code even _before_ you count the actual Blocks runtime. I should know better than start an argument about programming with you, but isn't your patch leaking memory? I don't know how often hfsplus tools allocate ctx-preMessage but just overwriting the pointer seems off. At least a comment, maybe? If bp were a block then yes, but since it's just a function pointer now... - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Wed, Jun 18, 2014 at 02:16:49PM -0400, Adam Jackson wrote:
On Mon, 2014-06-09 at 14:18 -0400, Adam Jackson wrote:
libguestfs uses hfsplus-tools in order to provide some HFS+ filesystem
features (mainly for Mac filesystems and .DMG files). We can remove
this functionality from the Fedora version, but of course it means
people won't be able to perform some operations on Mac filesystems.
Yeah, I'd prefer if we didn't retire hfsplus-tools too. It'd be nice if
this got some attention from the arm guys, I tried to force llvm to
default to hard-float in 3.4-8 but it doesn't seem to have been enough
to fix this. I can keep poking at it but I'm assuredly not the best man
for the job.
Just to follow up on this:
Richard added an ExcludeArch: %{arm} in Release: 7, so that fixed the
FTBFS in a sense. Florian Weimer, in a comment on bug 803433, offered
to fix the source to not use clang's blocks feature (which was the only
reason it needed clang to build), but I beat him to it. With that, and
another fix for arm's stdarg implementation being (righteously) pickier
than others, Release: 8 of hfsplus-tools builds with gcc for all arches:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7055465
If I may vent for a moment, I'd like to point out exactly how spurious
the blocks usage was (and, implicitly, troll for code review):
http://pkgs.fedoraproject.org/cgit/hfsplus-tools.git/plain/hfsplus-tools-no-blocks.patch
That's right kids, the C89 version is less code even _before_ you count
the actual Blocks runtime.
And even more if all the structure for multiple event callbacks that
just isn't used were removed. What's the point of all that?
--
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
Matthew Miller wrote: On Wed, Jun 11, 2014 at 02:00:13AM +0200, Kevin Kofler wrote: That was overly critical of me and did nothing to actually further the discussion. I apologise. No need to apologize! It's just the truth: ARM is not ready to be a primary Kevin, I disagree. A positive tone to discussion is important even when speaking the truth. There was no negative tone in Matthew Garrett's original message: If the Fedora/ARM community don't care about feature parity with x86, then we should just drop them back to secondary status. There was nothing impolite or insulting in there. It might be impopular with the ARM people, but it's still a valid point that had to be made, and shouldn't have been retracted. The decision to make ARM primary was a mistake, period. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Fri, Jun 13, 2014 at 01:50:32AM +0200, Kevin Kofler wrote: Matthew Miller wrote: Kevin, I disagree. A positive tone to discussion is important even when speaking the truth. There was no negative tone in Matthew Garrett's original message: If the Fedora/ARM community don't care about feature parity with x86, then we should just drop them back to secondary status. There was nothing impolite or insulting in there. It might be impopular with the ARM people, but it's still a valid point that had to be made, and shouldn't have been retracted. In context, there was absolutely an impolite tone - it confounded there being no interest in making a single package work on ARM with the Fedora ARM community having no interest in feature parity. These are not actually the same thing, and the fact that I equated them was inappropriate. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 09, 2014 at 02:22:57PM -0500, Dennis Gilmore wrote: On Mon, 9 Jun 2014 17:08:13 +0100 Richard W.M. Jones rjo...@redhat.com wrote: I have a Fedora 20 ppc64 Mac right next to my feet here that is definitely booting using yaboot. Then you did not install using Fedora 20. F20/Rawhide from DVD is uninstallable on these Macs. I wish that were not so, but it is. You have to go via the upgrade route from F19 or earlier. I'm just saying it's a fact that I have a ppc64 machine that uses yaboot to boot into Fedora 20. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 09, 2014 at 10:20:46PM +0100, Matthew Garrett wrote:
On Mon, Jun 09, 2014 at 08:43:07PM +0100, Richard W.M. Jones wrote:
Can we excludearch %{arm} for this one?
Why? It's a bug that it doesn't build on ARM. Refusing to build it
doesn't fix the bug, and then someone else will crash into the same
issue when they dare to build something that needs llvm.
It seems the alternative is hfsplus-tools doesn't work at all for
anyone.
Anyway, it looks as if a patch has been posted to the upstream (LLVM
on ARM) bug last week, so let's see if the bug finally gets some
attention.
BTW this package is also affected by the -fstack-protector-strong LLVM
bug, but that is simple to work around.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Jun 2014 07:48:36 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jun 09, 2014 at 02:22:57PM -0500, Dennis Gilmore wrote: On Mon, 9 Jun 2014 17:08:13 +0100 Richard W.M. Jones rjo...@redhat.com wrote: I have a Fedora 20 ppc64 Mac right next to my feet here that is definitely booting using yaboot. Then you did not install using Fedora 20. F20/Rawhide from DVD is uninstallable on these Macs. I wish that were not so, but it is. You have to go via the upgrade route from F19 or earlier. I'm just saying it's a fact that I have a ppc64 machine that uses yaboot to boot into Fedora 20. Rich. its a fact that there is no way to build a yaboot update period because 32 bit ppc has been dropped. I believe that apple and yellowdog ppc hardware is not tested or supported by the ppc team. so you are very much on your own there. just because you have an old build of a package installed is not a valid reason to keep it active when it can not be built or supported. any upgraded system will not automatically be migrated over. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTlw+XAAoJEH7ltONmPFDRCQIP/jDwC7IGHj0V02ynnooJD08K PmLJaox8ApAz53rs3JSC27z5SozbJrBrS+EJMAfdwWp8ub/VYn8ag7tLlR489GJ0 0oR+EicjQ1HrlHGFxYgO8C/NAgWtCMgpLIhmnqLzUcjpAz6lz8iDGnwUoxeIYdew pzc54OpAqxDSXU8OXnb1DblxEa+WYn8RxYXlnyFTz/7gPELd6btjznYIRQC/tfgE C8iXAnQOfU80rJT5l5FcSb1CRd6iGqgn1ZAh7PDH7W+cinSZn2d/+K1qChqwpPb6 nYZJw8sPojObv+RDQZKzqYdXR9+wR0NHe9wSFqIxbazf9Ybv+fn2Efk8oQwuhfSh Ywb4srXRZBXJ43aSAhCJeMveNOQp+Ey6lYryEr/dwDi1lzp0XBk6hfTwi0gZqkJC GtHQjMIA58u1OSlEWAktZAzc4sLEkHvHIbppzysmYEML6IYCJPt3JinUoJvmu9l0 tLxMHeFeGGquFBQlQpN1afVIXoWJ+X36IK+u4xTrJFOfwe/upf22mBi7ko01HOAm VokF1Q9PntXSa6r2btfpnAEq3ix145ci9JqqZRMzpA+eovxI+CddY0YdcNiYr38+ 7BApct1/KL/CcMofO4MUUB2GEXgUaI8bY2M7XbjT8z3KU0cS3dSbDEL+Jv8b4n3S GeOLgIUdJyBvV4ExLrYu =p2eF -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 07:54:26AM +0100, Richard W.M. Jones wrote:
On Mon, Jun 09, 2014 at 10:20:46PM +0100, Matthew Garrett wrote:
On Mon, Jun 09, 2014 at 08:43:07PM +0100, Richard W.M. Jones wrote:
Can we excludearch %{arm} for this one?
Why? It's a bug that it doesn't build on ARM. Refusing to build it
doesn't fix the bug, and then someone else will crash into the same
issue when they dare to build something that needs llvm.
It seems the alternative is hfsplus-tools doesn't work at all for
anyone.
Eh. We're constrained by our own policies here, not by anything
fundamental - LLVM being broken on ARM ought to mean that our ARM
product is worse, not that everything else is dragged down to the same
level.
BTW this package is also affected by the -fstack-protector-strong LLVM
bug, but that is simple to work around.
Yeah that complaint is completely fair.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 03:45:57PM +0100, Matthew Garrett wrote:
On Tue, Jun 10, 2014 at 07:54:26AM +0100, Richard W.M. Jones wrote:
On Mon, Jun 09, 2014 at 10:20:46PM +0100, Matthew Garrett wrote:
On Mon, Jun 09, 2014 at 08:43:07PM +0100, Richard W.M. Jones wrote:
Can we excludearch %{arm} for this one?
Why? It's a bug that it doesn't build on ARM. Refusing to build it
doesn't fix the bug, and then someone else will crash into the same
issue when they dare to build something that needs llvm.
It seems the alternative is hfsplus-tools doesn't work at all for
anyone.
Eh. We're constrained by our own policies here, not by anything
fundamental - LLVM being broken on ARM ought to mean that our ARM
product is worse, not that everything else is dragged down to the same
level.
So .. ExcludeArch %{arm} should be added? I'm not clear what you're
saying here.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 05:23:01PM +0100, Richard W.M. Jones wrote:
On Tue, Jun 10, 2014 at 03:45:57PM +0100, Matthew Garrett wrote:
Eh. We're constrained by our own policies here, not by anything
fundamental - LLVM being broken on ARM ought to mean that our ARM
product is worse, not that everything else is dragged down to the same
level.
So .. ExcludeArch %{arm} should be added? I'm not clear what you're
saying here.
ExcludeArch implies that it's acceptable that it doesn't build on ARM
and removes the incentive for anyone to fix it. It's not.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 06:00:05PM +0100, Matthew Garrett wrote:
On Tue, Jun 10, 2014 at 05:23:01PM +0100, Richard W.M. Jones wrote:
On Tue, Jun 10, 2014 at 03:45:57PM +0100, Matthew Garrett wrote:
Eh. We're constrained by our own policies here, not by anything
fundamental - LLVM being broken on ARM ought to mean that our ARM
product is worse, not that everything else is dragged down to the same
level.
So .. ExcludeArch %{arm} should be added? I'm not clear what you're
saying here.
ExcludeArch implies that it's acceptable that it doesn't build on ARM
and removes the incentive for anyone to fix it. It's not.
There's a process for handling this, which is to create (if required)
a Fedora bug for the package, and then attach it to this tracker:
https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-ARM
Then add ExcludeArch to the package, mentioning the particular bug.
I'm going to go ahead and do this now, since otherwise we won't have
hfsplus-tools at all for any user.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 06:14:03PM +0100, Richard W.M. Jones wrote: On Tue, Jun 10, 2014 at 06:00:05PM +0100, Matthew Garrett wrote: ExcludeArch implies that it's acceptable that it doesn't build on ARM and removes the incentive for anyone to fix it. It's not. There's a process for handling this, which is to create (if required) a Fedora bug for the package, and then attach it to this tracker: https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-ARM Then add ExcludeArch to the package, mentioning the particular bug. I've never seen this actually result in the bug being fixed in leaf packages. I'm going to go ahead and do this now, since otherwise we won't have hfsplus-tools at all for any user. This is inappropriate. The bug is in LLVM, not hfsplus-tools. Quoting from the guidelines: ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture. The code compiles fine, LLVM then fucks up linking. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 06:21:00PM +0100, Matthew Garrett wrote: On Tue, Jun 10, 2014 at 06:14:03PM +0100, Richard W.M. Jones wrote: On Tue, Jun 10, 2014 at 06:00:05PM +0100, Matthew Garrett wrote: ExcludeArch implies that it's acceptable that it doesn't build on ARM and removes the incentive for anyone to fix it. It's not. There's a process for handling this, which is to create (if required) a Fedora bug for the package, and then attach it to this tracker: https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-ARM Then add ExcludeArch to the package, mentioning the particular bug. I've never seen this actually result in the bug being fixed in leaf packages. The bug that I'm actually fixing is that we haven't had a successful hfsplus-tools build in nearly a year. However I think you're quite right that this is unlikely to fix the LLVM on ARM bug. I'm going to go ahead and do this now, since otherwise we won't have hfsplus-tools at all for any user. This is inappropriate. The bug is in LLVM, not hfsplus-tools. Quoting from the guidelines: ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture. The code compiles fine, LLVM then fucks up linking. It didn't even compile for me. The error was: clang -g3 -Wall -fblocks -I/home/rjones/d/fedora/hfsplus-tools/master/diskdev_cmds-540.1.linux3/BlocksRunTime -I/home/rjones/d/fedora/hfsplus-tools/master/diskdev_cmds-540.1.linux3/include -DDEBUG_BUILD=0 -D_FILE_OFFSET_BITS=64 -D LINUX=1 -D BSD=1 -D VERSION=\540.1.linux3\ -c -o runtime.o runtime.c clang: warning: unknown platform, assuming -mfloat-abi=soft In file included from runtime.c:26: In file included from /usr/include/stdio.h:27: In file included from /usr/include/features.h:388: /usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-soft.h' file not found # include gnu/stubs-soft.h ^ 1 error generated. make[1]: *** [runtime.o] Error 1 The relevant bit of the package guidelines is this: If a Fedora package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. which I've now done, and the package is now built in Rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=7033081 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 06:34:31PM +0100, Richard W.M. Jones wrote: The bug that I'm actually fixing is that we haven't had a successful hfsplus-tools build in nearly a year. Ok. Once the build's done let's remove the ExcludeArch so it continues to show up as a failure in mass builds. It can be restored if we actually need to make any code changes. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 06:39:52PM +0100, Matthew Garrett wrote: On Tue, Jun 10, 2014 at 06:34:31PM +0100, Richard W.M. Jones wrote: The bug that I'm actually fixing is that we haven't had a successful hfsplus-tools build in nearly a year. Ok. Once the build's done let's remove the ExcludeArch so it continues to show up as a failure in mass builds. It can be restored if we actually need to make any code changes. Where is the Fedora policy that we should break builds so that we can collectively remember there is a bug in a particular architecture? That's what Bugzilla is for. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 06:44:06PM +0100, Richard W.M. Jones wrote: On Tue, Jun 10, 2014 at 06:39:52PM +0100, Matthew Garrett wrote: Ok. Once the build's done let's remove the ExcludeArch so it continues to show up as a failure in mass builds. It can be restored if we actually need to make any code changes. Where is the Fedora policy that we should break builds so that we can collectively remember there is a bug in a particular architecture? That's what Bugzilla is for. Having it show up on the FTBFS list sparked a discussion that noted upstream movement on this. If it hadn't been there we wouldn't have noticed, and even once LLVM is fixed this would probably have remained ExcludeArch: arm. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 06:53:59PM +0100, Matthew Garrett wrote:
On Tue, Jun 10, 2014 at 06:44:06PM +0100, Richard W.M. Jones wrote:
On Tue, Jun 10, 2014 at 06:39:52PM +0100, Matthew Garrett wrote:
Ok. Once the build's done let's remove the ExcludeArch so it continues
to show up as a failure in mass builds. It can be restored if we
actually need to make any code changes.
Where is the Fedora policy that we should break builds so that we can
collectively remember there is a bug in a particular architecture?
That's what Bugzilla is for.
Having it show up on the FTBFS list sparked a discussion that noted
upstream movement on this. If it hadn't been there we wouldn't have
noticed, and even once LLVM is fixed this would probably have remained
ExcludeArch: arm.
I do think we should have a better way to track bugs in Bugzilla. It
is a place where bugs often go to die, because it lacks any useful
search function or overview mechanism.
In this case however I don't think much productive came from this
discussion we had about hfsplus-tools. Obviously no one wants
hfsplus-tools and/or clang enough on Fedora/ARM that they are prepared
to fix it. So I think we should just drop it on ARM, and let anyone
who wants it, fix it later (or reenable %{arm} if clang gets fixed).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 07:05:56PM +0100, Richard W.M. Jones wrote:
In this case however I don't think much productive came from this
discussion we had about hfsplus-tools. Obviously no one wants
hfsplus-tools and/or clang enough on Fedora/ARM that they are prepared
to fix it. So I think we should just drop it on ARM, and let anyone
who wants it, fix it later (or reenable %{arm} if clang gets fixed).
If the Fedora/ARM community don't care about feature parity with x86,
then we should just drop them back to secondary status.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 07:11:53PM +0100, Matthew Garrett wrote:
On Tue, Jun 10, 2014 at 07:05:56PM +0100, Richard W.M. Jones wrote:
In this case however I don't think much productive came from this
discussion we had about hfsplus-tools. Obviously no one wants
hfsplus-tools and/or clang enough on Fedora/ARM that they are prepared
to fix it. So I think we should just drop it on ARM, and let anyone
who wants it, fix it later (or reenable %{arm} if clang gets fixed).
If the Fedora/ARM community don't care about feature parity with x86,
then we should just drop them back to secondary status.
That was overly critical of me and did nothing to actually further the
discussion. I apologise.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tue, Jun 10, 2014 at 18:34:31 +0100, Richard W.M. Jones rjo...@redhat.com wrote: The relevant bit of the package guidelines is this: If a Fedora package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. Do these bugs need to stay open? I have a couple of things that are exclude arch because they require kernel modules that aren't built for arm. I'm not expecting that to change ever in one case and probably not in the next few years (if ever) for the other case. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
Matthew Garrett wrote: Eh. We're constrained by our own policies here, not by anything fundamental - LLVM being broken on ARM ought to mean that our ARM product is worse, not that everything else is dragged down to the same level. Didn't YOU vote for ARM as a primary architecture, and even actively lobby for it? Now you get to pick the (poisoned) fruit… This nonsense is exactly what primary architecture means. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
Matthew Garrett wrote: On Tue, Jun 10, 2014 at 07:11:53PM +0100, Matthew Garrett wrote: If the Fedora/ARM community don't care about feature parity with x86, then we should just drop them back to secondary status. +1, and: That was overly critical of me and did nothing to actually further the discussion. I apologise. No need to apologize! It's just the truth: ARM is not ready to be a primary architecture, and might not even be for years to come. (Just look at build times, which are still 2+ times slower than x86, entirely unacceptable! All my builds are always blocking on ARM slowness now.) It should never have been made primary in the first place, and this ought to be fixed ASAP. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Wed, Jun 11, 2014 at 02:00:13AM +0200, Kevin Kofler wrote: That was overly critical of me and did nothing to actually further the discussion. I apologise. No need to apologize! It's just the truth: ARM is not ready to be a primary Kevin, I disagree. A positive tone to discussion is important even when speaking the truth. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Wed, Jun 11, 2014 at 01:53:12AM +0200, Kevin Kofler wrote: Matthew Garrett wrote: Eh. We're constrained by our own policies here, not by anything fundamental - LLVM being broken on ARM ought to mean that our ARM product is worse, not that everything else is dragged down to the same level. Didn't YOU vote for ARM as a primary architecture, and even actively lobby for it? Now you get to pick the (poisoned) fruit… Er. No? I think you're confusing me with someone else. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On 06/11/2014 02:08 AM, Matthew Miller wrote: On Wed, Jun 11, 2014 at 02:00:13AM +0200, Kevin Kofler wrote: That was overly critical of me and did nothing to actually further the discussion. I apologise. No need to apologize! It's just the truth: ARM is not ready to be a primary Kevin, I disagree. A positive tone to discussion is important even when speaking the truth. Matthew, in this case, I concur with Kevin. The facts are obvious and because of this obviousness, the tone should not matter at all, IMO. It's time to *openly* discuss and to *seriously question* the arm's position in Fedora, even though such a discussion and/or the outcome should show to be unpleasant and/or undesired to some people/entities and their plans/interests. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
Dne 1.6.2014 11:24, Till Maas napsal(a): The following packages did not build for two releases (no new build since 2013-07-25) and will be retired when Fedora (F21) is branched, unless someone successfully builds them till then. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life According to https://fedoraproject.org/wiki/Schedule branching will occur not earlier than 2015-07-08. The packages will be retired shortly before. Package(co)maintainers === rubygem-audited-activerecord vondruch, vondruch Upstream is probably dead and have not provided support for RoR 4.x yet. It will be better if the package will be retired. rubygem-heroku vondruch, jstribny, vondruch Working on this right now. I hope I'll be able to build all dependencies prior the package gets retired. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Sun, Jun 01, 2014 at 11:24:09AM +0200, Till Maas wrote: hfsplus-toolsajax, ajax Just to be clear, is hfsplus-tools still at risk of being removed or not? I notice there has not been a successful build since 2013-06-12 (approximately 1 year ago). libguestfs uses hfsplus-tools in order to provide some HFS+ filesystem features (mainly for Mac filesystems and .DMG files). We can remove this functionality from the Fedora version, but of course it means people won't be able to perform some operations on Mac filesystems. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Sun, Jun 08, 2014 at 09:18:12PM -0500, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 9 Jun 2014 00:01:34 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: On Monday, June 2, 2014, 2:53:33 PM, Till Mass wrote: On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: On Sun, 1 Jun 2014 11:24:09 +0200 Till Maas opensou...@till.name wrote: yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji Actually according to Dennis this is a ppc32 package that can be retired, because ppc32 support is being dropped. Till, Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. Plus yaboot is still needed to boot ppc64 Macs, even on F20/F21. no it doesn't that part of why ppc is no longer built at all. f20 uses yaboot for dvd and grub2 for the installed system, f21 is using grub2 everywhere. I have a Fedora 20 ppc64 Mac right next to my feet here that is definitely booting using yaboot. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 9 Jun 2014 00:01:34 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: On Monday, June 2, 2014, 2:53:33 PM, Till Mass wrote: On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: On Sun, 1 Jun 2014 11:24:09 +0200 Till Maas opensou...@till.name wrote: yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji Actually according to Dennis this is a ppc32 package that can be retired, because ppc32 support is being dropped. Till, Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. Plus yaboot is still needed to boot ppc64 Macs, even on F20/F21. no it doesn't that part of why ppc is no longer built at all. f20 uses yaboot for dvd and grub2 for the installed system, f21 is using grub2 everywhere. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTlRkhAAoJEH7ltONmPFDRj0sQAJx47oFGw8WFmddl55Q8u/sm EhD9xtZlKLorIhH81iYWO9gWgDUVwiZjfTKuo5QUcFNoNKtoslJlhIaZFIFStBAl phbkd0tJagUC9/QVHeMYnTvi3AjSHtom+jVK2e4KnsA4wrnHWbPlI3TiRY4lQ7Jx cKENNX35x8fhh9nu6o+8P4WafySz6ZRtGe+u2QbnZ5qc0zDrB8EFmiQiggkIs55t s/i1VEvhGC+PNQxf86xpPMBfCUVeGZ+ww5XRe/3ypnijTH/OPYDjiKGJnk8zSNYF Bgd12W4mR1AjPyiBVjL4Wg0r8N9u/Cl+sf99L2S4Hg8uqBXlQHAXWTMOCxCV78pl FuJdjDSyU42G/RCvQETV6cb2maVY8HiR1xCJOaHD7Md1ggqSdi2/G+mktnXBueWc MBSD2Ix/uVBsEaghd+ag8zohGY/imXNkSg1vjPeZVZuC2eb1oSQbYk2mqOhQ5Z4B /yHjZ3Bzkhvx0yxcCfyYbtfm4o/K6nsLTgKj+u6LGhM0Kng4UxWtLYuNO/TTBDjs Gt4QBrK3nGcKQ2Upl19N/dOUOOpy93DsYj/wUR7EbAj1+EVUhZ+MwFK2b+zWKDGW t5OvzOYWMA4GRwdyPx4ugadC5xUUZb0Pamqc3jNvNUJdtlQkrHhAb1lsO+BNtQP+ e7+qJRgeXnBW+zqFvGx2 =1LGo -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Monday, June 9, 2014, 12:08:13 PM, Richard Jones wrote: On Sun, Jun 08, 2014 at 09:18:12PM -0500, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 9 Jun 2014 00:01:34 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: On Monday, June 2, 2014, 2:53:33 PM, Till Mass wrote: On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: On Sun, 1 Jun 2014 11:24:09 +0200 Till Maas opensou...@till.name wrote: yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji Actually according to Dennis this is a ppc32 package that can be retired, because ppc32 support is being dropped. Till, Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. Plus yaboot is still needed to boot ppc64 Macs, even on F20/F21. no it doesn't that part of why ppc is no longer built at all. f20 uses yaboot for dvd and grub2 for the installed system, f21 is using grub2 everywhere. I have a Fedora 20 ppc64 Mac right next to my feet here that is definitely booting using yaboot. Rich. The intent appears to have been to eliminate yaboot for F20 ppc64, but the implementation did not go smoothly. There were residual references to yaboot in the configuration created by Anaconda, that can even leave the resulting system in limbo. See https://bugzilla.redhat.com/show_bug.cgi?id=876625 and https://bugzilla.redhat.com/show_bug.cgi?id=1020112 I've had no luck getting a PowerMac G5 (Radeon 9600) install to complete with either F20 ppc DVD or Netboot, or the RHEL7 ppc64 RC. This makes looking at problems like the FTBFS for hfsplus-tools a tad problematic. I'd really like to get a local working Rawhide Live-DVD build running, since there are no current ppc64 (or ppc) Live-DVD spins or updated F20 install media. Al -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, 2014-06-09 at 17:07 +0100, Richard W.M. Jones wrote: On Sun, Jun 01, 2014 at 11:24:09AM +0200, Till Maas wrote: hfsplus-toolsajax, ajax Just to be clear, is hfsplus-tools still at risk of being removed or not? I notice there has not been a successful build since 2013-06-12 (approximately 1 year ago). The reason it doesn't build is that hfsplus-tools requires clang to build these days (sigh), and on arm the floating-point ABI logic in clang is apparently a mismatch with how Fedora does things, such that you don't find the right headers and then things go boom. There's been some attempts to address this but none of them seem to have worked. There's been a bug open about this for rather a long time now: https://bugzilla.redhat.com/show_bug.cgi?id=803433 And upstream: http://llvm.org/bugs/show_bug.cgi?id=15557 libguestfs uses hfsplus-tools in order to provide some HFS+ filesystem features (mainly for Mac filesystems and .DMG files). We can remove this functionality from the Fedora version, but of course it means people won't be able to perform some operations on Mac filesystems. Yeah, I'd prefer if we didn't retire hfsplus-tools too. It'd be nice if this got some attention from the arm guys, I tried to force llvm to default to hard-float in 3.4-8 but it doesn't seem to have been enough to fix this. I can keep poking at it but I'm assuredly not the best man for the job. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 09, 2014 at 05:07:14PM +0100, Richard W.M. Jones wrote: On Sun, Jun 01, 2014 at 11:24:09AM +0200, Till Maas wrote: hfsplus-toolsajax, ajax Just to be clear, is hfsplus-tools still at risk of being removed or not? It's required in order to build x86 install images, so not really. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 09, 2014 at 02:18:11PM -0400, Adam Jackson wrote:
On Mon, 2014-06-09 at 17:07 +0100, Richard W.M. Jones wrote:
On Sun, Jun 01, 2014 at 11:24:09AM +0200, Till Maas wrote:
hfsplus-toolsajax, ajax
Just to be clear, is hfsplus-tools still at risk of being removed or not?
I notice there has not been a successful build since 2013-06-12
(approximately 1 year ago).
The reason it doesn't build is that hfsplus-tools requires clang to
build these days (sigh), and on arm the floating-point ABI logic in
clang is apparently a mismatch with how Fedora does things, such that
you don't find the right headers and then things go boom. There's been
some attempts to address this but none of them seem to have worked.
There's been a bug open about this for rather a long time now:
https://bugzilla.redhat.com/show_bug.cgi?id=803433
And upstream:
http://llvm.org/bugs/show_bug.cgi?id=15557
OK, I can definitely reproduce the same problem on my 32 bit ARM
server running F20.
I tried several iterations of setting CFLAGS, but I could not fix the
problem either.
Can we excludearch %{arm} for this one?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 9 Jun 2014 17:08:13 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Sun, Jun 08, 2014 at 09:18:12PM -0500, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 9 Jun 2014 00:01:34 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: On Monday, June 2, 2014, 2:53:33 PM, Till Mass wrote: On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: On Sun, 1 Jun 2014 11:24:09 +0200 Till Maas opensou...@till.name wrote: yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji Actually according to Dennis this is a ppc32 package that can be retired, because ppc32 support is being dropped. Till, Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. Plus yaboot is still needed to boot ppc64 Macs, even on F20/F21. no it doesn't that part of why ppc is no longer built at all. f20 uses yaboot for dvd and grub2 for the installed system, f21 is using grub2 everywhere. I have a Fedora 20 ppc64 Mac right next to my feet here that is definitely booting using yaboot. Then you did not install using Fedora 20. the ppc team has dropped all 32 bit support. yaboot has only ever been built as a 32 bit app. they are the ones that chose to have it go away. They are the ones that made the decision to no longer support yaboot and worked to make grub2 its replacement. likely to move to grub2 you will need to manually set it up. but it really is not a viable bootloader for ppc64 anymore. no amount of disagreement will change that fact. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTlgmRAAoJEH7ltONmPFDRovoP/1q7Fq3v7V2jRULaD1jYDP4w ObmCx05Mht7kA+d8oDMUuMJW53JxSpSzY0CT79t9GWZqys8dNmeH9vE5Af7DGuUG pRIjj5ohR/R86EVP7qQYvpJCDUZ/iKVepssJLWuEJJCTBo7c0X/T+kknKiq6Vm56 pu7HeITtsv58309qV8vbNaa7n4UAtbojBMK06yxnk2wBtHAuTNBOBKyx8TohOWr2 Gh0kb8TRdW5g01ARfI1YrFVpFJRhbAwBN70GwHPFdfHIbynGfK4nnMr7/nLm4Zg7 4kXvKfwMGkHmA1BN9+q3kWqS038XmViWfTc0Ui1f9aCC5NRdPj1lJpl0ks8d9TE7 hL4sfYp4UA5YhoK/68Q4NUdqZXhj+j1cR6OZ7pmcTIsKthc6RMlWa+Li9QbXhwY0 nn9ar7DfOOaeHwbMmWxRyO5ySNneaSxvkMyJo6WcKhO5+IXRIOjTziEOmWtw2L2M tMwQ3FKBlkhCWYSI42niaXfSH2RNFQzWQNL1xEoCvypPOWiC+pFPa/b23wLv/Kte G/7kGgyyeoTolwT3KpudqFJa42JIOdaZQU8uSOxbO2jTVwfvCo5HKtu10RgeizqB 8j/UbBk81E885bCmAUhC27lxpBxRvX1f49dBtBE2/lJx5hENtr9NyEVsqSpHXdVY UY1xz10TlE6IqXyKDL3G =xHnz -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 09, 2014 at 08:43:07PM +0100, Richard W.M. Jones wrote:
Can we excludearch %{arm} for this one?
Why? It's a bug that it doesn't build on ARM. Refusing to build it
doesn't fix the bug, and then someone else will crash into the same
issue when they dare to build something that needs llvm.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: On Monday, June 2, 2014, 2:53:33 PM, Till Mass wrote: On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: On Sun, 1 Jun 2014 11:24:09 +0200 Till Maas opensou...@till.name wrote: yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji Actually according to Dennis this is a ppc32 package that can be retired, because ppc32 support is being dropped. Till, Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. Plus yaboot is still needed to boot ppc64 Macs, even on F20/F21. Rich. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 9 Jun 2014 00:01:34 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: On Monday, June 2, 2014, 2:53:33 PM, Till Mass wrote: On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: On Sun, 1 Jun 2014 11:24:09 +0200 Till Maas opensou...@till.name wrote: yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji Actually according to Dennis this is a ppc32 package that can be retired, because ppc32 support is being dropped. Till, Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. Plus yaboot is still needed to boot ppc64 Macs, even on F20/F21. no it doesn't that part of why ppc is no longer built at all. f20 uses yaboot for dvd and grub2 for the installed system, f21 is using grub2 everywhere. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTlRlkAAoJEH7ltONmPFDRkXAQAI3WLyXqOvIEbQycCmPJI4BS kil882vSjlqcQN4QGGLvqBwjI2LB/hiD0r3svzWWdCoQDj5EQgzA2rMfh+QWiKxD 9H+puoycDiNBmUK9pFvXrSnv1/Q5bs+NuXcp64DLPZXHSeVpDhNeTTU7unN5kgwU hWblqZ8/pLxLLSz1CPgzSttEcGtMYvasGVTvkhoZPkECp7kZt3ojXV3sChl8AA9U /ZS94/IHnkcFt1CsbtAZ5MlO14T03xXA8hVvUaPKHN9IE9/N71Od9o7mv8eLsK70 z5HvAYNUg94epo1+WXDESsYZ8kJZhaV6ykys2n0hlm3OGSjGvbyYHZ5DJX9u9yGw vrXZYAy6PCs88kq3eI29i+xQxMXbaN+XaMiIbshTTpWj++hVN9F6sVSlVPhV/acy FmBHcEAjJGi3cTBcDJ+l4wki6OIULcmTtQXg7cO+r6pyVPEwU9CAFE9EJKZURChj H+K3Fw/KiVSUlKWThNw8oXaeq0W0El7af13+NiM2KJbkd5fgReWKtYY2kuq3VJ/9 i8rcTSL2d4alZYbcnBXmOaDja5qSsU6R2yF4l88pPwPN17/6XtlWafvvzgVwWZDW ilCrNWxOM1bpPWkdLPvSuAF0hnyyQGIa9Bip6wlXSL7TPKeplsWKgScxHSOU3zrH uLH58ShkSrByIt+XkF+f =nDww -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
Till Maas wrote: The following packages did not build for two releases (no new build since 2013-07-25) and will be retired when Fedora (F21) is branched, unless someone successfully builds them till then. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life According to https://fedoraproject.org/wiki/Schedule branching will occur not earlier than 2015-07-08. The packages will be retired shortly before. Package(co)maintainers === [...] keybinderhannes, hannes fixed in rawhide and f20 [...] The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its trac instance: https://fedorahosted.org/rel-eng/ The sources of this script can be found at: https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orphans.py -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 02, 2014 at 09:42:02PM -0400, Rahul Sundaram wrote: Hi On Mon, Jun 2, 2014 at 5:57 PM, Till Maas wrote: gdome2 sundaram I have retired this already. What more should I do? You need to retire it in pkgdb. Btw. the retiring reason could be improved in the dead.package file. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, 2 Jun 2014 23:54:10 +0200 Till Maas opensou...@till.name wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. ok, but I guess there is no package left that is not properly configured in primary koji. If you continue with this effort, please re-open the rel-eng ticket in my other e-mail regarding yaboot. In the past it wasn't possible to block secondary arch only package in primary koji after it was introduced there, because during some releng action (branching, mass rebuild?) it affected also the secondary koji. Or pkgdb, maybe both. The result was that secondary arch only package was not accessible for commits and blocked in secondary koji and we had to resolve it manually with dgilmore. So please be careful. I think the problem was that pkgdb had no information about arches, it worked globally. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On 06/01/2014 05:24 AM, Till Maas wrote: R-bigmemory spot, spot RETIRED log4net spot, cicku, spot Fixed and built in rawhide: log4net-1.2.13-1.fc21 netgospot, spot RETIRED rpc2 spot, nhorman, spot Fixed and built in rawhide: rpc2-2.10-9.fc21 tkimgspot, spot Fixed and built in rawhide (I hate this package so much, it is the definition of crufty): tkimg-1.4-16.fc21 xsupplicant spot, spot Fixed and built in rawhide: xsupplicant-2.2.0-8.fc21 ~tom == ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸(((º OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal attachment: tcallawa.vcf-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tuesday, June 3, 2014, 2:37:49 AM, Dan Horák wrote: On Mon, 2 Jun 2014 23:54:10 +0200 Till Maas opensou...@till.name wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. ok, but I guess there is no package left that is not properly configured in primary koji. If you continue with this effort, please re-open the rel-eng ticket in my other e-mail regarding yaboot. In the past it wasn't possible to block secondary arch only package in primary koji after it was introduced there, because during some releng action (branching, mass rebuild?) it affected also the secondary koji. Or pkgdb, maybe both. The result was that secondary arch only package was not accessible for commits and blocked in secondary koji and we had to resolve it manually with dgilmore. So please be careful. I think the problem was that pkgdb had no information about arches, it worked globally. Thanks for the heads-up! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Sun, 1 Jun 2014 11:24:09 +0200 Till Maas opensou...@till.name wrote: The following packages did not build for two releases (no new build since 2013-07-25) and will be retired when Fedora (F21) is branched, unless someone successfully builds them till then. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life According to https://fedoraproject.org/wiki/Schedule branching will occur not earlier than 2015-07-08. The packages will be retired shortly before. Package (co)maintainers === yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji This needs special attention from Dennis: https://fedorahosted.org/rel-eng/ticket/5729 Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: On Sun, 1 Jun 2014 11:24:09 +0200 Till Maas opensou...@till.name wrote: yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji Actually according to Dennis this is a ppc32 package that can be retired, because ppc32 support is being dropped. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Monday, June 2, 2014, 2:53:33 PM, Till Mass wrote: On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: On Sun, 1 Jun 2014 11:24:09 +0200 Till Maas opensou...@till.name wrote: yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji Actually according to Dennis this is a ppc32 package that can be retired, because ppc32 support is being dropped. Till, Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. ok, but I guess there is no package left that is not properly configured in primary koji. If you continue with this effort, please re-open the rel-eng ticket in my other e-mail regarding yaboot. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Sun, Jun 01, 2014 at 12:56:58PM +0200, Till Maas wrote: On Sun, Jun 01, 2014 at 11:24:09AM +0200, Till Maas wrote: The following packages did not build for two releases (no new build since 2013-07-25) and will be retired when Fedora (F21) is branched, I might have used the wrong date, probably it should be 2013-02-12. I will create an updated list after I found the time. Here is an updated list, but there might be some errors left: Package(co)maintainers === IBSimu stevetraylen NearTree tmatsuu alliance chitlesh, tnorth bio2jack dtimms bitbake ixs blktap ke4qqq clearlooks-compact-gnome-theme cwickert, lkundrak drwright caillon freetalk orphan, rishi fuse-smb szpak g-wrap laxathom gdome2 sundaram guile-liblaxathom kannel thias, cicku, linuxthomass kguitar davidcornette libannodex thomasvs libopensync-plugin-opie awjb minbar izhar, hicham mozilla-firetray hicham pp3 mmahut proxyknife rishi python-gudev orphan, aledvink, sochotni rats smilner, rmonk verbiste icon wine-docsawjb yaboot dwmw2, fkocina, hegdevasant, jcajka, karsten, pnasrat, tbreeds zikula ke4qqq, pfrields The following packages require above mentioned packages: Depending on: NearTree rasmol (maintained by: krege) rasmol-2.7.5.2-2.fc21.i686 requires libCNearTree.so.5 rasmol-2.7.5.2-2.fc21.src requires NearTree-devel = 3.1.1-4.fc18 rasmol-gtk-2.7.5.2-2.fc21.i686 requires libCNearTree.so.5 Depending on: alliance pharosc (maintained by: chitlesh) pharosc-alliance-8.3-8.fc20.noarch requires alliance = 5.0-35.20090901snap.fc18 Depending on: bio2jack k3guitune (maintained by: dtimms) k3guitune-1.01-11.fc20.i686 requires libbio2jack.so.0 k3guitune-1.01-11.fc20.src requires bio2jack-devel = 0.9-8.fc18 Depending on: guile-lib coot (maintained by: timfenn) coot-0.7.2-1.fc21.src requires guile-lib = 0.1.6-5.fc18 Depending on: libannodex mod_annodex (maintained by: thomasvs) mod_annodex-0.2.2-20.fc21.i686 requires libannodex.so.0 mod_annodex-0.2.2-20.fc21.src requires libannodex-devel = 0.7.3-17.fc18 Depending on: python-gudev rhn-client-tools (maintained by: msuchy, mzazrive) rhn-client-tools-2.1.16-1.fc21.noarch requires python-gudev = 147.2-3.fc18 rhn-check-2.1.16-1.fc21.noarch requires yum-rhn-plugin = 2.1.7-1.fc21 rhn-setup-2.1.16-1.fc21.noarch requires rhnsd = 5.0.14-1.fc21 rhncfg (maintained by: msuchy, mzazrive) rhncfg-5.10.65-1.fc21.noarch requires rhn-client-tools = 2.1.16-1.fc21 rhnpush (maintained by: msuchy, mzazrive) rhnpush-5.5.65-2.fc20.noarch requires rhn-client-tools = 2.1.16-1.fc21 rhnpush-5.5.65-2.fc20.src requires rhn-client-tools = 2.1.16-1.fc21 rhnsd (maintained by: msuchy, mzazrive) rhnsd-5.0.14-1.fc21.i686 requires rhn-check = 2.1.16-1.fc21 spacewalk-certs-tools (maintained by: msuchy) spacewalk-certs-tools-2.1.6-1.fc21.noarch requires rhn-client-tools = 2.1.16-1.fc21 spacewalk-koan (maintained by: msuchy) spacewalk-koan-2.1.4-1.fc21.noarch requires rhn-check = 2.1.16-1.fc21
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Monday, June 2, 2014, 5:54:10 PM, Till Mass wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. ok, but I guess there is no package left that is not properly configured in primary koji. If you continue with this effort, please re-open the rel-eng ticket in my other e-mail regarding yaboot. Thanks - will do. The intent is to switch ppc32 over to grub2 once basic install is operational. F20 ppc64 GA made the switch, but it was not without trials - see https://bugzilla.redhat.com/show_bug.cgi?id=1020112 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
Hi On Mon, Jun 2, 2014 at 5:57 PM, Till Maas wrote: gdome2 sundaram I have retired this already. What more should I do? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Sun, Jun 01, 2014 at 11:24:09AM +0200, Till Maas wrote: The following packages did not build for two releases (no new build since 2013-07-25) and will be retired when Fedora (F21) is branched, I might have used the wrong date, probably it should be 2013-02-12. I will create an updated list after I found the time. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Sun, 1 Jun 2014 11:24:09 +0200, Till Maas wrote: The following packages did not build for two releases (no new build since 2013-07-25) and will be retired when Fedora (F21) is branched, unless someone successfully builds them till then. rss2emailmschwendt, mcepl, mschwendt That is inaccurate. The F21 mass-rebuild has been announced to start on 2014-06-06, so that should be early enough for rss2email. The package has been successfully (mass-)rebuilt for F17 to F19, but there has not been such a mass-rebuild for F20, so that is why there has not been a package with a .fc20 dist tag. According to https://fedoraproject.org/wiki/Schedule branching will occur not earlier than 2015-07-08. The packages will be retired shortly before. 2015 or 2014? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Sun, Jun 01, 2014 at 03:33:28PM +0200, Michael Schwendt wrote: rss2emailmschwendt, mcepl, mschwendt That is inaccurate. No, it is not. The F21 mass-rebuild has been announced to start on 2014-06-06, so that should be early enough for rss2email. Branching is after the mass rebuild, so if rss2email will build in the mass rebuild, nothing will happen to it. The package has been successfully (mass-)rebuilt for F17 to F19, but there has not been such a mass-rebuild for F20, so that is why there has not been a package with a .fc20 dist tag. According to rss2email's SPEC changelog Release Engineering tried to build it for a Fedora 20 mass rebuild on 2013-08-04. Also it just failed in a scratch build due to a missing patch: https://kojipkgs.fedoraproject.org//work/tasks/6180/6916180/build.log Also FYI: It contains a changelog from you about a lot of updated patches including the missing one, that was never successfully built. According to https://fedoraproject.org/wiki/Schedule branching will occur not earlier than 2015-07-08. The packages will be retired shortly before. 2015 or 2014? Thank you, fixed. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Sun, Jun 01, 2014 at 07:28:38PM +0200, Till Maas wrote: Branching is after the mass rebuild, so if rss2email will build in the mass rebuild, nothing will happen to it. Also nothing will happen to it if it keeps failing, because I written in my other mail, the cut-off date is earlier, therefore it is allow to stay broken for another cycle. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Sun, 1 Jun 2014 19:28:38 +0200, Till Maas wrote: On Sun, Jun 01, 2014 at 03:33:28PM +0200, Michael Schwendt wrote: rss2emailmschwendt, mcepl, mschwendt That is inaccurate. No, it is not. The F21 mass-rebuild has been announced to start on 2014-06-06, so that should be early enough for rss2email. Branching is after the mass rebuild, so if rss2email will build in the mass rebuild, nothing will happen to it. The package has been successfully (mass-)rebuilt for F17 to F19, but there has not been such a mass-rebuild for F20, so that is why there has not been a package with a .fc20 dist tag. According to rss2email's SPEC changelog Release Engineering tried to build it for a Fedora 20 mass rebuild on 2013-08-04. A pity that failed build job is not listed in koji: http://koji.fedoraproject.org/koji/packageinfo?packageID=3754 Also it just failed in a scratch build due to a missing patch: https://kojipkgs.fedoraproject.org//work/tasks/6180/6916180/build.log Thanks for the investigation. Fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
Hi On Sun, Jun 1, 2014 at 5:24 AM, Till Maas wrote: The following packages did not build for two releases sundaram: transmission-remote-cli, gdome2 I have retired gdome2 as upstream has been dead for a long time and I don't think there is any dependency on this. I have updated transmission-remote-cli to the latest upstream revision. Thanks Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
