Re: [ITP] Sendmail 8.14.9
On 2014-11-18 22:51, D. Boland wrote: Corinna Vinschen wrote: Just FYI for the next time: You sent the announcement message to the wrong mailing list. Announcements should go to the (moderated) cygwin-announce mailing list, without the leading "[ANNOUNCEMENT]" in the subject line. After approval, they go to the cygwin-announce ML and are automatically bounced to the cygwin ML with the leading "[ANNOUNCEMENT]" text. The last time I did that, all my subsequent posts where seen as spam and I had to ask the postmaster to unblock my emails. The postmaster (Faylor) wrote that announce at cygwin is a spam trap and I shouldn't post there. The list is cygwin-announce AT cygwin.com, not announce. -- Yaakov
Re: [ITP] Sendmail 8.14.9
Corinna Vinschen wrote: > > Hi Daniel, > > On Nov 15 19:40, D. Boland wrote: > > > > BTW: The procmail package is also affected. Its postinstall script > > > > creates a > > > > local group 'mail' using 'net localgroup ...'. This should be changed, > > > > IMO. > > > > > > Ouch, I didn't see that when I GTGed the package :( > > > > > > Yes, that should definitely be changed for the same reasons. > > > > I uploaded version 15 of the Procmail 3.22 package (see my > > announcement in the cygwin group). > > Thanks. > > Just FYI for the next time: You sent the announcement message to the > wrong mailing list. Announcements should go to the (moderated) > cygwin-announce mailing list, without the leading "[ANNOUNCEMENT]" in > the subject line. After approval, they go to the cygwin-announce ML and > are automatically bounced to the cygwin ML with the leading > "[ANNOUNCEMENT]" text. The last time I did that, all my subsequent posts where seen as spam and I had to ask the postmaster to unblock my emails. The postmaster (Faylor) wrote that announce at cygwin is a spam trap and I shouldn't post there. I *did* have the leading [ANNOUNCEMENT] in the subject text. Could that be the problem? D.
Re: [RFC] incremental rebase
Corinna Vinschen writes: > That sounds complicated in terms of usage by maintainers. Maybe I > didn't quite grok the gist of the idea, so... given the number of > strata, how is a maintainer supposed to know what stratum a given > postinstall script should be? 0 and z are simple choices, but > otherwise... Do you have something in mind which might allow to automate > that for the maintainer? In cygport? Well, of course there are many more strata than needed. But I think that anything in "Base" should perhaps be in its own stratum, maybe "b" for instance. The idea is not to use them all, but to have something that can be extended as needed. Some stuff is already neatly layered (KDE depends on X depends on Base). Most of the postinstall scripts will be on a single default stratum "(i" or whatever we are going to decide) anyway. In any case, this is mainly about putting the mechanism in place or rather to specify it. Making it usable would require support from cygport and upset/genini. Using hidden groups (like the non-functional _PostInstallLast we already have) would be an obvious way to do that. > How does the default dependency order come into play? How, in general, > do you handle package dependencies if everything is stratumized? The > stratum used for a script might invariable break the required order, > unles the maintainer know *exactly* how to choose the stratum. Again, > if it's not just simply 0 or z. Inside each stratum the dependency order is kept. The dependecies of each package must then obviously all post-install on the same or a lower stratum. "0" and "z" are indeed special since they have no or all dependencies on postinstall fullfilled, respectively. >> That would be the project "Cygwin", right? > > That would be "cygwin-apps". Ah, I thought I was supposed to chose a project from the list. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [RFC] incremental rebase
On Nov 18 20:15, Achim Gratz wrote: > Corinna Vinschen writes: > > I'm glad for this initiative, but personally I don't have a strong > > opinion what's the best way to go forward. I'd just like to see some > > mechanism to allow what Achim's _autorebase replacement does, > > preferredly for _update-info-dir and other packages as well, and Ken's > > request makes sense to me. And I'd prefer a simple method, which can be > > easily deployed by us maintainers, with the help of cygport if possible. > > I've thought about it some more, here's where I am so far: > > 1. I'd like to move from suffix to prefix so that the scripts will list > in approximately the order they are run. > > 2. I'd like to prepare for perpetual scripts, triggered scripts and > general stratified postinstallation. > > 3. The implementation will at first only provide pre-postinstall and > post-postinstall, both perpetual. Proper implementation of the things > prepared for with 2. can then follow later. > > Here's how I think the prefixes should look like: > > naming convention: (-)?_
Re: [RFC] incremental rebase
Corinna Vinschen writes: > I'm glad for this initiative, but personally I don't have a strong > opinion what's the best way to go forward. I'd just like to see some > mechanism to allow what Achim's _autorebase replacement does, > preferredly for _update-info-dir and other packages as well, and Ken's > request makes sense to me. And I'd prefer a simple method, which can be > easily deployed by us maintainers, with the help of cygport if possible. I've thought about it some more, here's where I am so far: 1. I'd like to move from suffix to prefix so that the scripts will list in approximately the order they are run. 2. I'd like to prepare for perpetual scripts, triggered scripts and general stratified postinstallation. 3. The implementation will at first only provide pre-postinstall and post-postinstall, both perpetual. Proper implementation of the things prepared for with 2. can then follow later. Here's how I think the prefixes should look like: naming convention: (-)?_
Re: Deleting just released nettle-3 package
On 2014-11-18 05:08, Dr. Volker Zell wrote: I just realized that gnutls cannot be build with the latest just uploaded nettle-3.0 packages for both architectures. Should I upload a version bumped nettle-2.7-2 package ? I don't think that will be necessary; 2.7-1 should revert to curr: automatically. Then the nettle 3.0 specific files libnettle5-3.0-1.tar.xz libhogweed3-3.0-1.tar.xz libnettle-devel-3.0-1.tar.xz nettle-3.0-1.tar.xz nettle-3.0-1-src.tar.xz should be removed. Done. -- Yaakov
Re: [ITP] postfix 2.11.3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On November 17, 2014 7:00:10 PM CET, Christian Franke
wrote:
>Corinna Vinschen wrote:
>> On Nov 17 15:50, Christian Franke wrote:
>>> Corinna Vinschen wrote:
On Nov 17 14:00, Christian Franke wrote:
>> Also, is
>> passwd -R really required? This is typically no necessary,
>unless you
>> potentially have to do stuff with native Windows tools
>(cron, sshd
>> session). Postfix doesn't seem to be a candidate for that.
> For example the postsuper admin tool always drops root permissions
>by
> setuid/gid() to $mail_owner ('postfix') before doing anything
>interesting.
> (postfix never uses chown(), BTW).
>
> Could this really be done without passwd -R or cyglsa ?
Usually, yes. As a Cygwin tool without accessing native Windows
functionality, it should not have a problem using
https://cygwin.com/preliminary-ug/ntsec.html#ntsec-nopasswd1,
>unless
it has to access network drives.
>>> Does not work for me when running e.g. /usr/sbin/postsuper from any
>>> admin user. The local admin group normally does not provide
>>> SeCreateTokenPrivilege, at least on Win 7.
>> postsuper switches the user account? Where to? From the command
>line
>> that's obviously a problem.
>
>See above (It always switches to $mail_owner and does never use
>chown()).
>
> From postsuper.c:
>
>* All file/directory updates must be done as the mail system owner.
>This
>* is because Postfix daemons manipulate the queue with those same
> * privileges, so directories must be created with the right ownership.
>
>
>>In theory postsuper should just use the
>> account it's running under on Cygwin.
>
>In (upstream) theory & practice, it should run with least privileges,
>which is good :-)
Well, passwd -R is still some mild variation of security by obscurity, and it
might not be allowed in some environments. But then again, what company would
actually use postfix on Cygwin as their MTA? Never mind,then.
Corinna
- --
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQJEBAEBCgAuBQJUazl1JxxDb3Jpbm5hIFZpbnNjaGVuIDxjb3Jpbm5hQHZpbnNj
aGVuLmRlPgAKCRD1NgadrkRPoD2XD/9K9Dw6IFDCMKljb+NRKpcKpVTJtl0Tx/yo
qHNEVG2NsgaJGIv5DLigus0hHcPLCgC/iyJ773z61LX0tP88gzLvpOoTNsaWcYPI
MUvCXhU8KOGb9f1MfztdLCZZyK/Hf1UrRkwDxVBFyUBiJPmFrKcTjHD5LEZkSdxl
YLYIe+GCIx9K3bdo1L6VEpH+uy+kneExq+PRzpxF0WmgScjJJ16rHfffWyfFnFz4
NO+Bsa68oB83v8QlXHym4x7pfVzXA4MMxrSbVYYTyTbhZMMgTraTRXgHMZUVKxPD
aCAzgeqMrnC9Bivp440hkLBAo17USmqGvh0eRzSJH4Iv9aNB3bEGBBn82UODeb3N
OIzi+rr/U2ea0oJ+dh1jvVzo1DgVnlQUDN2Ro0I0DcaSQldYRNYNm0rST/PH+GDv
CXeawekosd/5hZsMzLbf5FKtArNAEQpA0KxR+0HY0/eIMJGVhFJySQDfDXT9qvTE
7/uN8Pv7atKMEjEtIuNOO4wFN3WEP9UnvVwmP7VXxzgSH5C0oe0pXLdowNenaPhR
xjcKhGt8gdFWy2e/HFh5iNXLGWMZl+9DMYi2z/HHBMinFUuZttObnyaTXRyiZVcq
GONQBuRreRgUsGiT44//C14Fhe6ulyOZ9Fq3r0TCiT9HiJNLXwLSvPB9HlrK0E16
Jr3ndtey3g==
=wxD6
-END PGP SIGNATURE-
Deleting just released nettle-3 package
Hi I just realized that gnutls cannot be build with the latest just uploaded nettle-3.0 packages for both architectures. Should I upload a version bumped nettle-2.7-2 package ? Then the nettle 3.0 specific files libnettle5-3.0-1.tar.xz libhogweed3-3.0-1.tar.xz libnettle-devel-3.0-1.tar.xz nettle-3.0-1.tar.xz nettle-3.0-1-src.tar.xz should be removed. Ciao Volker
Re: [RFC] incremental rebase
Hi guys, On Nov 17 20:08, Achim Gratz wrote: > Ken Brown writes: > > What I have in mind is simpler than this. There's nothing wrong with > > the existing texlive postinstall scripts except slowness, due to the > > repetition of time-consuming commands in different scripts. So I just > > need to do some rearranging: > > > > 1. I would create a pre-postinstall perpetual script that checks > > /etc/postinstall to see if there are any ordinary texlive postinstall > > scripts that are not marked as done. If so, it runs mktexlsr. [This > > may not be necessary; I have to think about it some more.] > > If the ls-R file is younger than the package file in /etc/setup, then it > has already been re-created in that postinstall session, I'd think. > > > 2. I would modify all ordinary texlive postinstall scripts to remove > > all calls to mktexlsr, fc-cache, and updmap-sys, except for calls to > > the latter that simply enable maps. > > If the above works, leave them in and conditionalize on the result of > that test. > > > And I would remove the --nohash > > option from those. In addition, these scripts would create a marker > > file to indicate that updmap-sys and fc-cache need to be run later. > > It might be possible to just do this based on the timestamps as well, > that is if ls-R is younger than some file, re-run updmap and fc-cache. > > > 3. I would create a post-postinstall perpetual script that runs > > updmap-sys and fc-cache as needed. > > Indeed. I'm glad for this initiative, but personally I don't have a strong opinion what's the best way to go forward. I'd just like to see some mechanism to allow what Achim's _autorebase replacement does, preferredly for _update-info-dir and other packages as well, and Ken's request makes sense to me. And I'd prefer a simple method, which can be easily deployed by us maintainers, with the help of cygport if possible. Yaakov, as cygport maintainer and distro overlord you are best-suited to handle this issue. Can you please chime in here and move this forward? Other than that, I'm open to almost everything. Achim, if you don't already have write access to the setup repo, please send your ssh key per https://sourceware.org/cgi-bin/pdw/ps_form.cgi. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpio_7F0aiuK.pgp Description: PGP signature
