Message: previous - next
Month: May 2012

Re: [trinity-devel] Preparing updates for 3.5.13

From: Francois Andriot <francois.andriot@...>
Date: Thu, 03 May 2012 23:51:44 +0200
Le 01/05/2012 22:09, Sl�vek Banko a �crit :
> Hi
> In the user-list, I announced the state of preparation updates for 3.5.13:
> I also strongly modify the article in Etherpad. Now there is also a
> current listing of included patches. This will be easier for me to keep
> it up to date... and perhaps even easier for you:
> I would like to discuss with you whether further delay the official
> release updates? I intended to add to updates all packages for which were
> following patches:
> - Remove additional unneeded tq method conversions
> - Rename obsolete tq methods to standard names
> - Rename a few stragglers
> - Fix inadvertent "TQ" changes
> For some packages, already contained in the update, these patches solve
> tricky problems. But these patches applies to almost all the remaining
> packages. Therefore, I ask if I should go into it (will take some time to
> process it), or ask Tim whether to issue updates as they are ready now?
> Personally, I tend to do - to release as soon as possible. Updates already
> solves many errors. And that's why I find it useful to release as soon as
> possible. What is your opinion?
> I attach link to archive containing the current set of patches (5.4 MiB).
> Maybe useful for others who prepare packages for other distributions.
> Sl�vek

Hello, what would be great (for me), is that patches for stable release 
(currently 3.5.13) are downloadable individually from a central/official 
So that every distro could keep in sync with updated packages, instead 
of doing the work separately.

I'd also like to have source tarballs for when it's out, to 
eliminate the need for patches in packaging process.

About a release date, I'm not really in a hurry, since I already provide 
heavily patched packages for RHEL/Fedora.
So TDE is already working very well and there will be no big difference 
between current 3.5.13 and for the end-users.

BTW, the answer to a previous mail from you is below. (this is not 

Le 02/05/2012 17:35, Sl�vek Banko a �crit :
> Dne �t 24. dubna 2012 Fran�ois Andriot napsal(a):
>> But I did not find a place to download your patches. (I haven't
>> searched a lot ...) If you share them, I will happily use them too.
>> Francois
> Please could you compare if you have included patches that I am not
> incorporated? If will be managed to set up a GIT branch for 3.5.13
> updates, there would be good to incorporate also patches from you.
> My patches are now available for download here:
> Slavek

It takes a long time to compare every patch you have to every patch I 
have :-)
 From what I've seen, we have both backported all (or almost all) 
patches from GIT to TDE 3.5.13 .

The most notable differences are:
1) I have skipped all patches about "QT=>TQT" (or TQT=>QT) renaming, 
because I thought it was a never-ending work in progress which could 
cause hard-to-fix regression.
2) I absolutely need all GCC 4.7 related patch (I see you have some, but 
not all of them). This also applies to ruby 1.9 and libpng 1.4/1.5 .

Also, there are lots of commits by Darell to remove "More applications" 
from program menu, and neither you nor me have taken them. Maybe we 
should consider taking them.

For now, I've seen (or I believe I've seen) that you are lacking the 
following patches:

I have some FTBFS and some features added.

I have some features added.

I've just added a patch to add support for RHEL/Fedora in networkconf 
backend, see:

Too many patches to compare ! I think the only ones I have that you 
don't are RHEL/Fedora specific, so they won't go upstream.
An important point is the famous "startkde" script. Should we try to 
have a stable updated script upstream, or should we keep distro-specific 
changes in every packaging ?

I have some FTBFS on stock 3.5.13.

You do not have patch for bugs: 656 , 764
You do not have patch for commits: 24f144fa , 2b035349

The "klaptopdaemon" from upstream will only work on debian/ubuntu 
because there is a hardcoded "dpkg" command in its source code.
For all other distros, you should apply the following patch (should be 
upstream IMHO):

That's all what I see for now.
Good job BTW :-)