On 2010-10-25 20:36 , Jeremy Lavergne wrote:
> Is Google able to search our man pages (are they online)?
No, they are not. More than a year ago I started the new-help-system
branch, which is intended to rewrite our man pages in asciidoc. This
would make it possible to generate HTML pages as well a
On Mon, Oct 25, 2010 at 04:31, Anders F Björklund wrote:
>
> I think the main objection to sha256 checksums was
> that they were "too long", even though one sha256
> is shorter than two as in both of sha1 and rmd160...
Has this really come up as an issue?
--
arno s hautala /-| a...@alum.
On Oct 25, 2010, at 14:43, jerem...@macports.org wrote:
> Revision: 72747
> http://trac.macports.org/changeset/72747
> Author: jerem...@macports.org
> Date: 2010-10-25 12:43:13 -0700 (Mon, 25 Oct 2010)
> Log Message:
> ---
> xorg-libXaw: Bump to 1.0.8
> +patchfiles 0001-Mov
PyKDE4 isn't built presently, so I was going to skip going back through and
making it work in order to roll out KDE 4.5.2 faster.
This will in some way impact:
• printer-applet
• system-config-printer-kde
• Guidance Power Manager, a battery applet
• Ubiquity, insta
On Oct 25, 2010, at 12:22, and.dam...@macports.org wrote:
> Revision: 72742
> http://trac.macports.org/changeset/72742
> Author: and.dam...@macports.org
> Date: 2010-10-25 10:22:30 -0700 (Mon, 25 Oct 2010)
> Log Message:
> ---
> adding missing dependencies as per #26995
>
On 2010-10-25 18:37 , Ryan Schmidt wrote:
> On Oct 25, 2010, at 02:15, Titus von Boxberg wrote:
>> Are md5 checksums deprecated?
>
> They are to me, though we haven't made an official statement about that.
Should probably have a lint warning when using md5 alone, but removing
it when it's being u
On 10/25/10 12:33 , Ryan Schmidt wrote:
On Oct 25, 2010, at 11:45, Jonathan Stickel wrote:
Thanks! This was not obvious to me. Would it be worthwhile to put
this in the Macports Development Wiki, maybe under Committers Tips
and Tricks?
It is already in the manpage: "man port"
OPTIONS
[
On 2010-10-26 05:34 , Daniel J. Luke wrote:
> On Oct 25, 2010, at 2:32 PM, Ryan Schmidt wrote:
>>
>> But what I'm saying is that the dbus port (and probably all other ports that
>> manually install plists instead of using the MacPorts facilities for that)
>> are installing the plist even if start
> It is already in the manpage: "man port"
>
>
>
> OPTIONS
>
> [snip]
>
> -o honor state files older than Portfile
>
>
>
> Though perhaps that's not worded as clearly as it could be, or it doesn't
> explain what that really means to the user.
Is Google able to search our man pag
> But what I'm saying is that the dbus port (and probably all other ports that
> manually install plists instead of using the MacPorts facilities for that)
> are installing the plist even if startupitem_type is none. And these ports
> should be changed to not do that anymore.
ok
>> Now that we
On Oct 25, 2010, at 2:32 PM, Ryan Schmidt wrote:
>
> But what I'm saying is that the dbus port (and probably all other ports that
> manually install plists instead of using the MacPorts facilities for that)
> are installing the plist even if startupitem_type is none. And these ports
> should be
On Oct 25, 2010, at 13:28, Bradley Giesbrecht wrote:
>
> On Oct 25, 2010, at 11:18 AM, Marko Käning wrote:
>
>>> I see in my conf now that it is set to default, which is why it probably
>>> got installed together with dbus…
>>
>> Now that we are at it, is it perhaps better to set this to NONE
On Oct 25, 2010, at 11:45, Jonathan Stickel wrote:
> Thanks! This was not obvious to me. Would it be worthwhile to put this in
> the Macports Development Wiki, maybe under Committers Tips and Tricks?
It is already in the manpage: "man port"
OPTIONS
[snip]
-o honor state files
On Oct 25, 2010, at 11:18 AM, Marko Käning wrote:
I see in my conf now that it is set to default, which is why it
probably got installed together with dbus…
Now that we are at it, is it perhaps better to set this to NONE???
Reading macports.conf makes me thing NONE would mean NO startup_it
On Oct 25, 2010, at 13:18, Marko Käning wrote:
>> I see in my conf now that it is set to default, which is why it probably got
>> installed together with dbus…
But what I'm saying is that the dbus port (and probably all other ports that
manually install plists instead of using the MacPorts fac
> I see in my conf now that it is set to default, which is why it probably got
> installed together with dbus…
Now that we are at it, is it perhaps better to set this to NONE???
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lis
> See macports.conf for startupitem_type.
Thanks Jeremy!
I see in my conf now that it is set to default, which is why it probably got
installed together with dbus...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforg
> Should these plists instead rather be installed in the user's
> ~/Library/Launch* folders?
>
> What is the startupitem_type you are writing about? I at least couldn't find
> this in the said plist files...
See macports.conf for startupitem_type.
smime.p7s
Description: S/MIME cryptographic
> I don't think we should go changing the names of the plists.
>
> Rather, it feels to me that dbus is in error to be installing these plists
> into /Library/Launch* even when startupitem_type is set to none, which it is
> in my secondary MacPorts installations. dbus is the only port (I know of)
On 10/25/10 11:10 , Bradley Giesbrecht wrote:
On Oct 25, 2010, at 9:45 AM, Jonathan Stickel wrote:
Thanks! This was not obvious to me. Would it be worthwhile to put this
in the Macports Development Wiki, maybe under Committers Tips and Tricks?
Also, if you want to rerun a port command that c
> Isn't hardcoding /opt/local a problem here?
Oh, that would be bad, indeed! :)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
On Oct 25, 2010, at 10:14 AM, Jeremy Lavergne wrote:
as far as MacPorts users are concerned port maintainers produce the
authoritative hashes.
Says it all for me.
Bradley Giesbrecht
___
macports-dev mailing list
macports-dev@lists.macosforge.org
h
> We haven't decided, but in my mind, they aren't if upstream provides a md5
> checksum.
I'd simply point to the default hashes for MacPorts, which are presently
sha1/rmd160. There's really no difference between the checksums we provide and
what upstream might provide; as far as MacPorts users
On 10/25/2010 12:37 AM, Ryan Schmidt wrote:
On Oct 25, 2010, at 02:15, Titus von Boxberg wrote:
Thanks!
Please note that supported_archs seems to be an undocumented feature
(besides in Changelog of 1.9.0). Maybe you should introduce it
in the guide.
Correct, supported_archs and several other
Thanks! This was not obvious to me. Would it be worthwhile to put this
in the Macports Development Wiki, maybe under Committers Tips and Tricks?
Jonathan
On 10/25/10 10:34 , Jeremy Lavergne wrote:
Check out the -o option.
___
macports-dev mailin
Check out the -o option.
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
When attempting to debug a portfile, every change to the portfile
results in the message:
Portfile changed since last build; discarding previous state.
the build folder is deleted, and build process starts over. Is there
anyway to avoid this? It is common to debug problems with the destroot
Hello Anders,
On 2010-10-25 10:31 , Anders F Björklund wrote:
> I think the main objection to sha256 checksums was
> that they were "too long", even though one sha256
> is shorter than two as in both of sha1 and rmd160...
>
> But one way to make it "shorter" is to use base32
> rather than base16
Hi,
3 months ago I update autopano-sift-C to version 2.5.1. It's still not
committed to trunk. Please let me know what the status is.
Harry
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/
Am 25.10.2010 um 09:37 schrieb Ryan Schmidt:
> On Oct 25, 2010, at 02:15, Titus von Boxberg wrote:
>
>> Thanks!
>>
>> Please note that supported_archs seems to be an undocumented feature
>> (besides in Changelog of 1.9.0). Maybe you should introduce it
>> in the guide.
>
> Correct, supported_ar
I think the main objection to sha256 checksums was
that they were "too long", even though one sha256
is shorter than two as in both of sha1 and rmd160...
But one way to make it "shorter" is to use base32
rather than base16 for encoding the digest string ?
(the end bits are of course the same, ei
On Oct 25, 2010, at 02:57, Anders F Björklund wrote:
> Ryan Schmidt wrote:
>
>>> Are md5 checksums deprecated?
>>
>> They are to me, though we haven't made an official statement about that.
>
> Just like crc32, the md5 checksums are useful for a "quick check"...
>
> They are just deprecated fo
Ryan Schmidt wrote:
Are md5 checksums deprecated?
They are to me, though we haven't made an official statement about
that.
Just like crc32, the md5 checksums are useful for a "quick check"...
They are just deprecated for "security" or "validation", use SHA too.
Should move from sha1 to s
On Oct 25, 2010, at 02:15, Titus von Boxberg wrote:
> Thanks!
>
> Please note that supported_archs seems to be an undocumented feature
> (besides in Changelog of 1.9.0). Maybe you should introduce it
> in the guide.
Correct, supported_archs and several other features are not documented in the
g
On Mon, Oct 25, 2010 at 12:45 AM, Ryan Schmidt wrote:
> Because I mentioned the same thing about another of your revisions a few days
> ago:
> http://lists.macosforge.org/pipermail/macports-dev/2010-October/012966.html
That I totally missed, that's why I asked.
Fixed in r72725 , added dependenc
Would a committer please ci the patch.
Thanks
Am 01.10.2010 um 17:29 schrieb MacPorts:
> #26682: avr-libc @1.7.0_0 mtree violation
> --+-
> Reporter: macporter90...@… | Owner: ti...@…
> Type: defec
Thanks!
Please note that supported_archs seems to be an undocumented feature
(besides in Changelog of 1.9.0). Maybe you should introduce it
in the guide.
Are md5 checksums deprecated?
Regards
Titus
Am 24.10.2010 um 22:55 schrieb MacPorts:
> #26926: new Portfile for tclap
>
37 matches
Mail list logo
