[arch-dev-public] samba 3.5.0 bump
HI guys, next time please ask before bumping a quite complicated package directly to next major release. Also keep in mind to put it to testing first and not directly to extra. tdb can be used externally now, i'm rebuilding it now. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Tue, Mar 2, 2010 at 12:19 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
HI guys, next time please ask before bumping a quite complicated package directly to next major release.
Also keep in mind to put it to testing first and not directly to extra. tdb can be used externally now, i'm rebuilding it now.
To all the new guys on the list- this is especially sad considering this package was just brought up on this development list and tpowa was quite clearly active in the discussion. I know you guys think it is cool to have the latest and greatest in the repos, but us old guys do things the way we do for a reason. *You need to ask the maintainer before touching a package*, plain and simple. Don't version bump without doing this first (especially a major version bump!) and at least giving ample time for a response. Just because a package isn't in [core] doesn't mean it is easy to stay on top of. Thank you Tobias for bringing this up; I've noticed it with more than just this package. -Dan
2010/3/2, Dan McGee <dpmcgee@gmail.com>:
Thank you Tobias for bringing this up; I've noticed it with more than just this package.
OK, then I will stay away from packages that are not mine. Let's keep up out of date packages! Thanks a lot for your rant. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
On Tue, Mar 2, 2010 at 7:47 AM, Giovanni Scafora <giovanni@archlinux.org> wrote:
2010/3/2, Dan McGee <dpmcgee@gmail.com>:
Thank you Tobias for bringing this up; I've noticed it with more than just this package.
OK, then I will stay away from packages that are not mine. Let's keep up out of date packages! Thanks a lot for your rant.
I wasn't trying to call anyone out (I didn't even look at the commit logs!), I can't tell if you are being serious or sarcastic here. Only that you let the maintainer know you were thinking about doing something to his package so he has a chance to 1) do it himself or 2) tell you why he was holding off on it. If we have packages that are weeks/months old, those are much bigger candidates for rebuilding or dropping. Samba was only about 3 hours old, so calling it "out of date" is maybe a bit of a stretch, more like "out of hour". :) -Dan
2010/3/2, Dan McGee <dpmcgee@gmail.com>:
I wasn't trying to call anyone out (I didn't even look at the commit logs!), I can't tell if you are being serious or sarcastic here. Only that you let the maintainer know you were thinking about doing something to his package so he has a chance to 1) do it himself or 2) tell you why he was holding off on it.
If we have packages that are weeks/months old, those are much bigger candidates for rebuilding or dropping. Samba was only about 3 hours old, so calling it "out of date" is maybe a bit of a stretch, more like "out of hour". :)
I am being serious, no sarcastic here. Samba package was not old only because before I've rebuilt it to the 3.4.6 version, if not it was (old) to 3.4.5 version. BTW, no problem, I will stay away from packages that are not mine. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Am Tue, 2 Mar 2010 15:03:22 +0100 schrieb Giovanni Scafora <giovanni@archlinux.org>:
I am being serious, no sarcastic here. Samba package was not old only because before I've rebuilt it to the 3.4.6 version, if not it was (old) to 3.4.5 version. BTW, no problem, I will stay away from packages that are not mine.
that's not the wanted reaction. helping out on updates is wanted. but please be careful and talk to the one you want to help. something different: you have bumped apache-ant - please look at this http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-February/008464.h... Any ideas how to fix our ant pkg that I can build OpenJDK again? Run ant --diagnostics. Probably some stuff is missing (xerces and xalan are present). I'd like to call everybody with some java experience for help here. I even don't have an old ant version in my pkg cache to downgrade for now :( -Andy
2010/3/2, Andreas Radke <a.radke@arcor.de>:
Any ideas how to fix our ant pkg that I can build OpenJDK again? Run ant --diagnostics. Probably some stuff is missing (xerces and xalan are present). I'd like to call everybody with some java experience for help here. I even don't have an old ant version in my pkg cache to downgrade for now :(
Downgrade it. You can download it for x86_64 here: http://schlunix.org/archlinux/extra/os/x86_64/apache-ant-1.7.1-3-x86_64.pkg.... and for i686 here: http://schlunix.org/archlinux/extra/os/i686/apache-ant-1.7.1-3-i686.pkg.tar.... -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
On Tue, Mar 2, 2010 at 10:43 AM, Giovanni Scafora <giovanni@archlinux.org> wrote:
2010/3/2, Andreas Radke <a.radke@arcor.de>:
Any ideas how to fix our ant pkg that I can build OpenJDK again? Run ant --diagnostics. Probably some stuff is missing (xerces and xalan are present). I'd like to call everybody with some java experience for help here. I even don't have an old ant version in my pkg cache to downgrade for now :(
Downgrade it. You can download it for x86_64 here: http://schlunix.org/archlinux/extra/os/x86_64/apache-ant-1.7.1-3-x86_64.pkg.... and for i686 here: http://schlunix.org/archlinux/extra/os/i686/apache-ant-1.7.1-3-i686.pkg.tar....
FTR: You can always get old packages from /srv/package-cleanup/ on gerolde. The very old ones are removed but they remain there for a relatively long time.
2010/3/2, Andreas Radke <a.radke@arcor.de>:
something different: you have bumped apache-ant - please look at this
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-February/008464.h...
Any ideas how to fix our ant pkg that I can build OpenJDK again?
I apologize for that, I can't fix it. It's not my package. Sorry, but I will stay away from packages that are not mine. I just given you link to the previous version of apache-ant package. If you want, you can rebuild and force it to the previous version, then push it in extra repo. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
On 03/02/2010 10:54 AM, Giovanni Scafora wrote:
2010/3/2, Andreas Radke<a.radke@arcor.de>:
something different: you have bumped apache-ant - please look at this
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-February/008464.h...
Any ideas how to fix our ant pkg that I can build OpenJDK again?
I apologize for that, I can't fix it. It's not my package. Sorry, but I will stay away from packages that are not mine. I just given you link to the previous version of apache-ant package. If you want, you can rebuild and force it to the previous version, then push it in extra repo.
I'll look into this as soon as I can. Hopefully by the weekend. I think the observation here was only to avoid doing big bumps (the kinds that break stuff) without coordinating with the maintainer. There's sometimes reasons those take a longer time, just because these sorts of details have to be figured out in advance. In general, I find having people help me out with minor bumps and fixes is really useful. - P
On 03/02/2010 10:54 AM, Giovanni Scafora wrote:
2010/3/2, Andreas Radke<a.radke@arcor.de>:
something different: you have bumped apache-ant - please look at this
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-February/008464.h...
Any ideas how to fix our ant pkg that I can build OpenJDK again?
I apologize for that, I can't fix it. It's not my package. Sorry, but I will stay away from packages that are not mine. I just given you link to the previous version of apache-ant package. If you want, you can rebuild and force it to the previous version, then push it in extra repo.
At first glance, this looks like exactly what happens to me when I try to build openjdk6 with ant 1.8.0. I'll look at what Debian did to fix it and see if it will work for us: http://www.mail-archive.com/debian-bugs-rc@lists.debian.org/msg210628.html - P
On 03/03/2010 07:54 AM, Paul Mattal wrote:
On 03/02/2010 10:54 AM, Giovanni Scafora wrote:
2010/3/2, Andreas Radke<a.radke@arcor.de>:
something different: you have bumped apache-ant - please look at this
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-February/008464.h...
Any ideas how to fix our ant pkg that I can build OpenJDK again?
I apologize for that, I can't fix it. It's not my package. Sorry, but I will stay away from packages that are not mine. I just given you link to the previous version of apache-ant package. If you want, you can rebuild and force it to the previous version, then push it in extra repo.
At first glance, this looks like exactly what happens to me when I try to build openjdk6 with ant 1.8.0. I'll look at what Debian did to fix it and see if it will work for us:
http://www.mail-archive.com/debian-bugs-rc@lists.debian.org/msg210628.html
So it looks like a straightforward patch-- but we don't build ant from source. Starting to do that is theoretically possible, but not trivial. Also, this patch is already accepted and targeted for 1.8.1. I'll think about the compiling from source option. It would clearly give us more flexibility in situations like this. I seem to recall we ran into other problems with it in the past, though. - P
Am 02.03.2010 14:47, schrieb Giovanni Scafora:
2010/3/2, Dan McGee <dpmcgee@gmail.com>:
Thank you Tobias for bringing this up; I've noticed it with more than just this package.
OK, then I will stay away from packages that are not mine. Let's keep up out of date packages! Thanks a lot for your rant.
Obviously this is counter-productive. There are lots of packages one can just "bump" without looking at them further. Samba is not one of them, as is mplayer (just to mention a few). We should instead introduce a comment into those PKGBUILDs right above the pkgver= to prevent people from messing with them. Something like: # MAINTAINER INFO: don't upgrade or # MAINTAINER INFO: version x.y.z, do not upgrade on x or y change The latter case would cover all samba problem, as anyone who isn't the primary maintainer will see that if x or y changes, he should not upgrade it.
Am Dienstag, 2. März 2010 17:02:02 schrieb Thomas Bächler:
We should instead introduce a comment into those PKGBUILDs right above the pkgver= to prevent people from messing with them. Something like:
Or people could just talk to each other. We probably all have jabber, email etc., or at least send a mail to this list. If the package is orphaned or the maintainer is temporary unavailable just send a mail to the list. I don't see any rant a reason for being sarcastic here. Team work simply doesn't work without communication. If a package needs some special treatment it should be noted within the PKGBUILD; but this doesn't replace communication. There are a lot of reasons why a maintainer doesn't want to bump a package right now. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 03/03/10 03:54, Pierre Schmitz wrote:
Am Dienstag, 2. März 2010 17:02:02 schrieb Thomas Bächler:
We should instead introduce a comment into those PKGBUILDs right above the pkgver= to prevent people from messing with them. Something like:
Or people could just talk to each other. We probably all have jabber, email etc., or at least send a mail to this list. If the package is orphaned or the maintainer is temporary unavailable just send a mail to the list.
This is my take on the issues: 1) If a package is an orphan, then no-one cares much about it and anybody should feel free to update or fix it. 2) If a package is maintained by a less active dev (we all have a fair idea who they are) and needs a _minor_ version bump, go ahead. For _major_ bumps, send them an email first. From my experience, even the ones who are not so active in packaging these days respond fairly quickly to emails. 3) If a package has a bug report that has not been dealt with in a long time and the maintainer has not put a negative comment against the fix, fell free to implement it. Of course, do not blindly assume bug reporters are correct. In particular, not all feature requests should be implemented... 4) If a package is maintained by an active dev and you still can not wait for them to update/fix it, send them an email. If they are losing interest in the package, it might even be offered for you to maintain. 5) TAKE RESPONSIBILITY FOR YOUR PACKAGING. Do not touch packages that you are unprepared to be assigned bugs reports from. Even minor upstream updates can result in issues. If your update breaks something, be prepared to fix it or downgrade the package. Of course, large rebuilds are an "all hands on deck" situation and we are all encouraged to rebuild whatever we can. Finally, get to know you other devs. This is one of the advantages of the fairly small team we have. I have a fair idea whose packages I can update/fix without them having any issues about it; whose packages I should ask first; and whose packages I would not touch with a 10 foot pole. And some devs cover all those categories depending on the package. Allan
2010/3/3, Allan McRae <allan@archlinux.org>:
This is my take on the issues:
1) If a package is an orphan, then no-one cares much about it and anybody should feel free to update or fix it.
2) If a package is maintained by a less active dev (we all have a fair idea who they are) and needs a _minor_ version bump, go ahead. For _major_ bumps, send them an email first. From my experience, even the ones who are not so active in packaging these days respond fairly quickly to emails.
3) If a package has a bug report that has not been dealt with in a long time and the maintainer has not put a negative comment against the fix, fell free to implement it. Of course, do not blindly assume bug reporters are correct. In particular, not all feature requests should be implemented...
4) If a package is maintained by an active dev and you still can not wait for them to update/fix it, send them an email. If they are losing interest in the package, it might even be offered for you to maintain.
5) TAKE RESPONSIBILITY FOR YOUR PACKAGING. Do not touch packages that you are unprepared to be assigned bugs reports from. Even minor upstream updates can result in issues. If your update breaks something, be prepared to fix it or downgrade the package.
Of course, large rebuilds are an "all hands on deck" situation and we are all encouraged to rebuild whatever we can.
Finally, get to know you other devs. This is one of the advantages of the fairly small team we have. I have a fair idea whose packages I can update/fix without them having any issues about it; whose packages I should ask first; and whose packages I would not touch with a 10 foot pole. And some devs cover all those categories depending on the package.
Thanks a lot for your contribution, Allan. In the future, I will follow very carefully the above simple five rules. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Thanks a lot for your contribution, Allan. In the future, I will follow very carefully the above simple five rules. I appreciate your help on doing rebuilds on .so version bumps very much and on other programs. I was quite shocked about putting samba directly to extra. Well no looking back, time to get the bugs fixed. umount.cifs is now restored in -2 package. Seems there are more bugs opened on bugtracker, I don't have time to look into them until the weekend. If anyone has time and fun feel free to to look into them.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
participants (9)
-
Allan McRae
-
Andreas Radke
-
Dan McGee
-
Eric Bélanger
-
Giovanni Scafora
-
Paul Mattal
-
Pierre Schmitz
-
Thomas Bächler
-
Tobias Powalowski