Hi folks,
I'm using trinity on a 64 bit Ubuntu precise (12.04) installation and I want to report a very annoying bug caused by a package conflict of libogg0 from the trinity repository: https://bugs.launchpad.net/trinity-desktop/+bug/977103
Since trinity's libogg0 conflicts with Ubuntu libogg0:i386 several 32 bit applications such as adobe reader can no longer be installed on 64 bit trinity installations.
Is there really a conflict between libogg0 and libogg0:i386 that needs to be in the package definition or can one just remove this tag?
Best Regards, Stefan
Stefan Endrullis wrote:
I'm using trinity on a 64 bit Ubuntu precise (12.04) installation and I want to report a very annoying bug caused by a package conflict of libogg0 from the trinity repository: https://bugs.launchpad.net/trinity-desktop/+bug/977103
Since trinity's libogg0 conflicts with Ubuntu libogg0:i386 several 32 bit applications such as adobe reader can no longer be installed on 64 bit trinity installations.
Is there really a conflict between libogg0 and libogg0:i386 that needs to be in the package definition or can one just remove this tag?
*BUMP*
This problem is still there and causing major issues on recent Ubuntu installations. Is there any reason for Trinity to ship its own libogg0?
Julius
Stefan Endrullis wrote:
I'm using trinity on a 64 bit Ubuntu precise (12.04) installation and I want to report a very annoying bug caused by a package conflict of libogg0 from the trinity repository: https://bugs.launchpad.net/trinity-desktop/+bug/977103
Since trinity's libogg0 conflicts with Ubuntu libogg0:i386 several 32 bit applications such as adobe reader can no longer be installed on 64 bit trinity installations.
Is there really a conflict between libogg0 and libogg0:i386 that needs to be in the package definition or can one just remove this tag?
*BUMP*
This problem is still there and causing major issues on recent Ubuntu installations. Is there any reason for Trinity to ship its own libogg0?
Julius
Only to provide a .la file that was removed some time ago by Ubuntu upstream. 3.5.13 needed that file to build, R14 may not due to build system fixes.
Tim
Timothy Pearson wrote:
Stefan Endrullis wrote:
I'm using trinity on a 64 bit Ubuntu precise (12.04) installation and I want to report a very annoying bug caused by a package conflict of libogg0 from the trinity repository: https://bugs.launchpad.net/trinity-desktop/+bug/977103
Since trinity's libogg0 conflicts with Ubuntu libogg0:i386 several 32 bit applications such as adobe reader can no longer be installed on 64 bit trinity installations.
Is there really a conflict between libogg0 and libogg0:i386 that needs to be in the package definition or can one just remove this tag?
*BUMP*
This problem is still there and causing major issues on recent Ubuntu installations. Is there any reason for Trinity to ship its own libogg0?
Only to provide a .la file that was removed some time ago by Ubuntu upstream. 3.5.13 needed that file to build, R14 may not due to build system fixes.
Would it be possible to remove the offending packages from the repository? This would solve all the multi-arch issues. Another option would be adding "Multi-Arch: same".
Julius
Timothy Pearson wrote:
Stefan Endrullis wrote:
I'm using trinity on a 64 bit Ubuntu precise (12.04) installation and I want to report a very annoying bug caused by a package conflict of libogg0 from the trinity repository: https://bugs.launchpad.net/trinity-desktop/+bug/977103
Since trinity's libogg0 conflicts with Ubuntu libogg0:i386 several 32 bit applications such as adobe reader can no longer be installed on 64 bit trinity installations.
Is there really a conflict between libogg0 and libogg0:i386 that needs to be in the package definition or can one just remove this tag?
*BUMP*
This problem is still there and causing major issues on recent Ubuntu installations. Is there any reason for Trinity to ship its own libogg0?
Only to provide a .la file that was removed some time ago by Ubuntu upstream. 3.5.13 needed that file to build, R14 may not due to build system fixes.
Would it be possible to remove the offending packages from the repository? This would solve all the multi-arch issues. Another option would be adding "Multi-Arch: same".
Julius
Just so I fully understand the problem, is this problem occurring with the nightly builds on Precise, or is it occurring with the 3.5.13 repository forcibly installed onto Precise?
Thanks!
Tim
Timothy Pearson wrote:
Timothy Pearson wrote:
Stefan Endrullis wrote:
I'm using trinity on a 64 bit Ubuntu precise (12.04) installation and I want to report a very annoying bug caused by a package conflict of libogg0 from the trinity repository: https://bugs.launchpad.net/trinity-desktop/+bug/977103
Since trinity's libogg0 conflicts with Ubuntu libogg0:i386 several 32 bit applications such as adobe reader can no longer be installed on 64 bit trinity installations.
Is there really a conflict between libogg0 and libogg0:i386 that needs to be in the package definition or can one just remove this tag?
*BUMP*
This problem is still there and causing major issues on recent Ubuntu installations. Is there any reason for Trinity to ship its own libogg0?
Only to provide a .la file that was removed some time ago by Ubuntu upstream. 3.5.13 needed that file to build, R14 may not due to build system fixes.
Would it be possible to remove the offending packages from the repository? This would solve all the multi-arch issues. Another option would be adding "Multi-Arch: same".
Julius
Just so I fully understand the problem, is this problem occurring with the nightly builds on Precise, or is it occurring with the 3.5.13 repository forcibly installed onto Precise?
I have this problem with the nightly builds on Precise and had it with 3.5.13 as well. I expect that all previous Ubuntu version with multi-arch support are also broken by this however. This would be version 11.04 and later.
Julius
On Wed, Jul 25, 2012 at 11:36 AM, Julius Schwartzenberg julius.schwartzenberg@gmail.com wrote:
Timothy Pearson wrote:
Timothy Pearson wrote:
Stefan Endrullis wrote:
I'm using trinity on a 64 bit Ubuntu precise (12.04) installation and I want to report a very annoying bug caused by a package conflict of libogg0 from the trinity repository: https://bugs.launchpad.net/trinity-desktop/+bug/977103
Since trinity's libogg0 conflicts with Ubuntu libogg0:i386 several 32 bit applications such as adobe reader can no longer be installed on 64 bit trinity installations.
Is there really a conflict between libogg0 and libogg0:i386 that needs to be in the package definition or can one just remove this tag?
*BUMP*
This problem is still there and causing major issues on recent Ubuntu installations. Is there any reason for Trinity to ship its own libogg0?
Only to provide a .la file that was removed some time ago by Ubuntu upstream. 3.5.13 needed that file to build, R14 may not due to build system fixes.
Would it be possible to remove the offending packages from the repository? This would solve all the multi-arch issues. Another option would be adding "Multi-Arch: same".
Julius
Just so I fully understand the problem, is this problem occurring with the nightly builds on Precise, or is it occurring with the 3.5.13 repository forcibly installed onto Precise?
I have this problem with the nightly builds on Precise and had it with 3.5.13 as well. I expect that all previous Ubuntu version with multi-arch support are also broken by this however. This would be version 11.04 and later.
Julius
For me, I was fine on Oneiric (11.10), it only happened when I upgraded to Precise (12.04). Happened in both 3.5.13 (TDE's official Oneiric repo) and 3.5.13.1 (Slavek's Precise repo). Those are the only ones I've tried.
Jeff
On Wednesday 25 of July 2012 18:46:37 Timothy Pearson wrote:
Timothy Pearson wrote:
Stefan Endrullis wrote:
I'm using trinity on a 64 bit Ubuntu precise (12.04) installation and I want to report a very annoying bug caused by a package conflict of libogg0 from the trinity repository: https://bugs.launchpad.net/trinity-desktop/+bug/977103
Since trinity's libogg0 conflicts with Ubuntu libogg0:i386 several 32 bit applications such as adobe reader can no longer be installed on 64 bit trinity installations.
Is there really a conflict between libogg0 and libogg0:i386 that needs to be in the package definition or can one just remove this tag?
*BUMP*
This problem is still there and causing major issues on recent Ubuntu installations. Is there any reason for Trinity to ship its own libogg0?
Only to provide a .la file that was removed some time ago by Ubuntu upstream. 3.5.13 needed that file to build, R14 may not due to build system fixes.
Would it be possible to remove the offending packages from the repository? This would solve all the multi-arch issues. Another option would be adding "Multi-Arch: same".
Julius
Just so I fully understand the problem, is this problem occurring with the nightly builds on Precise, or is it occurring with the 3.5.13 repository forcibly installed onto Precise?
Thanks!
Tim
Tim,
I tried to find some information about the problem with the concurrent installation libogg:amd64 and libogg:i386. And I find a little mystery. When I add a apt source nighlty-build-deps, this library is in the conflict when I try to install both in the aptitude. But if I download these packages and install both packages manually using dpkg, so the conflict does not occur. As the information about the conflict was somewhere in the information for apt.
This would confirm the fact that when I install a library from my local apt source managed by reprepro, so the conflict does not occur.
What could be wrong in apt source managed by Launchpad? Within the package clearly not the problem.
Slavek --
Dne út 18. září 2012 Slávek Banko napsal(a):
Tim,
I tried to find some information about the problem with the concurrent installation libogg:amd64 and libogg:i386. And I find a little mystery. When I add a apt source nighlty-build-deps, this library is in the conflict when I try to install both in the aptitude. But if I download these packages and install both packages manually using dpkg, so the conflict does not occur. As the information about the conflict was somewhere in the information for apt.
This would confirm the fact that when I install a library from my local apt source managed by reprepro, so the conflict does not occur.
What could be wrong in apt source managed by Launchpad? Within the package clearly not the problem.
Slavek
I can confirm that in the Packages downloaded from the apt sources from PPA really missing information: Multi-Arch: same. Although in packages this information is provided.
Note: I noticed that for R14 is dependency libogg-dev-la replaced to libogg-dev. Tim, please, it caused some complications? It can also be used for 3.5.13.1?
Thanks, Slavek --
Dne út 18. záÅà 2012 Slávek Banko napsal(a):
Tim,
I tried to find some information about the problem with the concurrent installation libogg:amd64 and libogg:i386. And I find a little mystery. When I add a apt source nighlty-build-deps, this library is in the conflict when I try to install both in the aptitude. But if I download these packages and install both packages manually using dpkg, so the conflict does not occur. As the information about the conflict was somewhere in the information for apt.
This would confirm the fact that when I install a library from my local apt source managed by reprepro, so the conflict does not occur.
What could be wrong in apt source managed by Launchpad? Within the package clearly not the problem.
Slavek
I can confirm that in the Packages downloaded from the apt sources from PPA really missing information: Multi-Arch: same. Although in packages this information is provided.
This would seem to be a Launchpad bug; not sure if it has been fixed (or even reported!) upstream.
Note: I noticed that for R14 is dependency libogg-dev-la replaced to libogg-dev. Tim, please, it caused some complications? It can also be used for 3.5.13.1?
I have not yet completed an R14 rebuild set with the dependency changed; I still expect some packages to fail and require patching.
Tim
On Tuesday 18 of September 2012 17:23:19 Timothy Pearson wrote:
I can confirm that in the Packages downloaded from the apt sources from PPA really missing information: Multi-Arch: same. Although in packages this information is provided.
This would seem to be a Launchpad bug; not sure if it has been fixed (or even reported!) upstream.
Note: I noticed that for R14 is dependency libogg-dev-la replaced to libogg-dev. Tim, please, it caused some complications? It can also be used for 3.5.13.1?
I have not yet completed an R14 rebuild set with the dependency changed; I still expect some packages to fail and require patching.
Tim
I was hoping that this problem can be resolved any of these paths before releasing 3.5.13.1. But no one probably does not look for quick solutions. How do we do it? We'll leave it for now as it is?
Slavek --
On Tuesday 18 of September 2012 17:23:19 Timothy Pearson wrote:
Dne út 18. záÅà 2012 Slávek Banko napsal(a):
Tim,
I tried to find some information about the problem with the concurrent installation libogg:amd64 and libogg:i386. And I find a little mystery. When I add a apt source nighlty-build-deps, this library is in the conflict when I try to install both in the aptitude. But if I download these packages and install both packages manually using dpkg, so the conflict does not occur. As the information about the conflict was somewhere in the information for apt.
This would confirm the fact that when I install a library from my local apt source managed by reprepro, so the conflict does not occur.
What could be wrong in apt source managed by Launchpad? Within the package clearly not the problem.
Slavek
I can confirm that in the Packages downloaded from the apt sources from PPA really missing information: Multi-Arch: same. Although in packages this information is provided.
This would seem to be a Launchpad bug; not sure if it has been fixed (or even reported!) upstream.
Note: I noticed that for R14 is dependency libogg-dev-la replaced to libogg-dev. Tim, please, it caused some complications? It can also be used for 3.5.13.1?
I have not yet completed an R14 rebuild set with the dependency changed; I still expect some packages to fail and require patching.
Tim
Tim,
please, what tool is used by Launchpad to generate apt sources informations? It would be possible to update only this tool?
Slavek --
On Tuesday 18 of September 2012 17:23:19 Timothy Pearson wrote:
Dne út 18. záÅà 2012 Slávek Banko napsal(a):
Tim,
I tried to find some information about the problem with the
concurrent
installation libogg:amd64 and libogg:i386. And I find a little
mystery.
When I add a apt source nighlty-build-deps, this library is in the conflict when I try to install both in the aptitude. But if I
download
these packages and install both packages manually using dpkg, so the conflict does not occur. As the information about the conflict was somewhere in the information for apt.
This would confirm the fact that when I install a library from my
local
apt source managed by reprepro, so the conflict does not occur.
What could be wrong in apt source managed by Launchpad? Within the package clearly not the problem.
Slavek
I can confirm that in the Packages downloaded from the apt sources
from
PPA really missing information: Multi-Arch: same. Although in packages this information is provided.
This would seem to be a Launchpad bug; not sure if it has been fixed (or even reported!) upstream.
Note: I noticed that for R14 is dependency libogg-dev-la replaced to libogg-dev. Tim, please, it caused some complications? It can also be used for 3.5.13.1?
I have not yet completed an R14 rebuild set with the dependency changed; I still expect some packages to fail and require patching.
Tim
Tim,
please, what tool is used by Launchpad to generate apt sources informations? It would be possible to update only this tool?
Slavek
The proper solution is to remove the broken libogg package from the build-dependencies repository. I still have not completed a full build test with libogg-dev-la removed, so I don't know if this is feasible yet.
Tim
Timothy Pearson wrote:
On Tuesday 18 of September 2012 17:23:19 Timothy Pearson wrote:
Dne út 18. zářà 2012 Slávek Banko napsal(a): I can confirm that in the Packages downloaded from the apt sources
from
PPA really missing information: Multi-Arch: same. Although in packages this information is provided.
This would seem to be a Launchpad bug; not sure if it has been fixed (or even reported!) upstream.
Note: I noticed that for R14 is dependency libogg-dev-la replaced to libogg-dev. Tim, please, it caused some complications? It can also be used for 3.5.13.1?
I have not yet completed an R14 rebuild set with the dependency changed; I still expect some packages to fail and require patching.
please, what tool is used by Launchpad to generate apt sources informations? It would be possible to update only this tool?
Slavek
The proper solution is to remove the broken libogg package from the build-dependencies repository. I still have not completed a full build test with libogg-dev-la removed, so I don't know if this is feasible yet.
Now that we're on this topic. Does Trinity also really need its own python-sip (and python-sip-dbg) packages?
http://bugs.pearsoncomputing.net/show_bug.cgi?id=1012
Thanks, Julius
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Timothy Pearson wrote:
On Tuesday 18 of September 2012 17:23:19 Timothy Pearson wrote:
Dne út 18. zářà 2012 Slávek Banko napsal(a): I can confirm that in the Packages downloaded from the apt sources
from
PPA really missing information: Multi-Arch: same. Although in packages this information is provided.
This would seem to be a Launchpad bug; not sure if it has been fixed (or even reported!) upstream.
Note: I noticed that for R14 is dependency libogg-dev-la replaced to libogg-dev. Tim, please, it caused some complications? It can also be used for 3.5.13.1?
I have not yet completed an R14 rebuild set with the dependency changed; I still expect some packages to fail and require patching.
please, what tool is used by Launchpad to generate apt sources informations? It would be possible to update only this tool?
Slavek
The proper solution is to remove the broken libogg package from the build-dependencies repository. I still have not completed a full build test with libogg-dev-la removed, so I don't know if this is feasible yet.
Now that we're on this topic. Does Trinity also really need its own python-sip (and python-sip-dbg) packages?
http://bugs.pearsoncomputing.net/show_bug.cgi?id=1012
Thanks, Julius
Dreding up an ancient thread here since I got bitten by this bug two years later...
It seems that there was a time when the official Ubuntu Precise multiarch buildroots were broken, and the only symptom was multiarch failures such as this one. A simple binary rebuild against the new buildroot seems to have resolved the problem on my end: https://quickbuild.pearsoncomputing.net/~trinity/+archive/trinity-nightly-bu...
Tim
On Tuesday 03 of June 2014 22:34:54 Timothy Pearson wrote:
Timothy Pearson wrote:
On Tuesday 18 of September 2012 17:23:19 Timothy Pearson wrote:
Dne út 18. zářà 2012 Slávek Banko napsal(a): I can confirm that in the Packages downloaded from the apt sources
from
PPA really missing information: Multi-Arch: same. Although in packages this information is provided.
This would seem to be a Launchpad bug; not sure if it has been fixed (or even reported!) upstream.
Note: I noticed that for R14 is dependency libogg-dev-la replaced to libogg-dev. Tim, please, it caused some complications? It can also be used for 3.5.13.1?
I have not yet completed an R14 rebuild set with the dependency changed; I still expect some packages to fail and require patching.
please, what tool is used by Launchpad to generate apt sources informations? It would be possible to update only this tool?
Slavek
The proper solution is to remove the broken libogg package from the build-dependencies repository. I still have not completed a full build test with libogg-dev-la removed, so I don't know if this is feasible yet.
Now that we're on this topic. Does Trinity also really need its own python-sip (and python-sip-dbg) packages?
http://bugs.pearsoncomputing.net/show_bug.cgi?id=1012
Thanks, Julius
Dreding up an ancient thread here since I got bitten by this bug two years later...
It seems that there was a time when the official Ubuntu Precise multiarch buildroots were broken, and the only symptom was multiarch failures such as this one. A simple binary rebuild against the new buildroot seems to have resolved the problem on my end: https://quickbuild.pearsoncomputing.net/~trinity/+archive/trinity-nightly-b uild-dependencies/+sourcepub/84880/+listing-archive-extra
Tim
I thought that it has been verified that there is no need to hold own libogg, and that it can be smoothly removed from build-deps. Is there a reason for package libogg-dev-la?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Tuesday 03 of June 2014 22:34:54 Timothy Pearson wrote:
Timothy Pearson wrote:
On Tuesday 18 of September 2012 17:23:19 Timothy Pearson wrote:
> Dne út 18. zářà 2012 Slávek Banko napsal(a): > I can confirm that in the Packages downloaded from the apt sources
from
> PPA really missing information: Multi-Arch: same. Although in > packages > this information is provided.
This would seem to be a Launchpad bug; not sure if it has been
fixed
(or even reported!) upstream.
> Note: I noticed that for R14 is dependency libogg-dev-la replaced
to
> libogg-dev. Tim, please, it caused some complications? It can also
be
> used for 3.5.13.1?
I have not yet completed an R14 rebuild set with the dependency changed; I still expect some packages to fail and require patching.
please, what tool is used by Launchpad to generate apt sources informations? It would be possible to update only this tool?
Slavek
The proper solution is to remove the broken libogg package from the build-dependencies repository. I still have not completed a full
build
test with libogg-dev-la removed, so I don't know if this is feasible yet.
Now that we're on this topic. Does Trinity also really need its own python-sip (and python-sip-dbg) packages?
http://bugs.pearsoncomputing.net/show_bug.cgi?id=1012
Thanks, Julius
Dreding up an ancient thread here since I got bitten by this bug two years later...
It seems that there was a time when the official Ubuntu Precise multiarch buildroots were broken, and the only symptom was multiarch failures such as this one. A simple binary rebuild against the new buildroot seems to have resolved the problem on my end: https://quickbuild.pearsoncomputing.net/~trinity/+archive/trinity-nightly-b uild-dependencies/+sourcepub/84880/+listing-archive-extra
Tim
I thought that it has been verified that there is no need to hold own libogg, and that it can be smoothly removed from build-deps. Is there a reason for package libogg-dev-la?
-- Slavek
Honestly I don't remember. If there are no deps then I'll go ahead and remove it.
Tim
On Wednesday 04 of June 2014 02:06:55 Timothy Pearson wrote:
On Tuesday 03 of June 2014 22:34:54 Timothy Pearson wrote:
Timothy Pearson wrote:
On Tuesday 18 of September 2012 17:23:19 Timothy Pearson wrote: >> Dne út 18. zářà 2012 Slávek Banko napsal(a): >> I can confirm that in the Packages downloaded from the apt sources > > from > >> PPA really missing information: Multi-Arch: same. Although in >> packages >> this information is provided. > > This would seem to be a Launchpad bug; not sure if it has been
fixed
> (or > even reported!) upstream. > >> Note: I noticed that for R14 is dependency libogg-dev-la replaced
to
>> libogg-dev. Tim, please, it caused some complications? It can also
be
>> used for 3.5.13.1? > > I have not yet completed an R14 rebuild set with the dependency > changed; > I > still expect some packages to fail and require patching.
please, what tool is used by Launchpad to generate apt sources informations? It would be possible to update only this tool?
Slavek
The proper solution is to remove the broken libogg package from the build-dependencies repository. I still have not completed a full
build
test with libogg-dev-la removed, so I don't know if this is feasible yet.
Now that we're on this topic. Does Trinity also really need its own python-sip (and python-sip-dbg) packages?
http://bugs.pearsoncomputing.net/show_bug.cgi?id=1012
Thanks, Julius
Dreding up an ancient thread here since I got bitten by this bug two years later...
It seems that there was a time when the official Ubuntu Precise multiarch buildroots were broken, and the only symptom was multiarch failures such as this one. A simple binary rebuild against the new buildroot seems to have resolved the problem on my end: https://quickbuild.pearsoncomputing.net/~trinity/+archive/trinity-nightl y-b uild-dependencies/+sourcepub/84880/+listing-archive-extra
Tim
I thought that it has been verified that there is no need to hold own libogg, and that it can be smoothly removed from build-deps. Is there a reason for package libogg-dev-la?
-- Slavek
Honestly I don't remember. If there are no deps then I'll go ahead and remove it.
Tim
Dependence on libogg-dev-la was removed in commits (tde-packaging) 5af3bb60 and fac31b9e. Since then, the own package libogg is not needed.
By the way, nightly-build-deps contain multiple packages that are not needed. For example, ruby, gettext-kde for Ubuntu. For your information, in my deps-r14 PPA can see only the packages that are currently used really.
https://quickbuild.pearsoncomputing.net/~slavek-banko/+archive/deps-r14/+pac...
I also do not use ligogg0. Currently the only dependency packages that I am using in Debian/testing are:
akode compizconfig-python-trinity compiz-fusion-bcop-trinity compiz-fusion-plugins-extra-trinity compiz-fusion-plugins-main-trinity compiz-trinity fireflies gettext-kde imlib libapt-front libbeagle libcompizconfig-trinity libept-trinity libr opensync pcsc-lite-nodbus
which are the same listed in Slavek's repo.
Why is gettext-kde not needed in Ubuntu any more, while it is needed in Debian? I am a little surprised. Cheers Michele
On Wednesday 04 of June 2014 04:20:26 Michele Calgaro wrote:
I also do not use ligogg0. Currently the only dependency packages that I am using in Debian/testing are:
akode compizconfig-python-trinity compiz-fusion-bcop-trinity compiz-fusion-plugins-extra-trinity compiz-fusion-plugins-main-trinity compiz-trinity fireflies gettext-kde imlib libapt-front libbeagle libcompizconfig-trinity libept-trinity libr opensync pcsc-lite-nodbus
which are the same listed in Slavek's repo.
Why is gettext-kde not needed in Ubuntu any more, while it is needed in Debian? I am a little surprised. Cheers Michele
It has a simple explanation: package gettext-kde comes from Ubuntu => is a normal part of Ubuntu, we do not need own package :)
http://packages.ubuntu.com/search?keywords=gettext-kde&searchon=names&am...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
It has a simple explanation: package gettext-kde comes from Ubuntu => is a normal part of Ubuntu, we do not need own package :)
Ah ah! Thanks :)
Michele
I went ahead and removed the ogg and hal packages from the nightly build dependencies repository. The other extraneous packages don't conflict with official packages and I would like to leave them there to be on the safe side for now.
Tim
On Wednesday 04 of June 2014 20:03:13 Timothy Pearson wrote:
It has a simple explanation: package gettext-kde comes from Ubuntu => is a normal part of Ubuntu, we do not need own package :)
Ah ah! Thanks :)
Michele
I went ahead and removed the ogg and hal packages from the nightly build dependencies repository. The other extraneous packages don't conflict with official packages and I would like to leave them there to be on the safe side for now.
Tim
Packages ubuntu-rename-meta and sudo-trinity from nightly build dependencies are replaced by updated packages from Trinity main repository.
Packages libqt-perl and qca-tls are replace by libtqt-perl and tqca-tls in Trinity main repository.
Packages compiz-bcop-trinity are replaced by compiz-fusion-bcop-trinity.
Packages ruby contains some security issues (DSA-2810-1, DSA 2738-1).
I think that all these may be also removed from build-deps.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Wednesday 04 of June 2014 20:03:13 Timothy Pearson wrote:
It has a simple explanation: package gettext-kde comes from Ubuntu =>
is
a normal part of Ubuntu, we do not need own package :)
Ah ah! Thanks :)
Michele
I went ahead and removed the ogg and hal packages from the nightly build dependencies repository. The other extraneous packages don't conflict with official packages and I would like to leave them there to be on the safe side for now.
Tim
Packages ubuntu-rename-meta and sudo-trinity from nightly build dependencies are replaced by updated packages from Trinity main repository.
Packages libqt-perl and qca-tls are replace by libtqt-perl and tqca-tls in Trinity main repository.
Packages compiz-bcop-trinity are replaced by compiz-fusion-bcop-trinity.
Packages ruby contains some security issues (DSA-2810-1, DSA 2738-1).
I think that all these may be also removed from build-deps.
-- Slavek
All cleaned up except the ruby package. The ruby package was in there as TDE did not compile against the obsolete native version provided by upstream as of late 2012. Has this changed?
Thanks!
Tim
All cleaned up except the ruby package. The ruby package was in there as TDE did not compile against the obsolete native version provided by upstream as of late 2012. Has this changed?
In Debian/testing I am building using the Debian ruby package(s).
Cheers Michele
Dne po 9. června 2014 Timothy Pearson napsal(a):
On Wednesday 04 of June 2014 20:03:13 Timothy Pearson wrote:
It has a simple explanation: package gettext-kde comes from Ubuntu =>
is
a normal part of Ubuntu, we do not need own package :)
Ah ah! Thanks :)
Michele
I went ahead and removed the ogg and hal packages from the nightly build dependencies repository. The other extraneous packages don't conflict with official packages and I would like to leave them there to be on the safe side for now.
Tim
Packages ubuntu-rename-meta and sudo-trinity from nightly build dependencies are replaced by updated packages from Trinity main repository.
Packages libqt-perl and qca-tls are replace by libtqt-perl and tqca-tls in Trinity main repository.
Packages compiz-bcop-trinity are replaced by compiz-fusion-bcop-trinity.
Packages ruby contains some security issues (DSA-2810-1, DSA 2738-1).
I think that all these may be also removed from build-deps.
-- Slavek
All cleaned up except the ruby package. The ruby package was in there as TDE did not compile against the obsolete native version provided by upstream as of late 2012. Has this changed?
Thanks!
Tim
If I know the problems were resolved and the builds works successfully with upstream versions. Well, actually, except Debian Jessie, on which is again an update, that cause FTBFS in KOffice...
Fixed in: + koffice e566a4be, fc0c74f6, e1592357, cc278836 + tdebindings: de9980a5, 115acc39, 2712dc64
On Tuesday 18 of September 2012 17:23:19 Timothy Pearson wrote:
Note: I noticed that for R14 is dependency libogg-dev-la replaced to libogg-dev. Tim, please, it caused some complications? It can also be used for 3.5.13.1?
I have not yet completed an R14 rebuild set with the dependency changed; I still expect some packages to fail and require patching.
Tim
Tim,
I noticed that in tdelibs remained one dependency on libogg-dev-la. It is the intent or omission?
Slavek --
On Tuesday 18 of September 2012 17:23:19 Timothy Pearson wrote:
Note: I noticed that for R14 is dependency libogg-dev-la replaced to libogg-dev. Tim, please, it caused some complications? It can also be used for 3.5.13.1?
I have not yet completed an R14 rebuild set with the dependency changed; I still expect some packages to fail and require patching.
Tim
Tim,
I noticed that in tdelibs remained one dependency on libogg-dev-la. It is the intent or omission?
Slavek
That was an oversight. Fixed in GIT hash fac31b9.
Thanks!
Tim
-
Jeffry Johnston -
Julius Schwartzenberg -
Michele Calgaro -
Slávek Banko -
Stefan Endrullis -
Timothy Pearson