You are not logged in.
Pages: 1
Topic closed
The latest version is 0.9.60 while the latest one in the repositories is 0.9.56. I thought Arch was fairly bleeding edge, are all packages like this or only WINE?
Offline
Fortunately, we have the ABS so if we want a newer package we just make it. Piece 'o cake.
Offline
Technically 9.56 isn't too old of a release, since I believe Wine is on a two week release schedule.
Tido is correct though, the ABS system is nice. I just updated the pkgbuild from ABS and built my own 9.60
"He is no fool who gives what he cannot keep to gain that which he cannot lose." -Jim Elliot
Offline
For information on how to use ABS to accomplish such a task (bumping up the version number and compiling), see here.
Offline
I think the OP asks a valid question, some of us are on quite old hardware and while we could compile it ourselves it would take a quite long time. Not saying that the maintainer is bad at what he's doing, quite the opposite, he might manage a lot of packages and thus doesn't have the time to keep track of all new versions.
Last edited by Anders (2008-04-27 23:29:58)
Running: Arch Linux i686, x86_64, ppc
Offline
Technically 9.56 isn't too old of a release, since I believe Wine is on a two week release schedule.
Tido is correct though, the ABS system is nice. I just updated the pkgbuild from ABS and built my own 9.60
The wine developers calls that release old, if you go to the wine support channel on irc with a problem and that wine version, they will tell you to first upgrade to the latest version.
Use the Source, Luke!
Offline
Be careful this thread is not going to same way as in here: http://bbs.archlinux.org/viewtopic.php?id=44469
Anyway, WINE has been flagged out of date so the maintainer know there is a new version. It will get updated when he has time... If it takes a while and there is a significant feature increase between versions that you find essential, it may be acceptable to politely email the maintainer and ask if it can be updated. This is especially helpful if you know the latest version builds easily. Angry or demanding emails may have the opposite effect. Remember, the devs are volunteers and have lives away from a computer.
Last edited by Allan (2008-04-27 12:33:34)
Offline
Be careful this thread is not going to same way as in here: http://bbs.archlinux.org/viewtopic.php?id=44469
Anyway, WINE has been flagged out of date so the maintainer know there is a new version. It will get updated when he has time... If it takes a while and there is a significant feature increase between versions that you find essential, it may be acceptable to politely email the maintainer and ask if it can be updated. This is especially helpful if you know the latest version builds easily. Angry or demanding emails may have the opposite effect. Remember, the devs are volunteers and have lives away from a computer.
QFT.
Thanks Allan.
Offline
There is an up-to date binary package for i686 in AUR. http://aur.archlinux.org/packages.php?ID=16623
if you want easier install try yaourt
If it ain't broke, broke it then fix it.
Offline
I understand that maintaining packages is something people do on their free time, and do not get paid for it - but if the maintainer has lost interest, wouldn't it be right to enable someone else to maintain it?
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
>but if the maintainer has lost interest, wouldn't it be right to enable someone else to maintain it?
Would you please stop such nonsense talk? Just wait and see and do it yourself if it is essential for you. There is a life aside the computer, there are problems in *real life* and so on.
Use UNIX or die.
Offline
I understand that maintaining packages is something people do on their free time, and do not get paid for it - but if the maintainer has lost interest, wouldn't it be right to enable someone else to maintain it?
Here is a tip:
Update the PKGBUILD yourself, make sure it compiles and runs cleanly, then email it to the mantainer.
Giving a helping hand > complaining.
And yes, If a mantainer don't want to mantain a pkg, it either get's adopted by someone else, or trown back to unsupported. A recent example of that is xfce-svn that noone was intrested(or had the time/energy) in picking up, after wizzo resigned.
Evil #archlinux@libera.chat channel op and general support dude.
. files on github, Screenshots, Random pics and the rest
Offline
I understand that maintaining packages is something people do on their free time, and do not get paid for it - but if the maintainer has lost interest, wouldn't it be right to enable someone else to maintain it?
that sounds great. just one thing. if noone else wants to maintain it should wine be dropped to unsupported?
There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)
Offline
I understand that maintaining packages is something people do on their free time, and do not get paid for it - but if the maintainer has lost interest, wouldn't it be right to enable someone else to maintain it?
You really hit the nail on the head. I've been using Arch as my main desktop for about six months now, but unfortunately I will have to move on.
Not to be offending anyone, but the statement that "this is a volunteer project so don't expect much" is an insult to those of us who believe free software is as good as the other stuff and have worked many hours to show the world that is true.
The point of volunteering is not so much raising your hand and saying you will do something as it is actually doing it. If a dev does not have time to update a package at the very least every three months, he/she should give the package back to the community. When the maintainer of a package does not, for whatever reason, update the package, everyone is stuck. At least giving up the package would allow for it to be put into AUR.
I have no problem at all with any dev that does not have time to update a given package. But only if that dev lets the package go. The worst thing is hearing devs say "this isn't a priority so update the package yourself." Once you are the maintainer, you have obligations, and the community does have a right to expect a minimal level of quality.
Either that, or else users should be able to post updated PKGBUILDs in the AUR for packages already in the repos.
Again, I'm not trying to ruffle any feathers, just making some observations about Arch. I'm sure others have been rubbed the wrong way as well and left without saying anything.
Offline
I have no problem at all with any dev that does not have time to update a given package. But only if that dev lets the package go. The worst thing is hearing devs say "this isn't a priority so update the package yourself." Once you are the maintainer, you have obligations, and the community does have a right to expect a minimal level of quality.
Either that, or else users should be able to post updated PKGBUILDs in the AUR for packages already in the repos.
Again, I'm not trying to ruffle any feathers, just making some observations about Arch. I'm sure others have been rubbed the wrong way as well and left without saying anything.
I think a unsupported-extra repo will be in order. The idea is this new repo willl have PKGBUILD updated for packages in extra. There could/should be a server or 2 used for auto-building packages if not updated in a week. If a package is flag-out-of-date and has a PKGBUILD by the same name in unsupported-extra then the build server will build a new package for testing or unstable repo. The idea is only do the extra packages. The most/all core packages are to important to be put though a build server.
If a trusted user thinks the package is good it can put in the current extra repo. This sort of a bypass for getting around devs not having time to build his/her package every new release.
I think this could also help control the repeated packages in aur for extra.
I'm working on a live cds based on Archlinux. http://godane.wordpress.com/
Offline
I don't agree at all with these sentiments. Just copy the PKGBUILD for wine to a local directory, change the pkgver from 0.1 to 0.2 (or whatever it is), and type in makepkg. You're done.
Offline
The point of volunteering is not so much raising your hand and saying you will do something as it is actually doing it. If a dev does not have time to update a package at the very least every three months, he/she should give the package back to the community. When the maintainer of a package does not, for whatever reason, update the package, everyone is stuck. At least giving up the package would allow for it to be put into AUR.
I really don't get the point of this discussion... The only advantage of a package getting moved to the AUR is that you don't have to update the version number yourself. That is all you have to do with most minor updates and is part of the point of the ABS.
Just because a dev hasn't updated a package does not mean that he is not doing his job. Upstream, WINE updates every two weeks. Mostly minor stuff. There are plenty of other packages to update as well and these may take priority. I have yet to see anyone point out a feature in the newer release that they feel is essential.
Offline
The wine package is probably getting so much interest because it takes longer to compile than most other packages that users consider compiling.
I notice bin32-wine-suse and wine-suse in AUR, which are pre-compiled
Offline
But only if that dev lets the package go. The worst thing is hearing devs say "this isn't a priority so update the package yourself." Once you are the maintainer, you have obligations, and the community does have a right to expect a minimal level of quality.
You are contradicting yourself. If you want to have quality you should not put pressure on the devs to push a package only because the version number changed.
And, every individual can try to become a Dev or TU himself, if the situation is too annoying to him or her.
Offline
Another problem here is the lack of communication. I think there will be a lot less people complaining if we know the reason for the lack of update. Is it because the maintainer lacks time? Did he lost interest in maintaining it? Was it because of the recent repositories migration from CVS to SVN? At least tell us something so that we can stop speculating, debating or asking about it.
I'm sure nobody will complains if the maintainer says he can't update the package because he is currently too busy with other matters, but at lest let us know that is the case.
Last edited by zodmaner (2008-04-28 09:49:28)
Offline
No offense, zodmaner, but if a maintainer is too busy to do an update at the time it becomes available upstream, he's probably also too busy to come in here and explain why. I would ask you all to be patient, and to use the tools available to carry out any updates you regard as critical.
Offline
No offense, zodmaner, but if a maintainer is too busy to do an update at the time it becomes available upstream, he's probably also too busy to come in here and explain why. I would ask you all to be patient, and to use the tools available to carry out any updates you regard as critical.
None taken of course. I'm also sorry if I offense anyone with my last post. I know that Arch developers/maintainers are having their hands full and didn't mean to be rude to them.
Anyway, since recently there are quite a number of people that have been asking why a certain package isn't being update, I merely want to suggest that a word from the package maintainer or one of the devs might help in stopping people from asking essentially the same question over and over again.
Just a thought, sorry if I may not think it through enough. But for now, like tomk said, we should all be patience and wait for the maintainer to do his job.
Last edited by zodmaner (2008-04-28 11:29:32)
Offline
As happens all too often, this is rapidly turning into a complaint vs defense exercise. Complaints do not solve these issues- though requests sometimes do.
Arch provides perhaps the most high-quality ports-like system available, to build packages from source- ABS. It can be used most effectively in instances like this
Thread closed.
Offline
Pages: 1
Topic closed