[Fink-devel] Depends Question
Are implicit/sub-depends relationships valid, or do they need to be noted explicitly? Let's say there is a package B-shlibs that is marked "Depends: C-shlibs", and otool -L for files in package A shows linking against files in both B-shlibs and C-shlibs. Does A have to list Depends for both B-shlibs and C-shlibs, or is it sufficient to list B-shlibs? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Begining of a fink "roadmap", this is just an overview draft
On Sun, Nov 09, 2003 at 08:02:47PM +0100, Max Horn wrote: > Just to clarify this: I think I have a pretty good grasp of testing. I > have done test driven development a lot myself in the past. I even made > other people use tests :-). > I wouldn't start with the things I explained in my mails (in case you > thought that was what I proposed). I simply replied to your statements, > trying to explain the situation, and thus trying to increase your > understanding of how the fink build system and installation works. > Sorry if that failed due to miscommunication :-/ Good, then we agree we're totally confused and punching at air. Excellent. *sweeps all this complexity under a rug* Now back to just worrying about testing the modules. :) -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Let me check my notes. http://www.sluggy.com --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Script to change emails
On 8 Nov 2003, at 6:04 PM, Jeremy Higgs wrote: Hi everyone! Does anyone have a script that would allow me to change the email listed in each of the .info files for packages I maintain? I've done a little bit of simple shell scripting, so I was going to do it that way using a whole lot of for loops, but I'm not sure how to do it completely. If anyone has a script already (I remember some developers changing emails before) that I could look at, that would be great! You can do it in emacs using tags-query-replace First create a TAGS file for all info files cd /sw/fink find . -name "*.info" | xargs etags Fire up emacs, and go: M-x tags-query-replace enter the string you want to replace, and what you want to change it to, and go. It will open up each file in which a match is found. You can then either accept/reject individual changes, or type '!' to change all occurrences in that file. Voila! -- Rohan Lloyd --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] RoadMap, second attempt and I expect a bit more feedback this time (pretty please)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Max Horn wrote: You mean like the package manager TODO list which we already have? Maybe you should start with that? fink/TODO. yes, I do. I just would like to put it into a more public place. yes I know everyone can download it from CVS, but with a public place I mean a prominent place, such as the web-site clearly linked from somewhere in very big letters. Automatic GPG stuff sounds like snake oil to me. And non-automatic GPG sounds like a lot of work to me. That said, added security would be nice, but only if it's both convenient to use for developers and users. I can only agree. But as GPG is not exactly a trivial system, it will always require some interaction with the user or developer. I know that there are not only problems how to integrate this on a code level, but also trust issues. Who signs the packages? Are those indiv iduals or is there a fink core key that only specific people have and they sign the packages? who makes sure that the package is "fine" when they do. And if every developer may sign their package, who says I can trust them? I know it is complicated, but I also think that md5sums are nice, but they really do not do much for security now a days, imho. Timestamp handling of Rsync Server Importance: Very High This is a blocker item. I cannot really go out there and acquire more Master mirrors or children until this system has been put in place. In short it means that fink checks which TIMESTAMP it received from the picked mirror it updated last from. If the TIMESTAMP for the mirror it contacted for the next update is older than the locally stored one, that mirror is skipped. How: Hack support for that into Selfupdate.pm. Uhm, why not code it cleanly? :-) From webster: to hack: 3 a : to manage successfully 4 a : to write computer programs for enjoyment I did not mean to imply that "hack" means: do not do it cleanly *grin* Add it to the stuff we already have in our TODO. Hope that somebody gets around to do any of those. Dunno what else to say. Well, that is exactly what I do not wish to do. Wait that someone gets around to doing it, or someone feels like doing it because they happened to stumble across the TODO and they did not have anything better todo. I know that this is something that works very well and I guess lots of fink worked out to be coded that way. I just want to help by pushing this a bit forward. Thus exposing our needs to the public in a better way and explaining how they may interface with us might attract more coders. I am not sure if that is the right approach, so do flame me or guide me and please do nto think I wish to change the way things have worked so far. I just think there is room for improvement. But yes, you are right, the first step is, to add it to the TODO and on that account.. good night ;) - -d Max -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/rskdiW/Ta/pxHPQRAw3qAJ9hmXzJGATTPDoL6kNV+q3IjiA4OQCeJdbu RQav2r31SbuqNrz9atsbFR4= =nXUQ -END PGP SIGNATURE- --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] RoadMap, second attempt and I expect a bit more feedback this time (pretty please)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 QUICK SUMMARY: Migration path to GPG signed info files. Starting right now is possible. On Sunday, November 9, 2003, at 08:07 PM, Max Horn wrote: GPG handling for info signing Importance: Medium How: There are Modules that can do OpenGPG in pure perl, but those have a lot of dependencies. This would mean that we should make gpg essential and maybe a Perl module that interfaces with it. Automatic GPG stuff sounds like snake oil to me. And non-automatic GPG sounds like a lot of work to me. That said, added security would be nice, but only if it's both convenient to use for developers and > users. I think a good first step would be to add md5 sums for every used file and allow a PGP signature of each package .info file, similar to debian .dsc files (see below for an example). This would require a new field with a md5 sum of the patch file. The signature might be optional for a transitional period. This could be done with nearly no work. All the standard tools can be easily changed to ignore the PGP signatures. It should be simple to change the parsers. Nontheless this is a significant security increase. A check of this signature together with the md5 sums of the source and the patches ensures that nobody other than the package maintainer changed something. I don't know if it's really necessary to run this security checks on every user machine. But it could be used by more advanced scripts to check the CVS and the mirrors. Time will show how it can be incorporated into the user's tools. There might be cases like the compromised GNU server (http://www.cert.org/advisories/CA-2003-21.html), where it would be of incredible help if a script could check all the package sources. Going this way wouldn't require GPG support on every user machine. The developers could first learn about the details and figure out what the best migration path for all packeges could be. The minor changes in the parser shouldn't introduce complications and signed and unsigned packages could live side by side without problems. /Steffen Example of a debian package description: - -BEGIN PGP SIGNED MESSAGE- Format: 1.0 Source: apt Version: 0.5.4 Binary: apt-utils, libapt-pkg-doc, libapt-pkg-dev, apt Maintainer: APT Development Team <[EMAIL PROTECTED]> Architecture: any Standards-Version: 3.1.1 Build-Depends: debhelper, debiandoc-sgml, libdb2-dev Files: 274fb64e2e67318b4c9c94599785c37d 528995 apt_0.5.4.tar.gz - -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.3 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBO4BEDtxNMr81Jh4hAQFB2QP+MhZOsAUVu1CTL8LOZCHQgvICFimoRWBl WQCvzVhcoBBpv6r7Xiwkoqjz7y463utRZ6QUI3uJysICmgbIDhNFswouniJSWqiV bcn4fgHd8AcsRvDUWyrfQXpDJjrD4JaoQhWsU3qmC+3KA4finNj3IGToij+lO09J +adpFef2Gpk= =vedl - -END PGP SIGNATURE- - -- PGP Public Key: http://www.zib.de/prohaska/prohaska.pgp Key id: 0xDA749299 Key fingerprint: 8B59 83A8 A43D E0E2 DEDB D479 3157 2FEA DA74 9299 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) iD8DBQE/rp7UMVcv6tp0kpkRAqxLAJ4w56tMJPJvVmH74yylnzWlEQGGgACbBED8 NQfutgn5a+rSoUNsg079JJo= =db4q -END PGP SIGNATURE- --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] root-kde-icons-noia can't compile.
While doing fink update-all, I found the following compilation error. Just a little question: while I have gcc_select 3.3, why is /usr/include/gcc/darwin/3.1/g++-v3/cmath included by g++3? dpkg-deb -b root-kde-icons-noia-0.95-3 /sw/fink/dists/stable/main/binary-darwin-powerpc/kde dpkg-deb: building package `kde-icons-noia' in `/sw/fink/dists/stable/main/binary-darwin-powerpc/kde/kde-icons- noia_0.95-3_darwin-powerpc.deb'. ln -sf /sw/fink/dists/stable/main/binary-darwin-powerpc/kde/kde-icons- noia_0.95-3_darwin-powerpc.deb /sw/fink/debs/ rm -rf /sw/src/root-kde-icons-noia-0.95-3 dpkg -i /sw/fink/dists/stable/main/binary-darwin-powerpc/kde/kde-icons- noia_0.95-3_darwin-powerpc.deb (Reading database ... 197665 files and directories currently installed.) Preparing to replace kde-icons-noia 0.95-2 (using .../kde-icons-noia_0.95-3_darwin-powerpc.deb) ... Unpacking replacement kde-icons-noia ... Setting up kde-icons-noia (0.95-3) ... mkdir -p /sw/src/kseg-0.3.5-12 gzip -dc /sw/src/kseg-0.35.tar.gz | /sw/bin/tar -xf - sed 's|@PREFIX@|/sw|g' < /sw/fink/dists/stable/main/finkinfo/sci/kseg.patch | patch -p1 patching file Makefile patching file formula/Makefile patching file main.cpp make cd formula && make g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt box.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt kformula.cpp /sw/bin/moc kformulaedit.H -o kformulaedit.moc g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt kformulaedit.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt matrixbox.cpp /sw/bin/moc MatrixDialog.H -o MatrixDialog.moc g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt MatrixDialog.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_point.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_line.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_segment.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_ray.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_circle.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_arc.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_locus.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_arcSector.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_arcSegment.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_polygon.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_circleInterior.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_object.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_pointObject.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_lineObject.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_segmentObject.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_rayObject.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_circleObject.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_arcObject.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_locusObject.cpp g++3 -c -O2 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -I/sw/include/qt G_pointLocus.cpp G_pointLocus.cpp: In member function `virtual void G_locusObject::generatePointLocus()': G_pointLocus.cpp:286: call of overloaded `log(int&)' is ambiguous /usr/include/architecture/ppc/math.h:217: candidates are: double log(double) /usr/include/gcc/darwin/3.1/g++-v3/cmath:344: long double std::log(long double) /usr/include/gcc/darwin/3.1/g++-v3/cmath:336: float std::log(float) make: *** [G_pointLocus.o] Error 1 ### execution of make failed, exit code 2 Failed: compiling kseg-0.3.5-12 failed bash-2.05a# gcc_select Current default compiler: gcc version 3.3 20030304 (Apple Computer, Inc. build 1493) bash-2.05a# which g++3 /sw/bin/g++3 -- __Pascal Bourguignon__ http://www.informatimago.com/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ __
Re: [Fink-devel] using *-shlibs? *-dev? When? Where?
Am Sonntag, 09.11.03 um 16:02 Uhr schrieb Charles Lepple: On Sunday, November 9, 2003, at 07:43 AM, Max Horn wrote: Am Sonntag, 09.11.03 um 03:30 Uhr schrieb Stefan Langerman: I am still trying to figure out the whole -shlibs business. I suggest reading http://fink.sourceforge.net/doc/packaging/policy.php#sharedlibs Max: Is there any way we could persuade you (or anyone else who has time, and write access) to include an example, such as your explanation of curl, in the sharedlibs section of the Policy page? You will have no success persuading me (I just spent 5 hours correcting homework; I feel like coding, or going to a party, but not like writing docs, sorry :-). Usually a good approach, though, is this: You, the person needing the documentation, write it (e.g. integrate my example), then let me/other fink core folks review it, and we can put it online. Mind you, I don't ask that you write the whole docs, but e.g. if you understood my example, then you could grab the text of the docs, and integrate my example at a place you feel it fits, and then submit the updated text back to us. For someone who is just getting started with the process of creating an info file, it is invaluable to have one straightforward example to work from. (I clearly remember this when I started packaging gEDA.) Your explanation of how curl works is invaluable for a new developer, because as Stefan pointed out, sometimes it's not obvious which info file should be used as an example. Agreed. And while it's good that the Policy manual details both naming conventions, it's a little too much info for someone who "just wants to make it work" the first time. Yup. Max --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] RoadMap, second attempt and I expect a bit more feedback this time (pretty please)
Am Sonntag, 09.11.03 um 19:44 Uhr schrieb Darian Lanx: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hello ;) First of all, thank you Max and Michael for getting back to me. I realise that we cannot have fixed release cycles. We have talked about that on IRC and I see that there is no way to properly coordinate that. Yet I would appreciate it, if we could somewhat agree on a prioritised TODO list that is global. You mean like the package manager TODO list which we already have? Maybe you should start with that? fink/TODO. This means that someone who is interested in helping us with fink ( the package manager) can have a quick overview. What is needed Why is it needed How badly is it needed and of course suggestions how it could be done. Here is my first attempt at it. Please understand that these are my priorities and you have all the right in the world to put yours in as well. GPG handling for info signing Importance: Medium How: There are Modules that can do OpenGPG in pure perl, but those have a lot of dependencies. This would mean that we should make gpg essential and maybe a Perl module that interfaces with it. Automatic GPG stuff sounds like snake oil to me. And non-automatic GPG sounds like a lot of work to me. That said, added security would be nice, but only if it's both convenient to use for developers and users. Move the package Index to a BerkDB Importance: Medium How: Store the relevant infos from the Info file in a BerkelyDB so that index searches are faster. This is especially interesting should we really expand past the 3000 package border by a significant number. how exactly, I have no idea. To me, importance is low. Timestamp handling of Rsync Server Importance: Very High This is a blocker item. I cannot really go out there and acquire more Master mirrors or children until this system has been put in place. In short it means that fink checks which TIMESTAMP it received from the picked mirror it updated last from. If the TIMESTAMP for the mirror it contacted for the next update is older than the locally stored one, that mirror is skipped. How: Hack support for that into Selfupdate.pm. Uhm, why not code it cleanly? :-) [...] Your thoughts? Add it to the stuff we already have in our TODO. Hope that somebody gets around to do any of those. Dunno what else to say. Max --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Begining of a fink "roadmap", this is just an overview draft
Am Sonntag, 09.11.03 um 15:31 Uhr schrieb Michael G Schwern: On Sun, Nov 09, 2003 at 01:32:10PM +0100, Max Horn wrote: Sorry to have not been clear, I intend to build up a dummy fink installation for testing purposes. Of course this way you can only test a small fraction of Fink. E.g. the whole bootstrap isn't covered by this (which includes compiling stuff like dpkg and apt). Also, you can't test building & installing packages this way (i.e. without source modifications to fink), because fink needs root & dpkg for this, something which requires a) interactivity, and b) dpkg/apt/etc. in the Fink installation, which wouldn't be there. The latter problem maybe can be worked around by symlinks from /sw/bin/dpkg to /my/fake/sw/bin/dpkg etc. Dunno if that would work. That's ok. The tests that need dpkg can be optionally dependent on it. If the user has the dpkg and apt packages already installed they'll be used. We're just testing fink, not dpkg. You've got to draw the line somewhere. There's no problem for the tests to rely on fink packages being already installed. The only thing you don't want is it to alter /sw. Note quite. Because the dpkg installed in /sw has its status/config files in /sw. Getting it to work and live in our fake /sw is not that trivial. It might be possible to achieve that with a chroot box, though. I've done this sort of thing before (look at ExtUtils::MakeMaker). That's, IMHO, comparing Apples and Bananas. Sure, I have done stuff like this before, too . But installing ExtUtils::MakeMaker is, in my estimation (please correct me if I am wrong) much less complex than install Fink and fink. fink's about half the size. Only has one platform to deal with. They're both large sets of crufty code. They're both package build systems. They both build themselves. I don't argue that ExtUtils::MakeMaker is complex - I was specifically referring to *installing* it. :-). The "fink" tool is only a part of "Fink". As such it relies on several other components (dpkg, tar, apt, ncurses, ...) which have to be installed along with it. That takes time, and makes "faking" the environment harder. After that, it's very well possible ExtUtils::MakeMaker is as complex or even more complex, but that's not relevant :-) MakeMaker contains several dummy Perl modules for testing. It goes through the process of running the Makefile.PL and make and checking that all the output is correct and the module gets built and installed into a temp location. In addition it tests the methods individually as best it can. Its all basically the same technique except for this bootstrap bit which I wouldn't worry about how we're going to test it just yet. I am not worried about testing the bootstrap. The thing is, what I still don't quite see is how to do testing *without* a fully bootstrapped test environment. I.e. how to fake one in a useful manner. [...] You've only just got the first 1% tested and already you're worrying about the last 1%. Relax. Have some dip. Actually, I would be quite content already if we just had tests for all the modules. But going beyond module testing for me seems more like the "second 50%" and not the "last 1%"... [...] Not that this is a good example, because it's trivial to restore the fink database ;-) And the broken "fink purge" that just accidentally deleted every package? :) Interesting, I didn't even know we have a "fink purge" ? Somebody must have sneaked it in :-) Anyway, sounds like yet another misunderstanding, a problem of terminology: what do *you* call the "fink database"? For *me* it is the Storable drive "database" containing all the package descriptions, which is in turn derived from the .info files and thus trivial to restore. [...] Let's shelve this. There's a whole lot more basic testing ground to be covered before we get to this point at which point I'll hopefully have a better gesalt for fink and you for testing. Just to clarify this: I think I have a pretty good grasp of testing. I have done test driven development a lot myself in the past. I even made other people use tests :-). I wouldn't start with the things I explained in my mails (in case you thought that was what I proposed). I simply replied to your statements, trying to explain the situation, and thus trying to increase your understanding of how the fink build system and installation works. Sorry if that failed due to miscommunication :-/ Cheers, Max --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] RoadMap, second attempt and I expect a bit more feedback this time (pretty please)
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Hello ;)
First of all, thank you Max and Michael for getting back to me.
I realise that we cannot have fixed release cycles. We have talked about
that on IRC and I see that there is no way to properly coordinate that.
Yet I would appreciate it, if we could somewhat agree on a prioritised
TODO list that is global. This means that someone who is interested in
helping us with fink ( the package manager) can have a quick overview.
What is needed
Why is it needed
How badly is it needed and of course suggestions how it could be done.
Here is my first attempt at it. Please understand that these are my
priorities and you have all the right in the world to put yours in as well.
GPG handling for info signing
Importance: Medium
How: There are Modules that can do OpenGPG in pure perl, but those have
a lot of dependencies. This would mean that we should make gpg essential
and maybe a Perl module that interfaces with it.
Move the package Index to a BerkDB
Importance: Medium
How: Store the relevant infos from the Info file in a BerkelyDB so that
index searches are faster. This is especially interesting should we
really expand past the 3000 package border by a significant number. how
exactly, I have no idea.
Timestamp handling of Rsync Server
Importance: Very High
This is a blocker item. I cannot really go out there and acquire more
Master mirrors or children until this system has been put in place. In
short it means that fink checks which TIMESTAMP it received from the
picked mirror it updated last from. If the TIMESTAMP for the mirror it
contacted for the next update is older than the locally stored one, that
mirror is skipped.
How: Hack support for that into Selfupdate.pm.
Add uidgui branch, automatic adding and removing or users/groups, phase
out passwd file.
Priority: High
I have a few packages I would port, especially INN but I an not willing
to deal with the passwd package.
How: Properly test the branches then merge them to HEAD
Add shlibs branch, automatic lib depends in deb files, use ${SHILB_LIBS}
in the dep line and only hardcoding special cases or non libs.
Priority: Medium
I have no idea how this affects packaging, so I took the priority stated
by Max.
Implement BuildDependsOnly right now it seems to be a switch that does
nothing?
Priority: Low to Medium (yes, right now it's just a dummy field)
Same as above for this point.
Dependency engine
Priority: Medium to High
Probably a complete rewrite? This is definetly a long term goal?!
As you can see there is not much that has been added. maybe you could
help me put this list into an order? Sorted by what is most important
and should be done first? Personally I need that mirror stuff in as
quickly as possible. Yes I know, people are busy, thus ia m patient and
simply asking, but it is a perfect example of what _I_ would put on top
Your thoughts?
Thanks
- -d
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (Darwin)
iD8DBQE/ror+iW/Ta/pxHPQRA3s/AJ9wL102HJpBlTnhBV1JshkUx0+xFwCdGQmT
cyJVIEXXsoYov+U5NWVFtqc=
=m+Bu
-END PGP SIGNATURE-
---
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] So you want to know how up to date the mirror is you are using?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hello folks. I am completely aware, that the new mirror handling for rsync is not yet perfect. Yet I had some time and since I need to learn Perl a bit better I have taken the chance and created a tiny script. It checks the now supplied timestamps of the mirrors against the Master. it calculates the offset and shows when the mirror last updated. You can have a look here: http://finkmirrors.net/status.html I know it is not perfect yet and some values are still odd (like the last update on rjeka which the mirror maintainer was notified off, as well as atl which does not supplied a last updated timestamp yet) Thanks guys, see ya later - -d -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/rof6iW/Ta/pxHPQRA5rGAJ0Xpg2J84vVCZFvafAhl1DW+CmylACgj8I2 7+AARxYqSMhklr6ocE6F6vo= =bk9h -END PGP SIGNATURE- --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] using *-shlibs? *-dev? When? Where?
On Sunday, November 9, 2003, at 07:43 AM, Max Horn wrote: Am Sonntag, 09.11.03 um 03:30 Uhr schrieb Stefan Langerman: I am still trying to figure out the whole -shlibs business. I suggest reading http://fink.sourceforge.net/doc/packaging/policy.php#sharedlibs Max: Is there any way we could persuade you (or anyone else who has time, and write access) to include an example, such as your explanation of curl, in the sharedlibs section of the Policy page? For someone who is just getting started with the process of creating an info file, it is invaluable to have one straightforward example to work from. (I clearly remember this when I started packaging gEDA.) Your explanation of how curl works is invaluable for a new developer, because as Stefan pointed out, sometimes it's not obvious which info file should be used as an example. And while it's good that the Policy manual details both naming conventions, it's a little too much info for someone who "just wants to make it work" the first time. thanks, -- Charles Lepple [EMAIL PROTECTED] --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
RE: [Fink-devel] using *-shlibs? *-dev? When? Where?
A lot of this is covered in the Packaging Manual: http://fink.sourceforge.net/doc/packaging/index.php -- Alexander K. Hansen Levitated Dipole Experiment http://www.psfc.mit.edu/LDX -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Langerman Sent: Saturday, November 08, 2003 9:31 PM To: [EMAIL PROTECTED] Subject: [Fink-devel] using *-shlibs? *-dev? When? Where? I am still trying to figure out the whole -shlibs business. Just looking at a library package like glib2. It has 2 splitoffs which are glib2-shlibs and glib2-dev. If I understand the conventions correctly, I should only "Depend: glib2-shlibs", and then I guess "BuildDepend: glib2-dev". Ok, but then who depends on glib2 itself? why should it ever be installed ? Grepping around for glib2, I see that There are BuildDepends used both for glib2 and glib2-dev. There are also Depends on glib2 and glib2-shlibs. Are some of these packages wrong? Or is there something I don't get? -- Stefan. --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Begining of a fink "roadmap", this is just an overview draft
On Sun, Nov 09, 2003 at 01:32:10PM +0100, Max Horn wrote:
> >Sorry to have not been clear, I intend to build up a dummy fink
> >installation for testing purposes.
> Of course this way you can only test a small fraction of Fink. E.g. the
> whole bootstrap isn't covered by this (which includes compiling stuff
> like dpkg and apt). Also, you can't test building & installing packages
> this way (i.e. without source modifications to fink), because fink
> needs root & dpkg for this, something which requires a) interactivity,
> and b) dpkg/apt/etc. in the Fink installation, which wouldn't be there.
> The latter problem maybe can be worked around by symlinks from
> /sw/bin/dpkg to /my/fake/sw/bin/dpkg etc. Dunno if that would work.
That's ok. The tests that need dpkg can be optionally dependent on it. If
the user has the dpkg and apt packages already installed they'll be used.
We're just testing fink, not dpkg. You've got to draw the line somewhere.
There's no problem for the tests to rely on fink packages being already
installed. The only thing you don't want is it to alter /sw.
> > I've done this sort of thing before (look at ExtUtils::MakeMaker).
>
> That's, IMHO, comparing Apples and Bananas. Sure, I have done stuff
> like this before, too . But installing ExtUtils::MakeMaker is, in my
> estimation (please correct me if I am wrong) much less complex than
> install Fink and fink.
fink's about half the size. Only has one platform to deal with. They're
both large sets of crufty code. They're both package build systems.
They both build themselves.
MakeMaker contains several dummy Perl modules for testing. It goes through
the process of running the Makefile.PL and make and checking that all the
output is correct and the module gets built and installed into a temp
location. In addition it tests the methods individually as best it can.
Its all basically the same technique except for this bootstrap bit which
I wouldn't worry about how we're going to test it just yet.
> >The ideal process is edit, build, test, install. In order to do this
> >you
> >need some sort of testing data.
>
> Understood. But I find it hard to fit this schema on fink, because we
> have two different kinds of install. Two different kinds of build. What
> do you want to test, a full "Fink" installation (the whole distro,
> meaning a bootstrap), or just installing "fink" (the package manager)?
>
> I assumed so far that you meant the latter, but I am not sure anymore
> :-).
Dunno yet, I've just gotten started. Like I said, a lot of this will be
handled as necessary. No point drawing up a big plan now when I hardly
understand how fink works. I can't address testing bootstrap because I've
never really bothered to look at it. Right now I'm just trying to figure
out where to go from Fink::Config and Fink::Base!
You've only just got the first 1% tested and already you're worrying about
the last 1%. Relax. Have some dip.
> > A dummy install. Some static data you can
> >beat on and don't care about mangling if you make a mistake. Edit,
> >build,
> >install, test means you have to install your untested code and *then*
> >test
> >it against your live fink installation. This means you find out that
> >your
> >patch wrecks the fink database *after* its already done so to your
> >running
> >fink.
>
> Not that this is a good example, because it's trivial to restore the
> fink database ;-)
And the broken "fink purge" that just accidentally deleted every package? :)
> A much nicer example is testing "fink cleanup", which removes unused
> .debs. Testing that thoroughly would be a very nice thing. There are
> still some quirks left with it. Writing some good tests should help a
> lot towards finding and fixing those problems (and keeping them fixed).
>
> For this to work, one would indeed need some kind of dummy
> installation, in which one could put a dummy package set. Then create
> dummy .deb files ("touch" should sufficient). Then run "fink cleanup"
> and check if the correct .deb files/symlinks were deleted.
Yep, something like that. Don't get ahead of yourself. :)
> For other things, we'd have a well designed dummy package set which
> would cover many situations: package foo only in stable, only in
> unstable, in both; newer in stable,newer in unstable, same versions;
> etc.. Then test the output of fink list / fink desc etc.
Yep, those are the sorts of permutations you'll have to cover. With
situations like that where the possiblities are near endless its best
to test as the bugs appear rather than drive yourself crazy trying to
do a complete coverage.
> Not really. There are simply two meanings to "install" in this context,
> which might be cause of our problems understanding each other :-)
>
> (1) Bootstrap
> -> create a brand new Fink installation with a new config file, fink
> executable, the essential packages compiled etc.
> (2) Inject
> -> inject a new package
Re: [Fink-devel] problems with g77 3.4 segmentation faults
Hi Jeff et al: Many thanks again for your help with this. Although this version did in fact get rid of my segmentation fault, it didn't solve my other problem, which means the other problem was not specific to compiler version, so at least I have learned something. Given this, and what Remi Mommsen reports, I cannot make a compelling argument in favor of using version 3.3.2 instead of 3.4. (The other problem occurs in a package that isn't in fink, and I have now found can be solved using IBM's xlf.) I'll submit a bug report to the g77 folks for the seg fault in 3.4. I haven't yet had a chance to see if it is platform-indepenent. Again, thanks for helping with this. Bill Scott On Nov 8, 2003, at 5:12 PM, Remi Mommsen wrote: Hi Jeff, I tried your new g77 3.3.2 on 10.3 with cernlib. cernlib builds fine, but the test fails as it was the case with 3.3(.1) (see our email exchange from Jul 17, 2003). With the g77 3.4-20031015 it works flawlessly. Thanks for your effort. Remi William G. Scott Associate Professor Department of Chemistry and Biochemistry and The Center for the Molecular Biology of RNA Sinsheimer Laboratories University of California at Santa Cruz Santa Cruz, California 95064 USA phone: +1-831-459-5367 (office) +1-831-459-5292 (lab) fax: +1-831-4593139 (fax) url: http://chemistry.ucsc.edu/~wgscott/
[Fink-devel] Resubmitting packages for 10.3
I have noticed that my package descriptor for qhull [818090] which got accepted in 10.2/unstable is not on the fink website package list anymore. It still is in the 10.2/unstable tree. I tested it for 10.3 and it works fine. Is there a standard procedure for requesting for a package to be pushed in 10.3? Should I just resubmit it in the tracker? I also have a few other package descriptors that have been pending (for a while) on the tracker, that either work fine or which I have fixed for 10.3. Should I resubmit them separately? [821038] mdbtools-0.5 (to read MS access databases on Mac) [743446] xeukleides(geometric constructions program) [743448] ipe 6.0 preview 10 (great vector drawing program) -- Stefan. --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] using *-shlibs? *-dev? When? Where?
Am Sonntag, 09.11.03 um 03:30 Uhr schrieb Stefan Langerman: I am still trying to figure out the whole -shlibs business. I suggest reading http://fink.sourceforge.net/doc/packaging/policy.php#sharedlibs Just looking at a library package like glib2. It has 2 splitoffs which are glib2-shlibs and glib2-dev. If I understand the conventions correctly, I should only "Depend: glib2-shlibs", and then I guess "BuildDepend: glib2-dev". Ok, but then who depends on glib2 itself? why should it ever be installed ? Let me start with a maybe better example to understand the scheme: curl. curl-shlibs: provides shared libraries; packages using libcurl have to depend on it curl-dev: provides header files; packages using libcurl have to builddepend on it, to ensure that they "see" the headers when compiling curl: provides the curl command line tool. packages which want to use curl in script may depend on it. Other than that, it's up to the user to install it, and the user will install it if he wants to use the curl tool. As for glib2, let me quote its DescPort field: "glib2 provides etc/glib-2.0/charset.alias for darwin because there's no system-wide charset.alias." It also contains localized text files. As such, I imagine ther user can remove it, as long as he's using a pure english system. The user may install it to get nice non-english messages etc. In that regard, glib2 is a bit unusual. It stems from the strict separation between -shlibs (which contains shared libraries, and nothing else), and the main package - in this case, there simply isn't much left for the main package. Often the main package also contains binaries etc. which are useful for the user, but optional. Grepping around for glib2, I see that There are BuildDepends used both for glib2 and glib2-dev. There are also Depends on glib2 and glib2-shlibs. Are some of these packages wrong? Or is there something I don't get? It's valid to (build)depend on glib2. It's not valid to depend on glib2-dev, but you may builddepend on it. Cheers, Max --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Begining of a fink "roadmap", this is just an overview draft
Am Sonntag, 09.11.03 um 06:15 Uhr schrieb Michael G Schwern:
On Sun, Nov 09, 2003 at 03:30:31AM +0100, Max Horn wrote:
AFAIK this is simply the ability to generate fink from fink.in and
the
like
without installing it
Well fink needs a working Fink installation. It is possible to do some
hacking and get it to work in a partial pseudo installation (we do
this
for the package database, which is driven by fink on a Linux server),
but that only allows access to a fraction of fink's capabilities.
I am not sure how (if?) you suggest we could run fink w/o having a
Fink
installation around. Personally I see no point in it, either. Anybody
who wants to develop or test fink will have fink installed.
Sorry to have not been clear, I intend to build up a dummy fink
installation
for testing purposes. Because fink is already fully relocatable (ie.
/sw isn't
hard wired) this should be pretty straightforward. It'll probably
consist
of a config file (which is already there in t/basepath/etc/fink.conf)
and a
small dist tree containing whatever we need to test things. No point
laying it all out upfront, it'll build up with whatever is needed at
the
time.
Of course this way you can only test a small fraction of Fink. E.g. the
whole bootstrap isn't covered by this (which includes compiling stuff
like dpkg and apt). Also, you can't test building & installing packages
this way (i.e. without source modifications to fink), because fink
needs root & dpkg for this, something which requires a) interactivity,
and b) dpkg/apt/etc. in the Fink installation, which wouldn't be there.
The latter problem maybe can be worked around by symlinks from
/sw/bin/dpkg to /my/fake/sw/bin/dpkg etc. Dunno if that would work.
I've done this sort of thing before (look at ExtUtils::MakeMaker).
That's, IMHO, comparing Apples and Bananas. Sure, I have done stuff
like this before, too . But installing ExtUtils::MakeMaker is, in my
estimation (please correct me if I am wrong) much less complex than
install Fink and fink.
The ideal process is edit, build, test, install. In order to do this
you
need some sort of testing data.
Understood. But I find it hard to fit this schema on fink, because we
have two different kinds of install. Two different kinds of build. What
do you want to test, a full "Fink" installation (the whole distro,
meaning a bootstrap), or just installing "fink" (the package manager)?
I assumed so far that you meant the latter, but I am not sure anymore
:-).
A dummy install. Some static data you can
beat on and don't care about mangling if you make a mistake. Edit,
build,
install, test means you have to install your untested code and *then*
test
it against your live fink installation. This means you find out that
your
patch wrecks the fink database *after* its already done so to your
running
fink.
Not that this is a good example, because it's trivial to restore the
fink database ;-)
A much nicer example is testing "fink cleanup", which removes unused
.debs. Testing that thoroughly would be a very nice thing. There are
still some quirks left with it. Writing some good tests should help a
lot towards finding and fixing those problems (and keeping them fixed).
For this to work, one would indeed need some kind of dummy
installation, in which one could put a dummy package set. Then create
dummy .deb files ("touch" should sufficient). Then run "fink cleanup"
and check if the correct .deb files/symlinks were deleted.
For other things, we'd have a well designed dummy package set which
would cover many situations: package foo only in stable, only in
unstable, in both; newer in stable,newer in unstable, same versions;
etc.. Then test the output of fink list / fink desc etc.
So, in essense,
seperating the build and install phases and making it automatable.
You mean more automatic than "./inject.pl" ? Telepathy controlled
maybe? 8-). Seriously, would you please explain what that would mean?
I'm just a bit confused. I forgot inject.pl can be run independently
of
bootstrap.pl. inject.pl should work.
Besides this, as I explained, if you look at fink.info.in, then you see
that setup.sh is essentially the "build" and install.sh the "install
phases you talk about. What you want, essentially, is not (to my
understanding) a separation of build/install (there isn't much to
separate anyway, both are trivial). Rather you want a "setup test
environment" phase. *That* is something I can understand and could work
forward to.
Like I said, I'm the wrong person to be normalizing the build process
as
I don't really know anything about it. I just know what the end result
has to be for it to be testable.
But note that to be able to actually use fink as a whole, it has to be
installed into a working "Fink" installation, i.e. with all its
environment setup. You'd have to do some hacking to be able to use it
w/o installing it.
Hmm, circular build dependencies.
Not really. There are simply two meanings to "
[Fink-devel] using *-shlibs? *-dev? When? Where?
I am still trying to figure out the whole -shlibs business. Just looking at a library package like glib2. It has 2 splitoffs which are glib2-shlibs and glib2-dev. If I understand the conventions correctly, I should only "Depend: glib2-shlibs", and then I guess "BuildDepend: glib2-dev". Ok, but then who depends on glib2 itself? why should it ever be installed ? Grepping around for glib2, I see that There are BuildDepends used both for glib2 and glib2-dev. There are also Depends on glib2 and glib2-shlibs. Are some of these packages wrong? Or is there something I don't get? -- Stefan. --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
