[MacPorts] #41540: fetch-crl @3.0.12: new submission
#41540: fetch-crl @3.0.12: new submission -----------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: fetch-crl @3.0.12 -----------------------------+-------------------------------- This is another "Globus related" submission. Thanks for reviewing it! {{{ fetch-crl @3.0.12 (security, net) Description: The fetch-crl utility will retrieve certificate revocation lists (CRLs) for a set of installed trust anchors, based on crl_url files or IGTF-style info files. It will install these for use with OpenSSL, NSS or third-party tools. Homepage: http://wiki.nikhef.nl/grid/FetchCRL3 Platforms: darwin License: Apache-2 Maintainers: dennisvd@nikhef.nl, openmaintainer@macports.org }}} Again, I CC Dennis and Adam (same reasoning as for ticket #41532). For (co-)maintainer applies the same. The changes with respect to Dennis' former version: - update to 3.0.12; - add `openmaintainer`; - add `noarch`; This are perl scripts, so this should be okay; - add `license`, `long_description`, `livecheck`; - some further edits: minor format changes, destroot; Doubts: The scripts use System perl (/usr/bin/perl) so no dependency. Not sure if this is save and practise for MacPorts. -- Ticket URL: <https://trac.macports.org/ticket/41540> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission --------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl @3.0.12 | --------------------------------+-------------------------------- Comment (by Peter.Danecek@…): It looks like I made a copy paste error here. Please delete fetch-crl, @3.0.12 and add dennisvd@nikhef.nl. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Changes (by ram@…): * cc: fetch-crl, @… (removed) * cc: dennisvd@… (added) * type: defect => submission * port: fetch-crl @3.0.12 => fetch-crl -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by ram@…): A couple of comments: 1. With other ports that use launchd we name the plist file: `org.macports.${port}.plist` as to not interfere with upstream. May make sense to do this here. 1. I'm not sure I like the idea of the port running `launchctl`. In other ports that use launchd we leave the loading of the plist up to the user, MacPorts provides the `load` and `unload` commands that can be used to do this. I'd prefer seeing it work this way. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by Peter.Danecek@…): Thanks for the comments on lunched, have little experience on this. Could you point me to some port using it as you describe? -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by ram@…): Apologies but I'm not very familer with launchd either, I'd recommend emailing the list and asking for advice on how best to deal with a launchd plist. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) Comment: The `distfiles` line should be deleted since the default will work fine. The plist shouldn't be listed there because it's going to be in the files directory, not downloaded from a server at fetch time. The relevant section of the guide for launchd questions is the [http://guide.macports.org/chunked/reference.startupitems.html startupitem section], but MacPorts doesn't give you a lot of control over what goes into the plist; I see you're using `StartInterval` here which I don't think MacPorts knows about. In that case, you can install the plist manually like you're doing. Surprisingly, MacPorts doesn't check whether `startupitem.create` is `yes` when using the `sudo port load` and `sudo port unload` commands, so that works to your advantage in this case. Just make sure a symlink to the plist exists in /Library/LaunchDaemons/org.macports.${startupitem.name}.plist like you're doing. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by Peter.Danecek@…): Replying to [comment:6 ryandesign@…]:
The `distfiles` line should be deleted since the default will work fine. The plist shouldn't be listed there because it's going to be in the files directory, not downloaded from a server at fetch time.
Right, this was a left-over. Already deleted.
The relevant section of the guide for launchd questions is the [http://guide.macports.org/chunked/reference.startupitems.html startupitem section], but MacPorts doesn't give you a lot of control over what goes into the plist; I see you're using `StartInterval` here which I don't think MacPorts knows about. In that case, you can install the plist manually like you're doing. Surprisingly, MacPorts doesn't check whether `startupitem.create` is `yes` when using the `sudo port load` and `sudo port unload` commands, so that works to your advantage in this case. Just make sure a symlink to the plist exists in /Library/LaunchDaemons/org.macports.${startupitem.name}.plist like you're doing.
I renamed the plist file comply with the Macports naming scheme, but I realise it is not always followed by other ports. {{{ lrwxr-xr-x 1 root couchdb 57 Sep 4 18:01 org.apache.couchdb.plist -> /opt/local/Library/LaunchDaemons/org.apache.couchdb.plist lrwxr-xr-x 1 root admin 63 Nov 23 21:45 org.freedesktop.avahi- daemon.plist -> /opt/local/etc/LaunchDaemons/org.freedesktop.avahi- daemon.plist lrwxr-xr-x 1 root admin 65 Nov 23 21:45 org.freedesktop.avahi- dnsconfd.plist -> /opt/local/etc/LaunchDaemons/org.freedesktop.avahi- dnsconfd.plist lrwxr-xr-x 1 root admin 66 Jul 4 16:58 org.freedesktop.dbus- system.plist -> /opt/local/Library/LaunchDaemons/org.freedesktop.dbus- system.plist lrwxr-xr-x 1 root admin 82 Aug 14 22:11 org.macports.VirtualBox.plist -> /opt/local/etc/LaunchDaemons/org.macports.VirtualBox/org.macports.VirtualBox.plist lrwxr-xr-x 1 root admin 76 Nov 12 17:06 org.macports.antinat.plist -> /opt/local/etc/LaunchDaemons/org.macports.antinat/org.macports.antinat.plist lrwxr-xr-x 1 root admin 76 Nov 20 19:12 org.macports.apache2.plist -> /opt/local/etc/LaunchDaemons/org.macports.apache2/org.macports.apache2.plist lrwxr-xr-x 1 root admin 80 Mar 23 2013 org.macports.cassandra.plist -> /opt/local/etc/LaunchDaemons/org.macports.cassandra/org.macports.cassandra.plist lrwxr-xr-x 1 root admin 76 Nov 7 13:06 org.macports.mongodb.plist -> /opt/local/etc/LaunchDaemons/org.macports.mongodb/org.macports.mongodb.plist -rw-r--r-- 1 root admin 645 Sep 19 18:35 org.macports.privileged_startx.plist lrwxr-xr-x 1 root admin 74 Nov 18 2012 org.macports.rsyncd.plist -> /opt/local/etc/LaunchDaemons/org.macports.rsyncd/org.macports.rsyncd.plist }}} So what is the background here, and why `org.macports.privileged_startx.plist` installed directly? Another doubt is about these subdirectories in `/opt/local/etc/LaunchDaemons`: {{{ petr% ls -la total 8 drwxr-xr-x 10 root admin 340 Nov 26 15:36 . drwxr-xr-x 51 root admin 1734 Nov 26 15:36 .. -rwxr-xr-x 1 root admin 453 Nov 23 21:45 org.freedesktop.avahi- daemon.plist -rwxr-xr-x 1 root admin 457 Nov 23 21:45 org.freedesktop.avahi- dnsconfd.plist drwxr-xr-x 4 root wheel 136 Aug 14 22:11 org.macports.VirtualBox drwxr-xr-x 3 root wheel 102 Nov 12 17:06 org.macports.antinat drwxr-xr-x 4 root wheel 136 Nov 22 22:32 org.macports.apache2 drwxr-xr-x 3 root wheel 102 Nov 7 12:13 org.macports.cassandra drwxr-xr-x 3 root wheel 102 Nov 7 13:07 org.macports.mongodb drwxr-xr-x 4 root wheel 136 Oct 23 17:31 org.macports.rsyncd }}} I would have installed directly in `/opt/local/etc/LaunchDaemons`. Is there anything wrong about this? The guide does not mention `sudo port load ` and `sudo port unload`, but from `port(1)` I would understand that it translates to the corresponding `launchctl` commands. But the line {{{ system "launchctl remove org.eugridpma.fetch-crl || true" }}} has no correspondence. Is it save to just leave this line away? Is there some more magic involved with `port load / unload`? Might it be possible and/or reasonable to use `startupitem.create yes` instead and add the `StartInterval` in a later stage? Is there some hook, e.g. something like `startupitem-append` to do this? Or at which stage this could be done? Thanks! -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by Peter.Danecek@…): Okay this is where I got so far. I update the `Portfile` and attach `org.macports.fetch-crl.plist`, which would go into files. The file `org.eugridpma.fetch-crl.plist` becomes irrelevant. I still have some doubt on plist file handling, but see comment:7 for details. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by ryandesign@…): Replying to [comment:7 Peter.Danecek@…]:
I renamed the plist file comply with the Macports naming scheme, but I realise it is not always followed by other ports. {{{ lrwxr-xr-x 1 root couchdb 57 Sep 4 18:01 org.apache.couchdb.plist -> /opt/local/Library/LaunchDaemons/org.apache.couchdb.plist lrwxr-xr-x 1 root admin 63 Nov 23 21:45 org.freedesktop.avahi- daemon.plist -> /opt/local/etc/LaunchDaemons/org.freedesktop.avahi- daemon.plist lrwxr-xr-x 1 root admin 65 Nov 23 21:45 org.freedesktop.avahi- dnsconfd.plist -> /opt/local/etc/LaunchDaemons/org.freedesktop.avahi- dnsconfd.plist lrwxr-xr-x 1 root admin 66 Jul 4 16:58 org.freedesktop.dbus- system.plist -> /opt/local/Library/LaunchDaemons/org.freedesktop.dbus- system.plist lrwxr-xr-x 1 root admin 82 Aug 14 22:11 org.macports.VirtualBox.plist -> /opt/local/etc/LaunchDaemons/org.macports.VirtualBox/org.macports.VirtualBox.plist lrwxr-xr-x 1 root admin 76 Nov 12 17:06 org.macports.antinat.plist -> /opt/local/etc/LaunchDaemons/org.macports.antinat/org.macports.antinat.plist lrwxr-xr-x 1 root admin 76 Nov 20 19:12 org.macports.apache2.plist -> /opt/local/etc/LaunchDaemons/org.macports.apache2/org.macports.apache2.plist lrwxr-xr-x 1 root admin 80 Mar 23 2013 org.macports.cassandra.plist -> /opt/local/etc/LaunchDaemons/org.macports.cassandra/org.macports.cassandra.plist lrwxr-xr-x 1 root admin 76 Nov 7 13:06 org.macports.mongodb.plist -> /opt/local/etc/LaunchDaemons/org.macports.mongodb/org.macports.mongodb.plist -rw-r--r-- 1 root admin 645 Sep 19 18:35 org.macports.privileged_startx.plist lrwxr-xr-x 1 root admin 74 Nov 18 2012 org.macports.rsyncd.plist -> /opt/local/etc/LaunchDaemons/org.macports.rsyncd/org.macports.rsyncd.plist }}}
And this has been a problem, for example you'll find many tickets (e.g. #34359) and mailing list discussions from people encountering errors on activation of dbus, because its plist has a nonstandard name. Launchd plists have to be installed in (or symlinked into) the public directory /Library/LaunchDaemons, so if a user wants to [http://guide.macports.org/chunked/installing.macports.uninstalling.html uninstall MacPorts] but the `port` command is not working and he has to resort to using `sudo rm -rf`, the best we can do is give them a list of globs patterns to delete, and since /Library/LaunchDaemons may contain non-MacPorts files, we can't tell them to delete everything there; we can only tell them to delete everything starting with org.macports, which doesn't cover ports like dbus that install plists with different prefixes, so the dbus files remain. Then the user reinstalls MacPorts and encounters errors activating dbus. So if you're installing a launchd plist with MacPorts, please if possible use the org.macports prefix.
So what is the background here, and why `org.macports.privileged_startx.plist` installed directly?
I suppose because the xinit port is a little unusual. You could ask that port's maintainer why it's done that way. It may be a bug. It may be part of the cause for [https://lists.macosforge.org/pipermail/macports- users/2013-November/034019.html this problem]. Best would be to do what MacPorts base does: install in ${prefix}/etc/LaunchDaemons, then, if requested, symlink to the real location.
Another doubt is about these subdirectories in `/opt/local/etc/LaunchDaemons`:
{{{ petr% ls -la total 8 drwxr-xr-x 10 root admin 340 Nov 26 15:36 . drwxr-xr-x 51 root admin 1734 Nov 26 15:36 .. -rwxr-xr-x 1 root admin 453 Nov 23 21:45 org.freedesktop.avahi- daemon.plist -rwxr-xr-x 1 root admin 457 Nov 23 21:45 org.freedesktop.avahi- dnsconfd.plist drwxr-xr-x 4 root wheel 136 Aug 14 22:11 org.macports.VirtualBox drwxr-xr-x 3 root wheel 102 Nov 12 17:06 org.macports.antinat drwxr-xr-x 4 root wheel 136 Nov 22 22:32 org.macports.apache2 drwxr-xr-x 3 root wheel 102 Nov 7 12:13 org.macports.cassandra drwxr-xr-x 3 root wheel 102 Nov 7 13:07 org.macports.mongodb drwxr-xr-x 4 root wheel 136 Oct 23 17:31 org.macports.rsyncd }}}
I would have installed directly in `/opt/local/etc/LaunchDaemons`. Is there anything wrong about this?
It looks like MacPorts base creates directories when the port specifies `startupitem.start`, `startupitem.stop`, and/or `startupitem.restart`, because in those cases it needs to write a short wrapper shell script containing those commands and references that script from the plist, and I guess it seemed neater to have only a single item in ${prefix}/etc/LaunchDaemons for each port. When using `startupitem.executable` instead, which is the preferred method, then the plist can reference that executable directly and doesn't need a wrapper script.
The guide does not mention `sudo port load ` and `sudo port unload`, but from `port(1)` I would understand that it translates to the corresponding `launchctl` commands. But the line {{{ system "launchctl remove org.eugridpma.fetch-crl || true" }}} has no correspondence. Is it save to just leave this line away? Is there some more magic involved with `port load / unload`?
There's no magic; `port load` and `port unload` map directly to `launchctl`; e.g. browser:trunk/base/src/port1.0/portload.tcl. From this we can also see that the path you should be symlinking the plist to is /Library/${startupitem.location}/${startupitem.plist}. I don't know what `launchctl remove` does.
Might it be possible and/or reasonable to use `startupitem.create yes` instead and add the `StartInterval` in a later stage? Is there some hook, e.g. something like `startupitem-append` to do this? Or at which stage this could be done?
There's no hook specifically for that. This is what I meant when I said above that MacPorts doesn't give you a lot of control over it. I don't know exactly when the plist is created; you could try patching it in post- destroot if you want to go that route. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by Peter.Danecek@…): I am reconsidering the function of this port slightly. Actually this port makes the assumption that certificates go (will go) into `${prefix}/etc/grid-security/certificates`. This might not be the case and above all depends on choices made elsewhere (e.g. `igtf-bundle` see ticket #41532). On the other hand, the utilities provided by this port, are potentially useful in a context independent of any prepackages certificate bundle, for example if the user decides to manage certificates manually or to install them in `/etc/grid-security` for example, this tools still could be used. So this is what I propose: - this port installs **only** the utilities, the docu and an example config file; - does **no** default configuration and **no** launchd magic; - such configuration is moved to any potential user (dependent) of this port, e.g. (future) `igtf-bundle` port; - igtf-bundle will depend on this port and use it to make a first request for CRLs on activation, and clean CRLs when deactivated; It may provide a auto-fetch launchd service as well; -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by Peter.Danecek@…): I did some testing and share here some findings. Replying to [comment:9 ryandesign@…]:
I don't know what `launchctl remove` does. Seems, that this does basically the same as unload but does not require a plist file, instead it uses the job label.
Might it be possible and/or reasonable to use `startupitem.create yes` instead and add the `StartInterval` in a later stage? Is there some hook, e.g. something like `startupitem-append` to do this? Or at which stage this could be done?
There's no hook specifically for that. This is what I meant when I said above that MacPorts doesn't give you a lot of control over it. I don't know exactly when the plist is created; you could try patching it in post- destroot if you want to go that route.
I conclude, there is now no way to patch/modify/replace the created plist file. The reason is that the plist is created and added in the `destroot`-stage, but the files and links are not **yet** in place when `post-destroot` is executed. So the `startupitem` related stuff (and the message) are created **after** after `post-destroot`. Not sure if this is the best way to handle `startupitem`. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:11> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by Peter.Danecek@…): I updated the Portfile and it now provides to ports: * `fetch-crl` installs only the utility * `fetch-crl-launchd` installs the launchd entry * The port is now bumped to @3.0.13 I think, the problems from the former discussion are solved. Please review and commit, Thanks! -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:12> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by ram@…): Thanks, I'm swamped at the moment, with deadlines at work and visitors in town, but should be able to take a look at this after 3rd June. Hopefully someone else with commit access can get to it sooner... -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:13> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by Peter.Danecek@…): Laters small change related to corresponding change to #41532. The cached state files are now purged on `deactivate` here. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:14> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by Peter.Danecek@…): A small correction to the {{{ui_msg}}} statements, according to ticket:41532#comment:27. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:15> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by Peter.Danecek@…): Replying to [comment:13 ram@…]:
Thanks, I'm swamped at the moment, with deadlines at work and visitors in town, but should be able to take a look at this after 3rd June. Hopefully someone else with commit access can get to it sooner...
Hi, could you have a look at this now? -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:16> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.14: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:17> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.14: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by petr@…): I just updated the Portfile for `fetch-crl`: version bump and maintainer address changed. You will find the whole port [source:users/petr/ports/security/fetch-crl here] as well. I would appreciate if someone could audit it before I commit. It works fine for me, but maybe someone with more experienced might have a different idea on how it should be solved. Thanks! -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:18> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.14: new submission ------------------------------+-------------------- Reporter: Peter.Danecek@… | Owner: petr@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------- Changes (by ram@…): * owner: macports-tickets@… => petr@… Comment: Sorry for the delay, but this looks good to me. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:19> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.14: new submission ------------------------------+-------------------- Reporter: Peter.Danecek@… | Owner: petr@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------- Comment (by petr@…): Thanks! So I'll commit this and move on the tricky parts. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:20> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.14: new submission ------------------------------+-------------------- Reporter: Peter.Danecek@… | Owner: petr@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------- Comment (by petr@…): Committed in r121398. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:21> MacPorts <http://www.macports.org/> Ports system for OS X
#41540: fetch-crl @3.0.14: new submission ------------------------------+-------------------- Reporter: Peter.Danecek@… | Owner: petr@… Type: submission | Status: closed Priority: Normal | Milestone: Component: ports | Version: Resolution: fixed | Keywords: Port: fetch-crl | ------------------------------+-------------------- Changes (by petr@…): * status: new => closed * resolution: => fixed -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:22> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts