Re: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

newer
[arch-dev-public] Signoff report...

older
[arch-dev-public] Signoff report...

Sébastien Luttringer

14 May 2013 14 May '13

8:37 p.m.

On Tue, May 14, 2013 at 10:22 PM, Bartłomiej Piotrowski wrote:

Date: Tuesday, May 14, 2013 @ 22:22:08 Author: bpiotrowski Revision: 90846

upgpkg: fail2ban 0.8.8-3

- correct path to sendmail due to migration to /usr/bin

I see you moved exim from /usr/sbin/sendmail to /usr/bin/sendmail. This path is hardcoded to /usr/sbin/sendmail in _many_ sotfwares and all others rely on it (ssmtp, postfix, opensmtpd, heilroom-mailx, etc). By example, # mail -s toto seblu@seblu.net test . EOT /usr/sbin/sendmail: No such file or directory "/root/dead.letter" 9/210 . . . message not sent. I think we should do this correctly and rebuild /usr/sbin/sendmail in one shot, or include it in the global switch. -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A

Show replies by date

Dave Reisner

14 May 14 May

8:49 p.m.

New subject: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

On Tue, May 14, 2013 at 10:37:43PM +0200, Sébastien Luttringer wrote:

...

On Tue, May 14, 2013 at 10:22 PM, Bartłomiej Piotrowski wrote:

...
Date: Tuesday, May 14, 2013 @ 22:22:08 Author: bpiotrowski Revision: 90846

upgpkg: fail2ban 0.8.8-3

- correct path to sendmail due to migration to /usr/bin

I see you moved exim from /usr/sbin/sendmail to /usr/bin/sendmail.

This path is hardcoded to /usr/sbin/sendmail in _many_ sotfwares and all others rely on it (ssmtp, postfix, opensmtpd, heilroom-mailx, etc).

By example, # mail -s toto seblu@seblu.net test . EOT /usr/sbin/sendmail: No such file or directory "/root/dead.letter" 9/210 . . . message not sent.

I think we should do this correctly and rebuild /usr/sbin/sendmail in one shot, or include it in the global switch.

It's only hardcoded as /usr/sbin/sendmail for mailx because that's what the PKGBUILD for heirloom-mailx sets it to. Other packages can be fixed as well.

Tom Gundersen

9:07 p.m.

New subject: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

On Tue, May 14, 2013 at 10:49 PM, Dave Reisner wrote:

...

On Tue, May 14, 2013 at 10:37:43PM +0200, Sébastien Luttringer wrote:

...
On Tue, May 14, 2013 at 10:22 PM, Bartłomiej Piotrowski wrote:

...
Date: Tuesday, May 14, 2013 @ 22:22:08 Author: bpiotrowski Revision: 90846

upgpkg: fail2ban 0.8.8-3

- correct path to sendmail due to migration to /usr/bin

I see you moved exim from /usr/sbin/sendmail to /usr/bin/sendmail.

This path is hardcoded to /usr/sbin/sendmail in _many_ sotfwares and all others rely on it (ssmtp, postfix, opensmtpd, heilroom-mailx, etc).

By example, # mail -s toto seblu@seblu.net test . EOT /usr/sbin/sendmail: No such file or directory "/root/dead.letter" 9/210 . . . message not sent.

I think we should do this correctly and rebuild /usr/sbin/sendmail in one shot, or include it in the global switch.

It's only hardcoded as /usr/sbin/sendmail for mailx because that's what the PKGBUILD for heirloom-mailx sets it to. Other packages can be fixed as well.

I'm not following. If this path is hardcoded in several packages (and presumably in lots of custom packages/scripts), isn't this precisely one of the cases where we should delay the move until we do the proper usrmove and create the compat symlinks? Cheers, Tom

Dave Reisner

9:17 p.m.

New subject: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

On Tue, May 14, 2013 at 11:07:59PM +0200, Tom Gundersen wrote:

...

On Tue, May 14, 2013 at 10:49 PM, Dave Reisner wrote:

...
On Tue, May 14, 2013 at 10:37:43PM +0200, Sébastien Luttringer wrote:

...
On Tue, May 14, 2013 at 10:22 PM, Bartłomiej Piotrowski wrote:

...
Date: Tuesday, May 14, 2013 @ 22:22:08 Author: bpiotrowski Revision: 90846

upgpkg: fail2ban 0.8.8-3

- correct path to sendmail due to migration to /usr/bin

I see you moved exim from /usr/sbin/sendmail to /usr/bin/sendmail.

This path is hardcoded to /usr/sbin/sendmail in _many_ sotfwares and all others rely on it (ssmtp, postfix, opensmtpd, heilroom-mailx, etc).

By example, # mail -s toto seblu@seblu.net test . EOT /usr/sbin/sendmail: No such file or directory "/root/dead.letter" 9/210 . . . message not sent.

I think we should do this correctly and rebuild /usr/sbin/sendmail in one shot, or include it in the global switch.

It's only hardcoded as /usr/sbin/sendmail for mailx because that's what the PKGBUILD for heirloom-mailx sets it to. Other packages can be fixed as well.

I'm not following. If this path is hardcoded in several packages (and presumably in lots of custom packages/scripts), isn't this precisely one of the cases where we should delay the move until we do the proper usrmove and create the compat symlinks?

Cheers,

Tom

Expanding on that logic, why aren't we just doing this all at once?

Allan McRae

9:26 p.m.

New subject: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

On 15/05/13 07:17, Dave Reisner wrote:

...

On Tue, May 14, 2013 at 11:07:59PM +0200, Tom Gundersen wrote:

...
On Tue, May 14, 2013 at 10:49 PM, Dave Reisner wrote:

...
On Tue, May 14, 2013 at 10:37:43PM +0200, Sébastien Luttringer wrote:

...
On Tue, May 14, 2013 at 10:22 PM, Bartłomiej Piotrowski wrote:

...
Date: Tuesday, May 14, 2013 @ 22:22:08 Author: bpiotrowski Revision: 90846

upgpkg: fail2ban 0.8.8-3

- correct path to sendmail due to migration to /usr/bin

I see you moved exim from /usr/sbin/sendmail to /usr/bin/sendmail.

This path is hardcoded to /usr/sbin/sendmail in _many_ sotfwares and all others rely on it (ssmtp, postfix, opensmtpd, heilroom-mailx, etc).

By example, # mail -s toto seblu@seblu.net test . EOT /usr/sbin/sendmail: No such file or directory "/root/dead.letter" 9/210 . . . message not sent.

I think we should do this correctly and rebuild /usr/sbin/sendmail in one shot, or include it in the global switch.

It's only hardcoded as /usr/sbin/sendmail for mailx because that's what the PKGBUILD for heirloom-mailx sets it to. Other packages can be fixed as well.

I'm not following. If this path is hardcoded in several packages (and presumably in lots of custom packages/scripts), isn't this precisely one of the cases where we should delay the move until we do the proper usrmove and create the compat symlinks?

Cheers,

Tom

Expanding on that logic, why aren't we just doing this all at once?

I really wanted to reduce the size of the job first, given ~90% of the rebuild could be easily done separately. Allan

Sébastien Luttringer

11:46 p.m.

New subject: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

On Tue, May 14, 2013 at 11:26 PM, Allan McRae wrote:

...

On 15/05/13 07:17, Dave Reisner wrote:

...
On Tue, May 14, 2013 at 11:07:59PM +0200, Tom Gundersen wrote:

...
...
On Tue, May 14, 2013 at 10:37:43PM +0200, Sébastien Luttringer wrote:

...
On Tue, May 14, 2013 at 10:22 PM, Bartłomiej Piotrowski wrote: I'm not following. If this path is hardcoded in several packages (and

On Tue, May 14, 2013 at 10:49 PM, Dave Reisner wrote: presumably in lots of custom packages/scripts), isn't this precisely one of the cases where we should delay the move until we do the proper usrmove and create the compat symlinks?

Expanding on that logic, why aren't we just doing this all at once?

I really wanted to reduce the size of the job first, given ~90% of the rebuild could be easily done separately.

And I suggested to keep the well known hardcoded path /usr/sbin/sendmail (like the famous /bin/bash) for the last 10%. Cheers, -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A

Bartłomiej Piotrowski

15 May 15 May

11:02 a.m.

New subject: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

On 2013-05-14 22:37, Sébastien Luttringer wrote:

...

On Tue, May 14, 2013 at 10:22 PM, Bartłomiej Piotrowski wrote:

...
Date: Tuesday, May 14, 2013 @ 22:22:08 Author: bpiotrowski Revision: 90846

upgpkg: fail2ban 0.8.8-3

- correct path to sendmail due to migration to /usr/bin

I see you moved exim from /usr/sbin/sendmail to /usr/bin/sendmail.

This path is hardcoded to /usr/sbin/sendmail in _many_ sotfwares and all others rely on it (ssmtp, postfix, opensmtpd, heilroom-mailx, etc).

By example, # mail -s toto seblu@seblu.net test . EOT /usr/sbin/sendmail: No such file or directory "/root/dead.letter" 9/210 . . . message not sent.

I think we should do this correctly and rebuild /usr/sbin/sendmail in one shot, or include it in the global switch.

-- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A

Alea iacta est. While I agree that move could be planned better, it's not exim (nor any other MTA) fault that someone took bad decision to hardcode path to sendmail. SMTP forwarders aren't as crucial as bash is, therefore I don't see any reason to revert changes or delay moving binaries to /usr/bin. Just message maintainer that his package is broken due to recent changes. -- Bartłomiej Piotrowski http://bpiotrowski.pl/

Pierre Schmitz

3:48 p.m.

New subject: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

Am 15.05.2013 13:02, schrieb Bartłomiej Piotrowski:

...

Alea iacta est. While I agree that move could be planned better, it's not exim (nor any other MTA) fault that someone took bad decision to hardcode path to sendmail.

SMTP forwarders aren't as crucial as bash is, therefore I don't see any reason to revert changes or delay moving binaries to /usr/bin. Just message maintainer that his package is broken due to recent changes.

I am pretty sure this breaks a lot of stuff (PHP, web apps, scripts etc.). There is no reason to intentionally break things. It also doesn't matter who's fault it is and if using absolute paths is a great idea or not. I would say if a package is known to or might be used by third party apps or custom scripts, we should delay the move to the point where we can introduce a /bin /usr/bin symlink etc. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

Sébastien Luttringer

8:15 p.m.

New subject: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

On Wed, May 15, 2013 at 1:02 PM, Bartłomiej Piotrowski wrote:

...

On 2013-05-14 22:37, Sébastien Luttringer wrote:

...
On Tue, May 14, 2013 at 10:22 PM, Bartłomiej Piotrowski wrote:

...
Date: Tuesday, May 14, 2013 @ 22:22:08 Author: bpiotrowski Revision: 90846

SMTP forwarders aren't as crucial as bash is Without judging what you say, It's not a reason to break them!

...

I don't see any reason to revert changes or delay moving binaries to /usr/bin. Just message maintainer that his package is broken due to recent changes.

You're not alone to provide a smtp forwarder "virtual" package and the path provided by all must be the same. We cannot ask to users and others packagers to update their path if it is not the same accross smtp forwarders. Some packages will works with exim and others will not works with postfix, openstmpd, ssmtp, etc. The fail2ban package is a good example. This let no time to others to rebuild against the new path without breaking things and make us rush because you decide. This is *strong* reasons to revert your change. My suggestion is to wait Allan runs the final /usr move, because fixing the path in all _not_ packaged scripts or webapps is boring and not necessary. And we will need to be synchronized for the final step, so it will be easy to fixed package at this moment. Let's be pragmatic. Cheers, -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A

Tom Gundersen

8:23 p.m.

New subject: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

On Wed, May 15, 2013 at 1:02 PM, Bartłomiej Piotrowski wrote:

...

SMTP forwarders aren't as crucial as bash is, therefore I don't see any reason to revert changes or delay moving binaries to /usr/bin. Just message maintainer that his package is broken due to recent changes.

I see that this is a borderline case, but I agree with Allan and Pierre, no need to break stuff unnecessarily. Please revert (or add a symlink). Cheers, Tom

4018

Age (days ago)

4019

Last active (days ago)

List overview

Download

9 comments

6 participants

participants (6)

Allan McRae
Bartłomiej Piotrowski
Dave Reisner
Pierre Schmitz
Sébastien Luttringer
Tom Gundersen