time to retire some kde4/smoke-based language bindings?

[Rex Dieter]

I was looking at rawhide (ppc64) broken deps, and was reminded of some
pretty old and unmaintained (upstream) kde4/smoke-based language bindings
(csharp, perl, ruby), affected packages include:

kdebindings
kimono
perl-Qt
ruby-korundum
ruby-qt
smokeqt
smokekde
qyoto

Of these, I can see *maybe* keeping perl-Qt (and dep smokeqt), primarily
because it is the only one in this list that's not a leaf package (debconf-
kde depends on it).

Any comments or objection to orphaning these for f26+ ?


-- Rex
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send a

[Petr Pisar]

Post by Rex Dieter
I was looking at rawhide (ppc64) broken deps, and was reminded of some
pretty old and unmaintained (upstream) kde4/smoke-based language bindings
kdebindings
kimono
perl-Qt
ruby-korundum
ruby-qt
smokeqt
smokekde
qyoto

What are their replacements? I.e. how will users write Qt applications
in C#, Perl, Ruby after removing those packages?

-- Petr
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@list

[Stephen John Smoogen]

Post by Petr Pisar

Post by Rex Dieter
I was looking at rawhide (ppc64) broken deps, and was reminded of some
pretty old and unmaintained (upstream) kde4/smoke-based language bindings
kdebindings
kimono
perl-Qt
ruby-korundum
ruby-qt
smokeqt
smokekde
qyoto

What are their replacements? I.e. how will users write Qt applications
in C#, Perl, Ruby after removing those packages?

Do they even work now?

Post by Petr Pisar
-- Petr
_______________________________________________

[Petr Pisar]

Post by Stephen John Smoogen

Post by Petr Pisar

Post by Rex Dieter
I was looking at rawhide (ppc64) broken deps, and was reminded of some
pretty old and unmaintained (upstream) kde4/smoke-based language bindings
kdebindings
kimono
perl-Qt
ruby-korundum
ruby-qt
smokeqt
smokekde
qyoto

What are their replacements? I.e. how will users write Qt applications
in C#, Perl, Ruby after removing those packages?

Do they even work now?

perl-Qt works. At least to the extent of tests executed at build-time.

-- Petr
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscri

[Peter Robinson]

Post by Petr Pisar

Post by Rex Dieter
I was looking at rawhide (ppc64) broken deps, and was reminded of some
pretty old and unmaintained (upstream) kde4/smoke-based language bindings
kdebindings
kimono
perl-Qt
ruby-korundum
ruby-qt
smokeqt
smokekde
qyoto

What are their replacements? I.e. how will users write Qt applications
in C#, Perl, Ruby after removing those packages?

Presumably their qt5/kde5 equivalents.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@

[Petr Pisar]

Post by Peter Robinson

Post by Petr Pisar

Post by Rex Dieter
I was looking at rawhide (ppc64) broken deps, and was reminded of some
pretty old and unmaintained (upstream) kde4/smoke-based language bindings
kdebindings
kimono
perl-Qt
ruby-korundum
ruby-qt
smokeqt
smokekde
qyoto

What are their replacements? I.e. how will users write Qt applications
in C#, Perl, Ruby after removing those packages?

Presumably their qt5/kde5 equivalents.

And they are? I could find only C# binding for Qt5. It seems nothing
exists in Ruby or Perl. Though Ruby has QML binding.

-- Petr
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedorapr

[Rex Dieter]

Post by Petr Pisar

Post by Rex Dieter
I was looking at rawhide (ppc64) broken deps, and was reminded of some
pretty old and unmaintained (upstream) kde4/smoke-based language bindings
kdebindings
kimono
perl-Qt
ruby-korundum
ruby-qt
smokeqt
smokekde
qyoto

What are their replacements? I.e. how will users write Qt applications
in C#, Perl, Ruby after removing those packages?

No replacements that I'm aware of.

Fact is, this is old/unsupported(by upstream) code... and offering to orphan
them means anyone still interested in these can step in to keep them alive
as new package maintainer(s).

-- rex
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an

[Peter Robinson]

Post by Rex Dieter
I was looking at rawhide (ppc64) broken deps, and was reminded of some
pretty old and unmaintained (upstream) kde4/smoke-based language bindings
kdebindings
kimono
perl-Qt
ruby-korundum
ruby-qt
smokeqt
smokekde
qyoto
Of these, I can see *maybe* keeping perl-Qt (and dep smokeqt), primarily
because it is the only one in this list that's not a leaf package (debconf-
kde depends on it).
Any comments or objection to orphaning these for f26+ ?

Is qt3 stuff going with them?
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org

[Rex Dieter]

Post by Peter Robinson

Post by Rex Dieter
I was looking at rawhide (ppc64) broken deps, and was reminded of some
pretty old and unmaintained (upstream) kde4/smoke-based language bindings
kdebindings
kimono
perl-Qt
ruby-korundum
ruby-qt
smokeqt
smokekde
qyoto
Of these, I can see *maybe* keeping perl-Qt (and dep smokeqt), primarily
because it is the only one in this list that's not a leaf package
(debconf- kde depends on it).
Any comments or objection to orphaning these for f26+ ?

Is qt3 stuff going with them?

Not my call, kde-sig (for the most part) dropped support for qt3/kde3 stuff
a few releases ago... it's maintained (mostly) by Kevin Kofler these days.

-- Rex
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email t

[Kevin Kofler]

Post by Peter Robinson
Is qt3 stuff going with them?

No.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lis