[gentoo-dev] The Gentoo Qt Project wants your help!

[gentoo-dev] The Gentoo Qt Project wants your help!

[Ben de Groot]

The Gentoo Qt Project wants your help!
======================================

The Gentoo Qt Project is a small team responsible for maintaining the Qt
libraries and associated applications within our beloved distro. Over time
the number of packages we maintain has grown. Not only is there quite some
work to be done to get the shiny new Qt5 version ready for the portage tree,
we now also have our own light-weight Qt-based desktop environment in
Razor-qt, as well as a growing number of Qt-based applications.

Recently a few of our team members have left to do other things, so we are
looking for new people to help us out! Whatever your skill level, there is
probably something you can do to help! We specifically are looking for
people to help us to do the following:

1. Get Qt5 ready for inclusion in the tree. This includes writing and
improving ebuilds and eclasses, testing to build those, filing bug reports
on failure, finding fixes for those bugs, reporting problems upstream. We
do development in the "qt" overlay, using git.

2. Application maintenance. At the moment we simply don't have the manpower
to actively maintain all Qt-based applications that we have an interest in.
A number of those could use a more dedicated maintainer. This can be either
a Gentoo developer or a proxy-maintainer. You would be responsible for
spotting version bumps, updating ebuilds, handling bug reports and contacting
upstream developers where necessary. An overview of the packages we
(co-)maintain is here: http://euscan.iksaif.net/herds/qt/
For a specific list of packages we could use help with, see below.

3. Bug handling. See http://tiny.cc/qtbugs for our open bugs. We can use
help to test and confirm bugs and proposed patches; to see if bugs are filed
upstream and if there are patches available; to keep an eye on bug-fix
releases.

4. Documentation. We would like to see more user guides, and updates to our
FAQ, on the Gentoo Wiki.

What we can give you is a friendly developer team, with members spread all
over the world; assistance with ebuild writing skills; commit access to a
lively git-based overlay, even if you are not a developer; mentoring in case
you do want to become a developer; a dedicated #gentoo-qt IRC channel; and
the satisfaction that you help improving Gentoo, the distro we all love.

You can contact us on qt@gentoo.org, or the #gentoo-qt IRC channel.



== New primary maintainer needed: ==

app-admin/keepassx
app-cdr/acetoneiso
app-editors/focuswriter
app-editors/tea
app-editors/znotes
dev-python/pyside and related packages
dev-util/beediff
dev-util/eggy
dev-util/monkeystudio
media-sound/mp3diags
media-video/avidemux (bundled libs)
media-video/qx11grab
net-im/psi (urgently needs to be updated to new release version)
net-libs/qmf (needs gcc-4.7 fix)
x11-misc/qtfm


== We could also use a hand with: ==

app-text/goldendict
dev-games/tiled
dev-util/xxdiff
media-gfx/nomacs
media-sound/coquillo
net-news/quiterss
net-news/rssguard
www-client/qupzilla
x11-misc/basqet

app-editors/qwriter
app-editors/qxmledit
app-emulation/qtemu
app-mobilephone/past
app-mobilephone/qtadb
app-office/qchartdiary
app-text/cb2bib
dev-db/dbmodel
dev-db/sqliteman
dev-libs/qjson
dev-libs/qoauth
dev-tex/qtexengine
dev-tex/texamator
dev-util/qfsm
dev-util/universalindentgui
dev-vcs/hgview
dev-vcs/qct
dev-vcs/qsvn
media-gfx/pencil
media-gfx/pictureflow
media-gfx/qosmic
media-gfx/qvv
net-analyzer/nmapsi
net-ftp/oneclickftp
net-ftp/qshare
net-ftp/scythia
net-im/qwit
net-misc/dnetstats
net-misc/netfleet
sci-calculators/qalculator
sci-visualization/kst
x11-misc/okindd
x11-misc/qps
x11-misc/qsynergy
x11-misc/tinymount


-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Diego Elio Pettenò]

On 02/03/2013 07:54, Ben de Groot wrote:
> 1. Get Qt5 ready for inclusion in the tree. This includes writing and
> improving ebuilds and eclasses, testing to build those, filing bug reports
> on failure, finding fixes for those bugs, reporting problems upstream. We
> do development in the "qt" overlay, using git.

If you decide to work on Qt5, my suggestion if for somebody to proxy it
on main tree *under package.mask* and shoot me an email.

Leveraging the tinderbox will at least allow you to find failure points.

Good luck,

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Ben de Groot]

On 2 March 2013 15:57, Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
> On 02/03/2013 07:54, Ben de Groot wrote:
>> 1. Get Qt5 ready for inclusion in the tree. This includes writing and
>> improving ebuilds and eclasses, testing to build those, filing bug reports
>> on failure, finding fixes for those bugs, reporting problems upstream. We
>> do development in the "qt" overlay, using git.
>
> If you decide to work on Qt5, my suggestion if for somebody to proxy it
> on main tree *under package.mask* and shoot me an email.
>
> Leveraging the tinderbox will at least allow you to find failure points.

It's basically Davide (pesa) working on it now, but he doesn't have
enough time to do all the work needed. We have most of the basic parts
ready in the overlay. But we will discuss it in our meeting this
weekend.

When we move it to the tree, we will follow your advice and have it
masked initially, so we can get a tinderbox run and some more people
testing it. Thanks for the offer!

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Jauhien Piatlicki]

[-- Attachment #1: Type: text/plain, Size: 257 bytes --]

02.03.13 07:54, Ben de Groot написав(ла):

> app-admin/keepassx
> app-text/goldendict

If these two packages need a maintainer, I could proxy-maintain them.
I'm not a developer, but I have some experience with ebuild writing.

Jauhien



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Ben de Groot]

On 2 March 2013 20:26, Jauhien Piatlicki <jpiatlicki@gmail.com> wrote:
> 02.03.13 07:54, Ben de Groot написав(ла):
>
>> app-admin/keepassx
>> app-text/goldendict
>
> If these two packages need a maintainer, I could proxy-maintain them.
> I'm not a developer, but I have some experience with ebuild writing.

Yes. They are not high-maintenance, but someone keeping an eye on
version bumps and bug reports would be helpful.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Samuli Suominen]

On 02/03/13 08:54, Ben de Groot wrote:
> The Gentoo Qt Project wants your help!
> sci-calculators/qalculator

This project died after the first betas. I propose treecleaning it. We 
have plenty of more maintained calculators in tree.

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Ben de Groot]

On 2 March 2013 20:33, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 02/03/13 08:54, Ben de Groot wrote:
>>
>> The Gentoo Qt Project wants your help!
>> sci-calculators/qalculator
>
>
> This project died after the first betas. I propose treecleaning it. We have
> plenty of more maintained calculators in tree.
>

If it is dead upstream, then yes, maybe we should consider
treecleaning it instead.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Alexis Ballier]

On Sat, 2 Mar 2013 14:54:22 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> 
> == We could also use a hand with: ==
[...]
> app-text/cb2bib
[...]
> dev-tex/qtexengine
> dev-tex/texamator

you can add tex@g.o as second maintainer there if you wish

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

On Sat, 2 Mar 2013 14:54:22 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> media-video/avidemux (bundled libs)

I like this application, but am not so sure about maintaining this... =/

Would it be reasonable to create a new package avidemux-ffmpeg in which
we create a version of ffmpeg with their patches applied? Perhaps we
can also remove the parts of ffmpeg that aren't used by avidemux to
keep the overhead of having ffmpeg twice on the system low.

I don't see any other reliable solution, unless upstream is willing to
stop bundling ffmpeg and get their patches incorporated on that.
But upon reading the progress on Debian, there is barely any progress
on that as far as I am aware of; and I'm not willing to maintain a
package that has 1) an unpatched ffmpeg that breaks it for people or
2) a bundled ffmpeg that keeps it from getting unmasked / reliable / ...

The other approach is for someone to attempt to try to get all these
patches upstream, but some of them are undocumented which makes it hard
to understand what the changes actually are done for; and at this point
in time it is not guaranteed that ffmpeg would take these patches.

So, what is the Qt herd's opinion on creating a avidemux-ffmpeg package?


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Samuli Suominen]

On 02/03/13 15:08, Tom Wijsman wrote:
> On Sat, 2 Mar 2013 14:54:22 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>
>> media-video/avidemux (bundled libs)
>
> I like this application, but am not so sure about maintaining this... =/
>
> Would it be reasonable to create a new package avidemux-ffmpeg in which
> we create a version of ffmpeg with their patches applied? Perhaps we
> can also remove the parts of ffmpeg that aren't used by avidemux to
> keep the overhead of having ffmpeg twice on the system low.
>
> I don't see any other reliable solution, unless upstream is willing to
> stop bundling ffmpeg and get their patches incorporated on that.
> But upon reading the progress on Debian, there is barely any progress
> on that as far as I am aware of; and I'm not willing to maintain a
> package that has 1) an unpatched ffmpeg that breaks it for people or
> 2) a bundled ffmpeg that keeps it from getting unmasked / reliable / ...
>
> The other approach is for someone to attempt to try to get all these
> patches upstream, but some of them are undocumented which makes it hard
> to understand what the changes actually are done for; and at this point
> in time it is not guaranteed that ffmpeg would take these patches.
>
> So, what is the Qt herd's opinion on creating a avidemux-ffmpeg package?

The embedded FFmpeg in avidemux is only patched to convert UNIX line 
endings to DOS line endings to match rest of the avidemux source tree
There should be a script in the repository and/or the tarball to convert 
orig. FFmpeg source tree to this.
Even if that wasn't the case, separate package doesn't make sense, 
USE="+system-libs" might

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

On Sat, 02 Mar 2013 15:29:38 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> The embedded FFmpeg in avidemux is only patched to convert UNIX line 
> endings to DOS line endings to match rest of the avidemux source tree

Nope, it does various patches:

 $ ls -1 avidemux_core/ffmpeg_package/patches
common.mak.diff
config.mak.diff
config.mak.mac.diff
createPatches.sh
libavcodec_avcodec.h.patch
libavcodec_ff_spsinfo.h.patch
libavcodec_golomb.h.patch
libavcodec_h263dec.c.patch
libavcodec_h264_parser.c.patch
libavcodec_libavcodec.v.patch
libavcodec_mathops.h.patch
libavcodec_mpeg12enc.c.patch
libavcodec_mpegvideo_enc.c.patch
libavcodec_put_bits.h.patch
libavcodec_vdpau.h.patch
libavcodec_x86_fmtconvert_init.c.patch
libavformat_isom.c.patch
libavformat_matroskaenc.c.patch
libavformat_mpegtsenc.c.patch
libavutil_avutil.h.patch
libavutil_common.h.patch
libavutil_lfg.c.patch
libavutil_lfg.h.patch

I first thought it was a binary, but now that I see it is actually
compiled from source in the avidemux build process, we have control
over it. Therefore, I'll step up to be the primary maintainer.

Do you want me to keep the Qt herd in the metadata.xml as secondary?

> Even if that wasn't the case, separate package doesn't make sense, 
> USE="+system-libs" might

Agreed, an USE flag makes much more sense! I didn't consider this
because I thought it was a binary. Sadly the system library doesn't
work well with avidemux because it doesn't have any of these useful
patches; but indeed, together with mantainers of this package on other
distributions we should be able to push some patches upstream...

Therefore, I think we should keep USE="system-libs" until avidemux is
properly tested to make USE="+system-libs" appropriate.


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Samuli Suominen]

On 02/03/13 16:35, Tom Wijsman wrote:
> On Sat, 02 Mar 2013 15:29:38 +0200
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> The embedded FFmpeg in avidemux is only patched to convert UNIX line
>> endings to DOS line endings to match rest of the avidemux source tree
>
> Nope, it does various patches:
>
>   $ ls -1 avidemux_core/ffmpeg_package/patches
> common.mak.diff
> config.mak.diff
> config.mak.mac.diff
> createPatches.sh

^ That one should generate all of the others :P

> libavcodec_avcodec.h.patch
> libavcodec_ff_spsinfo.h.patch
> libavcodec_golomb.h.patch
> libavcodec_h263dec.c.patch
> libavcodec_h264_parser.c.patch
> libavcodec_libavcodec.v.patch
> libavcodec_mathops.h.patch
> libavcodec_mpeg12enc.c.patch
> libavcodec_mpegvideo_enc.c.patch
> libavcodec_put_bits.h.patch
> libavcodec_vdpau.h.patch
> libavcodec_x86_fmtconvert_init.c.patch
> libavformat_isom.c.patch
> libavformat_matroskaenc.c.patch
> libavformat_mpegtsenc.c.patch
> libavutil_avutil.h.patch
> libavutil_common.h.patch
> libavutil_lfg.c.patch
> libavutil_lfg.h.patch

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Ben de Groot]

On 2 March 2013 22:35, Tom Wijsman <TomWij@gentoo.org> wrote:
> I first thought it was a binary, but now that I see it is actually
> compiled from source in the avidemux build process, we have control
> over it. Therefore, I'll step up to be the primary maintainer.
>
> Do you want me to keep the Qt herd in the metadata.xml as secondary?

No, I don't think that's necessary. Keeping it in video herd makes more sense.

>> Even if that wasn't the case, separate package doesn't make sense,
>> USE="+system-libs" might
>
> Agreed, an USE flag makes much more sense! I didn't consider this
> because I thought it was a binary. Sadly the system library doesn't
> work well with avidemux because it doesn't have any of these useful
> patches; but indeed, together with mantainers of this package on other
> distributions we should be able to push some patches upstream...
>
> Therefore, I think we should keep USE="system-libs" until avidemux is
> properly tested to make USE="+system-libs" appropriate.

If avidemux keeps patching ffmpeg (beyond line-endings), I don't think
it is wise to make system-libs the default. I originally took on this
package when I became a Gentoo dev ~5 years ago, but I hardly use it
anymore and I don't have the time to maintain this. Thanks for
stepping up.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Davide Pesavento]

On Sat, Mar 2, 2013 at 6:35 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Sat, 02 Mar 2013 15:29:38 +0200
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> The embedded FFmpeg in avidemux is only patched to convert UNIX line
>> endings to DOS line endings to match rest of the avidemux source tree
>
> Nope, it does various patches:
>
>  $ ls -1 avidemux_core/ffmpeg_package/patches
> common.mak.diff
> config.mak.diff
> config.mak.mac.diff
> createPatches.sh
> libavcodec_avcodec.h.patch
> libavcodec_ff_spsinfo.h.patch
> libavcodec_golomb.h.patch
> libavcodec_h263dec.c.patch
> libavcodec_h264_parser.c.patch
> libavcodec_libavcodec.v.patch
> libavcodec_mathops.h.patch
> libavcodec_mpeg12enc.c.patch
> libavcodec_mpegvideo_enc.c.patch
> libavcodec_put_bits.h.patch
> libavcodec_vdpau.h.patch
> libavcodec_x86_fmtconvert_init.c.patch
> libavformat_isom.c.patch
> libavformat_matroskaenc.c.patch
> libavformat_mpegtsenc.c.patch
> libavutil_avutil.h.patch
> libavutil_common.h.patch
> libavutil_lfg.c.patch
> libavutil_lfg.h.patch
>
> I first thought it was a binary, but now that I see it is actually
> compiled from source in the avidemux build process, we have control
> over it. Therefore, I'll step up to be the primary maintainer.
>
> Do you want me to keep the Qt herd in the metadata.xml as secondary?

No. video or media-video or whatever it's called makes more sense.

And thanks a lot for stepping up to maintain avidemux!

Best,
Pesa

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Alexis Ballier]

On Sat, 2 Mar 2013 14:08:28 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Sat, 2 Mar 2013 14:54:22 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
> 
> > media-video/avidemux (bundled libs)
> 
> I like this application, but am not so sure about maintaining this...
> =/
> 
> Would it be reasonable to create a new package avidemux-ffmpeg in
> which we create a version of ffmpeg with their patches applied?
> Perhaps we can also remove the parts of ffmpeg that aren't used by
> avidemux to keep the overhead of having ffmpeg twice on the system
> low.
> 
> I don't see any other reliable solution, unless upstream is willing to
> stop bundling ffmpeg and get their patches incorporated on that.
> But upon reading the progress on Debian, there is barely any progress
> on that as far as I am aware of; and I'm not willing to maintain a
> package that has 1) an unpatched ffmpeg that breaks it for people or
> 2) a bundled ffmpeg that keeps it from getting unmasked /
> reliable / ...
> 
> The other approach is for someone to attempt to try to get all these
> patches upstream, but some of them are undocumented which makes it
> hard to understand what the changes actually are done for; and at
> this point in time it is not guaranteed that ffmpeg would take these
> patches.
> 
> So, what is the Qt herd's opinion on creating a avidemux-ffmpeg
> package?

In the end if you dump their ffmpeg version and use it only for
avidemux, the end result is the same as bundling it.

If you want to do things correctly, you'd try to get the patches merged
upstream. Maybe some are not even necessary these days.

First you'd need to have an option to use system ffmpeg. Then you could
work on porting patches.

That is what xbmc is doing: they have a bundled copy with a couple of
patches they try to get merged upstream (mainly windows patches btw)
but allow using system version. That way it is easier to work on fixing
bugs rather than trusting avidemux for adding random undocumented
fixes...

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

On Sat, 2 Mar 2013 14:32:47 +0100
Alexis Ballier <aballier@gentoo.org> wrote:

> In the end if you dump their ffmpeg version and use it only for
> avidemux, the end result is the same as bundling it.

Yeah, I thought they bundled a binary; as it appears they just compile
ffmpeg as well I can manipulate it in the avidemux package itself and
don't need a separate package for that. Nevermind that suggestion.
 
> If you want to do things correctly, you'd try to get the patches
> merged upstream. Maybe some are not even necessary these days.

I'll try to see what I can do...

> First you'd need to have an option to use system ffmpeg. Then you
> could work on porting patches.

Yeah, we can work bug-based instead of patch-based; instead of trying
to contribute undocumented patches upstream, we could base ourselves
upon found problems and report those as bugs upstream. And only attach
one of their patches if it is clear that it fixed that problem.

As said in the other reply, I'll take this package and work on getting
it fixed over the next days. Thank you both for your advice!


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]