Wouldn't this be way too privacy-infringing?
I would personally draw the line to:
- don't send anything identifying the user (no email ids etc.)
- don't send anything about his/her environment (that would be
potentially identifying, too)
We all know there's plenty of privacy-concerned
Maybe you have a sticky tag from
checking out a specific version? Look at cvs stat VERSION.
I already did a fresh check out, so cannot test that anymore.
Anyway, cvs up -A should release the sticky tags and give you HEAD.
Hmmm, that's a new variation ;-)
- Koen.
Asko Kauppi wrote:
Wouldn't this be way too privacy-infringing?
I would personally draw the line to:
- don't send anything identifying the user (no email ids etc.)
- don't send anything about his/her environment (that would be
potentially identifying, too)
This would absolutely
Dear Asko.
As someone who watches the legal side of what Fink is doing I can assure
you that we cannot retain any information which would enable us to
identify the user. Legally that would put too many obligations on us and
to have significant statistics that is not necessary. However,
Dear Developers,
I am a maintainer for a programme, CcpNmr, which installs minor
updates, like Webmin, to its point release through the user
interface. Hence, when an upgrade is made, from one point release to
another, dpkg does not remove the directory. To clear it up, I have a
Murali Vadivelu wrote:
The annoying thing about the the functioning of the script is that it
gets executed after dpkg replaces the old programme by the new one,
after an 'update ccpnmr-xx-xx' comand or 'update-all' command. This
leaves the user with no installation of the programme! The
On Wed, Dec 06, 2006 at 03:55:31PM +, Murali Vadivelu wrote:
Dear Developers,
I am a maintainer for a programme, CcpNmr, which installs minor
updates, like Webmin, to its point release through the user
interface. Hence, when an upgrade is made, from one point release to
another,
Dear Fink Developers, dear Sylvain
I set all packages previously maintained by Sylvain Cuaz to
unmaintained. Sylvain: We appreciate all the work you have done for
Fink and sure do hope that you are coming back! Please feel free to
take over those packages again once you have more time.
Personally, my one wish for Fink is better maintenance of FinkCommander.
I would like to see some more of the Fink functionality moved into
FinkCommander. I know FinkCommander is officially outside the Fink
suite, but it shouldn't be. For anyone new to open source on the Mac,
having a GUI
On 12/6/06, Philip Lamb [EMAIL PROTECTED] wrote:
Personally, my one wish for Fink is better maintenance of FinkCommander.
I would like to see some more of the Fink functionality moved into
FinkCommander. I know FinkCommander is officially outside the Fink
suite, but it shouldn't be. For
On 04.12.2006, at 11:09, Robert T Wyatt wrote:
Build/installation statistics.
Every time I open pine for the first time on a computer, it asks me
if I
would like to provide (anonymous) feedback to the maintainers. I
think it
would be great if fink.conf allowed for auto-feedback that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philip Lamb wrote:
In short, it is scandalous that such a key tool in the Fink suite has
been neglected. I would venture that 99% of new Fink users depend in
some way on FinkCommander, and I think more attention needs to be
paid to its
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Benjamin Reed wrote:
I've thought about reimplementing it in PerlQt though, might be an
option. :)
Does PerlQt exist on Mac OS X, natively?
And out of curiosity, how would you deploy such an app? Does Perl have a
mechanism for generating
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Walzer wrote:
Does PerlQt exist on Mac OS X, natively?
I believe it's been built against Qt/Mac, yes.
And out of curiosity, how would you deploy such an app? Does Perl have a
mechanism for generating standalone app bundles on OS X?
You
Something that I have wished for several times is more date information:
When I most recently installed a package
When I built it (this can be dug up from the deb build date, but it's
more work than it should be)
When the last update was on the servers (again, available but harder
than it
On Thu, Dec 07, 2006 at 01:03:53AM -0500, David Reiser wrote:
Something that I have wished for several times is more date information:
When I most recently installed a package
In one respect that's a pretty hard one...the data isn't stored
anywhere. I've heard debian talk about adding some
16 matches
Mail list logo