[arch-dev-public] libpng todo list
I just created a todo list containing 163 packages. This todo list contains all packages that link to libpng and that should get rebuilt when we update to libpng 1.4.0.
On Fri, Jan 8, 2010 at 3:59 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
I just created a todo list containing 163 packages. This todo list contains all packages that link to libpng and that should get rebuilt when we update to libpng 1.4.0.
*shudder*
On Fri, Jan 8, 2010 at 2:43 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Jan 8, 2010 at 3:59 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
I just created a todo list containing 163 packages. This todo list contains all packages that link to libpng and that should get rebuilt when we update to libpng 1.4.0.
So how is something like this accomplished? Do we coordinate a rebuild day for most devs to update their packages?
*shudder*
Heh that's what I thought. I had adopted libpng some time ago when rummaging through our orphans, but I orphaned it again after seeing how many apps were dependent on it--the thought of botching that was too much for me.
Aaron Griffin wrote:
On Fri, Jan 8, 2010 at 3:59 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
I just created a todo list containing 163 packages. This todo list contains all packages that link to libpng and that should get rebuilt when we update to libpng 1.4.0.
*shudder*
And that does not include [community]... When do you want to start this? In particular, do we get the ffmpeg/x264 rebuilds done a moved from [testing] first? Allan
On 01/09/2010 02:24 AM, Allan McRae wrote:
Aaron Griffin wrote:
On Fri, Jan 8, 2010 at 3:59 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
I just created a todo list containing 163 packages. This todo list contains all packages that link to libpng and that should get rebuilt when we update to libpng 1.4.0.
*shudder*
And that does not include [community]...
When do you want to start this? In particular, do we get the ffmpeg/x264 rebuilds done a moved from [testing] first?
Allan
yes. i'll do them later today. i just have to add fixes(feature requests) that are on bugtracker. -- Ionut
On Sat, 2010-01-09 at 10:24 +1000, Allan McRae wrote:
When do you want to start this? In particular, do we get the ffmpeg/x264 rebuilds done a moved from [testing] first?
I just made the todo list to show how much work is involved in this. Rebuilding 163 packages requires some serious planning. I can dedicate the next weekend for Archlinux, I almost have a full weekend including friday available. My core2quad is idle at this moment, it could use some build tasks ;) As for community: that takes 145 rebuilds. I could help out a bit on that also, but I have no idea about our community infrastructure, I never built any package for AUR or community before.
On 09/01/2010 11:12, Jan de Groot wrote:
On Sat, 2010-01-09 at 10:24 +1000, Allan McRae wrote:
When do you want to start this? In particular, do we get the ffmpeg/x264 rebuilds done a moved from [testing] first?
I just made the todo list to show how much work is involved in this. Rebuilding 163 packages requires some serious planning. I can dedicate the next weekend for Archlinux, I almost have a full weekend including friday available. My core2quad is idle at this moment, it could use some build tasks ;)
As for community: that takes 145 rebuilds. I could help out a bit on that also, but I have no idea about our community infrastructure, I never built any package for AUR or community before.
Hi folks, back again after six weeks of inactivity (Arch-Linux-wise, that is) ;) I intended to update texlive-bin these next few days, but since it is included in the libpng TODO list, I wonder whether it might be wiser to rebuild with the new libpng and push it to testing, rather that release it now and release a new, identical package for the new libpng a few days later. Or will this take rather weeks? What do you think? Regards to all and best wishes for the new year (also to Roman, whose orthodox new year shall begin next week I believe). FC
Am 09.01.2010 11:12, schrieb Jan de Groot:
On Sat, 2010-01-09 at 10:24 +1000, Allan McRae wrote:
When do you want to start this? In particular, do we get the ffmpeg/x264 rebuilds done a moved from [testing] first?
I just made the todo list to show how much work is involved in this. Rebuilding 163 packages requires some serious planning. I can dedicate the next weekend for Archlinux, I almost have a full weekend including friday available. My core2quad is idle at this moment, it could use some build tasks ;)
As for community: that takes 145 rebuilds. I could help out a bit on that also, but I have no idea about our community infrastructure, I never built any package for AUR or community before.
You would need access to sigurd and access svn-community from there, the rest is identical infrastructure-wise.
Jan de Groot wrote:
On Sat, 2010-01-09 at 10:24 +1000, Allan McRae wrote:
When do you want to start this? In particular, do we get the ffmpeg/x264 rebuilds done a moved from [testing] first?
I just made the todo list to show how much work is involved in this. Rebuilding 163 packages requires some serious planning. I can dedicate the next weekend for Archlinux, I almost have a full weekend including friday available. My core2quad is idle at this moment, it could use some build tasks ;)
As for community: that takes 145 rebuilds. I could help out a bit on that also, but I have no idea about our community infrastructure, I never built any package for AUR or community before.
So just to add to the fun :P
sudo checkpkg Password: 18,19c18,19 < usr/lib/libjpeg.so.7 < usr/lib/libjpeg.so.7.0.0
usr/lib/libjpeg.so.8 usr/lib/libjpeg.so.8.0.0 usr/lib/libjpeg.so.8: SONAME libjpeg.so.8 usr/lib/libjpeg.so.8.0.0: SONAME libjpeg.so.8
This should overlap a lot. Do we want to do both at once? Allan
On Sun, 2010-01-10 at 21:43 +1000, Allan McRae wrote:
sudo checkpkg Password: 18,19c18,19 < usr/lib/libjpeg.so.7 < usr/lib/libjpeg.so.7.0.0
usr/lib/libjpeg.so.8 usr/lib/libjpeg.so.8.0.0 usr/lib/libjpeg.so.8: SONAME libjpeg.so.8 usr/lib/libjpeg.so.8.0.0: SONAME libjpeg.so.8
This should overlap a lot. Do we want to do both at once?
I think that's a good thing to do. Could you build a todo list for libjpeg also? BTW: checkpkg works as non-root also now, pacman -Sp works as non-root.
Jan de Groot wrote:
On Sun, 2010-01-10 at 21:43 +1000, Allan McRae wrote:
sudo checkpkg Password: 18,19c18,19 < usr/lib/libjpeg.so.7 < usr/lib/libjpeg.so.7.0.0
usr/lib/libjpeg.so.8 usr/lib/libjpeg.so.8.0.0 usr/lib/libjpeg.so.8: SONAME libjpeg.so.8 usr/lib/libjpeg.so.8.0.0: SONAME libjpeg.so.8
This should overlap a lot. Do we want to do both at once?
I think that's a good thing to do. Could you build a todo list for libjpeg also?
I haven't rsynced my packages in several weeks and I never do [community] so perhaps Pierre can do this for me...
BTW: checkpkg works as non-root also now, pacman -Sp works as non-root.
Awesome. It would be even better if it tried getting the package out of the pacman cache first. Someone please implement it for me! :D
On Sun, Jan 10, 2010 at 7:03 AM, Allan McRae <allan@archlinux.org> wrote:
Jan de Groot wrote:
On Sun, 2010-01-10 at 21:43 +1000, Allan McRae wrote:
> sudo checkpkg Password: 18,19c18,19 < usr/lib/libjpeg.so.7 < usr/lib/libjpeg.so.7.0.0 --- > usr/lib/libjpeg.so.8 > usr/lib/libjpeg.so.8.0.0 usr/lib/libjpeg.so.8: SONAME libjpeg.so.8 usr/lib/libjpeg.so.8.0.0: SONAME libjpeg.so.8
This should overlap a lot. Do we want to do both at once?
I think that's a good thing to do. Could you build a todo list for libjpeg also?
I haven't rsynced my packages in several weeks and I never do [community] so perhaps Pierre can do this for me...
BTW: checkpkg works as non-root also now, pacman -Sp works as non-root.
Awesome. It would be even better if it tried getting the package out of the pacman cache first. Someone please implement it for me! :D
I tought I implemented it already: http://projects.archlinux.org/devtools.git/commit/?id=61e8cd97fb01997859b135... That commit should be in the last devtools release.
Eric Bélanger wrote:
On Sun, Jan 10, 2010 at 7:03 AM, Allan McRae <allan@archlinux.org> wrote:
sudo checkpkg Password: 18,19c18,19 < usr/lib/libjpeg.so.7 < usr/lib/libjpeg.so.7.0.0
usr/lib/libjpeg.so.8 usr/lib/libjpeg.so.8.0.0 usr/lib/libjpeg.so.8: SONAME libjpeg.so.8 usr/lib/libjpeg.so.8.0.0: SONAME libjpeg.so.8
This should overlap a lot. Do we want to do both at once? I think that's a good thing to do. Could you build a todo list for
On Sun, 2010-01-10 at 21:43 +1000, Allan McRae wrote: libjpeg also? I haven't rsynced my packages in several weeks and I never do [community] so
Jan de Groot wrote: perhaps Pierre can do this for me...
BTW: checkpkg works as non-root also now, pacman -Sp works as non-root. Awesome. It would be even better if it tried getting the package out of the pacman cache first. Someone please implement it for me! :D
I tought I implemented it already: http://projects.archlinux.org/devtools.git/commit/?id=61e8cd97fb01997859b135...
That commit should be in the last devtools release.
That is $PKGDEST which is not necessary the pacman cache.
On Sun, Jan 10, 2010 at 9:44 AM, Allan McRae <allan@archlinux.org> wrote:
Eric Bélanger wrote:
On Sun, Jan 10, 2010 at 7:03 AM, Allan McRae <allan@archlinux.org> wrote:
Jan de Groot wrote:
On Sun, 2010-01-10 at 21:43 +1000, Allan McRae wrote:
> sudo checkpkg Password: 18,19c18,19 < usr/lib/libjpeg.so.7 < usr/lib/libjpeg.so.7.0.0 --- > usr/lib/libjpeg.so.8 > usr/lib/libjpeg.so.8.0.0 usr/lib/libjpeg.so.8: SONAME libjpeg.so.8 usr/lib/libjpeg.so.8.0.0: SONAME libjpeg.so.8
This should overlap a lot. Do we want to do both at once?
I think that's a good thing to do. Could you build a todo list for libjpeg also?
I haven't rsynced my packages in several weeks and I never do [community] so perhaps Pierre can do this for me...
BTW: checkpkg works as non-root also now, pacman -Sp works as non-root.
Awesome. It would be even better if it tried getting the package out of the pacman cache first. Someone please implement it for me! :D
I tought I implemented it already:
http://projects.archlinux.org/devtools.git/commit/?id=61e8cd97fb01997859b135...
That commit should be in the last devtools release.
That is $PKGDEST which is not necessary the pacman cache.
Yes. right. But it can be easily implemented. In checkpkg, get the pacman cache from pacman.conf with a: CacheDir=$(grep '^CacheDir=' /etc/pacman.conf | cut -d= -f2) then add another if check at the end of my above commit: elif [ -f $CacheDir/$oldpkg ]; then cp $CacheDir/$oldpkg . Feel free to test and make a patch.
On Sun, Jan 10, 2010 at 9:55 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Sun, Jan 10, 2010 at 9:44 AM, Allan McRae <allan@archlinux.org> wrote:
Eric Bélanger wrote:
On Sun, Jan 10, 2010 at 7:03 AM, Allan McRae <allan@archlinux.org> wrote:
Jan de Groot wrote:
On Sun, 2010-01-10 at 21:43 +1000, Allan McRae wrote:
> sudo checkpkg Password: 18,19c18,19 < usr/lib/libjpeg.so.7 < usr/lib/libjpeg.so.7.0.0 --- > usr/lib/libjpeg.so.8 > usr/lib/libjpeg.so.8.0.0 usr/lib/libjpeg.so.8: SONAME libjpeg.so.8 usr/lib/libjpeg.so.8.0.0: SONAME libjpeg.so.8
This should overlap a lot. Do we want to do both at once?
I think that's a good thing to do. Could you build a todo list for libjpeg also?
I haven't rsynced my packages in several weeks and I never do [community] so perhaps Pierre can do this for me...
BTW: checkpkg works as non-root also now, pacman -Sp works as non-root.
Awesome. It would be even better if it tried getting the package out of the pacman cache first. Someone please implement it for me! :D
I tought I implemented it already:
http://projects.archlinux.org/devtools.git/commit/?id=61e8cd97fb01997859b135...
That commit should be in the last devtools release.
That is $PKGDEST which is not necessary the pacman cache.
Yes. right. But it can be easily implemented. In checkpkg, get the pacman cache from pacman.conf with a:
CacheDir=$(grep '^CacheDir=' /etc/pacman.conf | cut -d= -f2)
You might want/need to give it a default value: CacheDir= /var/cache/pacman/pkg/ CacheDir=$(grep '^CacheDir=' /etc/pacman.conf | cut -d= -f2)
then add another if check at the end of my above commit:
elif [ -f $CacheDir/$oldpkg ]; then cp $CacheDir/$oldpkg .
Feel free to test and make a patch.
On Sun, Jan 10, 2010 at 6:51 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Sun, 2010-01-10 at 21:43 +1000, Allan McRae wrote:
> sudo checkpkg Password: 18,19c18,19 < usr/lib/libjpeg.so.7 < usr/lib/libjpeg.so.7.0.0 --- > usr/lib/libjpeg.so.8 > usr/lib/libjpeg.so.8.0.0 usr/lib/libjpeg.so.8: SONAME libjpeg.so.8 usr/lib/libjpeg.so.8.0.0: SONAME libjpeg.so.8
This should overlap a lot. Do we want to do both at once?
I think that's a good thing to do. Could you build a todo list for libjpeg also?
BTW: checkpkg works as non-root also now, pacman -Sp works as non-root.
imagemagick will also have a soname bump. We might as well do it with the libpng and libjpeg ones as there is some overlap. Could someone create the todo list? The sonames are: usr/lib/libMagickCore.so.3: SONAME libMagickCore.so.3 usr/lib/libMagickCore.so.3.0.0: SONAME libMagickCore.so.3 usr/lib/libMagick++.so.3: SONAME libMagick++.so.3 usr/lib/libMagick++.so.3.0.0: SONAME libMagick++.so.3 usr/lib/libMagickWand.so.3: SONAME libMagickWand.so.3 usr/lib/libMagickWand.so.3.0.0: SONAME libMagickWand.so.3 Thanks Eric
Eric Bélanger wrote:
On Sun, Jan 10, 2010 at 6:51 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
sudo checkpkg Password: 18,19c18,19 < usr/lib/libjpeg.so.7 < usr/lib/libjpeg.so.7.0.0
usr/lib/libjpeg.so.8 usr/lib/libjpeg.so.8.0.0 usr/lib/libjpeg.so.8: SONAME libjpeg.so.8 usr/lib/libjpeg.so.8.0.0: SONAME libjpeg.so.8
This should overlap a lot. Do we want to do both at once? I think that's a good thing to do. Could you build a todo list for
On Sun, 2010-01-10 at 21:43 +1000, Allan McRae wrote: libjpeg also?
BTW: checkpkg works as non-root also now, pacman -Sp works as non-root.
imagemagick will also have a soname bump. We might as well do it with the libpng and libjpeg ones as there is some overlap. Could someone create the todo list? The sonames are:
usr/lib/libMagickCore.so.3: SONAME libMagickCore.so.3 usr/lib/libMagickCore.so.3.0.0: SONAME libMagickCore.so.3 usr/lib/libMagick++.so.3: SONAME libMagick++.so.3 usr/lib/libMagick++.so.3.0.0: SONAME libMagick++.so.3 usr/lib/libMagickWand.so.3: SONAME libMagickWand.so.3 usr/lib/libMagickWand.so.3.0.0: SONAME libMagickWand.so.3
autotrace dvdauthor libfprint obex-data-server psiconv pstoedit transcode xine-lib + any in [community]...
Talking to Jan, we really need a custom repo for this given the size of the rebuild and the length of time it will take. So I made the folders needed for a [jpng] repo. After making ~/staging/jpng I uploaded packages with commitpkg jpng "message" but then how do I get them to the repo. /arch/db-update checks the names of the repo used and of course jpng is not there... What am I missing? Allan
On 01/16/2010 05:00 AM, Allan McRae wrote:
Talking to Jan, we really need a custom repo for this given the size of the rebuild and the length of time it will take. So I made the folders needed for a [jpng] repo.
After making ~/staging/jpng I uploaded packages with commitpkg jpng "message"
but then how do I get them to the repo. /arch/db-update checks the names of the repo used and of course jpng is not there... What am I missing?
Allan
i don't think you can using db-update. i see in db-functions has a static return list. get_repos_for_host() { if [ "$(hostname)" = "sigurd" ]; then echo "community community-testing" else echo "core extra testing" fi } -- Ionut
On Sat, Jan 16, 2010 at 12:23, Ionut Biru <biru.ionut@gmail.com> wrote:
i don't think you can using db-update. i see in db-functions has a static return list.
get_repos_for_host() { if [ "$(hostname)" = "sigurd" ]; then echo "community community-testing" else echo "core extra testing" fi }
-- Ionut
Seems like it wouldn't be hard to give it a conf file using an associative array so that we could define these things on the fly.
Ionut Biru wrote:
On 01/16/2010 05:00 AM, Allan McRae wrote:
Talking to Jan, we really need a custom repo for this given the size of the rebuild and the length of time it will take. So I made the folders needed for a [jpng] repo.
After making ~/staging/jpng I uploaded packages with commitpkg jpng "message"
but then how do I get them to the repo. /arch/db-update checks the names of the repo used and of course jpng is not there... What am I missing?
Allan
i don't think you can using db-update. i see in db-functions has a static return list.
get_repos_for_host() { if [ "$(hostname)" = "sigurd" ]; then echo "community community-testing" else echo "core extra testing" fi }
Would it be possible to (temporarily) add jpng to the list for gerolde? That way we can use "/arch/db-update jpng" to add packages to the repo and have all the safety measures the db-scripts bring instead of manually using repo-add. Any objections? Allan
On Sun, 17 Jan 2010 11:00:31 +1000, Allan McRae <allan@archlinux.org> wrote:
Would it be possible to (temporarily) add jpng to the list for gerolde? That way we can use "/arch/db-update jpng" to add packages to the repo and have all the safety measures the db-scripts bring instead of manually using repo-add.
Any objections? Allan
Does not soud like a bad idea. I have added the repo to https://www.archlinux.de/?page=Packages;repository=7 and the diff list at https://www.archlinux.de/?page=ArchitectureDifferences Maybe that is of any help. I did not know that we need to patch some/many package to be build with the new libpng. However: Do you think we can merge that repo into testing once the most important packages are done? I fear we'll start to block each other or do unnecessary rebuilds soon. We are also working on kde-unstable (on top of testing) which should be merged into extra at the first week of February. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Pierre Schmitz wrote:
On Sun, 17 Jan 2010 11:00:31 +1000, Allan McRae <allan@archlinux.org> wrote:
Would it be possible to (temporarily) add jpng to the list for gerolde? That way we can use "/arch/db-update jpng" to add packages to the repo and have all the safety measures the db-scripts bring instead of manually using repo-add.
Any objections? Allan
Does not soud like a bad idea.
I added jpng as an "approved repo" for gerolde. It add packages there: 1) create ~/staging/jpng on gerolde 2) upload using: commitpkg jpng "message" 3) on gerolde: /arch/db-update jpng
I have added the repo to https://www.archlinux.de/?page=Packages;repository=7 and the diff list at https://www.archlinux.de/?page=ArchitectureDifferences Maybe that is of any help.
I did not know that we need to patch some/many package to be build with the new libpng. However: Do you think we can merge that repo into testing once the most important packages are done? I fear we'll start to block each other or do unnecessary rebuilds soon. We are also working on kde-unstable (on top of testing) which should be merged into extra at the first week of February.
It all depends how many people help with the rebuild... The last few rebuilds have been done by only two or three people. We could get through most of this in a day or two if people helped out. Allan
On Sun, 17 Jan 2010 12:14:16 +1000, Allan McRae <allan@archlinux.org> wrote:
It all depends how many people help with the rebuild... The last few rebuilds have been done by only two or three people. We could get through most of this in a day or two if people helped out.
Allan
It seems the most important packages are rebuild now. What do you guys think to merge the jpng repo into testing now? This way we might speed up the process and the TUs could start building packages for community-testing. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 01/18/2010 11:53 PM, Pierre Schmitz wrote:
On Sun, 17 Jan 2010 12:14:16 +1000, Allan McRae<allan@archlinux.org> wrote:
It all depends how many people help with the rebuild... The last few rebuilds have been done by only two or three people. We could get through most of this in a day or two if people helped out.
Allan
It seems the most important packages are rebuild now. What do you guys think to merge the jpng repo into testing now? This way we might speed up the process and the TUs could start building packages for community-testing.
that's what i said:D -- Ionut
Pierre Schmitz wrote:
On Sun, 17 Jan 2010 12:14:16 +1000, Allan McRae <allan@archlinux.org> wrote:
It all depends how many people help with the rebuild... The last few rebuilds have been done by only two or three people. We could get through most of this in a day or two if people helped out.
Allan
It seems the most important packages are rebuild now. What do you guys think to merge the jpng repo into testing now? This way we might speed up the process and the TUs could start building packages for community-testing.
Sounds fine. It looks like less patching is needed for libpng that was initially thought. A big cheer to all those who have helped out with the rebuild so far (Andrea, Eric, Ionut, Jan and Pierre). I have not been any help due to work commitments. A quick count shows there are still 99 packages left to be rebuilt for [extra] so there is plenty of scope for the rest of us to lend a hand. Allan
On 01/19/2010 02:32 AM, Allan McRae wrote:
Pierre Schmitz wrote:
On Sun, 17 Jan 2010 12:14:16 +1000, Allan McRae <allan@archlinux.org> wrote:
It all depends how many people help with the rebuild... The last few rebuilds have been done by only two or three people. We could get through most of this in a day or two if people helped out.
Allan
It seems the most important packages are rebuild now. What do you guys think to merge the jpng repo into testing now? This way we might speed up the process and the TUs could start building packages for community-testing.
Sounds fine. It looks like less patching is needed for libpng that was initially thought.
A big cheer to all those who have helped out with the rebuild so far (Andrea, Eric, Ionut, Jan and Pierre). I have not been any help due to work commitments. A quick count shows there are still 99 packages left to be rebuilt for [extra] so there is plenty of scope for the rest of us to lend a hand.
Allan
i'll send a warning now and in the morning i'll move them all. btw there is a script that can be used to moved all packages or i have to use db-move? -- Ionut
Ionut Biru wrote:
On 01/19/2010 02:32 AM, Allan McRae wrote:
Pierre Schmitz wrote:
On Sun, 17 Jan 2010 12:14:16 +1000, Allan McRae <allan@archlinux.org> wrote:
It all depends how many people help with the rebuild... The last few rebuilds have been done by only two or three people. We could get through most of this in a day or two if people helped out.
Allan
It seems the most important packages are rebuild now. What do you guys think to merge the jpng repo into testing now? This way we might speed up the process and the TUs could start building packages for community-testing.
Sounds fine. It looks like less patching is needed for libpng that was initially thought.
A big cheer to all those who have helped out with the rebuild so far (Andrea, Eric, Ionut, Jan and Pierre). I have not been any help due to work commitments. A quick count shows there are still 99 packages left to be rebuilt for [extra] so there is plenty of scope for the rest of us to lend a hand.
Allan
i'll send a warning now and in the morning i'll move them all. btw there is a script that can be used to moved all packages or i have to use db-move?
db-move it is... although your are moving everything in the jpng folder so it should be easy to script. Allan
On Mon, Jan 18, 2010 at 8:19 PM, Allan McRae <allan@archlinux.org> wrote:
Ionut Biru wrote:
On 01/19/2010 02:32 AM, Allan McRae wrote:
Pierre Schmitz wrote:
On Sun, 17 Jan 2010 12:14:16 +1000, Allan McRae <allan@archlinux.org> wrote:
It all depends how many people help with the rebuild... The last few rebuilds have been done by only two or three people. We could get through most of this in a day or two if people helped out.
Allan
It seems the most important packages are rebuild now. What do you guys think to merge the jpng repo into testing now? This way we might speed up the process and the TUs could start building packages for community-testing.
Sounds fine. It looks like less patching is needed for libpng that was initially thought.
A big cheer to all those who have helped out with the rebuild so far (Andrea, Eric, Ionut, Jan and Pierre). I have not been any help due to work commitments. A quick count shows there are still 99 packages left to be rebuilt for [extra] so there is plenty of scope for the rest of us to lend a hand.
Allan
i'll send a warning now and in the morning i'll move them all. btw there is a script that can be used to moved all packages or i have to use db-move?
db-move it is... although your are moving everything in the jpng folder so it should be easy to script.
Allan
wxgtk-2.6 doesn't build (error message below). Any objection if we remove it? It is only used by one package in community (comical) which is orphaned and who's last release was in 2006. In file included from ./src/gtk/gsockgtk.cpp:20: ./include/wx/gsocket.h:40: error: using typedef-name 'GSocket' after 'class' /usr/include/glib-2.0/gio/giotypes.h:120: error: 'GSocket' has a previous declaration here In file included from ./include/wx/gsocket.h:179, from ./src/gtk/gsockgtk.cpp:20: ./include/wx/unix/gsockunx.h:40: error: using typedef-name 'GSocket' after 'class' /usr/include/glib-2.0/gio/giotypes.h:120: error: 'GSocket' has a previous declaration here ./src/gtk/gsockgtk.cpp: In function 'void _GSocket_GDK_Input(void*, gint, GdkInputCondition)': ./src/gtk/gsockgtk.cpp:33: error: 'struct _GSocket' has no member named 'Detected_Read' ./src/gtk/gsockgtk.cpp:35: error: 'struct _GSocket' has no member named 'Detected_Write' ./src/gtk/gsockgtk.cpp: In member function 'virtual bool GSocketGUIFunctionsTableConcrete::Init_Socket(GSocket*)': ./src/gtk/gsockgtk.cpp:55: error: 'struct _GSocket' has no member named 'm_gui_dependent' ./src/gtk/gsockgtk.cpp:56: error: 'struct _GSocket' has no member named 'm_gui_dependent' ./src/gtk/gsockgtk.cpp: In member function 'virtual void GSocketGUIFunctionsTableConcrete::Destroy_Socket(GSocket*)': ./src/gtk/gsockgtk.cpp:66: error: 'struct _GSocket' has no member named 'm_gui_dependent' ./src/gtk/gsockgtk.cpp: In member function 'virtual void GSocketGUIFunctionsTableConcrete::Install_Callback(GSocket*, GSocketEvent)': ./src/gtk/gsockgtk.cpp:71: error: 'struct _GSocket' has no member named 'm_gui_dependent' ./src/gtk/gsockgtk.cpp:74: error: 'struct _GSocket' has no member named 'm_fd' ./src/gtk/gsockgtk.cpp:82: error: 'struct _GSocket' has no member named 'm_server' ./src/gtk/gsockgtk.cpp:89: error: 'struct _GSocket' has no member named 'm_fd' ./src/gtk/gsockgtk.cpp: In member function 'virtual void GSocketGUIFunctionsTableConcrete::Uninstall_Callback(GSocket*, GSocketEvent)': ./src/gtk/gsockgtk.cpp:97: error: 'struct _GSocket' has no member named 'm_gui_dependent' ./src/gtk/gsockgtk.cpp:107: error: 'struct _GSocket' has no member named 'm_server' make: *** [coredll_gsockgtk.o] Error 1
On Tue, 19 Jan 2010 01:26:43 -0500, Eric Bélanger <snowmaniscool@gmail.com> wrote:
wxgtk-2.6 doesn't build (error message below). Any objection if we remove it? It is only used by one package in community (comical) which is orphaned and who's last release was in 2006.
I am fine with solving the problem by removing the package. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Tue, 2010-01-19 at 01:26 -0500, Eric Bélanger wrote:
wxgtk-2.6 doesn't build (error message below). Any objection if we remove it? It is only used by one package in community (comical) which is orphaned and who's last release was in 2006.
In file included from ./src/gtk/gsockgtk.cpp:20: ./include/wx/gsocket.h:40: error: using typedef-name 'GSocket' after 'class' /usr/include/glib-2.0/gio/giotypes.h:120: error: 'GSocket' has a previous declaration here In file included from ./include/wx/gsocket.h:179, from ./src/gtk/gsockgtk.cpp:20:
wxgtk contains a patch for this.
On Tue, Jan 19, 2010 at 2:57 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Tue, 2010-01-19 at 01:26 -0500, Eric Bélanger wrote:
wxgtk-2.6 doesn't build (error message below). Any objection if we remove it? It is only used by one package in community (comical) which is orphaned and who's last release was in 2006.
In file included from ./src/gtk/gsockgtk.cpp:20: ./include/wx/gsocket.h:40: error: using typedef-name 'GSocket' after 'class' /usr/include/glib-2.0/gio/giotypes.h:120: error: 'GSocket' has a previous declaration here In file included from ./include/wx/gsocket.h:179, from ./src/gtk/gsockgtk.cpp:20:
wxgtk contains a patch for this.
I had forgotten about that patch so it might build. I still think that if no one is interested in comical, then we should remove both packages.
On Tue, Jan 19, 2010 at 2:11 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Tue, Jan 19, 2010 at 2:57 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Tue, 2010-01-19 at 01:26 -0500, Eric Bélanger wrote:
wxgtk-2.6 doesn't build (error message below). Any objection if we remove it? It is only used by one package in community (comical) which is orphaned and who's last release was in 2006.
In file included from ./src/gtk/gsockgtk.cpp:20: ./include/wx/gsocket.h:40: error: using typedef-name 'GSocket' after 'class' /usr/include/glib-2.0/gio/giotypes.h:120: error: 'GSocket' has a previous declaration here In file included from ./include/wx/gsocket.h:179, from ./src/gtk/gsockgtk.cpp:20:
wxgtk contains a patch for this.
I had forgotten about that patch so it might build. I still think that if no one is interested in comical, then we should remove both packages.
This rebuild is as good of an excuse as any to shoot some old stuff we have hanging around. +1 to killing it. -Dan
On Mon, Jan 18, 2010 at 8:11 PM, Ionut Biru <biru.ionut@gmail.com> wrote:
On 01/19/2010 02:32 AM, Allan McRae wrote:
Pierre Schmitz wrote:
On Sun, 17 Jan 2010 12:14:16 +1000, Allan McRae <allan@archlinux.org> wrote:
It all depends how many people help with the rebuild... The last few rebuilds have been done by only two or three people. We could get through most of this in a day or two if people helped out.
Allan
It seems the most important packages are rebuild now. What do you guys think to merge the jpng repo into testing now? This way we might speed up the process and the TUs could start building packages for community-testing.
Sounds fine. It looks like less patching is needed for libpng that was initially thought.
A big cheer to all those who have helped out with the rebuild so far (Andrea, Eric, Ionut, Jan and Pierre). I have not been any help due to work commitments. A quick count shows there are still 99 packages left to be rebuilt for [extra] so there is plenty of scope for the rest of us to lend a hand.
Allan
i'll send a warning now and in the morning i'll move them all. btw there is a script that can be used to moved all packages or i have to use db-move?
-- Ionut
Just a heads up. I had to fix the imlib, imlib2 and imagemagick packages that were initially put in the jpng repo. There was undefined symbols in the libraries. I believe it only affects when you try to link the library. So packages that were successfully built against the broken libs are probably OK. I haven't tested though. BTW, when trying to rebuild xfig and transfig, I'm getting this error: dev/libtransfig.a(readpng.o): In function `read_png': readpng.c:(.text+0x6a2): undefined reference to `png_set_dither' collect2: ld returned 1 exit status make[1]: *** [fig2dev] Error 1 I didn't find any mention about png_set_dither in the libpng 1.4.0 docs. Did another rebuilder encountered this problem? Does anyone know how to fix it? For the time being, I'll skip it. Another problem: Even after patching for libpng, xine-ui doesn't work. The window appears for a second then prints bunch of error messages like : IMLIB ERROR: Cannot load image: /usr/share/xine/skins/xine_splash.png All fallbacks failed. xiTK WARNING(xitk_image_load_image:1646): xitk_image_load_image(): couldn't find image /usr/share/xine/skins/xine_splash.png IMLIB ERROR: Cannot load image: /usr/share/xine/skins/xinetic/MainBg.png All fallbacks failed. I'll also skip it for now. If anyone has an idea on how to fix it or wants to work on it, go ahead.
On Tue, 2010-01-19 at 16:20 -0500, Eric Bélanger wrote:
IMLIB ERROR: Cannot load image: /usr/share/xine/skins/xine_splash.png All fallbacks failed. xiTK WARNING(xitk_image_load_image:1646): xitk_image_load_image(): couldn't find image /usr/share/xine/skins/xine_splash.png IMLIB ERROR: Cannot load image: /usr/share/xine/skins/xinetic/MainBg.png All fallbacks failed.
Announcement says: replace png_check_sig(buf, 8) with png_sig_cmp(buf, 0, 8) == 0 Your patch doesn't do the == 0, so results from that check are inverted.
On Tue, Jan 19, 2010 at 6:42 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Tue, 2010-01-19 at 16:20 -0500, Eric Bélanger wrote:
IMLIB ERROR: Cannot load image: /usr/share/xine/skins/xine_splash.png All fallbacks failed. xiTK WARNING(xitk_image_load_image:1646): xitk_image_load_image(): couldn't find image /usr/share/xine/skins/xine_splash.png IMLIB ERROR: Cannot load image: /usr/share/xine/skins/xinetic/MainBg.png All fallbacks failed.
Announcement says: replace png_check_sig(buf, 8) with png_sig_cmp(buf, 0, 8) == 0
Your patch doesn't do the == 0, so results from that check are inverted.
Thanks. That was it.
On Tue, Jan 19, 2010 at 4:20 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Jan 18, 2010 at 8:11 PM, Ionut Biru <biru.ionut@gmail.com> wrote:
On 01/19/2010 02:32 AM, Allan McRae wrote:
Pierre Schmitz wrote:
On Sun, 17 Jan 2010 12:14:16 +1000, Allan McRae <allan@archlinux.org> wrote:
It all depends how many people help with the rebuild... The last few rebuilds have been done by only two or three people. We could get through most of this in a day or two if people helped out.
Allan
It seems the most important packages are rebuild now. What do you guys think to merge the jpng repo into testing now? This way we might speed up the process and the TUs could start building packages for community-testing.
Sounds fine. It looks like less patching is needed for libpng that was initially thought.
A big cheer to all those who have helped out with the rebuild so far (Andrea, Eric, Ionut, Jan and Pierre). I have not been any help due to work commitments. A quick count shows there are still 99 packages left to be rebuilt for [extra] so there is plenty of scope for the rest of us to lend a hand.
Allan
i'll send a warning now and in the morning i'll move them all. btw there is a script that can be used to moved all packages or i have to use db-move?
-- Ionut
Just a heads up. I had to fix the imlib, imlib2 and imagemagick packages that were initially put in the jpng repo. There was undefined symbols in the libraries. I believe it only affects when you try to link the library. So packages that were successfully built against the broken libs are probably OK. I haven't tested though.
BTW, when trying to rebuild xfig and transfig, I'm getting this error:
dev/libtransfig.a(readpng.o): In function `read_png': readpng.c:(.text+0x6a2): undefined reference to `png_set_dither' collect2: ld returned 1 exit status make[1]: *** [fig2dev] Error 1
I didn't find any mention about png_set_dither in the libpng 1.4.0 docs. Did another rebuilder encountered this problem? Does anyone know how to fix it? For the time being, I'll skip it.
I found out the problem. In libpng 1.4.0, PNG_READ_DITHER_SUPPORTED is turned off by default. It seems that it wasn't working quite right and it had low usage: http://sourceforge.net/mailarchive/forum.php?thread_name=e56ccc8f0812151445ybd95eb0i78eb9aef434a6e28%40mail.gmail.com&forum_name=png-mng-misc Are there any objections in enabling it? Eric
On Sat, Jan 23, 2010 at 4:55 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Tue, Jan 19, 2010 at 4:20 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Jan 18, 2010 at 8:11 PM, Ionut Biru <biru.ionut@gmail.com> wrote:
On 01/19/2010 02:32 AM, Allan McRae wrote:
Pierre Schmitz wrote:
On Sun, 17 Jan 2010 12:14:16 +1000, Allan McRae <allan@archlinux.org> wrote:
It all depends how many people help with the rebuild... The last few rebuilds have been done by only two or three people. We could get through most of this in a day or two if people helped out.
Allan
It seems the most important packages are rebuild now. What do you guys think to merge the jpng repo into testing now? This way we might speed up the process and the TUs could start building packages for community-testing.
Sounds fine. It looks like less patching is needed for libpng that was initially thought.
A big cheer to all those who have helped out with the rebuild so far (Andrea, Eric, Ionut, Jan and Pierre). I have not been any help due to work commitments. A quick count shows there are still 99 packages left to be rebuilt for [extra] so there is plenty of scope for the rest of us to lend a hand.
Allan
i'll send a warning now and in the morning i'll move them all. btw there is a script that can be used to moved all packages or i have to use db-move?
-- Ionut
Just a heads up. I had to fix the imlib, imlib2 and imagemagick packages that were initially put in the jpng repo. There was undefined symbols in the libraries. I believe it only affects when you try to link the library. So packages that were successfully built against the broken libs are probably OK. I haven't tested though.
BTW, when trying to rebuild xfig and transfig, I'm getting this error:
dev/libtransfig.a(readpng.o): In function `read_png': readpng.c:(.text+0x6a2): undefined reference to `png_set_dither' collect2: ld returned 1 exit status make[1]: *** [fig2dev] Error 1
I didn't find any mention about png_set_dither in the libpng 1.4.0 docs. Did another rebuilder encountered this problem? Does anyone know how to fix it? For the time being, I'll skip it.
I found out the problem. In libpng 1.4.0, PNG_READ_DITHER_SUPPORTED is turned off by default. It seems that it wasn't working quite right and it had low usage:
Are there any objections in enabling it?
Eric
FYI: don't rebuild the openoffice packages. Andy told me that there will be new releases next week and those will be built against the libpng/jpeg in testing.
On Sat, Jan 23, 2010 at 4:55 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Tue, Jan 19, 2010 at 4:20 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Mon, Jan 18, 2010 at 8:11 PM, Ionut Biru <biru.ionut@gmail.com> wrote:
On 01/19/2010 02:32 AM, Allan McRae wrote:
Pierre Schmitz wrote:
On Sun, 17 Jan 2010 12:14:16 +1000, Allan McRae <allan@archlinux.org> wrote:
It all depends how many people help with the rebuild... The last few rebuilds have been done by only two or three people. We could get through most of this in a day or two if people helped out.
Allan
It seems the most important packages are rebuild now. What do you guys think to merge the jpng repo into testing now? This way we might speed up the process and the TUs could start building packages for community-testing.
Sounds fine. It looks like less patching is needed for libpng that was initially thought.
A big cheer to all those who have helped out with the rebuild so far (Andrea, Eric, Ionut, Jan and Pierre). I have not been any help due to work commitments. A quick count shows there are still 99 packages left to be rebuilt for [extra] so there is plenty of scope for the rest of us to lend a hand.
Allan
i'll send a warning now and in the morning i'll move them all. btw there is a script that can be used to moved all packages or i have to use db-move?
-- Ionut
Just a heads up. I had to fix the imlib, imlib2 and imagemagick packages that were initially put in the jpng repo. There was undefined symbols in the libraries. I believe it only affects when you try to link the library. So packages that were successfully built against the broken libs are probably OK. I haven't tested though.
BTW, when trying to rebuild xfig and transfig, I'm getting this error:
dev/libtransfig.a(readpng.o): In function `read_png': readpng.c:(.text+0x6a2): undefined reference to `png_set_dither' collect2: ld returned 1 exit status make[1]: *** [fig2dev] Error 1
I didn't find any mention about png_set_dither in the libpng 1.4.0 docs. Did another rebuilder encountered this problem? Does anyone know how to fix it? For the time being, I'll skip it.
I found out the problem. In libpng 1.4.0, PNG_READ_DITHER_SUPPORTED is turned off by default. It seems that it wasn't working quite right and it had low usage:
Are there any objections in enabling it?
Eric
I went ahead and put a libpng 1.4.0-2 in testing with dither support readded. And both xfig and transfig have been rebuilt.
On 01/17/2010 04:01 AM, Pierre Schmitz wrote:
On Sun, 17 Jan 2010 11:00:31 +1000, Allan McRae<allan@archlinux.org> wrote:
Would it be possible to (temporarily) add jpng to the list for gerolde? That way we can use "/arch/db-update jpng" to add packages to the repo and have all the safety measures the db-scripts bring instead of manually using repo-add.
Any objections? Allan
Does not soud like a bad idea. I have added the repo to https://www.archlinux.de/?page=Packages;repository=7 and the diff list at https://www.archlinux.de/?page=ArchitectureDifferences Maybe that is of any help.
I did not know that we need to patch some/many package to be build with the new libpng. However: Do you think we can merge that repo into testing once the most important packages are done? I fear we'll start to block each other or do unnecessary rebuilds soon. We are also working on kde-unstable (on top of testing) which should be merged into extra at the first week of February.
the most important packages have been rebuilt. I use jpng repo with a gnome desktop and didn't encounter any problem. i think is ready to be merged in testing so that TUs can do rebuilds too. all todos have been completed with community packages. -- Ionut
participants (11)
-
Aaron Griffin
-
Allan McRae
-
Daenyth Blank
-
Dan McGee
-
Eric Bélanger
-
Firmicus
-
Ionut Biru
-
Jan de Groot
-
Pierre Schmitz
-
Thayer Williams
-
Thomas Bächler