Re: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Christopher Meng]

I just want to ask here, why did you retire the pywcs and considered
it as dead upstream whereas pypi pywcs has a new release in the
February?

And now APLpy is broken.
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Sergio Pascual]

Hello

2014-07-21 10:59 GMT+02:00 Christopher Meng cicku...@gmail.com:

 I just want to ask here, why did you retire the pywcs and considered
 it as dead upstream whereas pypi pywcs has a new release in the
 February?


The functionallity of pywcs is now in astropy, is where active development
is happening. The API is the same. Sometimes the developers backport the
code to pywcs, but is a dead end.


 And now APLpy is broken.


I contacted the maintainer before the change and he agreed to update to
APLpy 0.9.11 that uses astropy instead of pywcs. He hasn't updated yet.

https://bugzilla.redhat.com/show_bug.cgi?id=1116895

In this report there is a new specfile for APLpy 0.9.11. I would have
updated myself but I'm not a proven packager.

Regards



 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

I'll take tinyca2 (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21 v3)

[Peter Hanecak]

Hello,

I would like to take over tinyca2.

I do not see anywhere on the list why the maintainers left it. So I'll
check the procedures and also other sources and take it.

According to Koji[1], some F21 build was successful last month so
hopefully there wont be many difficulties.

Sincerely

Peter

[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=536751


On 06/24/2014 10:12 PM, Till Maas wrote:
 The following packages are orphaned or did not build for two
 releases and will be retired when Fedora (F21) is branched, unless someone
 adopts them. 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 2014-07-08 (this is in *two* weeks). The packages
 will be retired shortly before.
 
 Note: If you received this mail directly you (co)maintain one of the affected
 packages or a package that depends on one.
 
   Package(co)maintainers
 ===
 NearTree   tmatsuu  
 SOAPpy orphan, pingou   
 SteGUI orphan, pingou   
 aeolus-configure   orphan, clalance, jeckersb, mmorsi,  
slinabery
 aleorphan, silfreed 
 alliance   chitlesh, tnorth 
 barry  orphan, gnat, vicodan
 bitbakeixs  
 blktap ke4qqq   
 cbmc   orphan, shakthimaan  
 cgnsliborphan, chitlesh 
 clutter-gtkmm  orphan, rhl  
 cx18-firmware  orphan, athimm   
 dee-qt orphan, jreznik  
 drwright   caillon  
 eclipse-cmakeedorphan, swagiaal 
 emacs-common-muse  orphan   
 emacs-identica-modeorphan, shakthimaan  
 eqntottorphan, chitlesh 
 espresso-aborphan, chitlesh 
 fprint_demoorphan, pingou   
 freetalk   orphan, rishi
 fuse-smb   szpak
 g-wrap laxathom 
 gdome2 orphan, sundaram 
 ghc-chalmers-lava2000  orphan, chitlesh 
 ghemical   orphan, tolland  
 gnome-shell-theme-elementary   orphan, eldermarco   
 gnomeradio orphan, itamarjp, roma   
 guile-lib  laxathom 
 ha-jdbcorphan   
 hdrpreporphan, silfreed 
 jbosscache-support orphan, arg  
 jbrout orphan   
 jchartsorphan   
 jdbm   orphan   
 jgroups212 orphan, arg  
 kannel thias, cicku, linuxthomass   
 libghemicalorphan   
 liboglappthorphan   
 minbar izhar, hicham
 mopac7 orphan   
 mozilla-firetray   hicham   
 mpqc   orphan   
 mule   orphan   
 nagios-plugins-check_sip   orphan   
 nesc   orphan, chitlesh 
 netatalk   orphan, fkocina  

Re: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Till Maas]

On Wed, Jul 02, 2014 at 12:38:10AM +0200, Sergio Pascual wrote:
 I thought I had retired correctly pywcs, but is not in the list. Did I miss
 some step?

The list contains only packages I am going to retire unless they are
taken care of. So if you retired a package, it is expected that the
package is not on the list. If you have further questions, be welcome to
ask.

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: I'll take tinyca2 (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21 v3)

[Paul Wouters]

On Wed, 2 Jul 2014, Peter Hanecak wrote:



I would like to take over tinyca2.

I do not see anywhere on the list why the maintainers left it. So I'll
check the procedures and also other sources and take it.

According to Koji[1], some F21 build was successful last month so
hopefully there wont be many difficulties.


huh? I re-instated tinyca2 a few months ago and am the active
maintainer? I see you grabbed ACLs, so now you are co-maintainer
whether you like it or not :)

Paul
--
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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Till Maas]

On Fri, Jun 27, 2014 at 06:28:58PM -0500, Yaakov Selkowitz wrote:

 alliance   chitlesh, tnorth
 
 https://bugzilla.redhat.com/show_bug.cgi?id=1105945

I applied your patch but then noticed that the version is also three
years behind upstream, therefore I am not convinced it is a good idea to
keep the package in Fedora without a proper maintainer. Does anyone want
to maintain it?

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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Christopher Meng]

On Wed, Jul 2, 2014 at 12:24 AM, Till Maas opensou...@till.name wrote:
 On Fri, Jun 27, 2014 at 06:28:58PM -0500, Yaakov Selkowitz wrote:

 alliance   chitlesh, tnorth

 https://bugzilla.redhat.com/show_bug.cgi?id=1105945

 I applied your patch but then noticed that the version is also three
 years behind upstream, therefore I am not convinced it is a good idea to
 keep the package in Fedora without a proper maintainer. Does anyone want
 to maintain it?

Hand it over to me.
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Till Maas]

On Wed, Jul 02, 2014 at 12:47:57AM +0800, Christopher Meng wrote:
 On Wed, Jul 2, 2014 at 12:24 AM, Till Maas opensou...@till.name wrote:
  On Fri, Jun 27, 2014 at 06:28:58PM -0500, Yaakov Selkowitz wrote:
 
  alliance   chitlesh, tnorth
 
  https://bugzilla.redhat.com/show_bug.cgi?id=1105945
 
  I applied your patch but then noticed that the version is also three
  years behind upstream, therefore I am not convinced it is a good idea to
  keep the package in Fedora without a proper maintainer. Does anyone want
  to maintain it?
 
 Hand it over to me.

done

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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Yaakov Selkowitz]

On 2014-06-24 15:12, Till Maas wrote:

The following packages are orphaned or did not build for two
releases and will be retired when Fedora (F21) is branched, unless someone
adopts them.


More patches:


alliance   chitlesh, tnorth


https://bugzilla.redhat.com/show_bug.cgi?id=1105945


fuse-smb   szpak


https://bugzilla.redhat.com/show_bug.cgi?id=1106309


Yaakov Selkowitz

--
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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Dmitrij S. Kryzhevich]

 On Wed, Jun 25, 2014 at 10:31:18AM +0700, Dmitrij S. Kryzhevich wrote:
 Package(co)maintainers
   
   
   ===
   NearTree   tmatsuu
   
   The following packages require above mentioned packages:
   Depending on: NearTree
   
 rasmol (maintained by: krege)
 
 rasmol-2.7.5.2-3.fc21.i686 requires libCNearTree.so.5
 rasmol-2.7.5.2-3.fc21.src requires NearTree-devel = 3.1.1-4.fc18
 rasmol-gtk-2.7.5.2-3.fc21.i686 requires libCNearTree.so.5
  
  Hi!
  I tried to contact tmatsuu but failed. I did an admin request in PkgDB for
  NearTree[1], what could I do else?
  
  [1] https://admin.fedoraproject.org/pkgdb/package/NearTree/
 
 Maybe worth asking for commit rights as well.
 
 Pierre

Admin rights would grant the posibility to add me into acl commit list by 
myself.
Anyway, done.
Anyway-2, as tmatsuu still unreacheble, what could I do else?

Dmitrij.

-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Christopher Meng]

I'd like to claim the ownership of blktap and alliance.

What should I do next? DIrectly request the ACL via bugzilla?

Thanks.
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Jerry James]

On Tue, Jun 24, 2014 at 2:12 PM, Till Maas opensou...@till.name wrote:
 cbmc   orphan, shakthimaan

I have taken this package.
-- 
Jerry James
http://www.jamezone.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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Yaakov Selkowitz]

On 2014-06-24 15:12, Till Maas wrote:

The following packages are orphaned or did not build for two
releases and will be retired when Fedora (F21) is branched, unless someone
adopts them.


I have posted patches for a few of these (some before I realized they 
were orphaned), should anyone want them:



drwright   caillon


https://bugzilla.redhat.com/show_bug.cgi?id=1106182


mpqc   orphan


https://bugzilla.redhat.com/show_bug.cgi?id=1106244


piccolo2d  orphan, akurtakov


https://bugzilla.redhat.com/show_bug.cgi?id=1106627


umlgraph   orphan, fabiand


https://bugzilla.redhat.com/show_bug.cgi?id=1107031


Yaakov Selkowitz

--
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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Till Maas]

On Tue, Jun 24, 2014 at 10:12:11PM +0200, Till Maas wrote:

 Depending on: jbosscache-support
   hibernate3 (maintained by: gil, jhernand, msrb)
   hibernate3-3.6.10-14.fc21.src requires jbosscache-common-parent 
 = 1.6-8.fc21
   hibernate3-jbosscache-3.6.10-14.fc21.noarch requires 
 mvn(org.jboss.cache:jbosscache-core) = ${jbosscache-core-version}

^^
it seems that something is wrong with the dependency generation for
hibernate3.
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Dmitrij S. Kryzhevich]

   Package(co)maintainers
 ===
 NearTree   tmatsuu
 
 The following packages require above mentioned packages:
 Depending on: NearTree
   rasmol (maintained by: krege)
   rasmol-2.7.5.2-3.fc21.i686 requires libCNearTree.so.5
   rasmol-2.7.5.2-3.fc21.src requires NearTree-devel = 3.1.1-4.fc18
   rasmol-gtk-2.7.5.2-3.fc21.i686 requires libCNearTree.so.5

Hi!
I tried to contact tmatsuu but failed. I did an admin request in PkgDB for 
NearTree[1], what could I do else?

Dmitrij S. Kryzhevich

[1] https://admin.fedoraproject.org/pkgdb/package/NearTree/
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Pierre-Yves Chibon]

On Wed, Jun 25, 2014 at 10:31:18AM +0700, Dmitrij S. Kryzhevich wrote:
Package(co)maintainers
  ===
  NearTree   tmatsuu
  
  The following packages require above mentioned packages:
  Depending on: NearTree
  rasmol (maintained by: krege)
  rasmol-2.7.5.2-3.fc21.i686 requires libCNearTree.so.5
  rasmol-2.7.5.2-3.fc21.src requires NearTree-devel = 3.1.1-4.fc18
  rasmol-gtk-2.7.5.2-3.fc21.i686 requires libCNearTree.so.5
 
 Hi!
 I tried to contact tmatsuu but failed. I did an admin request in PkgDB for 
 NearTree[1], what could I do else?
 
 [1] https://admin.fedoraproject.org/pkgdb/package/NearTree/

Maybe worth asking for commit rights as well.

Pierre
-- 
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)

[Adam Jackson]

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)

[Przemek Klosowski]

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)

[Adam Jackson]

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)

[Peter Jones]

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: [ACTION REQUIRED] Retiring packages for Fedora 21 v2

[Ales Ledvinka]

python-gudev orphan, aledvink, sochotni 

Taken.
Anyone who did miss the opportunity and still want it? Just let me know.
-- 
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)

[Kevin Kofler]

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)

[Matthew Garrett]

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: [ACTION REQUIRED] Retiring packages for Fedora 21 v2

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 11 June 2014 at 18:57, Till Maas wrote:
 The following packages are orphaned or did not build for two
 releases and will be retired when Fedora (F21) is branched, unless someone
 adopts them. 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 2014-07-08. The packages will be retired shortly 
 before.
 
 Note: If you received this mail directly you (co)maintain one of the affected
 packages or a package that depends on one.
 
  Package(co)maintainers 
 ===
[...]
 cleanfeedorphan

Taken. Co-maintainers welcome.

[...]
 inn  orphan, npajkovs, ovasik, s4504kr

Taken. Co-maintainers welcome.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
Faith manages.
-- Delenn to Lennier in Babylon 5:Confessions and Lamentations
-- 
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)

[Richard W.M. Jones]

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)

[Richard W.M. Jones]

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)

[Dennis Gilmore]

-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)

[Matthew Garrett]

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)

[Richard W.M. Jones]

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)

[Matthew Garrett]

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)

[Richard W.M. Jones]

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)

[Matthew Garrett]

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)

[Richard W.M. Jones]

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)

[Matthew Garrett]

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)

[Richard W.M. Jones]

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)

[Matthew Garrett]

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)

[Richard W.M. Jones]

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)

[Matthew Garrett]

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)

[Matthew Garrett]

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)

[Bruno Wolff III]

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)

[Kevin Kofler]

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)

[Kevin Kofler]

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)

[Matthew Miller]

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)

[Matthew Garrett]

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)

[Ralf Corsepius]

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)

[Vít Ondruch]

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)

[Richard W.M. Jones]

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)

[Richard W.M. Jones]

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)

[Dennis Gilmore]

-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)

[Al Dunsmuir]

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)

[Adam Jackson]

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)

[Matthew Garrett]

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)

[Richard W.M. Jones]

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)

[Dennis Gilmore]

-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)

[Matthew Garrett]

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)

[Richard W.M. Jones]

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)

[Dennis Gilmore]

-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)

[Johannes Lips]

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)

[Till Maas]

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)

[Dan Horák]

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)

[Tom Callaway]

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)

[Al Dunsmuir]

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)

[Dan Horák]

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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Adam Jackson]

On Sat, 2014-05-31 at 10:33 -0400, Al Dunsmuir wrote:

 Is  the  mga450 supported? Aside from formal graphics test days, I can
 run whatever tests required on x86 (both 32-bit and 64-bit).

Define supported.  I believe for PowerPC in RHEL we build the matroxfb
driver for this card, so that plus the fbdev driver for X is what you
get there.  I'm not sure what would happen on Fedora for that, probably
aligning it with RHEL makes sense.  On x86 you'd get vesa.

But in any of those cases there's no acceleration code involved, so
supported could reaally only mean lights up and sets modes.

 I've  also got a GXT120 (OEM'd MY220P) and the identical x86 card. I'm
 not  sure  if  that  would  be  covered by mgag200, but again, I can
 provide validation.

The mgag200 driver is, at the moment, only a driver for server variants
of the G200 (G200SE, G200WB, etc).  Actual G200, as well as G400 G450
and G550, are not driven by the mgag200 driver at this time.

- 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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Pavel Alexeev]

29.05.2014 17:43, Till Maas wrote:
 Since the mass rebuild will start in a week (2014-06-06) it is a good
 time to start cleaning up Fedora. After the mass rebuild, packages that
 fail to build for two releases will be be added to this list. Since this
 is the first run after adapting the script to pkgdb2, there might be
 some errors here, please report them.

 The following packages are orphaned and will be retired when Fedora
 (F21) is branched, unless someone adopts them. 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
 ===
…
 pmountorphan, agk,   
Took master, f19, а20.


-- 
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: hubbi...@jabber.ru
-- 
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]

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)

[Till Maas]

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)

[Al Dunsmuir]

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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Al Dunsmuir]

On Monday, June 2, 2014, 10:05:22 AM, Adam Jackson wrote:
 On Sat, 2014-05-31 at 10:33 -0400, Al Dunsmuir wrote:
 Is  the  mga450 supported? Aside from formal graphics test days, I can
 run whatever tests required on x86 (both 32-bit and 64-bit).

 Define supported.  I believe for PowerPC in RHEL we build the matroxfb
 driver for this card, so that plus the fbdev driver for X is what you
 get there.  I'm not sure what would happen on Fedora for that, probably
 aligning it with RHEL makes sense.  On x86 you'd get vesa.

Assuming  there  are no down-sides of aligning Fedora and RHEL in this
area, it would be appreciated. Do you need a BZ to do this?

 But in any of those cases there's no acceleration code involved, so
 supported could reaally only mean lights up and sets modes.

Light is good.  For the lower-functionality desktops, it is enough.

The  IBM  AIX  GXT135  driver  documents  a switch to enable minimally
acceleration,  but  does  not describe any details.  Even without that
enabled, it is usable under CDE.

 I've  also got a GXT120 (OEM'd MY220P) and the identical x86 card. I'm
 not  sure  if  that  would  be  covered by mgag200, but again, I can
 provide validation.

 The mgag200 driver is, at the moment, only a driver for server variants
 of the G200 (G200SE, G200WB, etc).  Actual G200, as well as G400 G450
 and G550, are not driven by the mgag200 driver at this time.

Thanks for the info, and your efforts!

I can give them a try around alpha-time, and see what transpires.



-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Adam Jackson]

On Mon, 2014-06-02 at 16:52 -0400, Al Dunsmuir wrote:
 On Monday, June 2, 2014, 10:05:22 AM, Adam Jackson wrote:
  On Sat, 2014-05-31 at 10:33 -0400, Al Dunsmuir wrote:
  Is  the  mga450 supported? Aside from formal graphics test days, I can
  run whatever tests required on x86 (both 32-bit and 64-bit).
 
  Define supported.  I believe for PowerPC in RHEL we build the matroxfb
  driver for this card, so that plus the fbdev driver for X is what you
  get there.  I'm not sure what would happen on Fedora for that, probably
  aligning it with RHEL makes sense.  On x86 you'd get vesa.
 
 Assuming  there  are no down-sides of aligning Fedora and RHEL in this
 area, it would be appreciated. Do you need a BZ to do this?

Appears to be thus already actually, so no bug needed.

- 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)

[Till Maas]

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)

[Till Maas]

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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Al Dunsmuir]

On Monday, June 2, 2014, 5:15:18 PM, Adam Jackson wrote:

 On Mon, 2014-06-02 at 16:52 -0400, Al Dunsmuir wrote:
 On Monday, June 2, 2014, 10:05:22 AM, Adam Jackson wrote:
  On Sat, 2014-05-31 at 10:33 -0400, Al Dunsmuir wrote:
  Is  the  mga450 supported? Aside from formal graphics test days, I can
  run whatever tests required on x86 (both 32-bit and 64-bit).
 
  Define supported.  I believe for PowerPC in RHEL we build the matroxfb
  driver for this card, so that plus the fbdev driver for X is what you
  get there.  I'm not sure what would happen on Fedora for that, probably
  aligning it with RHEL makes sense.  On x86 you'd get vesa.
 
 Assuming  there  are no down-sides of aligning Fedora and RHEL in this
 area, it would be appreciated. Do you need a BZ to do this?

 Appears to be thus already actually, so no bug needed.

Excellent!  Thanks for checking.



-- 
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)

[Al Dunsmuir]

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)

[Rahul Sundaram]

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)

[Till Maas]

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)

[Michael Schwendt]

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)

[Till Maas]

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)

[Till Maas]

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)

[Michael Schwendt]

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)

[Rahul Sundaram]

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

Re: [ACTION REQUIRED] Retiring packages for Fedora 21

[Al Dunsmuir]

On Friday, May 30, 2014, 12:22:18 PM, Adam Jackson wrote:

 On Thu, 2014-05-29 at 18:24 +0100, Richard W.M. Jones wrote:
 On Thu, May 29, 2014 at 03:43:49PM +0200, Till Maas wrote:
 Isn't this driver therefore required by this emulated card?  Or does
 another driver do the job?

 No and yes, respectively:
. . .
 The xorg-x11-drv-modesetting driver handles X support for KMS drivers
 without userspace acceleration, which at the moment means ast, bochs,
 cirrus, gma500, mgag200, and udl.

Ajax,

The  GXT135  is  the  most common video adapter for pSeries, and is an
OEM'd  mga450. I've got two (in ppc 32-bit machines, which is now more
of  a  long  term  challenge). I also now have two x86 equivalents for
testing (a PCI G450 identical to the GXT135, and another AGP version).

Is  the  mga450 supported? Aside from formal graphics test days, I can
run whatever tests required on x86 (both 32-bit and 64-bit).

I've  also got a GXT120 (OEM'd MY220P) and the identical x86 card. I'm
not  sure  if  that  would  be  covered by mgag200, but again, I can
provide validation.

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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Mat Booth]

On 29 May 2014 14:43, Till Maas opensou...@till.name wrote:

 eclipse-subclipse orphan,
   kdaniel, swagiaal



This affects some of my packages, taking.

-- 
Mat Booth
http://fedoraproject.org/get-fedora
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Adam Jackson]

On Thu, 2014-05-29 at 18:24 +0100, Richard W.M. Jones wrote:
 On Thu, May 29, 2014 at 03:43:49PM +0200, Till Maas wrote:
  xorg-x11-drv-cirrus   orphan, airlied, ajax, alexl, 
caillon, caolanm, glisse, 
hadess, johnp, 
mbarnes, rhughes, rstrode, ssp, whot, 
xiphmont  
 
 I think this one came up last time we went through this exercise.
 
 The Cirrus Logic CLGD 5446 card is the default one emulated by qemu
 (and Xen I think).  It has a number of problems, not least low maximum
 resolution, but it's simple and well understood.
 
 Isn't this driver therefore required by this emulated card?  Or does
 another driver do the job?

No and yes, respectively:

dmt:~% modinfo cirrus
filename:   
/lib/modules/3.14.4-200.fc20.x86_64/kernel/drivers/gpu/drm/cirrus/cirrus.ko
license:GPL
description:qemu Cirrus emulation
author: Matthew Garrett
alias:  pci:v1013d00B8sv1AF4sd1100bc*sc*i*
depends:drm,drm_kms_helper,ttm
intree: Y
vermagic:   3.14.4-200.fc20.x86_64 SMP mod_unload 
signer: Fedora kernel signing key
sig_key:73:8E:76:E6:10:AD:B0:ED:59:17:44:B5:F4:96:16:FE:D5:5A:36:15
sig_hashalgo:   sha256
parm:   modeset:Disable/Enable modesetting (int)

The xorg-x11-drv-modesetting driver handles X support for KMS drivers
without userspace acceleration, which at the moment means ast, bochs,
cirrus, gma500, mgag200, and udl.

- 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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Adam Jackson]

On Thu, 2014-05-29 at 15:43 +0200, Till Maas wrote:

 xorg-x11-drv-apm  orphan, airlied, ajax, alexl, 
 xorg-x11-drv-cirrus   orphan, airlied, ajax, alexl, 
 xorg-x11-drv-glintorphan, airlied, ajax, alexl, 
 xorg-x11-drv-i128 orphan, airlied, ajax, alexl, 
 xorg-x11-drv-i740 orphan, airlied, ajax, alexl, 
 xorg-x11-drv-mach64   orphan, glisse,   
 xorg-x11-drv-mga  orphan, airlied, ajax, alexl, 
 xorg-x11-drv-neomagic orphan, airlied, ajax, alexl, 
 xorg-x11-drv-r128 orphan, glisse,   
 xorg-x11-drv-renditionorphan, airlied, ajax, alexl, 
 xorg-x11-drv-s3virge  orphan, airlied, ajax, alexl, 
 xorg-x11-drv-savage   orphan, airlied, ajax, alexl, 
 xorg-x11-drv-siliconmotionorphan, airlied, ajax, alexl, 
 xorg-x11-drv-sis  orphan, airlied, ajax, alexl, 
 xorg-x11-drv-tdfx orphan, airlied, ajax, alexl, 
 xorg-x11-drv-trident  orphan, airlied, ajax, alexl, 

I announced orphaning these about nine months ago:

https://lists.fedoraproject.org/pipermail/devel/2013-August/188429.html

I've pushed a new xorg-x11-drivers metapackage that no longer pulls in
these drivers.  Next time the xserver ABI changes we'll update it to
Obsolete the incompatible drivers so they get uninstalled.

- 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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Jon Ciesla]

On Thu, May 29, 2014 at 8:43 AM, Till Maas opensou...@till.name wrote:

 Since the mass rebuild will start in a week (2014-06-06) it is a good
 time to start cleaning up Fedora. After the mass rebuild, packages that
 fail to build for two releases will be be added to this list. Since this
 is the first run after adapting the script to pkgdb2, there might be
 some errors here, please report them.

 http://fedoraproject.org/code-of-conduct

Many, many errors.  For one, curl isn't orphaned.  For another, CUnit is
orphaned but has 3 comaintainters, not the huge number reported, unless I'm
misunderstanding.  Though on seconf look it looks like that's caused by
CUnit being required by curl.  So maybe the output needs restructuring.
And one of the CUnit comaintainers needs to take ownership.

-J


-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Michael Schwendt]

On Thu, 29 May 2014 08:50:47 -0500, Jon Ciesla wrote:

 On Thu, May 29, 2014 at 8:43 AM, Till Maas wrote:
 
  Since the mass rebuild will start in a week (2014-06-06) it is a good
  time to start cleaning up Fedora. After the mass rebuild, packages that
  fail to build for two releases will be be added to this list. Since this
  is the first run after adapting the script to pkgdb2, there might be
  some errors here, please report them.
 
  http://fedoraproject.org/code-of-conduct
 
 Many, many errors.  For one, curl isn't orphaned. 

The list only says that curl is affected because it depends on CUnit.

 For another, CUnit is
 orphaned but has 3 comaintainters, 

The list says two.

 not the huge number reported, unless I'm
 misunderstanding.

Likely a misunderstanding. The list at the bottom tells which package
maintainers are affected by _any_ of the orphans, and in order to be
helpful, the list tells which soon to be retired package(s) each maintainer
is affected by.
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Troy Dawson]

On 05/29/2014 08:43 AM, Till Maas wrote:
 Since the mass rebuild will start in a week (2014-06-06) it is a good
 time to start cleaning up Fedora. After the mass rebuild, packages that
 fail to build for two releases will be be added to this list. Since this
 is the first run after adapting the script to pkgdb2, there might be
 some errors here, please report them.
 
 The following packages are orphaned and will be retired when Fedora
 (F21) is branched, unless someone adopts them. 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
 
...
 openshift-origin-cartridge-abstract   orphan,
   maxamillion   
 openshift-origin-cartridge-cron-1.4   orphan,
   maxamillion, tdawson  
 openshift-origin-cartridge-diy-0.1orphan,
   maxamillion, tdawson  
...

These three packages need to go away, they have been replaced.  Please
retire them with a clear conscious.

openshift-origin-cartridge-cron-1.4 - openshift-origin-cartridge-cron
openshift-origin-cartridge-diy-0.1 - openshift-origin-cartridge-diy
openshift-origin-cartridge-abstract - No longer needed.

I'd followed the procedure for Renaming/Replacing Existing Packages [1]
but I guess your script is just being extra cautious.

Troy Dawson

-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Jon Ciesla]

On Thu, May 29, 2014 at 9:27 AM, Michael Schwendt mschwe...@gmail.com
wrote:

 On Thu, 29 May 2014 08:50:47 -0500, Jon Ciesla wrote:

  On Thu, May 29, 2014 at 8:43 AM, Till Maas wrote:
 
   Since the mass rebuild will start in a week (2014-06-06) it is a good
   time to start cleaning up Fedora. After the mass rebuild, packages that
   fail to build for two releases will be be added to this list. Since
 this
   is the first run after adapting the script to pkgdb2, there might be
   some errors here, please report them.
  
   http://fedoraproject.org/code-of-conduct
 
  Many, many errors.  For one, curl isn't orphaned.

 The list only says that curl is affected because it depends on CUnit.

  For another, CUnit is
  orphaned but has 3 comaintainters,

 The list says two.

  not the huge number reported, unless I'm
  misunderstanding.

 Likely a misunderstanding. The list at the bottom tells which package
 maintainers are affected by _any_ of the orphans, and in order to be
 helpful, the list tells which soon to be retired package(s) each maintainer
 is affected by.


I thought so.  If someone doesn't step up soon I'll take CUnit.

-J


 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Paul Howarth]

On 29/05/14 15:31, Jon Ciesla wrote:




On Thu, May 29, 2014 at 9:27 AM, Michael Schwendt mschwe...@gmail.com
mailto:mschwe...@gmail.com wrote:

On Thu, 29 May 2014 08:50:47 -0500, Jon Ciesla wrote:

  On Thu, May 29, 2014 at 8:43 AM, Till Maas wrote:
 
   Since the mass rebuild will start in a week (2014-06-06) it is
a good
   time to start cleaning up Fedora. After the mass rebuild,
packages that
   fail to build for two releases will be be added to this list.
Since this
   is the first run after adapting the script to pkgdb2, there
might be
   some errors here, please report them.
  
   http://fedoraproject.org/code-of-conduct
 
  Many, many errors.  For one, curl isn't orphaned.

The list only says that curl is affected because it depends on CUnit.

  For another, CUnit is
  orphaned but has 3 comaintainters,

The list says two.

  not the huge number reported, unless I'm
  misunderstanding.

Likely a misunderstanding. The list at the bottom tells which package
maintainers are affected by _any_ of the orphans, and in order to be
helpful, the list tells which soon to be retired package(s) each
maintainer
is affected by.


I thought so.  If someone doesn't step up soon I'll take CUnit.


If you do, it'd be nice if you'd also branch and build it for EPEL-7 
(pretty please).


Paul.

--
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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Jon Ciesla]

On Thu, May 29, 2014 at 9:42 AM, Paul Howarth p...@city-fan.org wrote:

 On 29/05/14 15:31, Jon Ciesla wrote:




 On Thu, May 29, 2014 at 9:27 AM, Michael Schwendt mschwe...@gmail.com
 mailto:mschwe...@gmail.com wrote:

 On Thu, 29 May 2014 08:50:47 -0500, Jon Ciesla wrote:

   On Thu, May 29, 2014 at 8:43 AM, Till Maas wrote:
  
Since the mass rebuild will start in a week (2014-06-06) it is
 a good
time to start cleaning up Fedora. After the mass rebuild,
 packages that
fail to build for two releases will be be added to this list.
 Since this
is the first run after adapting the script to pkgdb2, there
 might be
some errors here, please report them.
   
http://fedoraproject.org/code-of-conduct
  
   Many, many errors.  For one, curl isn't orphaned.

 The list only says that curl is affected because it depends on CUnit.

   For another, CUnit is
   orphaned but has 3 comaintainters,

 The list says two.

   not the huge number reported, unless I'm
   misunderstanding.

 Likely a misunderstanding. The list at the bottom tells which package
 maintainers are affected by _any_ of the orphans, and in order to be
 helpful, the list tells which soon to be retired package(s) each
 maintainer
 is affected by.


 I thought so.  If someone doesn't step up soon I'll take CUnit.


 If you do, it'd be nice if you'd also branch and build it for EPEL-7
 (pretty please).

 Taken, branched, and building.

-J


 Paul.

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

CUnit pkgdb bug? / Re: [ACTION REQUIRED] Retiring packages for Fedora 21

[Michael Schwendt]

On Thu, 29 May 2014 09:31:52 -0500, Jon Ciesla wrote:

 If someone doesn't step up soon I'll take CUnit.

I visited pkgdb to try taking CUnit, but I can't. Pkgdb presents an empty
Branch field and doesn't let me continue. I'll look into reporting that
as a bug first.

:-(
-- 
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: CUnit pkgdb bug? / Re: [ACTION REQUIRED] Retiring packages for Fedora 21

[Jon Ciesla]

On Thu, May 29, 2014 at 9:57 AM, Michael Schwendt mschwe...@gmail.com
wrote:

 On Thu, 29 May 2014 09:31:52 -0500, Jon Ciesla wrote:

  If someone doesn't step up soon I'll take CUnit.

 I visited pkgdb to try taking CUnit, but I can't. Pkgdb presents an empty
 Branch field and doesn't let me continue. I'll look into reporting that
 as a bug first.

 :-(


Odd, I took it with no issues.  If you'd like it we can transfer after the
bug is worked out.

-J


 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
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: CUnit pkgdb bug? / Re: [ACTION REQUIRED] Retiring packages for Fedora 21

[Michael Schwendt]

On Thu, 29 May 2014 09:59:00 -0500, Jon Ciesla wrote:

  I visited pkgdb to try taking CUnit, but I can't. Pkgdb presents an empty
  Branch field and doesn't let me continue. I'll look into reporting that
  as a bug first.
 
  :-(
 
 
 Odd, I took it with no issues.  If you'd like it we can transfer after the
 bug is worked out.

Filed #17 in pkgdb2 tracker. Probably just a race-condition because you
took it shortly after I had loaded the pkgdb page to take it.
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Till Maas]

On Thu, May 29, 2014 at 08:50:47AM -0500, Jon Ciesla wrote:

 CUnit being required by curl.  So maybe the output needs restructuring.
 And one of the CUnit comaintainers needs to take ownership.

Do you have a suggestion about how to restructure? It seems to me that
the limits of plaintext emails are reached with all the information that
is include there, but I am interested in new ideas. :-)

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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Jon Ciesla]

On Thu, May 29, 2014 at 11:09 AM, Till Maas opensou...@till.name wrote:

 On Thu, May 29, 2014 at 08:50:47AM -0500, Jon Ciesla wrote:

  CUnit being required by curl.  So maybe the output needs restructuring.
  And one of the CUnit comaintainers needs to take ownership.

 Do you have a suggestion about how to restructure? It seems to me that
 the limits of plaintext emails are reached with all the information that
 is include there, but I am interested in new ideas. :-)


No, I was just compla^H^H^H^H^H^Hmaking an observation. :)

But I'll think about it.

-J


 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




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Richard W.M. Jones]

On Thu, May 29, 2014 at 03:43:49PM +0200, Till Maas wrote:
 xorg-x11-drv-cirrus   orphan, airlied, ajax, alexl, 
   caillon, caolanm, glisse, 
   hadess, johnp, 
   mbarnes, rhughes, rstrode, ssp, whot, 
   xiphmont  

I think this one came up last time we went through this exercise.

The Cirrus Logic CLGD 5446 card is the default one emulated by qemu
(and Xen I think).  It has a number of problems, not least low maximum
resolution, but it's simple and well understood.

Isn't this driver therefore required by this emulated card?  Or does
another driver do the job?

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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Dominik 'Rathann' Mierzejewski]

Hi Jochen,

On Thursday, 29 May 2014 at 15:43, Till Maas wrote:
 Since the mass rebuild will start in a week (2014-06-06) it is a good
 time to start cleaning up Fedora. After the mass rebuild, packages that
 fail to build for two releases will be be added to this list. Since this
 is the first run after adapting the script to pkgdb2, there might be
 some errors here, please report them.
 
 The following packages are orphaned and will be retired when Fedora
 (F21) is branched, unless someone adopts them. 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
 ===
[...]
 cleanfeed orphan 
[...]
 inn   orphan,
   npajkovs, ovasik, s4504kr 

I noticed inn is orphaned and will be retired if nobody steps up.
I see that you've been taking care of it for quite some time now,
would you like to take over inn officially?

Also, cleanfeed needs a new maintainer, too.

I haven't run a local INN instance for quite a few years now,
but I did it in the past and would take over if absolutely necessery,
if only to ensure it doesn't disappear from Fedora.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
Faith manages.
-- Delenn to Lennier in Babylon 5:Confessions and Lamentations
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21

[Eduardo Mayorga Téllez]

Hi,

I'll take ownership of python-ZConfig as I already maintain a few Python 
packages and I'm interested in keeping python-ZODB in the distribution.


Eduardo
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct