Alexander Hansen | 1 Feb 12:38 2011
Picon

Re: [Fink-users] XQuartz (X11) cannot be found by fink after updating to 2.6.0 (final) from 2.6.0 rc1 on Leopard/10.5.8


On 2/1/11 3:52 AM, Martin Costabel wrote:
> On 1/02/11 00:26 , Alexander Hansen wrote:
> []
>> I'm not sure whether anything in Fink actually looks at xorg-server.pc;
>> no packages carry a BuildDepend on system-pkgconfig-xorg-server, at any
>> rate.
>>
>> Once CVS is back up, we'll definitely fix check_x11_version().  I'm not
>> sure whether we'd want to scrap the system-pkgconfig-xorg-server virtual
>> or not.
>>
>> As a workaround, Ilgaz could create the missing
>> /usr/X11/lib/pkgconfig/xorg-server.pc with the following contents:
> 
> I asked on the x11-users list and got the following answer:
> 
> On 1/02/11 05:10 , Jeremy Huddleston wrote:
> 
>> On Jan 31, 2011, at 14:25, Martin Costabel wrote:
>>
>>> In xquartz-2.6.0, the file X11/lib/pkgconfig/xorg-server.pc is absent.
>>> It was always there, up until xquartz-2.6.0-rc1. Is there a reason for
>>> this absence?
>>
>> Yes. It's not supposed to be there. That's the pkg-config file used by
>> xf86 drivers and has nothing to do with XQuartz.
> 
> I guess that's why it is called "xorg-server".pc, but whatever. I am no
> longer wondering why this kind of arrogance always hits Fink where it
(Continue reading)

Re: Regarding porting of ConTeXt to fink

Sir,
Your references really helpful to me. I gone through the refereneces that u have mentioned and now my
package is ready now i have problem with security policies.

I dont know how to deal with that and how mentioned and use of it, so if u guide me accordingly it would be much
helpful to us.

Thanks & Regards
(kuldip)

Save A Tree From Your Email Signature
Do you really need to print this mail?

________________________________________
From: Alexander Hansen [alexanderk.hansen <at> gmail.com]
Sent: Tuesday, January 25, 2011 11:52 PM
To: Patel Kuldipkumar Laljibhai (MT2010096)
Cc: fink-devel <at> lists.sourceforge.net
Subject: Re: [Fink-devel] Regarding porting of ConTeXt to fink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/25/11 6:32 AM, Patel Kuldipkumar Laljibhai (MT2010096) wrote:
> Hello Sir/madam,
>
> We are here to do some contribution to fink.We know this is very small
> application that we are trying to port into fink.
>
> Currently we came up with package ConText which basically more rich as
(Continue reading)

Alexander Hansen | 4 Feb 14:32 2011
Picon

Re: Regarding porting of ConTeXt to fink


On 2/4/11 4:41 AM, Patel Kuldipkumar Laljibhai (MT2010096) wrote:
> Sir,
> Your references really helpful to me. I gone through the refereneces that u have mentioned and now my
package is ready now i have problem with security policies.
> 
> I dont know how to deal with that and how mentioned and use of it, so if u guide me accordingly it would be much
helpful to us.
> 
> Thanks & Regards
> (kuldip)
> 

What exactly do you mean by "security policies"?

--

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
jaya krishna | 4 Feb 15:28 2011
Picon

Issue with selfupdate

Hai,
 
   I  jaya krishna  trying to port advi1.9.0.
 
   I installed fink successfully but when i try to selfupdate ,the error was proxy doesnt support http tunneling.

  Please help me out.

Thank u
jaya

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Alexander Hansen | 4 Feb 15:55 2011
Picon

Re: Issue with selfupdate


On 2/4/11 9:28 AM, jaya krishna wrote:
> Hai,
>  
>    I  jaya krishna  trying to port advi1.9.0.
>  
>    I installed fink successfully but when i try to selfupdate ,the error
> was proxy doesnt support http tunneling.
> 
>   Please help me out.
> 
> Thank u
> jaya
> 
> 

Can you post the whole error message from an attempt to selfupdate?
It's impossible to tell from a description what is going on.

--

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
Daniel Johnson | 6 Feb 19:53 2011
Picon

Version control migration?

As we all should know by now, Sourceforge's CVS access went down on Jan 26 due to an attack on their servers and
is still down now with no estimate of when it'll be back. Sourceforge has also indicated that they're
considering ending CVS access altogether in the near future since its architecture is inherently
fragile and insecure. Some maintainers have discussed switching to something a little less ancient for a
while now but inertia is a powerful force. :)

So now that our hand is being forced, I decided to just go and do something. The maintainers I've talked to
would like to use Git or Mercurial (and so would I) but after some discussions on IRC I've come to the
conclusion that our best choice is Subversion. Now wait, don't yell at me! Let me explain. Fink is a bit
different from most projects in that our users have to interact with our repository to use fink, either
through rsync or cvs. So, we need something that is easy for our users to use.

Subversion has two big advantages going for it from a user's perspective.

1. It comes standard with the system on 10.5 and later. 10.4 users would have to 'fink install svn'.

2. Sourceforge provides svn access over https on standard port 443, which means people can use it behind
firewalls. Since most firewalls block everything but 80 and 443, svn is really our only choice because
it's the ONLY service Sourceforge supports over one of those ports.

Subversion also behaves substantially similar to cvs so maintainers won't have to learn a whole new way of
using the repository. Git and Mercurial work differently and would require people used to only cvs to
learn a new way of doing version control. If maintainers REALLY want to use them, git-svn and
hg-subversion allow Git and Mercurial to act as svn clients.

gecko2 has been keeping a copy of the sf cvs repository so I was able to download that and experiment.
Converting it to svn was simple with 'cvs2svn --fallback-encoding=utf_8
--retain-conflicting-attic-files'. There are a handful of log messages with utf8 text in them, thus the
--fallback-encoding, and a few cases of files existing in both the Attic and the regular tree--a mild form
of cvs corruption. cvs2svn worked like a charm and I now have a local svn repository with full history
preserved. I then implemented a selfupdate-svn method for fink. I successfully bootstrapped fink,
switched to selfupdate-svn, switched to selfupdate-rsync, then switched back to svn without a hitch. I
can't test switching with cvs, for obvious reasons.

There's nothing more that can be done at the moment since both cvs and shell access are still down, and we
can't enable svn without them. I just wanted to put this out there and see what opinions other people had.
There would need to be other changes made since fink's website is generated from the sources in cvs and the
package database draws information from there as well.

Daniel

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Alexander Hansen | 6 Feb 20:28 2011
Picon

Re: Version control migration?


On 2/6/11 1:53 PM, Daniel Johnson wrote:
> As we all should know by now, Sourceforge's CVS access went down on Jan 26 due to an attack on their servers
and is still down now with no estimate of when it'll be back. Sourceforge has also indicated that they're
considering ending CVS access altogether in the near future since its architecture is inherently
fragile and insecure. Some maintainers have discussed switching to something a little less ancient for a
while now but inertia is a powerful force. :)
> 
> So now that our hand is being forced, I decided to just go and do something. The maintainers I've talked to
would like to use Git or Mercurial (and so would I) but after some discussions on IRC I've come to the
conclusion that our best choice is Subversion. Now wait, don't yell at me! Let me explain. Fink is a bit
different from most projects in that our users have to interact with our repository to use fink, either
through rsync or cvs. So, we need something that is easy for our users to use.
> 
> Subversion has two big advantages going for it from a user's perspective.
> 
> 1. It comes standard with the system on 10.5 and later. 10.4 users would have to 'fink install svn'.
> 
> 2. Sourceforge provides svn access over https on standard port 443, which means people can use it behind
firewalls. Since most firewalls block everything but 80 and 443, svn is really our only choice because
it's the ONLY service Sourceforge supports over one of those ports.
> 
> Subversion also behaves substantially similar to cvs so maintainers won't have to learn a whole new way of
using the repository. Git and Mercurial work differently and would require people used to only cvs to
learn a new way of doing version control. If maintainers REALLY want to use them, git-svn and
hg-subversion allow Git and Mercurial to act as svn clients.
> 
> gecko2 has been keeping a copy of the sf cvs repository so I was able to download that and experiment.
Converting it to svn was simple with 'cvs2svn --fallback-encoding=utf_8
--retain-conflicting-attic-files'. There are a handful of log messages with utf8 text in them, thus the
--fallback-encoding, and a few cases of files existing in both the Attic and the regular tree--a mild form
of cvs corruption. cvs2svn worked like a charm and I now have a local svn repository with full history
preserved. I then implemented a selfupdate-svn method for fink. I successfully bootstrapped fink,
switched to selfupdate-svn, switched to selfupdate-rsync, then switched back to svn without a hitch. I
can't test switching with cvs, for obvious reasons.
> 
> There's nothing more that can be done at the moment since both cvs and shell access are still down, and we
can't enable svn without them. I just wanted to put this out there and see what opinions other people had.
There would need to be other changes made since fink's website is generated from the sources in cvs and the
package database draws information from there as well.
> 
> Daniel
> 
> 

The website is just updated via a "cvs update", so that shouldn't be
terribly difficult to handle.  And the rsync mirror scripts would need
to switch over as well.

Would we have the ability easily to regulate commits access on a more
fine-grained level than we're using right now?  E.g. to give most
established maintainers the ability to commit and modify their own .info
files but not to modify those of other maintainers?  That'd be a useful
additional feature in my opinion, because we could consider broadening
our pool of committers and thereby reduce the backlog on the tracker.
--

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
Daniel Johnson | 6 Feb 20:41 2011
Picon

Re: Version control migration?


On Feb 6, 2011, at 2:28 PM, Alexander Hansen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2/6/11 1:53 PM, Daniel Johnson wrote:
>> As we all should know by now, Sourceforge's CVS access went down on Jan 26 due to an attack on their servers
and is still down now with no estimate of when it'll be back. Sourceforge has also indicated that they're
considering ending CVS access altogether in the near future since its architecture is inherently
fragile and insecure. Some maintainers have discussed switching to something a little less ancient for a
while now but inertia is a powerful force. :)
>> 
>> So now that our hand is being forced, I decided to just go and do something. The maintainers I've talked to
would like to use Git or Mercurial (and so would I) but after some discussions on IRC I've come to the
conclusion that our best choice is Subversion. Now wait, don't yell at me! Let me explain. Fink is a bit
different from most projects in that our users have to interact with our repository to use fink, either
through rsync or cvs. So, we need something that is easy for our users to use.
>> 
>> Subversion has two big advantages going for it from a user's perspective.
>> 
>> 1. It comes standard with the system on 10.5 and later. 10.4 users would have to 'fink install svn'.
>> 
>> 2. Sourceforge provides svn access over https on standard port 443, which means people can use it behind
firewalls. Since most firewalls block everything but 80 and 443, svn is really our only choice because
it's the ONLY service Sourceforge supports over one of those ports.
>> 
>> Subversion also behaves substantially similar to cvs so maintainers won't have to learn a whole new way
of using the repository. Git and Mercurial work differently and would require people used to only cvs to
learn a new way of doing version control. If maintainers REALLY want to use them, git-svn and
hg-subversion allow Git and Mercurial to act as svn clients.
>> 
>> gecko2 has been keeping a copy of the sf cvs repository so I was able to download that and experiment.
Converting it to svn was simple with 'cvs2svn --fallback-encoding=utf_8
--retain-conflicting-attic-files'. There are a handful of log messages with utf8 text in them, thus the
--fallback-encoding, and a few cases of files existing in both the Attic and the regular tree--a mild form
of cvs corruption. cvs2svn worked like a charm and I now have a local svn repository with full history
preserved. I then implemented a selfupdate-svn method for fink. I successfully bootstrapped fink,
switched to selfupdate-svn, switched to selfupdate-rsync, then switched back to svn without a hitch. I
can't test switching with cvs, for obvious reasons.
>> 
>> There's nothing more that can be done at the moment since both cvs and shell access are still down, and we
can't enable svn without them. I just wanted to put this out there and see what opinions other people had.
There would need to be other changes made since fink's website is generated from the sources in cvs and the
package database draws information from there as well.
>> 
>> Daniel
>> 
>> 
> 
> The website is just updated via a "cvs update", so that shouldn't be
> terribly difficult to handle.  And the rsync mirror scripts would need
> to switch over as well.
> 
> Would we have the ability easily to regulate commits access on a more
> fine-grained level than we're using right now?  E.g. to give most
> established maintainers the ability to commit and modify their own .info
> files but not to modify those of other maintainers?  That'd be a useful
> additional feature in my opinion, because we could consider broadening
> our pool of committers and thereby reduce the backlog on the tracker.

Alas, no. "At this time, SourceForge.net does not provide finer-grained permissions (e.g. restrict
access by specific paths within a repository) for Subversion. We will consider implementing
fine-grained permissions for our Subversion service based on the feedback we receive from project
developers." It looks like all Sourceforge provides is access to the whole repository. That would
actually be a step backward from cvs. :/ I guess it would be possible to have a pre-commit-hook script that
limited access to certain areas. It would have to look up whether a maintainer had access to a particular
file and could veto unauthorized commits. We would have to set that up ourselves.

BTW, I hacked fink to use gecko2's cvs copy so that I could test switching between svn and cvs; it works fine.

Daniel

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Alexander Hansen | 6 Feb 20:47 2011
Picon

Re: Version control migration?

On 2/6/11 2:41 PM, Daniel Johnson wrote:
> 

>> Would we have the ability easily to regulate commits access on a more
>> fine-grained level than we're using right now?  E.g. to give most
>> established maintainers the ability to commit and modify their own .info
>> files but not to modify those of other maintainers?  That'd be a useful
>> additional feature in my opinion, because we could consider broadening
>> our pool of committers and thereby reduce the backlog on the tracker.
> 
> Alas, no. "At this time, SourceForge.net does not provide finer-grained permissions (e.g. restrict
access by specific paths within a repository) for Subversion. We will consider implementing
fine-grained permissions for our Subversion service based on the feedback we receive from project
developers." It looks like all Sourceforge provides is access to the whole repository. That would
actually be a step backward from cvs. :/ I guess it would be possible to have a pre-commit-hook script that
limited access to certain areas. It would have to look up whether a maintainer had access to a particular
file and could veto unauthorized commits. We would have to set that up ourselves.
> 
> BTW, I hacked fink to use gecko2's cvs copy so that I could test switching between svn and cvs; it works fine.
> 
> Daniel
> 
> 

It sounds like we might want ultimately to consider using Sourceforge's
svn repo for direct checkouts by our users, rsync mirror sites, and the
website (at least for now), and use hg or git as the primary developer
interface, with e.g. a script to transfer the hg|git repo into svn.
(sort of like the present developer vs. anonymous cvs setup).

--

-- 
Alexander Hansen, Ph.D.
Fink User Liaison

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Charles Lepple | 6 Feb 20:48 2011
Picon

Re: Version control migration?

On Feb 6, 2011, at 1:53 PM, Daniel Johnson wrote:

> As we all should know by now, Sourceforge's CVS access went down on  
> Jan 26 due to an attack on their servers and is still down now with  
> no estimate of when it'll be back. Sourceforge has also indicated  
> that they're considering ending CVS access altogether in the near  
> future since its architecture is inherently fragile and insecure.

For anonymous access, I suspect it's the CVS program, rather than the  
protocol, which is insecure.

Also, the SVN backing stores are not much more robust than CVS - they  
simply bundle the same change information into atomic commits (rather  
than the CVS per-file history).

> Some maintainers have discussed switching to something a little less  
> ancient for a while now but inertia is a powerful force. :)

... which is why I support moving something distributed.

> So now that our hand is being forced, I decided to just go and do  
> something. The maintainers I've talked to would like to use Git or  
> Mercurial (and so would I) but after some discussions on IRC I've  
> come to the conclusion that our best choice is Subversion. Now wait,  
> don't yell at me! Let me explain. Fink is a bit different from most  
> projects in that our users have to interact with our repository to  
> use fink, either through rsync or cvs. So, we need something that is  
> easy for our users to use.
>
> Subversion has two big advantages going for it from a user's  
> perspective.
>
> 1. It comes standard with the system on 10.5 and later. 10.4 users  
> would have to 'fink install svn'.

Agreed.

> 2. Sourceforge provides svn access over https on standard port 443,  
> which means people can use it behind firewalls. Since most firewalls  
> block everything but 80 and 443, svn is really our only choice  
> because it's the ONLY service Sourceforge supports over one of those  
> ports.

This supposes that we want to stay with SourceForge for version  
control. Their issue tracker doesn't interact with version control (to  
my knowledge), so there isn't any value-add that ties those services  
together (e.g. a commit message automatically closes a given tracker  
item when the tracker ID is mentioned after "closes:".)

Mercurial and Git are available over HTTP on other version control  
hosting sites.

> Subversion also behaves substantially similar to cvs so maintainers  
> won't have to learn a whole new way of using the repository. Git and  
> Mercurial work differently and would require people used to only cvs  
> to learn a new way of doing version control. If maintainers REALLY  
> want to use them, git-svn and hg-subversion allow Git and Mercurial  
> to act as svn clients.

Turning that around, Git allows you to set up a CVS pserver daemon  
which could be used for bootstrapping a Fink installation (if rsync is  
not desired). Again, maybe not an option for SourceForge, but part of  
the attractiveness of distributed SCM systems is that you can easily  
move to another hosting system if things go awry (temporarily or  
permanently).

I dunno, I won't complain (too loudly, anyway) if the consensus is  
SVN, but if we're looking at alternatives, we might want to look at  
things beyond just what SourceForge offers.

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel


Gmane