Orphaning gedit-valencia -- Re: Removing packages that have broken dependencies in F21 tree

2014-11-26 Thread Michel Alexandre Salim
Hi,

On 11/13/2014 08:20 PM, Kalev Lember wrote:
> Hi,
> 
> I would like to remove the packages that still have broken dependencies
> in the F21 tree.
> 
> This is a followup to
> https://lists.fedoraproject.org/pipermail/devel/2014-October/203411.html
> 
> It makes little sense to ship something that cannot even be installed.
> We're about to enter the final freeze next week in order to wrap up F21;
> after the gold release is done, fixes can no longer be pushed to the
> base repo. This means that anything that shipped with broken
> dependencies would stay that way in the base repo throughout the F21
> lifetime.
> 
> To avoid that, I'll file a FESCo ticket next Monday to approve dropping
> the following packages, unless they get fixed first:
> 
...
> gedit-valencia

Upstream (Yorba) has been aware of the breaking API changes in Gedit
3.12, but unfortunately lacks the manpower to fix it. There's a patch
submitted in September that laid dormant, and unfortunately changes
between Gedit 3.12 and 3.14 cause additional breakage.

https://bugzilla.gnome.org/show_bug.cgi?id=724173

Unfortunately I don't have the time to devote to fixing this, so I'm
pushing a final update for the Fedora 20 branch of gedit-valencia
(containing some test patches that can be applied to get the codebase to
compile on Fedora 21) but releasing ownership for F21 and master.

Any Vala / GObject / Gedit maven willing to take this package up?

Best regards,

-- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  sali...@fedoraproject.org  | GPG key ID: A36A937A
IDs:keybase.io/michel-slm  | IRC: michel_...@irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments



signature.asc
Description: OpenPGP digital 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: Taskotron depcheck broken/incomplete (was: Re: Removing packages that have broken dependencies in F21 tree)

2014-11-23 Thread Kevin Kofler
Adam Williamson wrote:
> http://tirfa.com/current-state-of-depcheck-and-paths-forward.html

Sigh. This shows that once again a purported replacement for a working piece 
of software was deployed before it was able to perform the allegedly 
replaced tool's most important task, even though the problem was known to 
the replacement's developers. We really should not accept this kind of known 
regressions.

> I'm sort-of volunteered to write the approach I suggested in a comment
> as a new test, but it's going to have to wait until at least post-f21.

Your approach indeed makes sense. It will not cause issues caused by added 
Conflicts or the like, but at least it catches the common case. (Just make 
sure you also consider Obsoleted packages as "the old package" whose 
Provides will no longer be available.)

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: Taskatron depcheck broken/incomplete (was: Re: Removing packages that have broken dependencies in F21 tree)

2014-11-21 Thread Adam Williamson
On Sun, 2014-11-16 at 01:21 +0100, Kevin Kofler wrote:
> Kalev Lember wrote:
> > 2) juffed was broken by
> > https://admin.fedoraproject.org/updates/FEDORA-2014-14301/ . Interestingly
> > enough the update passed the Taskatron depcheck test there, even though it
> > created a new broken dependency in the repo.
> 
> The Taskatron depcheck appears to be broken or incomplete: It might be 
> effective at checking whether the new package has any broken dependencies, 
> but it definitely does not appear to check whether the update breaks OTHER 
> packages' dependencies (at least I've seen 2 instances where it didn't catch 
> that, and this is the third). The old AutoQA got that right.

http://tirfa.com/current-state-of-depcheck-and-paths-forward.html

I'm sort-of volunteered to write the approach I suggested in a comment
as a new test, but it's going to have to wait until at least post-f21.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
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: Removing packages that have broken dependencies in F21 tree

2014-11-17 Thread Kalev Lember
On 11/13/2014 02:20 PM, Kalev Lember wrote:
> To avoid that, I'll file a FESCo ticket next Monday to approve dropping
> the following packages, unless they get fixed first:

I've filed the ticket now: https://fedorahosted.org/fesco/ticket/1368

In addition, 3 broken dependencies have pending fixes. Would be good to
karma those up today so that they can be pushed to stable in advance of
the freeze tomorrow:

juffed: https://admin.fedoraproject.org/updates/juffed-0.10-11.fc21
meshmagick: 
https://admin.fedoraproject.org/updates/meshmagick-0.6.0-23.svn2898.fc21
totpcgi: 
https://admin.fedoraproject.org/updates/FEDORA-2014-15164/totpcgi-0.5.5-4.fc21

-- 
Thanks,
Kalev
-- 
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: Taskotron depcheck broken/incomplete (was: Re: Removing packages that have broken dependencies in F21 tree)

2014-11-16 Thread Kevin Kofler
I wrote:
> The Taskatron depcheck appears to be broken or incomplete: It might be
> effective at checking whether the new package has any broken dependencies,
> but it definitely does not appear to check whether the update breaks OTHER
> packages' dependencies (at least I've seen 2 instances where it didn't
> catch that, and this is the third). The old AutoQA got that right.

Another fun Taskotron depcheck bug, this time a false positive:
https://admin.fedoraproject.org/updates/FEDORA-2014-14865
https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/13276/steps/runtask/logs/stdio

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

Taskatron depcheck broken/incomplete (was: Re: Removing packages that have broken dependencies in F21 tree)

2014-11-15 Thread Kevin Kofler
Kalev Lember wrote:
> 2) juffed was broken by
> https://admin.fedoraproject.org/updates/FEDORA-2014-14301/ . Interestingly
> enough the update passed the Taskatron depcheck test there, even though it
> created a new broken dependency in the repo.

The Taskatron depcheck appears to be broken or incomplete: It might be 
effective at checking whether the new package has any broken dependencies, 
but it definitely does not appear to check whether the update breaks OTHER 
packages' dependencies (at least I've seen 2 instances where it didn't catch 
that, and this is the third). The old AutoQA got that right.

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: Removing packages that have broken dependencies in F21 tree

2014-11-15 Thread Kevin Fenzi
On Thu, 13 Nov 2014 20:40:07 +0100
Till Maas  wrote:

> On Thu, Nov 13, 2014 at 07:40:19PM +0100, Till Maas wrote:
> > On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote:
> > 
> > > totpcgi
> > 
> > This requires an selinux export to make it build again:
> > 
> > | + make NAME=mls -f /usr/share/selinux/devel/Makefile
> > | Compiling mls totpcgi module
> > | totpcgi.te:55: Warning: miscfiles_read_certs() has been
> > deprecated, please use miscfiles_read_generic_certs() instead. |
> > totpcgi.te:58: Warning: miscfiles_read_certs() has been deprecated,
> > please use miscfiles_read_generic_certs() instead. |
> > totpcgi.te:41:ERROR 'unknown type httpd_totpcgi_script_t' at token
> > ';' on line 5216: | typeattribute httpd_totpcgi_script_t
> > syslog_client_type; | #line 41
> > 
> > https://github.com/mricon/totp-cgi/issues/27
> > https://bugzilla.redhat.com/show_bug.cgi?id=1107456
> 
> Thanks to tfirg on #selinux I now know that this is because
> 
> apache_content_template()
> 
> does not add a "httpd_" prefix to types in F21+.

Thanks for looking into this. 

I have requested commits on this package and in the mean time have done
rawhide and f21 build with your fix. 

kevin


pgp6GwYjRWG0V.pgp
Description: OpenPGP digital 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: Removing packages that have broken dependencies in F21 tree

2014-11-15 Thread Kalev Lember
On 11/15/2014 11:52 AM, Till Maas wrote:
> On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote:
> 
>> To avoid that, I'll file a FESCo ticket next Monday to approve dropping
>> the following packages, unless they get fixed first:
> 
> I can do the mass retirement if there is a final list and decision.

Thanks Till.

> Did you check that there are not packages listed that were just
> recently broken?

Most of those are longstanding (broken for more than a month), with two
exceptions:

1) gdesklet-SlideShow and gdesklets-citation depend on gdesklets which
appears to have been retired recently;

2) juffed was broken by 
https://admin.fedoraproject.org/updates/FEDORA-2014-14301/ .
Interestingly enough the update passed the Taskatron depcheck test
there, even though it created a new broken dependency in the repo.

> Also do you propose to retire the package only in F21 or also in 
> Rawhide?

My gut feeling is to retire the broken packages in Rawhide as well, but
it's ultimately up to FESCo to decide what to do.

-- 
Kalev
-- 
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: Removing packages that have broken dependencies in F21 tree

2014-11-15 Thread Kalev Lember
On 11/15/2014 03:02 PM, Kevin Kofler wrote:
> Kalev Lember wrote:
>> I would like to remove the packages that still have broken dependencies
>> in the F21 tree.
> 
> Please check for packages requiring those broken packages, and transitively 
> packages requiring packages requiring those broken packages etc. Otherwise, 
> you'll just add more broken dependencies.

Thanks Kevin, that's a very good point.

Here's the list of impacted dependant packages (package owners BCC'd):

Depending on: deltacloud-core (1), status change: 2014-07-08 (18 weeks ago)
condor-cloud (maintained by: imain)
condor-cloud-0.1-8.fc21.noarch requires deltacloud-core = 
1.1.3-1.fc20


Depending on: fatrat (1), status change: 2014-07-08 (18 weeks ago)
fatrat-subtitlesearch (maintained by: cicku)
fatrat-subtitlesearch-1.2.0-0.6.beta1.fc21.i686 requires 
fatrat(x86-32) = 1:1.2.0-0.21.beta2.fc21
fatrat-subtitlesearch-1.2.0-0.6.beta1.fc21.src requires 
fatrat-devel = 1:1.2.0-0.21.beta2.fc21


Depending on: gofer (1), status change: 2014-07-08 (18 weeks ago)
katello-agent (maintained by: lzap)
katello-agent-1.1.3-4.fc21.noarch requires gofer = 
0.77.1-2.fc21, gofer-package = 0.77.1-2.fc21


Depending on: libghemical (1), status change: 2014-07-08 (18 weeks ago)
ghemical (maintained by: cicku, tolland)
ghemical-2.99.2-24.fc20.i686 requires libghemical = 
2.99.1-24.fc20, libghemical.so.5
ghemical-2.99.2-24.fc20.src requires libghemical-devel = 
2.99.1-24.fc20


Depending on: rubygem-rubigen (1), status change: 2014-07-08 (18 weeks ago)
rubygem-newgem (maintained by: mmorsi)
rubygem-newgem-1.5.3-11.fc21.noarch requires rubygem(rubigen) = 
1.5.8, rubygem(rubigen) = 1.5.8-1
rubygem-newgem-1.5.3-11.fc21.src requires rubygem(rubigen) = 
1.5.8, rubygem(rubigen) = 1.5.8-1

-- 
Kalev
-- 
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: Removing packages that have broken dependencies in F21 tree

2014-11-15 Thread Dimitris Glezos
We're not running the Transifex Server on the Fedora infrastructure. The
Localization group has also decided to move to a self-managed Zanata
instance anyway.

The Transifex Client package is which is what many developers use.

-d

On Sat, Nov 15, 2014 at 5:59 AM, Kevin Kofler 
wrote:

> Matthias Runge wrote:
> > yes, that's the package. But IMHO transifex became closed source, and
> > last code change was about 2 years ago; since then, django changed quite
> > a bit.
>
> So we now have core Fedora infrastructure depending on a proprietary third-
> party web service?
>
> We should never have moved Fedora translations to the upstream Transifex
> instance. We now need to either fork the last Free version and put it up on
> Fedora Infrastructure, or replace it altogether.
>
> 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
>



-- 
Dimitris Glezos
Founder & CEO, Transifex
http://www.transifex.com/
-- 
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: Removing packages that have broken dependencies in F21 tree

2014-11-15 Thread Marcin Dulak

On 11/13/2014 02:20 PM, Kalev Lember wrote:

Hi,

I would like to remove the packages that still have broken dependencies
in the F21 tree.

This is a followup to
https://lists.fedoraproject.org/pipermail/devel/2014-October/203411.html

It makes little sense to ship something that cannot even be installed.
We're about to enter the final freeze next week in order to wrap up F21;
after the gold release is done, fixes can no longer be pushed to the
base repo. This means that anything that shipped with broken
dependencies would stay that way in the base repo throughout the F21
lifetime.

To avoid that, I'll file a FESCo ticket next Monday to approve dropping
the following packages, unless they get fixed first:

audtty
authhub
deltacloud-core
django-recaptcha
dragonegg
edelib
fatrat
flush
gdesklet-SlideShow
gdesklets-citation
gedit-valencia
gofer
gorm
juffed
leiningen
libghemical
libopensync-plugin-irmc
ltsp
meshmagick
monodevelop-vala
netdisco
nwchem
i have submitted nwchem update: 
https://admin.fedoraproject.org/updates/nwchem-6.5.26243-13.fc21


Best regards,

Marcin

ocaml-pa-do
openslides
openvas-client
pootle
python-askbot-fedmsg
python-coffin
python-django-addons
python-django-longerusername
rubygem-linecache19
rubygem-rubigen
rubygem-ruby-debug-base19
sugar-tamtam
totpcgi
transifex
valabind
why
zyGrib

Please note that Fedora policies allow adding new packages in the 
updates repo, so even if something gets dropped now, it can always be 
fixed and shipped in the updates repo at a later date.




--
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: Removing packages that have broken dependencies in F21 tree

2014-11-15 Thread Kevin Kofler
Kalev Lember wrote:
> I would like to remove the packages that still have broken dependencies
> in the F21 tree.

Please check for packages requiring those broken packages, and transitively 
packages requiring packages requiring those broken packages etc. Otherwise, 
you'll just add more broken dependencies.

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: Removing packages that have broken dependencies in F21 tree

2014-11-15 Thread Kevin Kofler
Matthias Runge wrote:
> yes, that's the package. But IMHO transifex became closed source, and
> last code change was about 2 years ago; since then, django changed quite
> a bit.

So we now have core Fedora infrastructure depending on a proprietary third-
party web service?

We should never have moved Fedora translations to the upstream Transifex 
instance. We now need to either fork the last Free version and put it up on 
Fedora Infrastructure, or replace it altogether.

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: Removing packages that have broken dependencies in F21 tree

2014-11-15 Thread Till Maas
On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote:

> To avoid that, I'll file a FESCo ticket next Monday to approve dropping
> the following packages, unless they get fixed first:

I can do the mass retirement if there is a final list and decision. Did
you check that there are not packages listed that were just recently
broken? Also do you propose to retire the package only in F21 or also in
Rawhide?

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: Removing packages that have broken dependencies in F21 tree

2014-11-14 Thread Kalev Lember
On 11/14/2014 02:15 PM, Vít Ondruch wrote:
> Dne 13.11.2014 v 14:20 Kalev Lember napsal(a):
>>
>> rubygem-linecache19
>> rubygem-ruby-debug-base19
> 
> Removing this two will break rubygem-ruby-debug19, so you should remove
> it as well (unless maintainer fixes them, which does not appear to be
> the case).

I'll add it to the list, thanks!

-- 
Kalev
-- 
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: Removing packages that have broken dependencies in F21 tree

2014-11-14 Thread Vít Ondruch
Dne 13.11.2014 v 14:20 Kalev Lember napsal(a):
>
> rubygem-linecache19
> rubygem-ruby-debug-base19

Removing this two will break rubygem-ruby-debug19, so you should remove
it as well (unless maintainer fixes them, which does not appear to be
the case).


Vír
-- 
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: Removing packages that have broken dependencies in F21 tree

2014-11-13 Thread Till Maas
On Thu, Nov 13, 2014 at 07:40:19PM +0100, Till Maas wrote:
> On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote:
> 
> > totpcgi
> 
> This requires an selinux export to make it build again:
> 
> | + make NAME=mls -f /usr/share/selinux/devel/Makefile
> | Compiling mls totpcgi module
> | totpcgi.te:55: Warning: miscfiles_read_certs() has been deprecated, please 
> use miscfiles_read_generic_certs() instead.
> | totpcgi.te:58: Warning: miscfiles_read_certs() has been deprecated, please 
> use miscfiles_read_generic_certs() instead.
> | totpcgi.te:41:ERROR 'unknown type httpd_totpcgi_script_t' at token ';' on 
> line 5216:
> | typeattribute httpd_totpcgi_script_t syslog_client_type;
> | #line 41
> 
> https://github.com/mricon/totp-cgi/issues/27
> https://bugzilla.redhat.com/show_bug.cgi?id=1107456

Thanks to tfirg on #selinux I now know that this is because

apache_content_template()

does not add a "httpd_" prefix to types in F21+.

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: Removing packages that have broken dependencies in F21 tree

2014-11-13 Thread Till Maas
On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote:

> totpcgi

This requires an selinux export to make it build again:

| + make NAME=mls -f /usr/share/selinux/devel/Makefile
| Compiling mls totpcgi module
| totpcgi.te:55: Warning: miscfiles_read_certs() has been deprecated, please 
use miscfiles_read_generic_certs() instead.
| totpcgi.te:58: Warning: miscfiles_read_certs() has been deprecated, please 
use miscfiles_read_generic_certs() instead.
| totpcgi.te:41:ERROR 'unknown type httpd_totpcgi_script_t' at token ';' on 
line 5216:
| typeattribute httpd_totpcgi_script_t syslog_client_type;
| #line 41

https://github.com/mricon/totp-cgi/issues/27
https://bugzilla.redhat.com/show_bug.cgi?id=1107456

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: Removing packages that have broken dependencies in F21 tree

2014-11-13 Thread Jerry James
On Thu, Nov 13, 2014 at 6:33 AM, Richard W.M. Jones  wrote:
> On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote:
>> why
>
> This is another OCaml package.  For some reason I'm not getting any
> emails about this, but I will try a rebuild now.

I had already rebuilt it, and an update was pending.  I just pushed
the update to stable, so nothing further needs to be done here.
-- 
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: Removing packages that have broken dependencies in F21 tree

2014-11-13 Thread Pete Travis
On Nov 13, 2014 8:02 AM, "Kalev Lember"  wrote:
>
> On 11/13/2014 03:33 PM, Richard W.M. Jones wrote:
>>
>> On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote:
>>>
>>> transifex
>>
>>
>> Huh??  If this is the package I'm thinking of, it's pretty important
>> to many other packages.
>
>
> It depends on python-django14 that was removed a while back and nobody
seems to have ported it to a newer django version:
>
> [transifex]
> transifex-1.2.1-12.fc21.noarch requires python-django14
>
>
> --
> Kalev
>
> --

transifex-client is probably seeing a lot more use ( at least on my desk :)

It still seems openly active at
https://github.com/transifex/transifex-client .  I doubt they will change
that - it's mostly just pycurl talking to an API, no secret sauce, and tx
really does advocate open souce even if they struggled with making it
commercially viable.

--Pete
-- 
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: Removing packages that have broken dependencies in F21 tree

2014-11-13 Thread Bruno Wolff III

On Thu, Nov 13, 2014 at 15:20:03 +0200,
 Kalev Lember  wrote:

meshmagick


For meshmagick the real isssue is FTBFS due to stricter checking by gcc. 
I started working on it a while back but didn't finish and didn't get back 
to it. I believe I can get it fixed by Monday.

--
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: Removing packages that have broken dependencies in F21 tree

2014-11-13 Thread Kalev Lember

On 11/13/2014 03:33 PM, Richard W.M. Jones wrote:

On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote:

transifex


Huh??  If this is the package I'm thinking of, it's pretty important
to many other packages.


It depends on python-django14 that was removed a while back and nobody 
seems to have ported it to a newer django version:


[transifex]
transifex-1.2.1-12.fc21.noarch requires python-django14


--
Kalev
--
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: Removing packages that have broken dependencies in F21 tree

2014-11-13 Thread Richard W.M. Jones
On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote:
> ocaml-pa-do

This package was rewritten upstream.  I've not tried to package the
new version.  The version packaged in Fedora Rawhide is orphaned, so I
guess you may as well remove the F21 package too (unless someone else
wants to jump in and fix this).

> transifex

Huh??  If this is the package I'm thinking of, it's pretty important
to many other packages.

> why

This is another OCaml package.  For some reason I'm not getting any
emails about this, but I will try a rebuild now.

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: Removing packages that have broken dependencies in F21 tree

2014-11-13 Thread Matthias Runge
On 13/11/14 14:33, Richard W.M. Jones wrote:
> On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote:
>> ocaml-pa-do
> 
> This package was rewritten upstream.  I've not tried to package the
> new version.  The version packaged in Fedora Rawhide is orphaned, so I
> guess you may as well remove the F21 package too (unless someone else
> wants to jump in and fix this).
> 
>> transifex
> 
> Huh??  If this is the package I'm thinking of, it's pretty important
> to many other packages.
yes, that's the package. But IMHO transifex became closed source, and
last code change was about 2 years ago; since then, django changed quite
a bit.

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