Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 25/08/15 17:59, Oxan van Leeuwen wrote: > On 25-08-15 09:09, Tomasz Buchert wrote: > >Hi, > >do you understand this lintian warning about incomplete translation? > >It complains about the templates file, it looks strange to me. > > I believe it complains that there are no translations for the debconf > templates yet. I'm not sure how to get translations for a package that isn't > in the archive yet though, a quick search revealed only workflows for > existing packages. > > Cheers, > Oxan > I've added Polish translation and the lintian tag is gone. The package is now uploaded and will hit NEW queue soon. Thanks for your patience! :D Tomasz signature.asc Description: Digital signature
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 25/08/15 17:59, Oxan van Leeuwen wrote: > On 25-08-15 09:09, Tomasz Buchert wrote: > >Hi, > >do you understand this lintian warning about incomplete translation? > >It complains about the templates file, it looks strange to me. > > I believe it complains that there are no translations for the debconf > templates yet. I'm not sure how to get translations for a package that isn't > in the archive yet though, a quick search revealed only workflows for > existing packages. > > Cheers, > Oxan > Ok, I'll upload what we have now. Tomasz signature.asc Description: Digital signature
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 25-08-15 09:09, Tomasz Buchert wrote: Hi, do you understand this lintian warning about incomplete translation? It complains about the templates file, it looks strange to me. I believe it complains that there are no translations for the debconf templates yet. I'm not sure how to get translations for a package that isn't in the archive yet though, a quick search revealed only workflows for existing packages. Cheers, Oxan
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 25/08/15 00:19, Oxan van Leeuwen wrote: > Hi Thomas, > > On 24-08-15 14:10, Tomasz Buchert wrote: > >Nicely done, but there is one issue. If you modify conffiles in postinst > >it marks them as changed, and this is not something you want to do. > > > >In my branch "tomasz-changes" I followed ADVANCED PROGRAMMING WITH > >DEBCONF section in "man debconf-devel". The outcome is that the config > >file is not tracked by conffiles machinery and hence the problem does > >not exist. Please review. > > Yeah, that's definitely true. Your branch looks good to me. It's probably a > bit cleaner to wrap the config-writing machinery in the postinst in an if [ > "$1" = "configure" ], but I don't think it hurts to execute it for the other > postinst invocations as well. > > Other than that, I don't think there are any remaining issues preventing > upload? Hi, do you understand this lintian warning about incomplete translation? It complains about the templates file, it looks strange to me. Anybody? Cheers, Tomasz > > Cheers, > Oxan > signature.asc Description: Digital signature
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi Thomas, On 24-08-15 14:10, Tomasz Buchert wrote: Nicely done, but there is one issue. If you modify conffiles in postinst it marks them as changed, and this is not something you want to do. In my branch "tomasz-changes" I followed ADVANCED PROGRAMMING WITH DEBCONF section in "man debconf-devel". The outcome is that the config file is not tracked by conffiles machinery and hence the problem does not exist. Please review. Yeah, that's definitely true. Your branch looks good to me. It's probably a bit cleaner to wrap the config-writing machinery in the postinst in an if [ "$1" = "configure" ], but I don't think it hurts to execute it for the other postinst invocations as well. Other than that, I don't think there are any remaining issues preventing upload? Cheers, Oxan
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 22/08/15 15:06, Oxan van Leeuwen wrote: > Hi, > > On 21-08-15 00:19, Tomasz Buchert wrote: > >I think that we either: > > > > * need hard dependency on postfix > > * need to have a debconf dialog that goes more or less like that: > > - if postconf exists, the domain is taken from there > > - if not, the current hostname is taken > > - then a debconf dialog is shown prefilled with these defaults > > - the obtained domain name is used in init scripts > > > >Waht do you think? Tell me if you need help with the second. > The second option seems sensible, I've pushed an implementation. Let me know > what you think. Nicely done, but there is one issue. If you modify conffiles in postinst it marks them as changed, and this is not something you want to do. In my branch "tomasz-changes" I followed ADVANCED PROGRAMMING WITH DEBCONF section in "man debconf-devel". The outcome is that the config file is not tracked by conffiles machinery and hence the problem does not exist. Please review. > > >I think that a sensible thing to do would be to provide POSTSRSD_OPTS > >as 'Environment=...' and then pull a config file with > >'EnvironmentFile=-...' (which may contain various configs in comments > >too). It seems to be sort-of standard. And, right, if you also use > >debconf, then you probably need to pull a file created created in > >postinst. > I'd prefer to keep separate variables for the most common options. A single > options variable will be quite cryptic (as postsrsd doesn't support long > options), and that will make it harder to change a setting without having to > pull the manpage. Duplicating a few defaults is a small price to pay for > ease of configuration in my opinion. We could add a options variable to add > additional command-line options, though I doubt it will be used much. Ok. > > Cheers, > Oxan > Cheers, Tomasz signature.asc Description: Digital signature
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi, On 21-08-15 00:19, Tomasz Buchert wrote: I think that we either: * need hard dependency on postfix * need to have a debconf dialog that goes more or less like that: - if postconf exists, the domain is taken from there - if not, the current hostname is taken - then a debconf dialog is shown prefilled with these defaults - the obtained domain name is used in init scripts Waht do you think? Tell me if you need help with the second. The second option seems sensible, I've pushed an implementation. Let me know what you think. I think that a sensible thing to do would be to provide POSTSRSD_OPTS as 'Environment=...' and then pull a config file with 'EnvironmentFile=-...' (which may contain various configs in comments too). It seems to be sort-of standard. And, right, if you also use debconf, then you probably need to pull a file created created in postinst. I'd prefer to keep separate variables for the most common options. A single options variable will be quite cryptic (as postsrsd doesn't support long options), and that will make it harder to change a setting without having to pull the manpage. Duplicating a few defaults is a small price to pay for ease of configuration in my opinion. We could add a options variable to add additional command-line options, though I doubt it will be used much. Cheers, Oxan
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 20/08/15 13:24, Oxan van Leeuwen wrote: > Hi, > Hi, > On 18-08-15 01:01, Tomasz Buchert wrote: > >great! Just nit-picking here, really. And trying to understand > >AppArmor :). > You seem to be right, I've committed a patch to remove the m flag. Ok. > > >Yes, I tried without postconf present and the unit failed. > > > >>Its output is silenced, and postsrsd fails > >>when the -d argument is empty anyway. > > > >I don't think you want this systemd unit to fail *by default*. > Hmm, you're right about that. Would a Recommends be good enough, or do we > really need a hard dependency? I'd like to avoid adding a hard dependency > only for the systemd unit (since the daemon itself runs fine without > postfix), and failing is in my opinion the only reasonable option when > neither postconf nor a configured domain is present. I think that we either: * need hard dependency on postfix * need to have a debconf dialog that goes more or less like that: - if postconf exists, the domain is taken from there - if not, the current hostname is taken - then a debconf dialog is shown prefilled with these defaults - the obtained domain name is used in init scripts Waht do you think? Tell me if you need help with the second. > > >Sorry, I didn't notice that. I agree, though, that it would make sense > >to put all configuation in one place. > I looked a bit further into this, and Debian Policy 9.3.2 says that removing > the /etc/default file should be supported, so I don't think we can drop the > defaults from the systemd unit. I think that a sensible thing to do would be to provide POSTSRSD_OPTS as 'Environment=...' and then pull a config file with 'EnvironmentFile=-...' (which may contain various configs in comments too). It seems to be sort-of standard. And, right, if you also use debconf, then you probably need to pull a file created created in postinst. > > Cheers, > Oxan > Cheers, Tomasz signature.asc Description: Digital signature
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi, On 18-08-15 01:01, Tomasz Buchert wrote: great! Just nit-picking here, really. And trying to understand AppArmor :). You seem to be right, I've committed a patch to remove the m flag. Yes, I tried without postconf present and the unit failed. Its output is silenced, and postsrsd fails when the -d argument is empty anyway. I don't think you want this systemd unit to fail *by default*. Hmm, you're right about that. Would a Recommends be good enough, or do we really need a hard dependency? I'd like to avoid adding a hard dependency only for the systemd unit (since the daemon itself runs fine without postfix), and failing is in my opinion the only reasonable option when neither postconf nor a configured domain is present. Sorry, I didn't notice that. I agree, though, that it would make sense to put all configuation in one place. I looked a bit further into this, and Debian Policy 9.3.2 says that removing the /etc/default file should be supported, so I don't think we can drop the defaults from the systemd unit. Cheers, Oxan
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 17/08/15 21:53, Oxan van Leeuwen wrote:
> Hi,
>
> On 15-08-15 12:21, Tomasz Buchert wrote:
> >I've tested the AppArmor profile too, it looks fine, although I'm not
> >sure if 'm' is needed in the profile for '/usr/sbin/postsrsd', since
> >it seems to work just fine without it. I've a rather basic knowledge
> >about AppArmor, so if you could explain it to me, I'd be grateful.
> I'm not sure about it either, I just copied the AppArmor profile from
> upstream. Judging from the AppArmor docs it's indeed not needed, I'll do
> some further research tomorrow and remove it if possible.
Hi,
great! Just nit-picking here, really. And trying to understand
AppArmor :).
>
> >And the last thing: in the systemd unit, you do:
> >
> >-d$${SRS_DOMAIN:-$$(postconf -h mydomain 2>/dev/null)}
> >
> >Well, first if SRS_DOMAIN is set to something that it's fine, if it's not,
> >then postconf is used to get the mail server domain. But postconf may not
> >be present! You probably need to depend on postfix, unless postsrsd can be
> >used
> >with other mail software.
> Technically postsrsd can be used with other mail servers too, though I doubt
> it will happen in practice. Is it really a problem if postconf is called
> when it's not present, though?
Yes, I tried without postconf present and the unit failed.
> Its output is silenced, and postsrsd fails
> when the -d argument is empty anyway.
I don't think you want this systemd unit to fail *by default*.
>
> >I'd also recommend using EnvironmentFile in your systemd unit [1].
> The systemd unit is already loading /etc/default/postsrsd as
> EnvironmentFile, it's just the defaults that are in the systemd unit. Not
> sure why I did that though (I believe we usually don't support removing
> files from /etc/default), so they can be safely removed. I'll push a fix.
Sorry, I didn't notice that. I agree, though, that it would make sense
to put all configuation in one place.
>
> >I also pushed some minor fixes.
> Are you sure? I don't see any new commits in the collab-maint repository.
>
No, I'm not sure ;). It's pushed right now (sometimes I miss svn, where
when you commit you also push ;) ).
> >When this is done, I'll be happy to push your package,
> >I already use it myself for some time :).
> That's great!
>
> Cheers,
> Oxan
>
Cheers,
Tomasz
signature.asc
Description: Digital signature
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi,
On 15-08-15 12:21, Tomasz Buchert wrote:
I've tested the AppArmor profile too, it looks fine, although I'm not
sure if 'm' is needed in the profile for '/usr/sbin/postsrsd', since
it seems to work just fine without it. I've a rather basic knowledge
about AppArmor, so if you could explain it to me, I'd be grateful.
I'm not sure about it either, I just copied the AppArmor profile from
upstream. Judging from the AppArmor docs it's indeed not needed, I'll do
some further research tomorrow and remove it if possible.
And the last thing: in the systemd unit, you do:
-d$${SRS_DOMAIN:-$$(postconf -h mydomain 2>/dev/null)}
Well, first if SRS_DOMAIN is set to something that it's fine, if it's not,
then postconf is used to get the mail server domain. But postconf may not
be present! You probably need to depend on postfix, unless postsrsd can be used
with other mail software.
Technically postsrsd can be used with other mail servers too, though I
doubt it will happen in practice. Is it really a problem if postconf is
called when it's not present, though? Its output is silenced, and
postsrsd fails when the -d argument is empty anyway.
I'd also recommend using EnvironmentFile in your systemd unit [1].
The systemd unit is already loading /etc/default/postsrsd as
EnvironmentFile, it's just the defaults that are in the systemd unit.
Not sure why I did that though (I believe we usually don't support
removing files from /etc/default), so they can be safely removed. I'll
push a fix.
I also pushed some minor fixes.
Are you sure? I don't see any new commits in the collab-maint repository.
When this is done, I'll be happy to push your package,
I already use it myself for some time :).
That's great!
Cheers,
Oxan
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 24/07/15 15:49, Oxan van Leeuwen wrote:
> Hi,
>
> On 24-07-15 02:43, Cameron Norman wrote:
> >I see the prerm file is empty -- why not just delete it?
> Oops, that's a leftover from the switch to dh_apparmor. I've deleted it
> in the git repository.
>
> >Also, why do you patch the sysv-redhat init script if you end up using
> >the sysv-lsb one? I think you can drop that part of the patch.
> Yes, it's probably not that useful to keep that patch. It shouldn't
> hurt either though.
>
> >Finally, have you actually tested the AppArmor profile works on Debian?
> Yes, I've tested it.
>
> Cheers,
> Oxan
>
Hi guys,
I've tested the AppArmor profile too, it looks fine, although I'm not
sure if 'm' is needed in the profile for '/usr/sbin/postsrsd', since
it seems to work just fine without it. I've a rather basic knowledge
about AppArmor, so if you could explain it to me, I'd be grateful.
And the last thing: in the systemd unit, you do:
-d$${SRS_DOMAIN:-$$(postconf -h mydomain 2>/dev/null)}
Well, first if SRS_DOMAIN is set to something that it's fine, if it's not,
then postconf is used to get the mail server domain. But postconf may not
be present! You probably need to depend on postfix, unless postsrsd can be used
with other mail software.
I'd also recommend using EnvironmentFile in your systemd unit [1].
I also pushed some minor fixes.
When this is done, I'll be happy to push your package,
I already use it myself for some time :).
Great work,
Tomasz
[1]
https://fedoraproject.org/wiki/Packaging%3aSystemd#EnvironmentFiles_and_support_for_.2Fetc.2Fsysconfig_files
signature.asc
Description: Digital signature
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi, On 24-07-15 02:43, Cameron Norman wrote: I see the prerm file is empty -- why not just delete it? Oops, that's a leftover from the switch to dh_apparmor. I've deleted it in the git repository. Also, why do you patch the sysv-redhat init script if you end up using the sysv-lsb one? I think you can drop that part of the patch. Yes, it's probably not that useful to keep that patch. It shouldn't hurt either though. Finally, have you actually tested the AppArmor profile works on Debian? Yes, I've tested it. Cheers, Oxan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi Tomasz, Yes, I'm still looking for a sponsor. Cheers, Oxan On 23-07-15 23:40, Tomasz Buchert wrote: Hi Oxan, still looking for a sponsor? I've just wanted to implement SRS on my mail server! Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On Wed, Jul 22, 2015 at 2:27 PM, Oxan van Leeuwen wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "postsrsd" > > * Package name: postsrsd >Version : 1.2-1 >Upstream Author : Timo Röhling > * URL : https://github.com/roehling/postsrsd > * License : GPL-2+ >Section : mail > > It builds those binary packages: > > postsrsd - Sender Rewriting Scheme (SRS) lookup table for Postfix > > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/postsrsd > > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/p/postsrsd/postsrsd_1.2-1.dsc > > More information about hello can be obtained from http://www.example.com. > > Changes since the last upload: > > postsrsd (1.2-1) unstable; urgency=medium > > * Initial release (Closes: #757720) > > -- Oxan van Leeuwen Fri, 26 Dec 2014 17:35:3 > I see the prerm file is empty -- why not just delete it? Also, why do you patch the sysv-redhat init script if you end up using the sysv-lsb one? I think you can drop that part of the patch. Finally, have you actually tested the AppArmor profile works on Debian? Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi Oxan, still looking for a sponsor? I've just wanted to implement SRS on my mail server! Tomasz signature.asc Description: Digital signature
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "postsrsd" * Package name: postsrsd Version : 1.2-1 Upstream Author : Timo Röhling * URL : https://github.com/roehling/postsrsd * License : GPL-2+ Section : mail It builds those binary packages: postsrsd - Sender Rewriting Scheme (SRS) lookup table for Postfix To access further information about this package, please visit the following URL: http://mentors.debian.net/package/postsrsd Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/postsrsd/postsrsd_1.2-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: postsrsd (1.2-1) unstable; urgency=medium * Initial release (Closes: #757720) -- Oxan van Leeuwen Fri, 26 Dec 2014 17:35:3 Regards, Oxan van Leeuwen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
