Re: how to handle this element in Makefile.config ?

On 2018-03-26 14:31, macpo...@parvis.nl wrote: > I'm working on a port for munin 2.0.x > > the munin-node component builds and installs java plugins if the Makefile can > find the javac compiler. > > on my system I need to have java but I want to ignore this feature. > > code is: > - > # Ja

Mirror size & completeness of binaries

On 2018-03-27 13:56, Mojca Miklavec wrote: > I don't know about the best way to do it, but I would like to suggest to > provide macports mirorring in two different sizes: a small one and a > complete one. > > While I'm a heavy supporter of providing support for legacy systems, I > see no reason to

Re: Mirror size & completeness of binaries

On 2018-03-29 16:19, Ryan Schmidt wrote: > At the same time, we need to consider how MacPorts base will respond to the > situation. Currently, it assumes all packages are available on all mirrors. > Therefore, it tries to find a package on three mirrors before giving up. If > many mirror operato

Re: Mirror size & completeness of binaries

On 2018-03-30 21:20, Ryan Schmidt wrote: > I have not yet heard any reason why we need to change the file structure of > the packages server. The start of the discussion was to have mirrors that only provide a subset of the packages, for example the latest release. It would be a lot easier to see

Re: Python ports: should we use wheel files?

On 2018-03-31 12:11, Enrico Maria Crisostomo wrote: > The definition of a wheel file is the following: > >> Wheel (in this context) is a project that adds the bdist_wheel command to >> distutils/setuptools. This produces a cross platform binary packaging format >> (called “wheels” or “wheel file

Re: [macports-ports] branch boost_update created (now b06095e)

Hello Mark, On 2016-12-27 20:15, Mark Evenson wrote: > Mark Evenson (easye) pushed a change to branch boost_update > in repository macports-ports. > > at b06095e boost: update to 1.63.0; remove $id$ line. > > This branch includes the following new commits: > > new b06095e boost: up

xcodebuild wants to write to $HOME/Library/Developer (was: Re: Editing Git history with GitUp)

On 2018-03-23 11:17, Mojca Miklavec wrote: > I just stumbled upon this app (I haven't tested it yet) which might be > able to avoid some pain when editing git history before pushing your > changes upstream: > http://gitup.co Thank you for the this tip. I especially like the visualization of br

Re: [macports-base] branch master updated: portbuild: Pass -j for parallel builds to cargo

On 2018-04-02 22:13, Jeremy Huddleston Sequoia wrote: > This causes cargo to fail to build with -j being unrecognized. > > --->  Building cargo > Executing:  cd > "/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_devel_cargo/cargo/work/cargo-0.25.0" > &&  > /opt/local/var/ma

Re: CI system for PR builds

On 2018-04-03 01:18, db wrote: > On 2 Apr 2018, at 23:09, Clemens Lang wrote: >> On Mon, Apr 02, 2018 at 08:43:52PM +0200, db wrote: >>> GitLab 10.6 released with CI/CD for GitHub >> Interesting, but I couldn't find any indication that this would support >> builds on macOS. Do you have more info?

Re: Trac upgraded to 1.2

On 2018-04-01 09:35, Ryan Schmidt wrote: > So far, I dislike the "cosmetic improvements for ticket changelog". > > https://trac.edgewall.org/ticket/11835 > > I'm pretty sure I don't like the property changes floated to the right, and I > don't like that the box they're in is yellow. I agree the

Re: CI system for PR builds

On 2018-04-03 12:31, db wrote: > On 3 Apr 2018, at 02:20, Rainer Müller wrote: >> Then please explain what this would offer us at all? > > I'll try. GitLab let's you have external runners > (https://docs.gitlab.com/ee/ci/runners/README.html), while TravisCI o

Re: CI system for PR builds

On 2018-04-03 13:37, Mojca Miklavec wrote: >> We can already trigger our Buildbot directly from GitHub and could spawn >> a VM from a snapshot using libvirt. > > My (potentially wrong) impression was that libvirt only works: > - from 10.11 on I think you are mixing things up here. libvirt offers a

Re: port policy questions for munin

On 2018-04-04 01:38, macpo...@parvis.nl wrote: > Questions about policy: > - how to submit Portfile (unified diff against the previous version?) If your new Portfile is significantly different from the previous version, a unified diff would not be helpful. Just attach the full Portfile in this cas

Re: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto

On 2018-04-04 16:36, Andrew Moore wrote: > If I’m reading correctly the attached report from build...@macports.org > , port net/mosquitto fails for OS X <= > 10.6 due to indirect dependency: libpsl.  If so, this is presumably a > known issue, since many ports depend up

Re: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto

On 2018-04-04 17:19, Rainer Müller wrote: > Now that we execute the mirror step before attempting a build, we should > make the buildbot use a master_site_local pointing to a local mirror, as > we cannot expect the upload to be completed at the time the build runs. > Right now we are

Re: port & root

On 2018-04-05 18:26, Bjarne D Mathiesen wrote: > When running './diffPorts php72-' as root I get this : Just to be specific, did you open a root shell first or did you run it with sudo? > Error: /macports/bin/port: Failed to initialize MacPorts, error deleting > "/macports/var/macports/home/Libra

Re: port & root

On 2018-04-05 19:14, Joshua Root wrote: > My guess is that this is a bug in Tcl's file command. Deleting a > nonexistent file is not supposed to be considered an error. But by > starting two instances of port(1) at the same time, a race condition > arises. The 'file delete' command probably checks

Re: py36 sub-ports fail to build

On 2018-04-05 19:05, Bjarne D Mathiesen wrote: > port -q search py36- \ > | xargs -n1 sudo port -Nup -f install Just a small hint here. The port command supports wildcards for port names. Just remember to escape for your shell: $ sudo port -Nup -f install 'py36-*' > diff <( port -q search py36-

Re: [macports-ports] branch master updated: librsvg: also use pre-cargo version for 10.8

On 2018-04-05 22:32, David B. Evans wrote: > +# cargo build also fails on 10.8 due to known SSL/TLS issues with > github.com +# Updating registry > `https://github.com/rust-lang/crates.io-index` +# Downloading > shell-escape v0.1.4 +# error: unable to get packages from source +# > Caused by:[35] SS

Re: [MacPorts] ProblemHotlist modified

On 2018-04-06 07:54, Ryan Schmidt wrote: > > On Apr 5, 2018, at 20:54, MacPorts Wiki wrote: > >> Page "ProblemHotlist" was changed by raimue >> Diff URL: >> >> Revision 138 >> Comment: No longer hot, have not even heard of t

Re: port & root

On 2018-04-05 19:39, Joshua Root wrote: > On 2018-4-6 03:25 , Rainer Müller wrote: >> On 2018-04-05 19:14, Joshua Root wrote: >>> My guess is that this is a bug in Tcl's file command. Deleting a >>> nonexistent file is not supposed to be considered an error. But

Re: [macports-ports] 01/04: aften: An A/52 audio encoder

On 2018-04-06 14:34, Michael Dickens wrote: > The issue being that if a port's configure checks for the build type (e.g., > {{{ > if(${CMAKE_BUILD_TYPE} STREQUAL "Release") then > ... > elseif > }}} > and so forth, and if "MacPorts" is not in BUILD_TYPEs list -- no matter > whether it has setting

CI system for PR builds

On 2018-04-07 07:40, Mojca Miklavec wrote: >>> - with a bit of legal questionability >> >> From my understanding, it is legal to virtualize macOS, as long as the >> hypervisor is running on a Mac as well, which is possible. > > I'm aware that it's legal to virtualize macOS on mac hardware, it's >

Re: CI system for PR builds

On 2018-04-07 19:44, Clemens Lang wrote: > For these resons, we want to reset the machines to a clean state before > every build, which we could do with buildbot, but requires some python > magic that hasn't been written yet. I think this is mostly written. What is needed is only a little bit of c

Re: CI system for PR builds

On 2018-04-08 12:06, Ryan Schmidt wrote: >> As the buildbot has no local packages installed, operations like >> checking for the existence of a package over HTTP and then fetching the >> file will be slow. I expect this to be one major bottleneck. Our usual >> portbuilders have all previously built

Re: [macports-ports] branch master updated: aacgain: Update dirname in post-extract phase

On 2018-04-08 12:56, Jackson Isaac wrote: > On Sun, Apr 8, 2018 at 3:33 PM, Jackson Isaac wrote: >> I did find one at "https://github.com/mecke/aacgain"; but I was not so >> sure if they both are by same author since 'alvarez' was mentioned at >> http://aacgain.altosdesign.com and on github it was

Re: Online MacPorts Meeting on 21st April at 13:00 UTC - suggestion

On 2018-04-07 14:18, William H. Magill wrote: > IRC is still quite popular in Europe, but is little used in the US. IRC on our #macports channel is fine to ask questions for which you do not want to write a lengthy email or to debug problems with quick back-and-forth on what to check or try. Howev

Re: [macports-base] branch master updated: Honour startupitem.install at activation time

On 2018-04-08 03:26, Joshua Root wrote: > Joshua Root (jmroot) pushed a commit to branch master > in repository macports-base. > > https://github.com/macports/macports-base/commit/3dde77d7d6c66dbb8fcc1d4b1b4972a2ac8b1947 > > The following commit(s) were added to refs/heads/master by this push: > ne

Re: [macports-base] branch master updated: Honour startupitem.install at activation time

On 2018-04-09 00:06, Joshua Root wrote: > On 2018-4-9 07:55 , Rainer Müller wrote: >> On 2018-04-08 03:26, Joshua Root wrote: >>> Joshua Root (jmroot) pushed a commit to branch master >>> in repository macports-base. >>> >>> htt

Re: [macports-base] branch master updated: Honour startupitem.install at activation time

On 2018-04-09 01:20, Joshua Root wrote: > On 2018-4-9 08:43 , Rainer Müller wrote: >> This handles ports that create .plist files via startupitem.* or the new >> startupitems. However, there are also ports that install custom .plist >> file to ${destroot}/Library/Launch*. So

Releasing 2.4.3

Hello, according to our milestone on Trac, there is nothing left to be fixed or backported to the release-2.4 branch for MacPorts 2.4.3. The ChangeLog was already updated and reflects the changes this release will contain: https://github.com/macports/macports-base/blob/release-2.4/ChangeLog See

Re: Releasing 2.4.3

On 2018-04-10 19:07, Ryan Schmidt wrote: > > On Apr 9, 2018, at 17:15, Rainer Müller wrote: > >> If nobody objects, I am going to tag a new release on Tuesday and >> prepare tarballs. > > Please merge my other two commits from this ticket: > > https://trac.

Re: Releasing 2.4.3

On 2018-04-10 19:39, Ryan Schmidt wrote: > > On Apr 10, 2018, at 12:07, Ryan Schmidt wrote: > >> On Apr 9, 2018, at 17:15, Rainer Müller wrote: >> >>> If nobody objects, I am going to tag a new release on Tuesday and >>> prepare tarballs. >> >>

Re: Releasing 2.4.3

On 2018-04-10 20:26, Ryan Schmidt wrote: > > On Apr 10, 2018, at 12:54, Rainer Müller wrote: >> >> At some point we should make a cut and not add many changes in the last >> minute... > > Well I can't force you to merge them. I cannot stop you either... I am

Re: Releasing 2.4.3

On 2018-04-10 21:06, Ryan Schmidt wrote: > I'm not going to merge them, because I don't know how, and don't have the > energy to attempt to learn how to do so, given the zillion other things I'm > trying to do right now. This is even documented: https://trac.macports.org/wiki/WorkingWithGit#cher

Re: Releasing 2.4.3

On 2018-04-10 19:39, Ryan Schmidt wrote: > Do you want to merge this performance enhancement too: [...] > And these bugfixes: I assigned this to the MacPorts 2.4.4 milestone, so we do not forget about them: https://trac.macports.org/ticket/56267 Rainer

Re: port version reports 2.4.2 when built from tag v2.4.3

On 2018-04-11 10:52, Enrico Maria Crisostomo wrote: > I've just created a new installation of macports-base from tag v2.4.3 > following the instructions in the documentation (basically git checkout > v2.4.3, ./configure ..., make and make install) and I've just noticed that > `port` reports 2.4.

Re: CI system for PR builds

On 2018-04-11 14:11, db wrote: > I won't address every single point and just say that it might be interpreted > as finger-pointing, but I'm actually curious about what's the state of the > project, how it got where it is, where is it going, should I build always > from source, should I use anoth

Re: CI system for PR builds

On 2018-04-11 16:43, Joshua Root wrote: > On 2018-4-12 00:37 , Mojca Miklavec wrote: >> We could move them to something like "changesneeded" (not sure where >> exactly; they could get a special status, even if closed, but it >> should be easy enough to find them should anyone have motivation to >>

Re: Builds with "fakeroot" (was Re: CI system for PR builds)

On 2018-04-11 18:55, Perry E. Metzger wrote: > Just a side note: other package building systems have dealt (in > various ways) with being able to build things without privileges. > > For example, the Debian project has a cool tool called "fakeroot" > which uses an LD_PRELOADed library to make thin

Re: Dealing with False Positive during Livecheck

On 2018-04-11 21:18, Jackson Isaac wrote: > One possible way as suggested on IRC is to add a comment in the Portfile > as to why it cannot and/or won't be updated further (in case of > inactive upstream) > and removing the livecheck regex. Be careful that removing the options does not mean disabli

Re: CI system for PR builds

On 2018-04-12 20:14, db wrote: > On 12 Apr 2018, at 18:52, Ryan Schmidt wrote: >> 1. MacPorts does not have a method of declaring that a port does not build >> on a version of macOS. Such a feature is being discussed: >> https://trac.macports.org/ticket/15712 >> In the absence of this feature, we

Re: port version reports 2.4.2 when built from tag v2.4.3

On 2018-04-13 00:42, Jack Howarth wrote: > This issue might also be impacting the High Sierra macports 2.4.3 > installer image as well. After installing it on a machine with no > /opt/local, I get the following from 'sudo port self update'... > > --->  Updating MacPorts base sources using rsync >

Re: New guide section on Git and GitHub

On 2018-04-13 15:31, Jonathan Stickel wrote: > As a long time contributor of patches using the ticket interface (Trac), > I think it would be a mistake to discourage submission of patches there. > While it is fine to encourage use of git pull requests, the barrier of > entry is much higher. In fact

Re: port version reports 2.4.2 when built from tag v2.4.3

On 2018-04-13 23:55, Joshua Root wrote: > On 2018-4-14 07:30 , Enrico Maria Crisostomo wrote: >> Hence, the macports installation that was built from the dirty tree is >> referring to the installation directory of the previous build. That also >> explains why removing that directory makes port c

Re: [macports-base] 03/03: fetch: Do not redirect stderr

On 2018-04-16 01:31, Ryan Schmidt wrote: > > On Apr 15, 2018, at 11:34, Rainer Müller wrote: > >> Rainer Müller (raimue) pushed a commit to branch vcs-fetch >> in repository macports-base. >> >> >> https://github.com/macports/macports-base/commit/6

Re: [macports-base] 01/06: fetch: Always use ${prefix}/bin/git for gitfetch

On 2018-04-16 22:29, Ryan Schmidt wrote: > > On Apr 14, 2018, at 22:09, Rainer Müller wrote: > >> Rainer Müller (raimue) pushed a commit to branch vcs-fetch >> in repository macports-base. >> >> >> https://github.com/macports/macports-base/commit/d

Re: Online MacPorts Meeting on 21st April at 13:00 UTC - suggestion

On 2018-04-13 13:34, Mojca Miklavec wrote: > If we find three volunteers (I volunteer, so only two more needed), we > could perhaps do a technology test run tomorrow at 13:00 UTC (that's > precisely 7 days earlier) > ... (or at any other potentially more suitable hour depending on who > wants to pa

Re: [macports-base] 01/06: fetch: Always use ${prefix}/bin/git for gitfetch

On 2018-04-18 05:37, Ryan Schmidt wrote: > > On Apr 17, 2018, at 07:33, Rainer Müller wrote: > >> On 2018-04-16 22:29, Ryan Schmidt wrote: >>> >>> On Apr 14, 2018, at 22:09, Rainer Müller wrote: >>> >>>> Rainer Müller (raimue) pushed a commi

Re: Buiid/install stages documentation?

On 2018-04-18 15:20, Perry E. Metzger wrote: > On Tue, 17 Apr 2018 22:33:10 -0500 Ryan Schmidt > wrote: >> On Apr 17, 2018, at 12:39, Perry E. Metzger wrote: >> >>> Just to be clear: I know what is in: >>> https://guide.macports.org/#reference.phases >>> >>> but I'm trying to figure out a bit more

Re: Online MacPorts Meeting on 21st April at 13:00 UTC - suggestion

On 2018-04-18 01:11, Rainer Müller wrote: > On 2018-04-13 13:34, Mojca Miklavec wrote: >> If we find three volunteers (I volunteer, so only two more needed), we >> could perhaps do a technology test run tomorrow at 13:00 UTC (that's >> precisely 7 days earlier) >>

Re: Can't use Expect in a portfile

On 2018-04-19 13:31, Ryan Schmidt wrote: > I can't seem to use Expect in a portfile. Using the following minimal > portfile: > > > PortSystem 1.0 > name foo > version 1 > fetch { > system "expect -c 'spawn echo hello; interact;'" > } > > > And running: > > > sudo port fetch > > > I get

Re: Can't use Expect in a portfile

On 2018-04-19 13:58, Ryan Schmidt wrote: > > On Apr 19, 2018, at 06:49, Rainer Müller wrote: > >> On 2018-04-19 13:31, Ryan Schmidt wrote: >>> I can't seem to use Expect in a portfile. [...] >>> >>> The system has no more ptys. Ask your sys

Re: Allow access to a file in trace mode

On 2018-04-19 12:44, Ryan Schmidt wrote: > If I try to build minivmac in trace mode (sudo port -t install minivmac) it > fails because: > > Warning: The following existing files were hidden from the build system by > trace mode: > /Applications/MacPorts/Mini vMac/vMac.ROM > > The minivmac bui

Re: Online MacPorts Meeting on 21st April at 13:00 UTC - suggestion

On 2018-04-19 11:24, Rainer Müller wrote: > On 2018-04-18 01:11, Rainer Müller wrote: >> On 2018-04-13 13:34, Mojca Miklavec wrote: >>> If we find three volunteers (I volunteer, so only two more needed), we >>> could perhaps do a technology test run tomorrow at 13:00

Releasing 2.4.4

Hello, as discussed in today's online meeting [1], there is nothing left to be fixed or backported to the release-2.4 branch for MacPorts 2.4.4. The ChangeLog shows the changes this release will contain: https://github.com/macports/macports-base/blob/release-2.4/ChangeLog See also the full detai

Re: Online MacPorts Meeting on 21st April at 13:00 UTC

On 2018-04-07 10:31, Mojca Miklavec wrote: > I would like to announce the first online MacPorts meeting happening > two weeks from now, on April 21st at 13:00 - 14:00 UTC (if it takes > much longer than one hour, we are probably doing something wrong). The minutes of the meeting can be found on th

Failure in port diagnose (was: Re: Releasing 2.4.4)

On 2018-04-21 23:23, Michael wrote: > I took a look at the change log, and saw there is a command, port diagnose This was first released with 2.4.0 last year, but no changes were made for 2.4.4. > bash-3.2# port -v diagnose > Error: process_cmd failed: dsAttrTypeNative:shell: /bin/bash > launchct

Re: Migrating the guide to AsciiDoc

On 2018-04-22 09:44, Andrew Moore wrote: > Just to be clear, asciidoc is the format, but asciidoctor is the text > processor (a superset of python asciidoc). Is that correct? Yes. AsciiDoc is both the name of the format and also the name of the original reference implementation in Python, but de

Re: Migrating the guide to AsciiDoc

On 2018-04-23 10:42, Jan Stary wrote: > Also, having manpages written in asciidoc means we need > the abominable docbook to actually produce the man(7) pages, right? > At least that's what it says at the end of install: > > * Warning: Using pre-generated man pages only. > * asciidoc, x

Re: Migrating the guide to AsciiDoc

On 2018-04-23 10:12, Jan Stary wrote: >>> We are already using the AsciiDoc format for our man pages, >> >> Manpages are supposed to be written in mdoc(7), the language of >> manpages, just like e.g. /usr/share/man/man1/ls.1 is. >> >> The current port-* manpages are horrible >> (not talking about c

Re: Migrating the guide to AsciiDoc

On 2018-04-23 14:27, Jan Stary wrote: >> These quirks are added by DocBook XSLT and are apparently required to >> make the output compatible. If you disagree with that, talk to DocBook >> why they added them. > > You don't care that a 2008 workaround to a Debian bug > is included in every manpage

Re: Migrating the guide to AsciiDoc

On 2018-04-22 09:29, Mojca Miklavec wrote: > Hi, > > As requested during yesterday's meeting, here's the result of > automatic conversion of our guide from xml (docbook) to asciidoc: > > https://github.com/macports/macports-guide/tree/master/guide/adoc > > This was initially explored by Alja

Re: [macports-ports] branch master updated: collectd: update to 5.8.0

On 2018-04-23 19:47, Perry E. Metzger wrote: > Perry E. Metzger (pmetzger) pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/5b70112c367fdc957b751f1ca6b8f1d1314f3b46 > > The following commit(s) were added to refs/heads/master by t

Installing nokogiri with --use-system-libraries (was: Re: Migrating the guide to AsciiDoc)

On 2018-04-23 20:35, Andrew Moore wrote: > You might try: > > $ sudo gem update —system > > which should install the latest version of bundler (you really want that), > and go from there. > In the particular case of nokogiri, you might also try running `gem install > nokogiri` as user root. I

Re: [macports-ports] branch master updated: collectd: update to 5.8.0

On 2018-04-24 00:48, Perry E. Metzger wrote: > On Mon, 23 Apr 2018 23:58:23 +0200 Rainer Müller > wrote: >> It is a bit suspicious that you made no changes to files/dep-gen.sh >> in the port directory. >> >> The second half of the Portfile is fully generated by tha

Re: Installing nokogiri with --use-system-libraries

On 2018-04-24 07:50, Mojca Miklavec wrote: > On 23 April 2018 at 17:42, Rainer Müller wrote: >> >> Ruby and gems are really strange... >> >> Apparently, installing nokogiri with bundle fails > > Wasn't it you who said that we don't need a port

Re: Migrating the guide to AsciiDoc

On 2018-04-22 09:29, Mojca Miklavec wrote: > As requested during yesterday's meeting, here's the result of > automatic conversion of our guide from xml (docbook) to asciidoc: > > https://github.com/macports/macports-guide/tree/master/guide/adoc > > This was initially explored by Aljaž and giv

Re: What "openmaintainer" means

On 2018-04-25 17:10, Joshua Root wrote: > On 2018-4-26 00:25 , Perry E. Metzger wrote: >> On Wed, 25 Apr 2018 04:43:12 +1000 Joshua Root >> wrote: >>> On 2018-4-25 03:56 , Ken Cunningham wrote: Waiting for the maintainer to review the ticket submission someday often resulted in months of

Re: Agility

On 2018-04-25 21:02, Perry E. Metzger wrote: > On Thu, 26 Apr 2018 01:19:59 +1000 Joshua Root > wrote: >> On 2018-4-26 00:44 , Perry E. Metzger wrote: >>> I tend to think it's a better way of working but it's up to the >>> community as a whole to say if it's really the right way to do >>> things.

Re: Binary packages not rebuilding against updated libraries

On 2018-04-26 00:11, Jan Stary wrote: > On Apr 24 09:31:04, ken.cunningham.web...@gmail.com wrote: >> Portfile authors need to manually "revbump" >> the library's dependent ports when >> supporting libraries change significantly. >> It's not automatically figured out by MacPorts. > > Wait, what? I

Re: Binary packages not rebuilding against updated libraries

On 2018-04-26 08:03, Jan Stary wrote: >> >> For comparison, the OpenBSD port system has resigned on upstreams' >> library versioning, and versions the libraries itself. For example, >> in audio/libsndfile (1.0.28): >> >> SHARED_LIBS += sndfile 6.0 # .1.28 >> >> and it installs /usr/local/

Re: Binary packages not rebuilding against updated libraries

On 2018-04-26 07:48, Jan Stary wrote: > On Apr 26 03:16:37, rai...@macports.org wrote: >> On 2018-04-26 00:11, Jan Stary wrote: >>> On Apr 24 09:31:04, ken.cunningham.web...@gmail.com wrote: Portfile authors need to manually "revbump" the library's dependent ports when supporting lib

Re: Binary packages not rebuilding against updated libraries

On 2018-04-26 15:36, Perry E. Metzger wrote: > Not sure. I did come up with a better solution for the ABI bump > problem, though, and wanted to run it by you. > > So rather than just guessing based on things like major version of a > library whether dependents need to be bumped, I would suggest we

Re: Binary packages not rebuilding against updated libraries

On 2018-04-26 18:55, Perry E. Metzger wrote: > On Fri, 27 Apr 2018 02:46:43 +1000 Joshua Root > wrote: >>> So what might work would be trying out installing the archives in >>> a sandbox and using the same mechanism that's used locally before >>> triggering a rebuild? >> >> Sounds like a plan? >

Re: How do I check what is autobuilding successfully?

On 2018-04-26 22:31, Clemens Lang wrote: > | Error: Checksum (rmd160) mismatch for coffee-script-1.3.3.tar.gz > | Portfile checksum: coffee-script-1.3.3.tar.gz rmd160 > 22cf20180c06c92f5fdc223180ba94bb96b6ff7b > | Distfile checksum: coffee-script-1.3.3.tar.gz rmd160 > e069ff420bc2584015f4a412d559

Re: How do I check what is autobuilding successfully?

On 2018-04-26 22:48, Rainer Müller wrote: > On 2018-04-26 22:31, Clemens Lang wrote: >> | Error: Checksum (rmd160) mismatch for coffee-script-1.3.3.tar.gz >> | Portfile checksum: coffee-script-1.3.3.tar.gz rmd160 >> 22cf20180c06c92f5fdc223180ba94bb96b6ff7b >> | Distf

Re: guide bug?

On 2018-04-27 03:23, Perry E. Metzger wrote: > In one part of the guide, we say not to use "file copy" but to use > "copy" instead, Are you sure you read that in the guide? > but in 4.3.2. we show an example using "file copy" > rather than "copy". Is this a bug? "file copy|move|delete" are native

Re: guide bug?

On 2018-04-27 14:37, Perry E. Metzger wrote: > "For the above operations provided by Tcl's file command, MacPorts > provides the following shorthands. These should be used in preference > to the Tcl commands above, as they may work around certain bugs." Ah, I even linked to this section, but did n

Re: guide bug?

On 27 April 2018 23:12:31 GMT+02:00, Ryan Schmidt wrote: > >On Apr 27, 2018, at 16:11, Joshua Root wrote: > >> On 2018-4-28 06:25 , Ryan Schmidt wrote: >> >>> On Apr 27, 2018, at 08:10, Joshua Root wrote: >>> >>> 'move' still handles some case-sensitivity issues, but indeed >'copy' and >>

Re: [macports-ports] 17/17: fd: use new features of cargo PG

On 2018-04-28 00:34, Marcus Calhoun-Lopez wrote: > Marcus Calhoun-Lopez (MarcusCalhoun-Lopez) pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/24864aeda99bedbc183f882878df70e8b555aa0b > > commit 24864aeda99bedbc183f882878df70e8b5

Re: [macports-ports] 09/17: cargo PG: respect build_arch; allow universal build

On 2018-04-28 00:34, Marcus Calhoun-Lopez wrote: > Marcus Calhoun-Lopez (MarcusCalhoun-Lopez) pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/68a34f577814e3e5b3f444530262b109093da515 > > commit 68a34f577814e3e5b3f444530262b10909

Re: Open Letter of Apology

Hello Marcus, On 2018-04-28 01:33, Marcus Calhoun-Lopez wrote: > Recently, I made some major changes to the cargo PortGroup and the Portfiles > of several people. > My intent was: > *) create a branch > *) solicit feedback on the branch with the changes > > Instead, I pushed the chan

Re: [MacPorts] Tickets modified

On 2018-04-30 16:14, MacPorts Wiki wrote: > Page "Tickets" was changed by pmetzger > Diff URL: > Revision 43 > Comment: Correct report number. > Changes: > ---8<--8<--8<--8<--8<--8<--8<--8< > Ind

Re: Why didn't this PR get labeled?

On 2018-04-30 15:49, Perry E. Metzger wrote: > Sometimes, I've noticed, PRs in the queue don't get automatically > labeled as expected. See this one, for example: > > https://github.com/macports/macports-ports/pull/1687 > > Anyone know why? The log file on braeburn says (times in UTC): Apr 28 1

Re: build failures and lack of logs

On 2018-04-29 14:31, Joshua Root wrote: > On 2018-4-29 22:04 , Jack Howarth wrote: >> As far as I can see, the links for the main.log file on these mailed >> build failure reports is a dead or empty file. > I see what you mean now. I'm not sure why we have a separate main.log > link when all the sa

Re: Request for discussion: lowering the backlog of old Trac tickets.

On 2018-04-30 18:16, Perry E. Metzger wrote: > But, more generally: because if you make your tracking system into a > graveyard of dead requests that will never be acted on, you end up > with it being very difficult for someone to look through it and find > things that actively need fixing. > > Th

Re: Request for discussion: lowering the backlog of old Trac tickets.

On 2018-04-30 21:09, Chris Jones wrote: > I would also argue we are using the same system, for two different things. > Short term bug reports and longer term 'work goals' are not the same, but we > seem to mix them up in the same system. Maybe some way (label ?) to identify > tickets that are go

Re: [macports-ports] 01/17: cargo PG: modify comments

On 2018-04-30 05:26, Ryan Schmidt wrote: > > On Apr 28, 2018, at 04:31, Joshua Root wrote: > >> On 2018-4-28 13:04 , Ryan Schmidt wrote: >>> According to WikiPedia, "All rights reserved" has no effect in any legal >>> jurisdiction: >>> >>> https://en.wikipedia.org/wiki/All_rights_reserved >>> >>

Re: Why didn't this PR get labeled?

On 2018-05-01 03:45, Helmut K. C. Tessarek wrote: > > > On 2018-04-30 09:49, Perry E. Metzger wrote: >> Sometimes, I've noticed, PRs in the queue don't get automatically >> labeled as expected. See this one, for example: >> >> https://github.com/macports/macports-ports/pull/1687 >> >> Anyone know

Re: trac rrdtool

On 2018-05-01 15:20, macpo...@parvis.nl wrote: > searching for open tickets on rrdtool, I don't understand some things. [...] > What is happening here? Did these people perhaps made a patch on basis > of a rrdtool patch and didn't change the filename? The guide uses "Portfile-rrdtool.diff" as an

Re: Why didn't this PR get labeled?

On 2018-05-01 16:28, Perry E. Metzger wrote: > On Tue, 1 May 2018 13:20:45 + Zero King wrote: >> As Rainer replied, GitHub didn't provide the needed information in >> time. Maybe we should wait 30 seconds and retry? > > That seems like a very good idea. I'd probably wait two minutes, > though

Re: [macports-ports] 01/17: cargo PG: modify comments

On 2018-05-01 03:16, Rainer Müller wrote: > However, why do we add a license header to the port groups at all? > We also do not add it to each Portfile. I think we should drop the > license headers from all port groups. https://github.com/macports/macports-ports/pull/1707 Rainer

Re: missing dejavusansmono in rrdtool pango cairo fontconfig

On 2018-05-02 12:44, macpo...@parvis.nl wrote: Macports installs fonts in /opt/local/share/fonts. This directory is seen only by fontconfig (defined in /opt/local/etc/fonts/fonts.conf). Most software uses cairo for advanced font handling and pango for the heavy-lifting in cairo. This is calle

Re: missing dejavusansmono in rrdtool pango cairo fontconfig

On 2018-05-02 22:17, macpo...@parvis.nl wrote: > >> On 2018-05-02, at 16:15, Rainer Müller wrote: >> >> On 2018-05-02 12:44, macpo...@parvis.nl wrote: >>> (...) >>> Pango has a simple tool to show font examples: >>> pango-view --backend= --tex

Re: Help with Pull Request

On 2018-05-03 12:14, Marcus Calhoun-Lopez wrote: > The only git commands I have been running (not in this order) are > git pull --rebase upstream master > git pull --rebase origin cargo-pg > git pull --rebase origin master > git push origin cargo-pg > where > cargo-pg is the nam

Re: Instructions for creating patches

On 2018-05-03 09:14, Zero King wrote: > On Thu, May 03, 2018 at 08:51:49AM +0200, Mojca Miklavec wrote: >> On 1 May 2018 at 16:11, Rainer Müller wrote: >>> >>> The guide uses "Portfile-rrdtool.diff" as an example filename [1]. Some >>> users seem to ta

Re: Releasing 2.4.4

On 2018-04-29 10:17, Mojca Miklavec wrote: > Are there any news or progress about the 2.4.4 release? It has been two weeks. How do we want to proceed? Rainer

Re: Compiler blacklist 'shorthand'

On 2018-05-06 12:07, Ryan Schmidt wrote: > > On May 5, 2018, at 19:36, Craig Treleaven wrote: > >> A couple of times recently, I’ve noticed boilerplate in ports that require >> C++14. After including the compiler_blacklist_versions portgroup, they then >> do some gymnastics like: >> >> compile

New project member: vishnu

Please join us in welcoming the following new MacPorts project member: - Vishnu M (vishnu, @Vishnum98) We look forward to continued excellent contributions during Google Summer of Code 2018 and beyond. - Joshua, Ryan, and Rainer Do you want to join the MacPorts team? If you would like to be c

  1   2   3   4   5   6   >