how about a 'snowleopardfixes' library port?

[Ken Cunningham]

Snow Leopard has two missing but fairly commonly used functions, getline and 
strnlen.  These two functions are responsible for a number of snow leopard 
build failures.

It seemed that reinventing the wheel over and over for a getline replacement 
was getting rather tedious, port after port. I built a static library with a 
getline replacement in it, called it 'libsnowleopardfixes.a', put it in 
/opt/local/lib, and added it to the linked libraries on lnav. 

Then, it required only a single line of code to be added to the file where it 
fails (in this case, common_executor.cc); because lnav is c++ code, it required 
this version:

"extern "C" ssize_t getline(char **lineptr, size_t *n, FILE *stream);"

and to have the library added to the ldflags, and the port built and ran 
without trouble. 

Perhaps there is somewhere more elegant I could have put the definition, but it 
seemed to be required only in this one file.

This seems to be a contender for a fairly easy way to solve a lot of troubles 
with these missing snowleopard functions...

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [151794] trunk/dports/graphics/fntsample

[Mojca Miklavec]

On 22 August 2016 at 20:15, Ryan Schmidt wrote:
>
>> +@@ -944,7 +944,7 @@ int main(int argc, char **argv)
>> + exit(1);
>> + }
>> +
>> +-cairo_set_source_rgb(cr, 0.0, 0.0, 0.0);
>> ++cairo_set_source_rgb(cr, 0.0, 0.0, 0.0);
>> + draw_glyphs(cr, cr_font, face, fontname, other_face);
>> + cairo_destroy(cr);
>> + return 0;
>
> The second hunk of the patch appears to be a no-op.

Thank you. I have no clue how I ended up with this.

(I was just systematically going through "uncommitted patches" in the
tree like you suggested and don't remember how I ended up a change
that doesn't do anything.)

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [151794] trunk/dports/graphics/fntsample

[Ryan Schmidt]

> On Aug 22, 2016, at 5:50 AM, mo...@macports.org wrote:
> 
> Revision
> 151794
> Author
> mo...@macports.org
> Date
> 2016-08-22 03:50:00 -0700 (Mon, 22 Aug 2016)
> Log Message
> 
> fntsample: add a new variant +brightcolors and a patch to fix colors
> Modified Paths
> 
>   • trunk/dports/graphics/fntsample/Portfile
> Added Paths
> 
>   • trunk/dports/graphics/fntsample/files/
>   • trunk/dports/graphics/fntsample/files/patch-color.diff
> Diff
> 
> Modified: trunk/dports/graphics/fntsample/Portfile (151793 => 151794)
> 
> --- trunk/dports/graphics/fntsample/Portfile  2016-08-22 10:25:22 UTC (rev 
> 151793)
> +++ trunk/dports/graphics/fntsample/Portfile  2016-08-22 10:50:00 UTC (rev 
> 151794)
> 
> @@ -45,3 +45,9 @@
> 
>  post-patch {
> 
>  reinplace -W ${worksrcpath} "s|^#! /usr/bin/perl|#! 
> ${prefix}/bin/perl${perl5.major}|g" pdfoutline.pl
> 
>  }
> 
> +
> +# this patch is only available in MacPorts; not sure what exactly to ask 
> upstream
> +# the original colors are "useless" for print
> +variant brightcolors description {Use brighter colors in tables (consume 
> less ink)} {
> +patchfiles  patch-color.diff
> +}
> 
> Added: trunk/dports/graphics/fntsample/files/patch-color.diff (0 => 151794)
> 
> --- trunk/dports/graphics/fntsample/files/patch-color.diff
> (rev 0)
> +++ trunk/dports/graphics/fntsample/files/patch-color.diff2016-08-22 
> 10:50:00 UTC (rev 151794)
> 
> @@ -0,0 +1,25 @@
> 
> +--- fntsample.c.orig
>  fntsample.c
> +@@ -537,9 +537,11 @@ static void fill_empty_cell(cairo_t *cr, double x, 
> double y, unsigned long charc
> + cairo_save(cr);
> + if (g_unichar_isdefined(charcode)) {
> + if (g_unichar_iscntrl(charcode))
> +-cairo_set_source_rgb(cr, 0.0, 0.0, 0.5);
> ++cairo_set_source_rgb(cr, 0.85, 0.85, 1.0);
> + else
> +-cairo_set_source_rgb(cr, 0.5, 0.5, 0.5);
> ++cairo_set_source_rgb(cr, 0.9, 0.9, 0.9);
> ++} else {
> ++cairo_set_source_rgb(cr, 0.5, 0.5, 0.5);
> + }
> + cairo_rectangle(cr, x, y, cell_width, cell_height);
> + cairo_fill(cr);
> +@@ -944,7 +944,7 @@ int main(int argc, char **argv)
> + exit(1);
> + }
> + 
> +-cairo_set_source_rgb(cr, 0.0, 0.0, 0.0);
> ++cairo_set_source_rgb(cr, 0.0, 0.0, 0.0);
> + draw_glyphs(cr, cr_font, face, fontname, other_face);
> + cairo_destroy(cr);
> + return 0;

The second hunk of the patch appears to be a no-op.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port install v port mpkg | mdmg

[Ryan Schmidt]

On Aug 12, 2016, at 5:30 AM, Rainer Müller wrote:
> 
>> My mythtv-pkg.27 is intended to be used to create an all-in-one
>> installer package for MythTV.  I have a VM with a custom prefix for
>> this.  The resulting mpkg needs daemondo, so I created the nasty hack
>> in MacPorts_daemondo.  However, mythtv-pkg.27 could be a nice
>> shortcut for a MacPorts user that wants to install a complete MythTV
>> system in one go.  In such case, they don’t need MacPorts_daemondo.
> 
> One solution for this could be in base to automatically include daemondo
> in the mpkg when it is used by the port being packaged.

That would be acceptable.


> See portmpkg::make_dependency_list in src/package1.0/portmpkg.tcl [1]
> where the list of dependencies is generated. If the port to be packaged
> has a startupitem, additionally include MacPorts_daemondo in the result
> list.
> 
> Of course MacPorts_daemondo itself would still be a hack and require
> force activation...

No, I would not have MacPorts add a dependency on the port MacPorts_daemondo. 
The MacPorts_daemondo port should not exist. If a user installs it, they will 
get a message that it cannot be activated, except by being forced. If the user 
forces the activation, it will replace a part of MacPorts base. If they 
uninstall the port, that part of MacPorts base will be removed. We do not want 
to give users the opportunity to get themselves into this situation.

Craig, until base is fixed to automatically include daemondo in pkgs when 
needed, can't you just add a post-pkg block that copies daemondo from the 
location where it was installed by MacPorts base, without needing a separate 
MacPorts_daemondo port?


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] WorkingWithGit modified

[MacPorts]

Hi Clemens,

On 21.08.2016 17:28, Clemens Lang wrote:

Thanks for the section on setting up commiter name and email address, I
had forgot about this.


you are welcome. I saw the page and that was the first thing hitting my 
eye,

which is why I started to give that wiki page some polish. :-)


+Additionally one should define a few (not necessarily global) presets 
for working with your clone of the MacPorts repository:

+{{{
+$ git config --global push.default nothing
+$ git config --global branch.autosetuprebase always
+$ git config --global core.excludesfile ~/.gitignore_global
+$ git config --global commit.template ~/.git-commit-template
+}}}


Well, I chose to suggest these, as they were recommended by the KDE 
community.




I do not think we should recommend setting these variables for the
following reasons:


Let's see...



 - Users don't understand they're doing here. I want our developers
   to know what and why things are happening with Git, not serve them a
   "here's how you ought to do it" recipe.


So, than we need to explain what these settings do. I am strongly 
opposing the
concept of giving just orders to our port maintainers without educating 
them about
why things were set up the way they are. These settings make sense 
because they
prevent bad things which can happen easily with git. I always favour(ed) 
Mercurial
over it, but it was decided against... so we need to make sure that the 
basic settings

are chosen such that they prevent evil.


 - This is also the reason why the "Fetching the latest changes" 
section

   I wrote yesterday is so long: Developers should understand what
   happens when they run these commands, not just be told "run this". I
   think we should move branch.autosetuprebase to the end of the
   "Fetching the latest changes" section where we tell them that 
instead

   of the --rebase flag, they can also set this option. Also, setting
   this option globally is bad; other projects might not want this
   behavior.


As I wrote above that section I am aware of that those settings might 
not be
wanted as global ones, but I actually have them set as global in most of 
my

setups, to tell you the truth.


 - push.default nothing may be a good idea, but I would only put it as 
a

   recommendation in a section on committing and pushing changes for
   people that want to make sure they're not accidentially pushing
   something they don't want to push.


I think it is a good thing, as it always forces the maintainers to think 
about
which branch they really want to target. That's an extra level of 
precaution.




 - I do not think we need .gitignore_global; We already converted our
   svn:excludes into .gitignores in the repositories and we've always
   left the configuration of svn clients to our developers. If they
   think this is necessary, they can figure it out on their own.


OK, fine with me.


 - I also do not think we should recommend a git commit template for 
the

   same reason. Developers with Subversion have always been free to
   configure their own client and while a commit template is possible
   with Subversion, we did not recommend it there either.


Well, a commit template I definitely favour, because quite some times 
you
do find commits to the MacPorts repo which do not adhere to the 
standards
defined on our Wiki or in the Guide. A template would guide the 
committers
to not to forget some rules of the game. But, if you don't want to annoy 
our

committers with too many rules then so be it. :)

Greets,
Marko

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #52068: darkice needs pkgconfig dependency

[Rainer Müller]

On 2016-08-22 12:39, Niels Dettenbach wrote:
> Hmmm,
> i'm just wondering how the port worked up to 1.2 - there was no significant 
> changes within darkice sources done as far as i know from Rafael Diniz 
> (darkice maintainer) and i see no differences in the configure flag sheme too.

If you had the pkgconfig port installed, it just worked because it was
already available. That is very likely as pkgconfig is a build
dependency for many other ports.

> Do i have to correct here something further? In that case i have to dig in 
> deeper asap (i.e. next weekend) into macports again.
> 
> depends_build-append port:pkgconfig

That would be correct.

> Could i add this in general anywhere or should place this under any of the 
> variant sections? In practice, any mac osx user would at least need jack - 
> and 
> i don't know if further of the encoders need pkg-config too.

According to the configure script, the detection for all of them uses
pkg-config. Makes sense to add it as a general dependency.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #52068: darkice needs pkgconfig dependency

[Niels Dettenbach]

Am Samstag, 20. August 2016, 12:13:32 schrieb MacPorts:
>  Alternatively, you may set the environment variables JACK_CFLAGS
>  and JACK_LIBS to avoid the need to call pkg-config.
>  See the pkg-config man page for more details.
> 
>  To get pkg-config, see .
>  See `config.log' for more details
>  }}}
> 
>  Evidently, darkice needs pkgconfig to find jack, so a build dependency on
>  port:pkgconfig should be added to the port somewhere. But where?
> 
>  If only the jack variant needs pkgconfig, then put the dependency in the
>  jack variant.
> 
>  It looks lame was detected without pkgconfig. What about the other
>  variants, which are not default variants? If some of them require
>  pkgconfig, then the pkgconfig dependency should be made in a conditional
>  outside of a variant directive (to avoid each variant declaring the same
>  dependency). For example, if only jack and faac need pkgconfig, you could
>  do:
> 
>  {{{
>  if {[variant_isset faac] || [variant_isset jack]} {
>  depends_build-append port:pkgconfig
>  }
>  }}}

Hmmm,
i'm just wondering how the port worked up to 1.2 - there was no significant 
changes within darkice sources done as far as i know from Rafael Diniz 
(darkice maintainer) and i see no differences in the configure flag sheme too.

Do i have to correct here something further? In that case i have to dig in 
deeper asap (i.e. next weekend) into macports again.

depends_build-append port:pkgconfig

Could i add this in general anywhere or should place this under any of the 
variant sections? In practice, any mac osx user would at least need jack - and 
i don't know if further of the encoders need pkg-config too.

Just to explain a bit:

 - darkice needs one audio i/o framework to work (currently the only available 
under MacOS seems jack - coreaudio is not provided yet)

 - beside this, darklice need at least (!) one of the encoder framworks - but 
could be compiled with any other combination (or even all enc libraries)  as 
well. There is no further dependency between them.

The most "typical" (entry) setup of darkice is jack + lame (mp3) - as defined 
in the default_variants


many thanks.
best regards,


Niels.


-- 
 ---
 Niels Dettenbach
 Syndicat IT & Internet
 http://www.syndicat.com
 PGP: https://syndicat.com/pub_key.asc
 ---
 





signature.asc
Description: This is a digitally signed message part.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to use git

[Dr M J Carter]

On Sun, Aug 21, 2016 at 01:44:55PM +1000, Ian Wadham wrote:

> If you are going to fix a bug, you need to retrieve the new branch
> from central and make the same fix in two branches.  I can never
> remember exactly how to do that… ;-)

Commit the fix in one branch, and cherry-pick that commit into the
other  ?  That way, git knows not to reapply the commit if/when
said branches are merged later.

-- 
Dr Martin J Carter
Computer System Administrator
Astrophysics, University of Oxford
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to use git

[David Bariod]

On Mon, Aug 22, 2016 at 10:57 AM, Mojca Miklavec  wrote:

> On 20 August 2016 at 02:19, Ryan Schmidt wrote:
> >
> > https://trac.macports.org/wiki/WorkingWithGit
>
> We should add this:
> http://stackoverflow.com/questions/927358/how-to-undo-
> last-commits-in-git#927386
> to:
> https://trac.macports.org/wiki/WorkingWithGit#revert
>
> Currently the third paragraph sounds scary and it doesn't have to be.
>
> I use "git reset HEAD~" all the time to fix commit messages or to fix
> whatever I screwed up in the last commit.
>

Don't you find git commit --amend easier for such purpose ?

--
David
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to use git

[Mojca Miklavec]

On 20 August 2016 at 02:19, Ryan Schmidt wrote:
>
> https://trac.macports.org/wiki/WorkingWithGit

We should add this:

http://stackoverflow.com/questions/927358/how-to-undo-last-commits-in-git#927386
to:
https://trac.macports.org/wiki/WorkingWithGit#revert

Currently the third paragraph sounds scary and it doesn't have to be.

I use "git reset HEAD~" all the time to fix commit messages or to fix
whatever I screwed up in the last commit.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to use git

[Mojca Miklavec]

On 21 August 2016 at 22:47, Fred Wright wrote:
> On Sat, 20 Aug 2016, Brandon Allbery wrote:
>> On Sat, Aug 20, 2016 at 11:44 PM, Ian Wadham wrote:
>>
>> > Fork the repo??
>>
>> github expects you to do this, yes. I don't actually recommend it because
>> keeping up to date with the original repo's a PITA (and *not* automated in
>> any way. https://help.github.com/articles/syncing-a-fork/ is annoyingly
>
> Umm, the whole merging aspect is something you need to do regardless of
> whether you're pulling from "origin" or "upstream", so this isn't a good
> argument against using a fork.  It gets more complicated with multiple
> branches, but again the merging part is the same whether you're using a
> fork or not, and the only difference is whether you also need to push the
> merged branches to the fork.
>
> Meanwhile, the whole pull request mechanism is designed around the forked
> repo model, so anyone without direct commit access should be strongly
> encouraged to use a fork.  And even for someone *with* direct commit
> access, a fork provides a backed-up sandbox for changes that aren't ready
> for the main repo (even in a branch).
>
> There's a slight difference in whether you need to specify "upstream" in
> the "fetch" or "pull" (since you don't normally want to make "upstream"
> the default remote), but that's pretty minor.

I agree. Sure, updating your fork is not automated in any way, but not
forking the repository doesn't make it any easier to deal with
updates.

You may do the following:
- fork the original repository
- git clone https://github.com/your-username/macports-ports.git
- cd macports-ports
- git remote add mp https://github.com/macports/macports-ports.git

and then whenever you want to change something you do

- git fetch --all
- git pull mp master
[- git push origin master (or whatever you call your own fork)]

You only have to do that last step when you have something worth
uploading, but the updates will go there automatically. Even if your
fork is not kept up to date, the changes you made in one particular
branch can still be fetched by interested users.

(It actually doesn't matter if you clone from macports first and then
add your own fork with "git remote add myowncopy
https://github.com/your-username/macports-ports.git;. It's just a
matter of which one will be called "origin" by default. You can rename
it later anyway.)

When submitting pull request one can create a new branch, make a pull
request, then delete that branch (or delete the fork for that matter).

>> manual). You lose the ability to maintain your clone with github's web
>> interface, but that's not much of a loss really. (Or you can do their thing
>> in reverse: clone the repo, add github as an additional upstream, create a
>> new empty repo (not a fork) via their web interface, push to github
>> periodically as a backup.)

Sure, but you end up with exactly the situation described above.
In what way is creating an empty repository easier than forking one?

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev