Re: Portfile: fetching/verifying a single file

On 8/29/20 5:52 , Ryan Schmidt wrote: > On Aug 28, 2020, at 21:52, Eric F wrote: >> When downloading/fetching a single (script) file from a Git repo. If I use: >> >> // ... >> >> That works, and I can verify against the checksums, etc. But is that an ok >> method? …or is there a better &/or

Portfile: fetching/verifying a single file

Hi, When downloading/fetching a single (script) file from a Git repo. If I use: ``` fetch { file mkdir ${worksrcpath} system -W ${worksrcpath} "curl -qs ${master_sites}/${_file} -o ${distpath}/${distname}" } post-checksum { copy ${distpath}/${distname} ${worksrcpath} } ``` That

Re: supertuxkart non-redistributable?

Fedora, who usually are very restricted about things, have this take: > “ However, we consider that the OpenSSL library is a system library, as > defined by the GPL, *on Fedora* and therefore we are allowed to ship GPL > software that links to the OpenSSL library. …” > — >

Re: port "cask" -- installing prebuilt binaries

On 8/15/20 8:48 , Lothar Haeger wrote: >> Am 15.08.2020 um 01:11 schrieb Ken Cunningham >> : >> >> so -- what would a user typing > Obviously that variant would conflict with all other variants, much like > +ruby21 conflicts with +ruby22. So the user would type > > sudo port -v install macvim

Re: PRs now going back 18 months -- let's close the clearly dead ones

On 7/26/20 8:20 , Ryan Schmidt wrote: >> We don’t want the PR queue to start to look like the (ridiculous) ticket >> list, with dormant open tickets going back decades. >> >> Ken > > The ridiculous ticket list is similarly important. … > > Of course, if there are open tickets or PRs that are

Re: Port variants for deps

On 9/20/19 3:10 , Ryan Schmidt wrote: > Oh, I didn't realize you were talking about a perl module. That's more > complicated, because a perl module port already creates its own subports, one > for each perl version. I see you've figured out a way to do it anyway, but > I'm really not sure it's

Re: Port variants for deps

On 9/16/19 23:20 , Ryan Schmidt wrote: > On Sep 15, 2019, at 22:31, Eric F (iEFdev) wrote: >> What would be better (ie good “portiquette”)… Adding subports (keeping the >> variants), or replacing variants with subports? > Provide only one way for a user to install a feature

Re: Port variants for deps

-16 12:44 , Eric F (iEFdev) wrote: >> /Evening all,/ >> >> To pass along a variant for a dependency, without having to add in when >> you install. >> How do you do that? …or is there really no other way than adding it >> during “port

Port variants for deps

/Evening all,/ To pass along a variant for a dependency, without having to add in when you install. How do you do that? …or is there really no other way than adding it during “port install”. One /would/ like to do: ``` depends_lib.append port:first \ port:second

Re: Reopening a PR.

Sorry about the noise. Chris was /really/ fast and had already fixed it. Thanks! · Eric On 9/7/19 22:24 , Eric F (iEFdev) wrote: > > Hi all, > > Tried to open a PR on GitHub, but there's no option to do so. > > Searched around a bit, and one place said that when adding a new c

Reopening a PR.

Hi all, Tried to open a PR on GitHub, but there's no option to do so. Searched around a bit, and one place said that when adding a new commen - it would come up an option to also reopen it. But, it didn't. Any ideas? · Eric

Re: Testing an idea

On 2/10/19 14:05 , Mojca Miklavec wrote: > We do support fetching sources of various software from bitbucket and > gitlab (improved / simplified support underway; Chris mentioned > https://github.com/macports/macports-ports/pull/3510 for example), but > that's orthogonal to what you are asking.

Re: Testing an idea

On 2/10/19 11:23 , Chris Jones wrote: >> Speaking of that… Are there any plans to expand to GitLab? They have a great >> function to import/mirror from GitHub, which keep the repo updated. > What do you mean by expand to gitlab?. We have > > https://github.com/macports/macports-ports/pull/3510 >

Re: Testing an idea

Thanks Zero. On 2/10/19 2:39 , Zero King wrote: > I believe the maintainers field is used to contact the maintainer, > either via email or by mentioning (@) the user on GitHub. We can't > contact one with their GitLab or Bitbucket account in our PRs or Trac > tickets, so I think other Git

Testing an idea

Hi, I had this idea I want to test here. When creating a Portfile and adding: maintainers - only GitHub is recognized when adding a username like “@fooBar”. One *could* cheat and use: In Portfile: maintainers{GitHost:\ @fooBar} With "port info": Maintainers: Email: GitHost: @fooBar

Re: Q about a (new) portgroup file

On 1/27/19 19:39 , Rainer Müller wrote: > On 27.01.19 14:33, Eric F (iEFdev) wrote: >> Ok, here it is: https://github.com/macports/macports-ports/pull/3510 >> Hope that was ok. At least it passed the checks. :) > FYI, Travis CI will only test changed Portfiles, as you can s

Re: Q about a (new) portgroup file

On 1/27/19 14:21 , Christopher Jones wrote: > If you don’t think it is quite ready, but you want to start to get feedback, > then that is exactly with WIP PRs are for. Just remember to start the title > with ‘WIP” and also add the wip label to the PR. > > Chris Thanks! Ok, here it is:

Re: Q about a (new) portgroup file

Thanks Chris, On 1/27/19 12:41 , Christopher Jones wrote: >> So, I'd like to ask… Where to put it? > > The port group code lives in the same GitHub project as the ports. See > > https://github.com/macports/macports-ports/tree/b7dbaee30cd63f197eb8d1b0db9090a5a5c948f4/_resources/port1.0/group > >

Re: LaunchDaemon and startupitem

On 1/21/19 10:44 , Joshua Root wrote: >> startupitemsnamedbus-system \ >> locationLaunchDaemons \ >> uniquename ${daemon_uniquename} \ >> plist ${daemon_uniquename}.plist > Sure, that works. You don't have to

Re: LaunchDaemon and startupitem

Thanks Josh! That looks interesting. Yes, keep it as a file is prob the best, but if using puts, for the example. Something like this then (based on the dbus example)? set daemon_uniquenameorg.macports.${name} startupitem.typelaunchd startupitem.create no startupitemsname

Re: Help with a Portfile (part 2)

On 1/16/19 23:11 , Ryan Schmidt wrote: >> For the maintainer… The old 'libgeoip' was pixilla. I sent him an email >> asking if he wanted this one as well, but haven't heard anything. I guess >> nomaintainer is better, unless I should be in there. It's ok. > pixilla hasn't been seen in awhile.

Re: Help with a Portfile (part 2)

On 1/16/19 19:22 , Ryan Schmidt wrote: > On Jan 15, 2019, at 15:55, Eric F (iEFdev) wrote: >> It's a 2 part install. C lib (dependency) + a module. >> - https://github.com/maxmind/libmaxminddb/ > I tried to build this Portfile and found that in the libtap directory, t

Re: Help with a Portfile (part 2)

Thanks for the quick reply… On 1/16/19 0:35 , Ryan Schmidt wrote: > Sounds like apxs doesn't like the -arch flag, so don't pass that to it. Maybe > using "-Wl,-arch,x86_64" instead of "-arch x86_64" is what you need. Or maybe > you don't need an -arch flag at all. Been doing some trial'n'error

Help with a Portfile (part 2)

Thanks for all the help with last one.  Now I'm doing the other (last) one(s), and I'm not really sure how to do this. It's a 2 part install. C lib (dependency) + a module. - https://github.com/maxmind/libmaxminddb/ - https://github.com/maxmind/mod_maxminddb/ The C lib builds and

Re: Help with a Portfile

Thanks Ken… It was something like that I had in mind - putting curl/openssl in a separate folder. I'm all for #51516 // …and that is also how the FAQ describes it (FAQ#syslibs ) :) > Keep your wits about you when updating the bootstrap installation.

Re: Help with a Portfile

On 1/15/19 7:22 , Ryan Schmidt wrote: > On Jan 15, 2019, at 00:18, iEFdev wrote: >>> You cannot fetch from GitHub using the curl bundled with a macOS version >>> that old. >> Would it be possible to link around the problem in any way, if not just >> temporarily? Just replace curl with a newer