On Thursday 17 March 2016 08:35:32 deloptes wrote:

Michele Calgaro wrote:

...

On 03/17/2016 02:09 AM, deloptes wrote:

...

Hi I filed a bug 2613 (https://bugs.trinitydesktop.org/show_bug.cgi?id=2613)

This is really blocking me ATM, hence the high prio I set. How does the fix cycle looks like from time line perspective?

I'm considering downloading the source and patching myself.

thanks in advance

Hi Deloptes, I will fix this (including support for Z format) during the weekend or next week at most. In terms of fix cycle, it depends on what distro and repository you use. If you are on Debian/Ubuntu and use Slavek's preliminary stable build, you can expect the fix to be available right after the fix (just the time to recompile on Slavek's builder). If you are on Debian/Ubuntu and use the nighly builds, same thing. If you use other PPA or other distros, you will probably get the fix with the next R14.0.4 release (probably 2-3 months later). If you need the fix urgently, you will probably have to download the fix from GIT and then rebuild locally and then use that until the next maintenance release.

Cheers Michele

Hi Michele,

I use this - not sure what it is exactly, but I think this is the official repo

deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian jessie main deb-src http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian jessie main deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-builddeps-r14.0.0/debi an jessie main deb-src http://mirror.ppa.trinitydesktop.org/trinity/trinity-builddeps-r14.0.0/debi an jessie main

I don't know what is best to wait or to recompile, because its the libs and there is a lot of packages produced/dependant.

Is it possible to get/download this package after it was build on Slaveks stable build as deb file?

thanks in advance

Why not just use Slávek's Preliminary Stable Builds repository instead of the ones you have? It would solve your problem immediately for very little effort. I switched some while ago because I wanted a patch fast and have never looked back. It is great! You get exactly what will be going into 14.0.4, but you get it sooner. And come the release of 14.0.4 you won't need to upgrade because you will already have it. Note the "Stable" in the name. ;-)

Lisi

On Thursday 17 March 2016 19:06:00 deloptes wrote:

Lisi Reisz wrote:

...

Why not just use Slávek's Preliminary Stable Builds repository instead of the ones you have?  It would solve your problem immediately for very little effort.  I switched some while ago because I wanted a patch fast and have never looked back.  It is great!  You get exactly what will be going into 14.0.4, but you get it sooner.  And come the release of 14.0.4 you won't need to upgrade because you will already have it.  Note the "Stable" in the name. ;-)

Lisi

I don't know - this is new to me and the steak is big as I can not risk, so I had to investigate pro and contra but never got the opportunity to do so. Since I have time to follow up the list closer, it was in some sort of transition, but I think now it settled down. If you have some information to enlighten me, this would be nice.

What would you like to know? Debian users are apt to see Slávek's Preliminary Stable Builds repository as the equivalent of Testing, but that is wrong.

Assuming that you go on using deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian jessie main deb-src http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian jessie main deb and that you update and upgrade regularly, then when 14.0.4 is released you will get all the new packages and patches in one fell, quite large swoop. If you don't want then you will have to stop upgrading or comment out the Trinity repositories.

Those packages and patches are not prepared suddenly over-night. They are gathered up over time and stored until it is time to release them. It is Slávek who stores them. (I think only Slávek, but possibly not only Slávek).

If you change to:

deb http://mirror.xcer.cz/trinity-sb jessie deps-r14 main-r14 deb-src http://mirror.xcer.cz/trinity-sb jessie deps-r14 main-r14

then as the bug patches and new packages are ready, you will get them immediately. Exactly the same ones as you would get later in 14.0.4 when it is released. Mostly bug patches. As with Debian Stable, new things are _mostly_ reserved for the next major release and it is bug fixes which are released meanwhile. So the only difference is when you get them. As there is no such thing as software without bugs, presumably there are occasionally bugs in the bug-fixes, and presumably they are occasionally found and put right.

But I do not see what you would have to lose if you want a patched package urgently. What you are doing now strikes me as just possibly being able to mess up your system. Not very likely, but more likely than stuff released by Slávek, since that has been tested elsewhere, and its tested dependencies worked out, before it reaches your system. The Preliminary Stable Builds repositories are no more risky than any other upgrade.

I'm not sure if that has answered your questions at all. Just ask, if it hasn't. But if you want a particular bug fix to a particular package, and Slávek has the patch, this is in MHO the safest, and certainly the quickest and easiest, way to get it.

Lisi

On Thursday 17 March 2016 22:58:34 deloptes wrote:

if the repo builds up incrementally, does it mean I have all dependencies in one go?

It is intended as the holder for the next point release. The package would not be there. AIUI, without its fully tested dependencies. After all, it would not be functional without them. It is Stable, not Testing. So yes, you get the dependencies in one go. Things only go there when they are ready. (Or believed to be.)

If you would be unhappy installing 14.0.4 in one fell swoop, then don't do this. If you would install 14.0.4, you would get the same, but all at once. I think the nightly builds are for the kind of development you seem to envisage. But I haven't used them, so have not investigated them. Or rather, have not investigated them and have not used them.

Any change has to carry a small risk. But so does stasis.

But don't let me put you off using developmental stuff and helping with developing it!

Lisi

On Friday 18 of March 2016 01:35:21 deloptes wrote:

Lisi Reisz wrote:

...

But don't let me put you off using developmental stuff and helping with developing it!

Lisi

No problem thanks, Lisi.

I'll try this in the dev/test env I'm using.

I am pragmatic and I don't mess up with the system I work on, because I'm sick of not being able to do something I was used to do before. Of course with TDE the risk is really low, but still, I won't run the code I've written on my productive system for the first time. This is my philosophy and has turned to be right over the years.

Regards

As already mentioned exactly Lisi, the preliminary stable builds are not like the Debian "testing" - it would be apposite to compare them to the Debian "stable-proposed-updates":

https://wiki.debian.org/StableProposedUpdates

About dependencies: because packages are built over the preliminary stable builds repository, individual packages may require a versions from the preliminary stable builds repository.

Michele Calgaro wrote:

On 03/17/2016 02:09 AM, deloptes wrote:

...

Hi I filed a bug 2613 (https://bugs.trinitydesktop.org/show_bug.cgi?id=2613)

This is really blocking me ATM, hence the high prio I set. How does the fix cycle looks like from time line perspective?

I'm considering downloading the source and patching myself.

thanks in advance

Hi Deloptes, I will fix this (including support for Z format) during the weekend or next week at most. In terms of fix cycle, it depends on what distro and repository you use. If you are on Debian/Ubuntu and use Slavek's preliminary stable build, you can expect the fix to be available right after the fix (just the time to recompile on Slavek's builder). If you are on Debian/Ubuntu and use the nighly builds, same thing. If you use other PPA or other distros, you will probably get the fix with the next R14.0.4 release (probably 2-3 months later). If you need the fix urgently, you will probably have to download the fix from GIT and then rebuild locally and then use that until the next maintenance release.

Cheers Michele

I downloaded tdelibs - r14.0.3.tar.gz and tde-packaging - r14.0.3.tar.gz

but when I try cmake I get following error. Where are those macros defined?

thanks

-- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") CMake Error at CMakeLists.txt:39 (include): include could not find load file:

TDEMacros

CMake Error at CMakeLists.txt:40 (include): include could not find load file:

TDESetupPaths

CMake Error at CMakeLists.txt:45 (tde_setup_paths): Unknown CMake command "tde_setup_paths".

-- Configuring incomplete, errors occurred!

Slávek Banko wrote:

On Thursday 17 of March 2016 10:43:38 deloptes wrote:

...

Michele Calgaro wrote:

...

On 03/17/2016 02:09 AM, deloptes wrote:

...

Hi I filed a bug 2613 (https://bugs.trinitydesktop.org/show_bug.cgi?id=2613)

This is really blocking me ATM, hence the high prio I set. How does the fix cycle looks like from time line perspective?

I'm considering downloading the source and patching myself.

thanks in advance

Hi Deloptes, I will fix this (including support for Z format) during the weekend or next week at most. In terms of fix cycle, it depends on what distro and repository you use. If you are on Debian/Ubuntu and use Slavek's preliminary stable build, you can expect the fix to be available right after the fix (just the time to recompile on Slavek's builder). If you are on Debian/Ubuntu and use the nighly builds, same thing. If you use other PPA or other distros, you will probably get the fix with the next R14.0.4 release (probably 2-3 months later). If you need the fix urgently, you will probably have to download the fix from GIT and then rebuild locally and then use that until the next maintenance release.

Cheers Michele

I downloaded tdelibs - r14.0.3.tar.gz and tde-packaging - r14.0.3.tar.gz

but when I try cmake I get following error. Where are those macros defined?

thanks

-- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") CMake Error at CMakeLists.txt:39 (include): include could not find load file:

TDEMacros

CMake Error at CMakeLists.txt:40 (include): include could not find load file:

TDESetupPaths

CMake Error at CMakeLists.txt:45 (tde_setup_paths): Unknown CMake command "tde_setup_paths".

-- Configuring incomplete, errors occurred!

Tarballs generated from the git unfortunately are not sufficient because they contain submodules - usually admin and cmake. Either you have to download and add these submodules, or you can use the "orig.tar.xz" from debian / ubuntu repository - for example:

http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/ubuntu/pool/mai...

http://mirror.xcer.cz/trinity-sb/pool/main-r14/t/tdelibs-trinity/tdelibs-tri...

Thanks Slavek, I think I owe you one or two beers already.

I'll give it a try right away.

regards

On Thursday 17 of March 2016 23:10:28 deloptes wrote:

Slávek Banko wrote:

...

On Thursday 17 of March 2016 10:43:38 deloptes wrote:

Tarballs generated from the git unfortunately are not sufficient because they contain submodules - usually admin and cmake. Either you have to download and add these submodules, or you can use the "orig.tar.xz" from debian / ubuntu repository - for example:

http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/ubuntu/pool/ma in/t/tdelibs-trinity/tdelibs-trinity_14.0.3.orig.tar.xz

http://mirror.xcer.cz/trinity-sb/pool/main-r14/t/tdelibs-trinity/tdelibs-tr inity_14.0.4~pre1.orig.tar.xz

Hi Slavek, Michele, all, where do I get the proper debian files?

http://mirror.git.trinitydesktop.org/cgit/tde-packaging/tree/debian/squeeze /tdelibs/debian/changelog

tdelibs-trinity (4:3.5.12-0ubuntu6+r1116280) lucid; urgency=low

• Automated svn build

deloptes, you took the right file! The trick is (very simplified) as follows:

1) take the source code of module from the git (including submodules) 2) add the appropriate debian folder from the git source tde-packaging 3) into debian/changelog add at the top version of your build and date 4) build your package :)

As I mentioned, the procedure is shown greatly simplified. For example: because the packages are created in the format "3.0 (quilt)", you have to prepare tarball "orig.tar.xz" with the corresponding version number. To enable a smooth path for update packages, you need to establish the method of counting the basic version of the packages and in addition counting version of the "packaging" files - including the version of the distribution, for which the package is created. For this reason, Tim, Michele and I have scripts that automate this process.

If you were interested in: For preliminary stable builds repository is now from one git module generated 18 source packages - for each version of the distributions. From these source packages is then 49 builds of binary packages - for each platform of each distribution. Establish rules for counting versions is therefore very important step :)

If you plan to simply test your upcoming patches on the current version of the package, you can simplify your work as follows:

1) apt-get source _package_ "orig.tar.xz", "debian.tar.xz" and "dsc" will be downloaded and extracted 2) add your desired patches to folder debian/patches and write them to the list debian/patches/series 3) if you wish, enter a higher version number in the debian/changelog 4) build your updated package :)