I've created updated packages:
- sdl 1.2.6 with templates from previous package updated to compile without a problem
- libxml2 2.4.12 - with examples/utils in bin directory
- i18n - libiconv-1.8-1 and libintl-0.11.5-2
- imagelib - zlib-1.1.4-1, libpng-1.2.5, tiff-3.5.7, jpeg-6b-1 (no libxpm) - with examples/utils in bin for each one.
Packages were created based on zip files from http://gnuwin32.sf.net/ except sdl - this one from libsdl.org with templates from sdl124.devpak
Is there a place where I could upload them so people can test it and if they like it they could become official dev-cpp packages?
Thanks,
Marek
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I can't help you with hosting, but I want to say thanks for putting these together! A lot of the ones in the webupdate are VERY out of date. Would be nice if we had a maintainer to look out for that stuff
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would you like to make this information available over on the Bloodshed forum (higher traffic), or would that generate too much traffic/problems for you?
Wayne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the traffic is my only concern - that's why I started this topic. Let's do this: post it wherever you want, but if the traffic goes over what I can give, I'll disable the location (most likely until begining of next month or something).
Basically, I was hoping that some mirrors that used to host original packages would just copy them to their websites, or alternatively there would be a "contrib" file group on sf.net that a user would be able to download those files from. That is of couse after users would provide some feedback that the packages are usable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it possible to point dev-cpp webupdate to [the dowloads at devpaks.sourceforge.net] website?
In that case the devpacks could be hosted with SF.net Incedentlaly, devpaks.sourceforge.net only has FLTK DevPak 0.1 ( So it is hardly right to say "This page contains the complete listing of known DevPaks")
Currently my WebUpdateModule points to "Andreas Aberg's server",...and this does not have all dev packs available, nor the most up to date. For example there is a more up to date wxWindows package (which actually works) at http://michel.weinachter.free.fr/ (which is apperantly mirrored at http://www.fis.unipr.it/pub/win/devc++/devpak/\)
And if you do a quick google search, you will find many more.
This is a very messy situation, and most unfortunate.
Is "Andreas Aberg's server" willing to host all these dev packs...
... or, probably much better, can we use SF.net to host the files, and make the webUpdate somehow work with this.
either way, send a message out to everybody else who has some devpaks somewhere, please make sure your devPaks are there. ?
It would be very nice for the users if this was better organized, and I would be willing to help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Colin, how do you feel about having the webupdate point to the devpaks project ? I have an idea how this could work (and would be willing to help), and then we could really work on making that the central repository, and ask that anybody who creates a DevPak becomes a member of the devpak project and checks their devpak in there etc.
Comments ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
why not make webupdate read an ini file that would contain a location of webconf. It would come with the current location by default (currently hardcoded), but a user would be able to change it to whatever, i.e. devpacks project.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I imagine the intention was that the webupdate server would be configurable, and that you would be able to set multiple values (presumably mirrors), as it is also in a pull down list in the user interface, but that this simply has not been implemented yet.
The issue I am bringing up here, however, is more a question of organization, that devpaks are spread all over the web, and that it would be good to have an agreed central repository for these:
that this should of course be mirrored, and not be dependant on some persons bandwidth alocation.
It should also freely allow who ever wants to contribute a devpack, or an update to an existing one, to gain controled access and to do so.
It should also allow a person or a small group of volunteers to be able manage this process, maintain, and have some quality control on all this.
I believe that the devpaks project sf.net could already provide all this.
I am proposing to help with this effort by testing the webupdate with the devpaks server. Collecting all the dev paks I can find all over the internet,contacting their authors about this central repository, and inviting them to join the devpaks project, and put their devpaks there, and also, perhaps, to work on some perl script to run on the devpaks.sf.net web site, which would collect, in a authenticated way , all the data from the contributor of each devpak in order to be able to keep ( perhaps subject to an approval) the webupdate server configuration file up to date.
I especially want to know how you, Colin, and Eugene (laserlight) feel about this idea?
... and of course, also, any body else's comments or ideas ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I assume you mean the admin of the devpak project ? From reading their forums, apperantly they do plan to do a some monitoring and quality control etc.
It is hardly a plan at this point, just my proposition to help out with getting a centralized place where all the devPaks trully are. (and I would be just as willing to help out with a different solution, if it was chosen instead, and that meets the same objectives)
If you mean those who make devPak's (such as yourself) There is not much we can do if they dont want to put their devPak in a central location, except ask them why not, and do they have better ideas to manage it, and can we at least put a copy of their devPak there so it is available to the whole Dev-C++ user community via webupdate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, let's clarify the situation:
we are in need of new mirrors, currently only Andreas has been willing to provide a mirror (although i just received today an email from somebdy who can make a new one so we should have at least two soon). Then we will probably setup a rsync system in order to synchronize the mirrors, with mirror providers such as planetmirror.com. About downloading from WebUpdate directly from sourceforge, i'm not sure sf will really like it, but that might be possible though.
About the mirrors being hard-coded in Dev-C++: there is also a feature which has not been used yet that makes it possible to download from WebUpdate itself a new mirror list, that will be installed automatically. So I can add new mirrors without recompiling Dev-C++.
Greetings,
Colin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Colin: by hardcoded I meant where you get webupdate.conf from not the mirror list (mirrors.cfg). If the location was configurable other people (like devpacks project) could propose their own list of devpack (new versions other packages etc).
some other comments:
The remotefilename entry for devpack limits the location of the file to the server and directory where the webupdate.conf is - one cannot tell webupdate to poll the file from other server.
I think that it would be useful if there was another flag, that would mean importance of the package: Right now I can think of two: recommended and optional. For example: recommed for new devcpp.exe, mingw-runtime etc, optional for rest.
It would be also nice if it had some sort of dependancy checking (like for imagelib for example). There would also have to be option to go back to previous version of some package, in case it was buggy etc.
I don't know how people like current package system, but in my opinion it should be slighly different. For example imagelib should be back split into its member libraries, so if person wanted to update just libpng, he/she would have to update the whole imagelib. Version numbers should reflect the version of the software not the package - that's what build number is for. This would create a lot more packages but, with recommended/optional/other system it wouldn't be hard.
One more thing I would like would be to know what exactly of mingw.org is installed with dev-cpp: for example package manager just after first install should have entries for gcc, mingw-runtime, gdb, etc. with version numbers of those programs.
just my five cents...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Colin, Thank you for posting a reply.
...though the only thing you said about my idea was "I'm not sure sf will really like it." I could ask them (and it may be up to asking their indevidual file mirrors like umn,easynews, flow, unc, twtelecom, heanet etc)... but first I would like to know what you think of this idea?
The folks at the devPaks sf project certainly seem to have some motivation to take on the management involved in handling contribution and quality control of devpaks, and I think sf.net also provides a workable infastructure for this, so you don't have to do this all from scratch.
I would also be willing, though, to help with contribution management (eg perl scripts as mentioned above) and maintanance of a different solution other then devpaks at sf, if this is going to be the centralized place devPaks, and used for webupdate.
Anyhow, at very least, could you add the to the current web updates server:
The updated image and wxWindows devPaks found here http://michel.weinachter.free.fr/ as (at least the templates) dont work with the wxWindows currently available on the webupdate server.
and perhaps specu's devPaks listed above.
Also, could you post what a very brief word on what must be done if somebody would like to have a devpak included to the webupdates.
Pleas let me know what you think of the ideas, and if /how I can help to at least keep current webupdate location up to date, and complete
wishing everyone a great weekend :Auriel.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the list is configurable since you can edit the file mirrors.cfg in your Documents and Settings\user\Local settings\Application Data folder.
Packages creation are made by users, so they did their own versioning/packaging information, so maybe a sort of "how to" could be made to tell people the principes of making a good DevPak.
Greetings,
Colin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I've created updated packages:
- sdl 1.2.6 with templates from previous package updated to compile without a problem
- libxml2 2.4.12 - with examples/utils in bin directory
- i18n - libiconv-1.8-1 and libintl-0.11.5-2
- imagelib - zlib-1.1.4-1, libpng-1.2.5, tiff-3.5.7, jpeg-6b-1 (no libxpm) - with examples/utils in bin for each one.
Packages were created based on zip files from http://gnuwin32.sf.net/ except sdl - this one from libsdl.org with templates from sdl124.devpak
Is there a place where I could upload them so people can test it and if they like it they could become official dev-cpp packages?
Thanks,
Marek
Well, I can't help you with hosting, but I want to say thanks for putting these together! A lot of the ones in the webupdate are VERY out of date. Would be nice if we had a maintainer to look out for that stuff
if anyone wants to use them they're at:
http://www.castlesofpoland.com/dev-cpp/
please do not link to this location - feel free to copy them to your website and distribute them.
constructive criticism welcome.
Marek,
Would you like to make this information available over on the Bloodshed forum (higher traffic), or would that generate too much traffic/problems for you?
Wayne
the traffic is my only concern - that's why I started this topic. Let's do this: post it wherever you want, but if the traffic goes over what I can give, I'll disable the location (most likely until begining of next month or something).
Basically, I was hoping that some mirrors that used to host original packages would just copy them to their websites, or alternatively there would be a "contrib" file group on sf.net that a user would be able to download those files from. That is of couse after users would provide some feedback that the packages are usable.
I started a thread on the devpackages project a week ago:
http://www.sourceforge.net/projects/devpaks/
Would you like to work with us, specu?
I don't have much spare time, but I could post something once in a while. If you want to include my packages in your project - feel free to do so.
is it possible to point dev-cpp webupdate to your website?
Okay, specu asked a very good question:
Is it possible to point dev-cpp webupdate to [the dowloads at devpaks.sourceforge.net] website?
In that case the devpacks could be hosted with SF.net Incedentlaly, devpaks.sourceforge.net only has FLTK DevPak 0.1 ( So it is hardly right to say "This page contains the complete listing of known DevPaks")
Currently my WebUpdateModule points to "Andreas Aberg's server",...and this does not have all dev packs available, nor the most up to date. For example there is a more up to date wxWindows package (which actually works) at http://michel.weinachter.free.fr/ (which is apperantly mirrored at http://www.fis.unipr.it/pub/win/devc++/devpak/\)
And if you do a quick google search, you will find many more.
This is a very messy situation, and most unfortunate.
Is "Andreas Aberg's server" willing to host all these dev packs...
... or, probably much better, can we use SF.net to host the files, and make the webUpdate somehow work with this.
either way, send a message out to everybody else who has some devpaks somewhere, please make sure your devPaks are there. ?
It would be very nice for the users if this was better organized, and I would be willing to help.
it's hardset in the code here: http://cvs.sourceforge.net/viewcvs.py/\*checkout*/dev-cpp/V5/source/webupdate/WebUpdate.pas?rev=1.9
the location is:
Andreas Aberg''s server=http://vUpdate.servebeer.com/
which contains a file: webupdate.conf
If you look at changelog the only people changing anything are Kip and Colin, so they would be the ones to talk to.
Other option is to recompile dev-cpp to use ini file or at least hardset it to somewhere else.
Colin, how do you feel about having the webupdate point to the devpaks project ? I have an idea how this could work (and would be willing to help), and then we could really work on making that the central repository, and ask that anybody who creates a DevPak becomes a member of the devpak project and checks their devpak in there etc.
Comments ?
why not make webupdate read an ini file that would contain a location of webconf. It would come with the current location by default (currently hardcoded), but a user would be able to change it to whatever, i.e. devpacks project.
Yes, I imagine the intention was that the webupdate server would be configurable, and that you would be able to set multiple values (presumably mirrors), as it is also in a pull down list in the user interface, but that this simply has not been implemented yet.
The issue I am bringing up here, however, is more a question of organization, that devpaks are spread all over the web, and that it would be good to have an agreed central repository for these:
that this should of course be mirrored, and not be dependant on some persons bandwidth alocation.
It should also freely allow who ever wants to contribute a devpack, or an update to an existing one, to gain controled access and to do so.
It should also allow a person or a small group of volunteers to be able manage this process, maintain, and have some quality control on all this.
I believe that the devpaks project sf.net could already provide all this.
I am proposing to help with this effort by testing the webupdate with the devpaks server. Collecting all the dev paks I can find all over the internet,contacting their authors about this central repository, and inviting them to join the devpaks project, and put their devpaks there, and also, perhaps, to work on some perl script to run on the devpaks.sf.net web site, which would collect, in a authenticated way , all the data from the contributor of each devpak in order to be able to keep ( perhaps subject to an approval) the webupdate server configuration file up to date.
I especially want to know how you, Colin, and Eugene (laserlight) feel about this idea?
... and of course, also, any body else's comments or ideas ?
what is your alternative plan if dev-cpp maintainers will not agree to your proposition?
I assume you mean the admin of the devpak project ? From reading their forums, apperantly they do plan to do a some monitoring and quality control etc.
It is hardly a plan at this point, just my proposition to help out with getting a centralized place where all the devPaks trully are. (and I would be just as willing to help out with a different solution, if it was chosen instead, and that meets the same objectives)
If you mean those who make devPak's (such as yourself) There is not much we can do if they dont want to put their devPak in a central location, except ask them why not, and do they have better ideas to manage it, and can we at least put a copy of their devPak there so it is available to the whole Dev-C++ user community via webupdate.
http://sourceforge.net/forum/forum.php?thread_id=972619&forum_id=48211
Curtis
Hello all,
Ok, let's clarify the situation:
we are in need of new mirrors, currently only Andreas has been willing to provide a mirror (although i just received today an email from somebdy who can make a new one so we should have at least two soon). Then we will probably setup a rsync system in order to synchronize the mirrors, with mirror providers such as planetmirror.com. About downloading from WebUpdate directly from sourceforge, i'm not sure sf will really like it, but that might be possible though.
About the mirrors being hard-coded in Dev-C++: there is also a feature which has not been used yet that makes it possible to download from WebUpdate itself a new mirror list, that will be installed automatically. So I can add new mirrors without recompiling Dev-C++.
Greetings,
Colin
Colin: by hardcoded I meant where you get webupdate.conf from not the mirror list (mirrors.cfg). If the location was configurable other people (like devpacks project) could propose their own list of devpack (new versions other packages etc).
some other comments:
The remotefilename entry for devpack limits the location of the file to the server and directory where the webupdate.conf is - one cannot tell webupdate to poll the file from other server.
I think that it would be useful if there was another flag, that would mean importance of the package: Right now I can think of two: recommended and optional. For example: recommed for new devcpp.exe, mingw-runtime etc, optional for rest.
It would be also nice if it had some sort of dependancy checking (like for imagelib for example). There would also have to be option to go back to previous version of some package, in case it was buggy etc.
I don't know how people like current package system, but in my opinion it should be slighly different. For example imagelib should be back split into its member libraries, so if person wanted to update just libpng, he/she would have to update the whole imagelib. Version numbers should reflect the version of the software not the package - that's what build number is for. This would create a lot more packages but, with recommended/optional/other system it wouldn't be hard.
One more thing I would like would be to know what exactly of mingw.org is installed with dev-cpp: for example package manager just after first install should have entries for gcc, mingw-runtime, gdb, etc. with version numbers of those programs.
just my five cents...
Colin, Thank you for posting a reply.
...though the only thing you said about my idea was "I'm not sure sf will really like it." I could ask them (and it may be up to asking their indevidual file mirrors like umn,easynews, flow, unc, twtelecom, heanet etc)... but first I would like to know what you think of this idea?
The folks at the devPaks sf project certainly seem to have some motivation to take on the management involved in handling contribution and quality control of devpaks, and I think sf.net also provides a workable infastructure for this, so you don't have to do this all from scratch.
I would also be willing, though, to help with contribution management (eg perl scripts as mentioned above) and maintanance of a different solution other then devpaks at sf, if this is going to be the centralized place devPaks, and used for webupdate.
Anyhow, at very least, could you add the to the current web updates server:
The updated image and wxWindows devPaks found here http://michel.weinachter.free.fr/ as (at least the templates) dont work with the wxWindows currently available on the webupdate server.
and perhaps specu's devPaks listed above.
Also, could you post what a very brief word on what must be done if somebody would like to have a devpak included to the webupdates.
Pleas let me know what you think of the ideas, and if /how I can help to at least keep current webupdate location up to date, and complete
wishing everyone a great weekend :Auriel.
the list is configurable since you can edit the file mirrors.cfg in your Documents and Settings\user\Local settings\Application Data folder.
Packages creation are made by users, so they did their own versioning/packaging information, so maybe a sort of "how to" could be made to tell people the principes of making a good DevPak.
Greetings,
Colin
Hello all,
maybe you could be interested in our project:
http://sourceforge.net/forum/message.php?msg_id=2351939
Regards,
Michal
FYI:
http://sourceforge.net/forum/forum.php?thread_id=1069586&forum_id=326329