From martin.opel at informatik.fh-regensburg.de Mon Sep 1 11:01:15 2003 From: martin.opel at informatik.fh-regensburg.de (Martin Opel) Date: Mon, 1 Sep 2003 13:01:15 +0200 (CEST) Subject: [clc-devel] Meta ports In-Reply-To: <20030830192628.5f40d0ad.simonerota@operamail.com> References: <20030830152613.GB3703@hoc.cablecom.ch> <20030830192628.5f40d0ad.simonerota@operamail.com> Message-ID: On Sat, 30 Aug 2003, Simone Rota wrote: [...] > I support the second option too, with a couple of considerations: > > 1. The ideal solution would be to have dependencies listed also > in /base and /opt. I know we discussed the thing a hundred times > or so, but I'm still think that: > - This wouldn't undermine the "keep it simple" idea: standard pkgtools will simply ignore deps. > - It would be nice to have the same Pkgfile format for all ports. I support his Simone's opinion. All other suggestions sound like workarounds, not like real solutions. A depends line in base is not necessary in my eyes, because base is installed everywhere. But opt is definitly optional and a user cannot read out of a Pkgfile, on which other package it depends. So without a depends line the opt Pkgfiles will depart from the keep-it-simple concept. With a depends line it becomes even simpler. pkgtools can ignore it. Just a comment for the installer (and of course prt-get). Regards Martin -- martin opel / fachbereich informatik - fachhochschule regensburg / email: martin.opel at informatik.fh-regensburg.de / web: http://rfhs8012.fh-regensburg.de/~opel/ / phone: +49 941 943-1336, fax: +49 941 943-1426 From juergen.daubert at t-online.de Mon Sep 1 11:27:48 2003 From: juergen.daubert at t-online.de (juergen.daubert at t-online.de) Date: Mon, 1 Sep 2003 13:27:48 +0200 Subject: [clc-devel] Meta ports In-Reply-To: References: <20030830152613.GB3703@hoc.cablecom.ch> <20030830192628.5f40d0ad.simonerota@operamail.com> Message-ID: <20030901112748.GA1201@jue.netz> On Mon, Sep 01, 2003 at 01:01:15PM +0200, Martin Opel wrote: > On Sat, 30 Aug 2003, Simone Rota wrote: > > [...] > > I support the second option too, with a couple of considerations: > > > > 1. The ideal solution would be to have dependencies listed also > > in /base and /opt. I know we discussed the thing a hundred times > > or so, but I'm still think that: > > - This wouldn't undermine the "keep it simple" idea: standard pkgtools will simply ignore deps. > > - It would be nice to have the same Pkgfile format for all ports. > > I support his Simone's opinion. All other suggestions sound like > workarounds, not like real solutions. yep, me too. > A depends line in base is not necessary in my eyes, because base is > installed everywhere. The assumption "base is installed" simplifies the whole thing a lot, and it's a must for me to exclude references to base packages. > But opt is definitly optional and a user cannot read > out of a Pkgfile, on which other package it depends. So without a depends > line the opt Pkgfiles will depart from the keep-it-simple concept. With a > depends line it becomes even simpler. > pkgtools can ignore it. Just a comment for the installer (and of course > prt-get). That's the point, we need not much more as we have already, only a simple comment line in the opt ports, but _not_ a "official" dependency system. Greetings J?rgen -- juergen.daubert at t-online.de From jw at tks6.net Mon Sep 1 11:34:49 2003 From: jw at tks6.net (Johannes Winkelmann) Date: Mon, 1 Sep 2003 13:34:49 +0200 Subject: [clc-devel] Applications In-Reply-To: <20030830140930.GA10974@jue.netz> References: <20030830120542.GB1373@hoc.cablecom.ch> <20030830140930.GA10974@jue.netz> Message-ID: <20030901113449.GB411@hoc.cablecom.ch> Hi Giuseppe, We have considered your application and you'll pretty close to become a CLC maintainer; there is one little thing though: J?rgen posted some comments on your ports on clc-devel and we'd like to hear a comment from you :-) On Sat, Aug 30, 2003 at 16:09:30 +0200, juergen.daubert at t-online.de wrote: [...] > I've looked at Giuseppe's ports, some comments: > > - scribus: works fine for me with freetype2, I'd suggest to change > the 'depends on' line from freetype1 to freetype2. Configure option > --disable-nls not needed/supported by scribus. > > - xfce4-plugins: same as above for --disable-nls. I'd suggest to add > a --enable-static=no option instead, because this is the way I've > built the xfce4 port and we don't need the *.a libraries. Consistency is really one of our major goals at CLC, so issues like this are important. Kind regards, Johannes -- Johannes Winkelmann mailto:jw at tks6.net Biel, Switzerland http://jw.tks6.net From giuseppecoviello at tin.it Mon Sep 1 13:15:04 2003 From: giuseppecoviello at tin.it (slash) Date: Mon, 1 Sep 2003 15:15:04 +0200 Subject: [clc-devel] i've uploaded my ports In-Reply-To: <20030901125900.GB507@cruxbox.slash.net> References: <20030901125900.GB507@cruxbox.slash.net> Message-ID: <20030901131504.GC507@cruxbox.slash.net> hi to all, i've made up the mod suggested by Jurgen to my ports and I've uploaded them on http://coviello.altervista.org/ports/ see you soon From viper at mcmeekin.info Tue Sep 2 03:08:41 2003 From: viper at mcmeekin.info (Robert McMeekin) Date: Mon, 1 Sep 2003 23:08:41 -0400 (EDT) Subject: [clc-devel] Slow GNOME Updates (again) Message-ID: <200309020308.h8238fYV027928@reveal.localdomain> Hello clc-devel, Sorry there are a few updates I've not been making in the past week or so. The GNOME 2.3 branch is quickly becoming the GNOME 2.4 branch and should be ready for general use around the 10th of September. I've got everything ready (pretty much). I just have to go through and CLC-ify everything. Also I've been trying to make sure everything from the GNOME Desktop release is available from the CLC, but to continue that trend someone will have to right backends for gnome-system-tools (although the boot/partition manager seems to work well right out of the box). I may do that but I probably won't have any time since school starts on Wednesday. Also, for the record, I don't mind if anyone wants to change something in a package of mine. If you were accepted as a CLC Maintainer, odds are you know better than me anyway (and it's less work for me). :-) //rrm3 -- You will think of something funnier than this to add to the fortunes. From jw at tks6.net Tue Sep 2 14:01:53 2003 From: jw at tks6.net (Johannes Winkelmann) Date: Tue, 2 Sep 2003 16:01:53 +0200 Subject: [clc-devel] pre- and post-install scripts Message-ID: <20030902140153.GB1756@hoc> Hey there, For some time, I thought it would be better not to support pre- and post-install scripts in prt-get but I decided I'll leave this choice to the user ;-). The more, there was some discussion about better ways to support pre-/post-installation, but nothing actually worked out. As we currently have some ports with post-install scripts, I decided to offer a simple solution which might be removed once there's a better way to do it (e.g. in pkgutils). The current implementation is meant to simplify installation of large suites of packages like gnome or kde. Credits for an initial version of this go to Daniel M?ller, unfortunately I didn't find his patch anymore therefore his name didn't make it into prt-get's source code ;-). I've uploaded prt-get 0.5.2pre2 (just update the Pkgfile) which has the following new switches: --pre-install (execute pre-install scripts) --post-install (execute post-install scripts) --install-scripts (execute both pre- and post-install) Testing from interested packagers is very much appreciated! 0.5.2pre2 also includes a 'remove' command to call pkgrm on an arbitrary number of ports: prt-get remove perl ruby python For users of the programmable bash completion, I've updated misc/prt-get_complete as well (in the tarball). Notes: - the scripts must be in the port's directory and have the exact name 'pre-install' and 'post-install' - They're executed for every install and update; therefore, the packager must ensure that things work even if the very same script was already called during an earlier install; - failing pre/post scripts don't interrupt the installation process - the listing in the very end will tell you which ports had pre/post scripts and whether it succeeded or not - In test mode, you won't see whether scripts would be executed Example session: [15:43][root at hoc:~]# prt-get install prepost --install-scripts ... -- Packages installed prepost [pre: ok] [post: ok] prt-get: installed successfully [15:44][root at hoc:~]# Things left to do: - show whether there are pre-/post-install scripts in prt-get info - config file option ("always execute scripts"; not sure yet) - some uninstall equivalent; would benefit from a better specification of crux' pre/post-(un)install functionality though Kind regards, Johannes -- Johannes Winkelmann mailto:jw at tks6.net Biel, Switzerland http://jw.tks6.net From giuseppecoviello at tin.it Tue Sep 2 17:25:18 2003 From: giuseppecoviello at tin.it (slash) Date: Tue, 2 Sep 2003 19:25:18 +0200 Subject: [clc-devel] my ports Message-ID: <20030902172518.GA522@cruxbox.slash.net> I think thet to publis my ports I must do anything else, but what?! I don't know if I'm a mantainer or a future mantainer or a probably future mantainer: teache me, please! From jw at tks6.net Tue Sep 2 17:52:24 2003 From: jw at tks6.net (Johannes Winkelmann) Date: Tue, 2 Sep 2003 19:52:24 +0200 Subject: [clc-devel] my ports In-Reply-To: <20030902172518.GA522@cruxbox.slash.net> References: <20030902172518.GA522@cruxbox.slash.net> Message-ID: <20030902175224.GA465@hoc> Hi, On Tue, Sep 02, 2003 at 19:25:18 +0200, [slash] wrote: > I think thet to publis my ports I must do anything else, but what?! > I don't know if I'm a mantainer or a future mantainer or a probably > future mantainer: teache me, please! You are a probable future maintainer. Someone will have to advocate for you, and I won't as I'm already looking after three other new maintainer. There's nothing you can do than wait, someone will definitely take care of your application. Please note that everyone at CLC does this as a hobby only, so sometimes most of us are busy with work/school/holidays. Regards, Johannes -- Johannes Winkelmann mailto:jw at tks6.net Biel, Switzerland http://jw.tks6.net From sip at varlock.com Tue Sep 2 20:46:01 2003 From: sip at varlock.com (Simone Rota) Date: Tue, 2 Sep 2003 22:46:01 +0200 Subject: [clc-devel] pre- and post-install scripts In-Reply-To: <20030902140153.GB1756@hoc> References: <20030902140153.GB1756@hoc> Message-ID: <20030902224601.191b8c73.sip@varlock.com> On Tue, 2 Sep 2003 16:01:53 +0200 Johannes Winkelmann wrote: > Hey there, Hi Johannes, [cut] > As we > currently have some ports with post-install scripts, I decided to offer > a simple solution which might be removed once there's a better way to do > it (e.g. in pkgutils). The current implementation is meant to simplify > installation of large suites of packages like gnome or kde. This is great. I always felt that there was something missing in the current way CRUX handle packages installation. During last discussion on old CLC mailing list (or was it the CRUX ml?) I ended up (after a brief analysis of ports with needed some pre-post install funcion) thinking that I'd prefer to do the stuff manually for most of them. From another point of view it would be very useful to have PPIS (Pre-Post-Install Scripts [TM]) in some case.(exp. Gnome). With the great tools we have now (prt-get+pkgtools) I think that making a great distro is a consequence of having great packagers, that is how we use such tools. If the prt-get addons are appreciated among packagers, a good start could be a specification of what to include in PPIS and what not to. Regarding your mention to pkgutils and "possible better way to do it", I personally prefer to leave the base work to pkgtools and implement the fancy add-ons into 3rd party utils (prt-get). [cut] > Testing from interested packagers is very much appreciated! I'll definitly test the patch and do every kind of nasty experiment ;) Again I realized that I replied to your post with --verbose-mode-on, please bear with me. I see CRUX & CLC getting better and better everyday, and we're now discussing about the few shortcomings I could ever find in the distro..that is really exciting! > Kind regards, > Johannes Regards, Simone From martin.opel at informatik.fh-regensburg.de Wed Sep 3 08:30:13 2003 From: martin.opel at informatik.fh-regensburg.de (Martin Opel) Date: Wed, 3 Sep 2003 10:30:13 +0200 (CEST) Subject: [clc-devel] Holiday announcement In-Reply-To: <20030902175224.GA465@hoc> References: <20030902172518.GA522@cruxbox.slash.net> <20030902175224.GA465@hoc> Message-ID: On Tue, 2 Sep 2003, Johannes Winkelmann wrote: Hi clc list, please notice that I'll be offline from September, 6th for three weeks, because I'm _very_ busy with holidays :-) While this time I will not be able to add new maintainers. New maintainers will have to wait until September the 29th. Regards Martin From juergen.daubert at t-online.de Wed Sep 3 10:00:47 2003 From: juergen.daubert at t-online.de (juergen.daubert at t-online.de) Date: Wed, 3 Sep 2003 12:00:47 +0200 Subject: [clc-devel] my ports In-Reply-To: <20030902175224.GA465@hoc> References: <20030902172518.GA522@cruxbox.slash.net> <20030902175224.GA465@hoc> Message-ID: <20030903100047.GA26581@jue.netz> On Tue, Sep 02, 2003 at 07:52:24PM +0200, Johannes Winkelmann wrote: > Hi, > > On Tue, Sep 02, 2003 at 19:25:18 +0200, [slash] wrote: > > I think thet to publis my ports I must do anything else, but what?! > > I don't know if I'm a mantainer or a future mantainer or a probably > > future mantainer: teache me, please! > You are a probable future maintainer. Someone will have to advocate for > you Yes, I'll do so Greetings J?rgen -- juergen.daubert at t-online.de From giuseppecoviello at tin.it Wed Sep 3 10:08:41 2003 From: giuseppecoviello at tin.it (slash) Date: Wed, 3 Sep 2003 12:08:41 +0200 Subject: [clc-devel] my ports In-Reply-To: <20030903100047.GA26581@jue.netz> References: <20030902172518.GA522@cruxbox.slash.net> <20030902175224.GA465@hoc> <20030903100047.GA26581@jue.netz> Message-ID: <20030903100841.GA1103@cruxbox.slash.net> Thank you! * juergen.daubert at t-online.de (juergen.daubert at t-online.de) ha scritto: | On Tue, Sep 02, 2003 at 07:52:24PM +0200, Johannes Winkelmann wrote: | > Hi, | > | > On Tue, Sep 02, 2003 at 19:25:18 +0200, [slash] wrote: | > > I think thet to publis my ports I must do anything else, but what?! | > > I don't know if I'm a mantainer or a future mantainer or a probably | > > future mantainer: teache me, please! | > You are a probable future maintainer. Someone will have to advocate for | > you | | Yes, I'll do so | | Greetings | J?rgen | | | -- | juergen.daubert at t-online.de | _______________________________________________ | clc-devel mailing list | clc-devel at lists.berlios.de | http://lists.berlios.de/mailman/listinfo/clc-devel From jw at tks6.net Wed Sep 3 10:57:05 2003 From: jw at tks6.net (Johannes Winkelmann) Date: Wed, 3 Sep 2003 12:57:05 +0200 Subject: [clc-devel] pre- and post-install scripts In-Reply-To: <20030902224601.191b8c73.sip@varlock.com> References: <20030902140153.GB1756@hoc> <20030902224601.191b8c73.sip@varlock.com> Message-ID: <20030903105705.GC946@hoc> Hey, On Tue, Sep 02, 2003 at 22:46:01 +0200, Simone Rota wrote: [...] > [...] If the prt-get addons are appreciated > among packagers, a good start could be a specification of what > to include in PPIS and what not to. Yeah, we should definitely write some sentences about this in the package guidelines. We could probably define "dos and don'ts with pre- and post-install". I've started a discussion page on the CLC Wiki, every with a cvstrac account is invited to write his comments there: http://crux.fh-regensburg.de/cgi-bin/cvstrac/wiki?p=PrePostInstallGuidelines Kind regards, Johannes -- Johannes Winkelmann mailto:jw at tks6.net Biel, Switzerland http://jw.tks6.net From giuseppecoviello at tin.it Wed Sep 3 11:00:37 2003 From: giuseppecoviello at tin.it ( slash ) Date: Wed, 3 Sep 2003 13:00:37 +0200 Subject: [clc-devel] my ports In-Reply-To: References: <20030902172518.GA522@cruxbox.slash.net> <20030902175224.GA465@hoc> <20030903100047.GA26581@jue.netz> <20030903100841.GA1103@cruxbox.slash.net> Message-ID: <20030903110037.GA1480@cruxbox.slash.net> dear martin, I've attached to this mail my id_rsa.pub i wish you to have a nice holiday * Martin Opel (martin.opel at informatik.fh-regensburg.de) ha scritto: | | Hi Giuseppe, | | please send me your SSH Key, then I will add your CVS/CVSTrac account, | before I go on holiday. | | Regards | Martin | -------------- next part -------------- ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAww5Y4Lj9qrI1ZbqgNSA3vGPiaNETNkpPjXCXZu5xk14uW6vXKxf+S7lFzjxNwzlVBFUC2O8KBpgTnW4zKHLFsM67lVfPoID1uZcxddbElQ7QR+Sd4ZbG8RDE1HtnSGd4GsB0kMpIJB9yUyaAkrKP3LPeBfePJI4EciWK8vcAjkc= slash at cruxbox.slash.net From mo at obbl-net.de Wed Sep 3 11:11:18 2003 From: mo at obbl-net.de (mo at obbl-net.de) Date: 3 Sep 2003 13:11:18 +0200 Subject: [clc-devel] new maintainer 'slash' Message-ID: <20030903111118.11829.qmail@rfhpc8082.fh-regensburg.de> Hi list, we have a new maintainer in our team: His berlios account: slash His mail: slash at users.berlios.de His berlios web page: http://developer.berlios.de/users/slash/ His real name: Giuseppe Coviello Regards Martin Opel From root at rfhs8012.fh-regensburg.de Wed Sep 3 11:12:07 2003 From: root at rfhs8012.fh-regensburg.de (root at rfhs8012.fh-regensburg.de) Date: 3 Sep 2003 13:12:07 +0200 Subject: [clc-devel] maintainer 'slash' left the team Message-ID: <20030903111207.11849.qmail@rfhpc8082.fh-regensburg.de> Hi list, I'm sorry to tell you, that slash left our clc team. His berlios account: slash His mail: slash at users.berlios.de His berlios web page: http://developer.berlios.de/users/slash/ Regards Martin Opel From mo at obbl-net.de Wed Sep 3 11:16:48 2003 From: mo at obbl-net.de (mo at obbl-net.de) Date: 3 Sep 2003 13:16:48 +0200 Subject: [clc-devel] new maintainer 'slash' Message-ID: <20030903111648.11894.qmail@rfhpc8082.fh-regensburg.de> Hi list, we have a new maintainer in our team: His berlios account: slash His mail: giuseppecoviello at tin.it His real name: Giuseppe Coviello Regards Martin Opel From jw at tks6.net Wed Sep 3 19:08:45 2003 From: jw at tks6.net (Johannes Winkelmann) Date: Wed, 3 Sep 2003 21:08:45 +0200 Subject: [clc-devel] Port version diff Message-ID: <20030903190845.GD946@hoc> Hi, Inspired by Victor I wrote a little script that searches for ports which used to be in CONTRIB-$OLDVERSION but are missing now (means not in the new contrib, base, opt or unmaintained). It's written in Ruby, so you need to install the ruby interpreter to enjoy it. http://www.hta-bi.bfh.ch/~winkj/files/crux/clc-version-diff.rb Might be helpful for future version updates. Kind regards, Johannes -- Johannes Winkelmann mailto:jw at tks6.net Biel, Switzerland http://jw.tks6.net From log-clc at plutor.org Thu Sep 4 17:24:19 2003 From: log-clc at plutor.org (Logan Ingalls) Date: Thu, 4 Sep 2003 13:24:19 -0400 (EDT) Subject: [clc-devel] Custom port: naim Message-ID: <57157.12.146.113.247.1062696259.squirrel@webmail.discordians.net> I was told that this would be the best way to submit a port for consideration. Naim is a curses-based AIM/IRC/Lily client that's great for those of us with old computers that can't run X. I've got the three files currently hosted on my website. http://plutor.org/projects/crux/?naim I'd love comments, considering this is my first port. Logan From t.mausbach at netcologne.de Thu Sep 4 19:50:10 2003 From: t.mausbach at netcologne.de (Thomas Mausbach) Date: Thu, 04 Sep 2003 21:50:10 +0200 Subject: [clc-devel] Application Message-ID: <3F579772.8080207@netcologne.de> My name is Thomas Mausbach from Cologne (Germany) and I'm interessted in becoming a Maintainer. My IRC nick is 'hulahub' and if I'm online you can find me in the #crux channel. I've created some Ports: teamspeak_client teamspeak_server vim-gtk2 I think they are well formed, and hope I get any response. Note: I wanted to tell you that libSDL has been updated to 1.2.6. I think it's an important release, because it fixes the refresh rate bug. So I hope you will update it. Thomas Mausbach www.axtis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.opel at informatik.fh-regensburg.de Fri Sep 5 08:22:51 2003 From: martin.opel at informatik.fh-regensburg.de (Martin Opel) Date: Fri, 5 Sep 2003 10:22:51 +0200 (CEST) Subject: [clc-devel] non-root users in .footprint Message-ID: Hi all, especially the new maintainers :), the following ports contain non-root users in the footprint: xfce4-artwork xfce4-minicmd-plugin xfce4-netload-plugin xfce4-showdesktop-plugin xfce4-systemload-plugin Please correct this. If you build ports as a non-root user (this is what I prefer, because you see when buggy install scripts try to install directly in /usr/bin,...), you can check the port with the prtcheck scripts from the prt-utils package: ----------- sample session ----------- scott at host > pkgmk =======> ERROR: Footprint mismatch found: MISSING drwxr-xr-x root/root etc/ MISSING -rw-r--r-- root/root etc/prtwash.conf ... NEW drwxr-xr-x user/users etc/ NEW -rw-r--r-- user/users etc/prtwash.conf ... =======> ERROR: Building '/home...clc/prt-utils/prt-utils#0.5.1-1.pkg.tar.gz' failed. scott at host > pkgmk -uf =======> Footprint updated. scott at host > prtcheck ====> WARNING: non-root users found! ====> WARNING: run "prtcheck --root" to convert footprint scott at host > prtcheck --root scott at host > cvs diff .footprint scott at host > ----> NO FOOTPRINT DIFFERENCES, PORT OK! ----------- end sample session ----------- If the unpacked tar archive contains files with different uids or different gids (php 4.3.3 is such a buggy package) and the install routine does not change them to the executing user, then you have to insert a "chown -R root:root $PKG/" as the last line in your Pkgfile. The method shown above does not work in this case, because pkgmk fails: a non-root user cannot "chown root" files. Bye Martin -- martin opel / fachbereich informatik - fachhochschule regensburg / email: martin.opel at informatik.fh-regensburg.de / web: http://rfhs8012.fh-regensburg.de/~opel/ / phone: +49 941 943-1336, fax: +49 941 943-1426 From giuseppecoviello at tin.it Fri Sep 5 09:41:04 2003 From: giuseppecoviello at tin.it (slash) Date: Fri, 5 Sep 2003 11:41:04 +0200 Subject: [clc-devel] non-root users in .footprint In-Reply-To: References: Message-ID: <20030905094104.GA711@cruxbox.slash.net> i think that i've just corrected them. excuse me for my many and great errors, please! * Martin Opel (martin.opel at informatik.fh-regensburg.de) ha scritto: | | Hi all, especially the new maintainers :), | | the following ports contain non-root users in the footprint: | | xfce4-artwork | xfce4-minicmd-plugin | xfce4-netload-plugin | xfce4-showdesktop-plugin | xfce4-systemload-plugin | | Please correct this. If you build ports as a non-root user (this is what I | prefer, because you see when buggy install scripts try to install | directly in /usr/bin,...), you can check the port with the prtcheck | scripts from the prt-utils package: | | ----------- sample session ----------- | scott at host > pkgmk | =======> ERROR: Footprint mismatch found: | MISSING drwxr-xr-x root/root etc/ | MISSING -rw-r--r-- root/root etc/prtwash.conf | ... | NEW drwxr-xr-x user/users etc/ | NEW -rw-r--r-- user/users etc/prtwash.conf | ... | =======> ERROR: Building | '/home...clc/prt-utils/prt-utils#0.5.1-1.pkg.tar.gz' failed. | scott at host > pkgmk -uf | =======> Footprint updated. | scott at host > prtcheck | ====> WARNING: non-root users found! | ====> WARNING: run "prtcheck --root" to convert footprint | scott at host > prtcheck --root | scott at host > cvs diff .footprint | scott at host > ----> NO FOOTPRINT DIFFERENCES, PORT OK! | ----------- end sample session ----------- | | If the unpacked tar archive contains files with different uids or | different gids (php 4.3.3 is such a buggy package) and the install routine | does not change them to the executing user, then you have to insert a | "chown -R root:root $PKG/" as the last line in your Pkgfile. The method | shown above does not work in this case, because pkgmk fails: a non-root | user cannot "chown root" files. | | Bye | Martin | | -- | martin opel / fachbereich informatik - fachhochschule regensburg | / email: martin.opel at informatik.fh-regensburg.de | / web: http://rfhs8012.fh-regensburg.de/~opel/ | / phone: +49 941 943-1336, fax: +49 941 943-1426 | _______________________________________________ | clc-devel mailing list | clc-devel at lists.berlios.de | http://lists.berlios.de/mailman/listinfo/clc-devel From giuseppecoviello at tin.it Sat Sep 6 09:47:28 2003 From: giuseppecoviello at tin.it (slash) Date: Sat, 6 Sep 2003 11:47:28 +0200 Subject: [clc-devel] two collection of ports Message-ID: <20030906094728.GA485@cruxbox.slash.net> I (and other italian crux users) think that isn't good to have two collection of contrib ports (1.1 and 1.2), because many crux users often upgrade the system by installing the new version of their packages then even if their system is marked "version 1.1" they have a system thet is upgraded like (or more than) a 1.2 ones. see you soon! From juergen.daubert at t-online.de Sat Sep 6 12:38:11 2003 From: juergen.daubert at t-online.de (juergen.daubert at t-online.de) Date: Sat, 6 Sep 2003 14:38:11 +0200 Subject: [clc-devel] two collection of ports In-Reply-To: <20030906094728.GA485@cruxbox.slash.net> References: <20030906094728.GA485@cruxbox.slash.net> Message-ID: <20030906123811.GA177@jue.netz> On Sat, Sep 06, 2003 at 11:47:28AM +0200, [slash] wrote: Hi Guiseppe, > I (and other italian crux users) think that isn't good to have two > collection of contrib ports (1.1 and 1.2), because many crux users often > upgrade the system by installing the new version of their packages then > even if their system is marked "version 1.1" they have a system thet is upgraded > like (or more than) a 1.2 ones. I'm sorry to say, but this shows me that you not really understand how cvs and the tagging system we (CLC) use works. I'd suggest to read the CLC cvs manual again and even look at Martin's fine cvs page at btw, it's a _MUST_ for every CLC ports maintainer to update to every new CRUX release asap. regards J?rgen -- juergen.daubert at t-online.de From giuseppecoviello at tin.it Sat Sep 6 12:59:44 2003 From: giuseppecoviello at tin.it (slash) Date: Sat, 6 Sep 2003 14:59:44 +0200 Subject: [clc-devel] two collection of ports In-Reply-To: <20030906125200.GA19885@cruxbox.slash.net> References: <20030906094728.GA485@cruxbox.slash.net> <20030906123811.GA177@jue.netz> <20030906125200.GA19885@cruxbox.slash.net> Message-ID: <20030906125944.GA29678@cruxbox.slash.net> dear Jurgen, i've understood the way to work of CLC with cvs; but i've not understood why a crux user have to re-install crux (the new version) to use the new ports even if he have upgraded his system. * juergen.daubert at t-online.de (juergen.daubert at t-online.de) ha scritto: | On Sat, Sep 06, 2003 at 11:47:28AM +0200, [slash] wrote: | | Hi Guiseppe, | | > I (and other italian crux users) think that isn't good to have two | > collection of contrib ports (1.1 and 1.2), because many crux users often | > upgrade the system by installing the new version of their packages then | > even if their system is marked "version 1.1" they have a system thet is upgraded | > like (or more than) a 1.2 ones. | | I'm sorry to say, but this shows me that you not really understand how | cvs and the tagging system we (CLC) use works. I'd suggest to read the | CLC cvs manual | | | | again and even look at Martin's fine cvs page at | | | | btw, it's a _MUST_ for every CLC ports maintainer to update to every new | CRUX release asap. | | regards | J?rgen | | | -- | juergen.daubert at t-online.de | _______________________________________________ | clc-devel mailing list | clc-devel at lists.berlios.de | http://lists.berlios.de/mailman/listinfo/clc-devel From return at submitstar.com Sun Sep 7 02:12:04 2003 From: return at submitstar.com (Irene Parker) Date: Sun, 7 Sep 2003 10:12:04 +0800 Subject: [clc-devel] CLC.BERLIOS.DE Message-ID: <> An HTML attachment was scrubbed... URL: From juergen.daubert at t-online.de Sun Sep 7 10:32:25 2003 From: juergen.daubert at t-online.de (juergen.daubert at t-online.de) Date: Sun, 7 Sep 2003 12:32:25 +0200 Subject: [clc-devel] two collection of ports In-Reply-To: <20030906125944.GA29678@cruxbox.slash.net> References: <20030906094728.GA485@cruxbox.slash.net> <20030906123811.GA177@jue.netz> <20030906125200.GA19885@cruxbox.slash.net> <20030906125944.GA29678@cruxbox.slash.net> Message-ID: <20030907103225.GA302@jue.netz> On Sat, Sep 06, 2003 at 02:59:44PM +0200, [slash] wrote: > > dear Jurgen, i've understood the way to work of CLC with cvs; but i've > not understood why a crux user have to re-install crux (the new version) > to use the new ports even if he have upgraded his system. Because keeping the packages up-to-date isn't the full story. Major or even minor updates of the important system stuff like e.g. glibc/gcc/binutils will only happen at release boundaries. For such changes recompiling of the whole system is required. This is very time-consuming bootstrapping process, but gracefully done by Per for us. Greetings J?rgen -- juergen.daubert at t-online.de From jw at tks6.net Sun Sep 7 14:02:22 2003 From: jw at tks6.net (Johannes Winkelmann) Date: Sun, 7 Sep 2003 16:02:22 +0200 Subject: [clc-devel] two collection of ports In-Reply-To: <20030906094728.GA485@cruxbox.slash.net> References: <20030906094728.GA485@cruxbox.slash.net> Message-ID: <20030907140222.GC4114@hoc> Hi Slash, First of all, we'd appreciate if you could use a realname. It is written in the CLC maintainer guideline that this is a requirement for this job. On Sat, Sep 06, 2003 at 11:47:28 +0200, [slash] wrote: > I (and other italian crux users) think that isn't good to have two > collection of contrib ports (1.1 and 1.2), because many crux users often > upgrade the system by installing the new version of their packages then > even if their system is marked "version 1.1" they have a system thet > is upgraded like (or more than) a 1.2 ones. You should really take a deeper look at how CRUX and CLC works. CRUX updates sometimes involve changes which have an impact on the ports (Pkgfiles and footprints). The ports CLC provides for a specific version of CRUX will work for this version. If a new version of CRUX is released (let's say 1.3), CONTRIB-1_2 will continue to work for 1.2 systems even if 1.3 will use RPM. The more, dependencies of CLC do not include versions but imply that you use the current version of a dependency from the ports tree. Having no (CRUX release) version tags for CLC ports would break this system completely. The CLC tag are important to match the library and software versions of the corresponding CRUX release, to make sure it works with the version of pkgutils of this release and to ensure the dependency specifications of CLC. Kind regards, Johannes -- Johannes Winkelmann mailto:jw at tks6.net Biel, Switzerland http://jw.tks6.net From sip at varlock.com Sun Sep 7 21:16:43 2003 From: sip at varlock.com (Simone Rota) Date: Sun, 7 Sep 2003 23:16:43 +0200 Subject: [clc-devel] RFC: a script to check availability of updates Message-ID: <20030907231643.21bf09ba.sip@varlock.com> Hi everybody, I'm putting together a set of scripts to automatically check for new releases of packages. I currently maintain few ports in CLC, more are planned and I needed a way to automate the search for new releases. I attach an archive with a preliminary system of main script + tests + config file. Please refer to the README file for detailed description and other infos. Comments and contributions are welcome, inspite I won't have many time in the next 2 weeks (exams approaching). Regards, Simone Rota -------------- next part -------------- A non-text attachment was scrubbed... Name: checkup.tar.gz Type: application/x-gunzip Size: 3778 bytes Desc: not available URL: From sip at varlock.com Sun Sep 7 21:20:53 2003 From: sip at varlock.com (Simone Rota) Date: Sun, 7 Sep 2003 23:20:53 +0200 Subject: [clc-devel] RFC: a script to check availability of updates In-Reply-To: <20030907231643.21bf09ba.sip@varlock.com> References: <20030907231643.21bf09ba.sip@varlock.com> Message-ID: <20030907232053.46ffbc68.sip@varlock.com> On Sun, 7 Sep 2003 23:16:43 +0200 Simone Rota wrote: (I hate auto-replying...) > Comments and contributions are welcome, > inspite I won't have many time in the next > 2 weeks (exams approaching). I meant: even if I won't have many time in the next 2 weeks (exams approaching). From juergen.daubert at t-online.de Mon Sep 8 05:41:25 2003 From: juergen.daubert at t-online.de (juergen.daubert at t-online.de) Date: Mon, 8 Sep 2003 07:41:25 +0200 Subject: [clc-devel] RFC: a script to check availability of updates In-Reply-To: <20030907231643.21bf09ba.sip@varlock.com> References: <20030907231643.21bf09ba.sip@varlock.com> Message-ID: <20030908054125.GA239@jue.netz> On Sun, Sep 07, 2003 at 11:16:43PM +0200, Simone Rota wrote: > Hi everybody, Hi Simone, hi all, > I'm putting together a set of scripts to automatically > check for new releases of packages. hmm, just for your information, maybe it's not known by everyone. You can "subscribe to new releases" for an unlimited number of projects on freshmeat. Create a account there, subscribe your progs and you will get an email for every new release. This works for nearly all of my ports. Greetings J?rgen -- juergen.daubert at t-online.de From jw at tks6.net Mon Sep 8 08:48:37 2003 From: jw at tks6.net (Johannes Winkelmann) Date: Mon, 8 Sep 2003 10:48:37 +0200 Subject: [clc-devel] RFC: a script to check availability of updates In-Reply-To: <20030908054125.GA239@jue.netz> References: <20030907231643.21bf09ba.sip@varlock.com> <20030908054125.GA239@jue.netz> Message-ID: <20030908084837.GA1282@hoc> Hi J?rgen, On Mon, Sep 08, 2003 at 07:41:25 +0200, juergen.daubert at t-online.de wrote: > On Sun, Sep 07, 2003 at 11:16:43PM +0200, Simone Rota wrote: > > Hi everybody, > > Hi Simone, hi all, > > > I'm putting together a set of scripts to automatically > > check for new releases of packages. > > hmm, just for your information, maybe it's not known by > everyone. > You can "subscribe to new releases" for an unlimited number > of projects on freshmeat. Create a account there, subscribe > your progs and you will get an email for every new release. > This works for nearly all of my ports. I agree the freshmeat notification is a pretty good thing, OTOH some ports need special attention (e.g. the j2sdk binary takes a while until it's found on a public ftp site), and therefore I like to have one utility able to check both freshmeat and "other" sites :-) (for now I use a homebrewn script, but I'll have a look at Simone's). Anyway, to each his own ;-) Kind regards, Johannes -- Johannes Winkelmann mailto:jw at tks6.net Biel, Switzerland http://jw.tks6.net From viper at mcmeekin.info Mon Sep 8 09:01:52 2003 From: viper at mcmeekin.info (Robert McMeekin) Date: Mon, 8 Sep 2003 05:01:52 -0400 Subject: [clc-devel] RFC: a script to check availability of updates In-Reply-To: <20030908084837.GA1282@hoc> References: <20030907231643.21bf09ba.sip@varlock.com> <20030908054125.GA239@jue.netz> <20030908084837.GA1282@hoc> Message-ID: <20030908090151.GA16928@mcmeekin.info> On Mon, Sep 08, 2003 at 10:48:37AM +0200, Johannes Winkelmann wrote: [...] > I agree the freshmeat notification is a pretty good thing, OTOH some > ports need special attention (e.g. the j2sdk binary takes a while > until it's found on a public ftp site), and therefore I like to have > one utility able to check both freshmeat and "other" sites :-) (for > now I use a homebrewn script, but I'll have a look at Simone's). I've been using some stupid script that looks at .listing files and doesn't work very well (fortunately there's the gnome ftp-release-list). Anyway, if Simone's scripts work well perhaps the CLC could implement a system of notifying maintainers/packagers when they need to update their ports? That would be super cool. :-) //rrm3 -- The end of the human race will be that it will eventually die of civilization. -- Ralph Waldo Emerson From juergen.daubert at t-online.de Mon Sep 8 10:08:17 2003 From: juergen.daubert at t-online.de (juergen.daubert at t-online.de) Date: Mon, 8 Sep 2003 12:08:17 +0200 Subject: [clc-devel] RFC: a script to check availability of updates In-Reply-To: <20030908084837.GA1282@hoc> References: <20030907231643.21bf09ba.sip@varlock.com> <20030908054125.GA239@jue.netz> <20030908084837.GA1282@hoc> Message-ID: <20030908100817.GC239@jue.netz> On Mon, Sep 08, 2003 at 10:48:37AM +0200, Johannes Winkelmann wrote: [...] > I agree the freshmeat notification is a pretty good thing, OTOH some > ports need special attention (e.g. the j2sdk binary takes a while until > it's found on a public ftp site), and therefore I like to have one > utility able to check both freshmeat and "other" sites :-) Yes, of course ! My intention was not to query Simone's script but to point on the freshmeat possibilities ;) I'll test it today for the progs which does not announce new releases on freshmeat. kind regards J?rgen -- juergen.daubert at t-online.de From sip at varlock.com Mon Sep 8 11:32:24 2003 From: sip at varlock.com (Simone Rota) Date: Mon, 8 Sep 2003 13:32:24 +0200 Subject: [clc-devel] RFC: a script to check availability of updates In-Reply-To: <20030908054125.GA239@jue.netz> References: <20030907231643.21bf09ba.sip@varlock.com> <20030908054125.GA239@jue.netz> Message-ID: <20030908133224.10bceaf2.sip@varlock.com> On Mon, 8 Sep 2003 07:41:25 +0200 juergen.daubert at t-online.de wrote: > Hi Simone, hi all, Hi Juergen, > You can "subscribe to new releases" for an unlimited number > of projects on freshmeat. Create a account there, subscribe > your progs and you will get an email for every new release. > This works for nearly all of my ports. Thank you for pointing out this hint. I already have an account at freshmeat, but never thought of subscribing to new releases. Sometimes the solution of a problem is so simple but I can't see it! Since I like to waste my time, I think I'll go on with the script, to handle ports not listed on freshmeat, or just to have some fun :) > Greetings > J?rgen Regards, Simone From log at plutor.org Mon Sep 8 18:58:22 2003 From: log at plutor.org (Logan Ingalls) Date: Mon, 8 Sep 2003 14:58:22 -0400 (EDT) Subject: [clc-devel] Snort 2.0.1 Message-ID: <46224.12.146.113.247.1063047502.squirrel@webmail.discordians.net> I've made an update for the snort port from 2.0.0 to 2.0.1, which was released in July. There was an option on the 2.0.0 port (unmaintained, but packaged by Jeremy Jones) that was strange. It was configured "--with-flexresp", which first of all is the wrong option for flexible responses, the correct option is "--enable-flexresp". Second, in the documentation, flexresp is marked with "Consider this code as ALPHA. Heavy testing is needed.". I'm not sure what the general policy is for CLC contrib ports, but I think that the spirit of Crux is to stick to stable versions and stable features. I've thus removed this option (and the dependency on libnet-compat. (Please correct me if I'm wrong) The 2.0.1 Pkgfile, .md5sum, and .footprint files are available here: http://plutor.org/projects/crux/?snort Logan From samuel_sande_gov at latinmail.com Wed Sep 10 18:00:19 2003 From: samuel_sande_gov at latinmail.com (samuel sande) Date: Wed, 10 Sep 2003 14:00:19 -0400 Subject: [clc-devel] CONFIDENTIAL BUSINESS INVESTMENT Message-ID: <20030910164946.748813BAC7C@smtp.latinmail.com> FROM THE DESK OF: MR. BRANDY SAMUEL OTHELLO HON. MINISTER OF AGRICULTURE REPUBLIC OF LIBERIA. WEST AFRICA. ATTN: SIR,I KNOW YOU MIGHT BE EMBARRASSED RECIEVING THIS WITHOUT KNOWING ME BEFORE ALSO I WANT YOU TO HANDLE AND SEE THIS BUSINESS PROPOSAL AS GENUINE AND REAL. FOR THIS DOES NOT HAVE ANYTHING TO DO WITH SCAM OR FRAUD BECAUSE BUT AM TELLING YOU THE TRUTH OF THIS MATTER AND IS THAT THIS IS A REAL DEAL AND GENUINE. I AM BRANDY SAMUEL OTHELLO, HON. MINISTER OF AGRICULTURE OF FEDERAL REPUBLIC OF LIBERA. I AM SENDING THIS LETTER TO YOU TO SOLICIT FOR A BUSINESS/INVESTMENT PARTNERSHIP THAT INVOLVES MILLIONS OF DOLLARS. I HAVE TRUNK BOXES CONTAINING DIAMONDS SALES WHICH IS NOW LYING UNDER THE CUSTODY OF A DIPLOMATIC SECURITY COMPANY IN LONDON AND THIS CONSIGNMENT WAS MOVED WITH MY POSITION IN THE OFFICE. I CAME ACROSS THIS DIAMOND SALES WHEN I WAS THE MINISTER OF AGRICULTURE AND MINING/MINERAL RECOURCES,SO WITH MY POSITION THEN IN THE OFFICE I WAS ABLE TO ACQUIRE THESE AND MOVED IT IN A SECURITY COMPANY IN LONDON. THIS IS A LUCRATIVE BUSINESS WHICH I WANT YOU TO HANDLE WITH SERIOUSNESS AND CONFIDENTIALITY UNTIL WE SUCCESSFULLY CONCLUDE THIS PROJECT AND WE WILL USE THE PROCEEDS OF THIS DIAMONDS FOR INVESTMENT PURPOSES. I WILL ALSO LIKE YOU TO MAKE SOME FEASIBILITY STUDY ON THE AREA IN WHICH YOU FEEL I CAN INVEST IN YOUR COUNTRY. ALL MODALITIES ON HOW TO CONCLUDE THIS BUSINESS HAVE BEEN TAKEN CARE OF ALSO EVERY ARRANGEMENT THAT WILL BACK US UP TO CONCLUDE THIS BUSINESS HAVE BEEN ARRANGED. NOTE: THIS BUSINESS IS SCAM AND FRAUD FREE ALSO IS 100% RISK FREE FOR THERE IS NOTHING TO BE SCARED OF,BECAUSE IT DOES CONTAIN ANYTHING SUCH AS: DRUG,MONEY LAUNDERING,TERRORISM ETC. BEAR IN MIND THAT YOU WILL BE COMING DOWN TO LONDON FOR THE CLAIM OF THE DIAMOND ( BOX CONTAINING THE DIAMOND SALES ) ALSO THE SECURITY FIRM WHERE THE DIAMOND IS DEPOSITED SHALL BE IN CONTACT WITH YOU TILL YOUR ARRIVAL. ALSO YOUR INTEREST AND SECURITY HAVE BEEN TAKEN CARE OF. BASED ON OUR UNDERSTANDING AND CO-OPERATION WE WILL CONCLUDE THIS BUSINESS WITHIN 14 WORKING DAYS STARTING FROM THE DAY I RECEIVE YOUR LETTER OF ACCEPTANCE. I WANT US TO CONCLUDE THIS BUSINESS FAST BECAUSE AS YOU CAN SEE THE PROBLEM IN MY COUNTRY NOW AND I WOULD NOT WANT ANYTHING THAT WILL LEOPARDISE OR TAMPER WITH THIS BUSINESS BECAUSE IS MY LIFE. I SHALL EXPLAIN MORE TO YOU ON RECIEPT OF YOUR RESPONSE. THANKS. I AWAIT YOUR URGENT RESPONSE. YOURS FAITHFULLY, MR. BRANDY SAMUEL OTHELLO HON. MINISTER OF AGRICULTURE FEDERAL REPUBLIC OF LIBERIA. NOTE: PLEASE, REPLY ME THROUGH MY EMAIL ADDRESS: _________________________________________________________ http://www.latinmail.com. Gratuito, latino y en espa?ol. From jaeger at morpheus.net Thu Sep 11 13:29:22 2003 From: jaeger at morpheus.net (Matt Housh) Date: Thu, 11 Sep 2003 08:29:22 -0500 Subject: [clc-devel] Application In-Reply-To: <3F579772.8080207@netcologne.de> References: <3F579772.8080207@netcologne.de> Message-ID: <3F6078B2.3080700@morpheus.net> I've looked at Thomas' ports and at Johannes' request, I'm emailing the list to suggest Thomas be added as a maintainer. Matt (jaeger at freenode/#crux) From giuseppecoviello at tin.it Sat Sep 13 05:58:54 2003 From: giuseppecoviello at tin.it (slash) Date: Sat, 13 Sep 2003 07:58:54 +0200 Subject: [clc-devel] errors in ncftp's .footprint Message-ID: <20030913055853.GA7866@cruxbox.slash.net> hi list, I found some errors in the .footprint of ncftp, I've attached the log of "prt-get install ncftp" here! see you soon -------------- next part -------------- =======> Building '/usr/ports/unmaintained/ncftp/ncftp#3.1.6-1.pkg.tar.gz'. tar -C /usr/ports/unmaintained/ncftp/work/src --use-compress-program=bzip2 -xf /usr/ports/unmaintained/ncftp/ncftp-3.1.6-src.tar.bz2 creating cache ./config.cache checking if you set and exported the environment variable CC... no (you may want to do that since configure scripts look for gcc first) checking for environment variable CFLAGS... -O2 -march=i686 -pipe checking for environment variable CPPFLAGS... no checking for environment variable LDFLAGS... no checking for environment variable LIBS... no checking version of C library... glibc2.3.2 checking for gcc... gcc checking whether the C compiler (gcc -O2 -march=i686 -pipe ) works... yes checking whether the C compiler (gcc -O2 -march=i686 -pipe ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking if the C compiler can use precompiled headers... no checking how to run the C preprocessor... gcc -E checking the version of GCC... 3.2.3 checking if we should customize your CFLAGS environment variable... no checking if this is a debug build... no checking NOOPTCFLAGS... -O0 -march=i686 -pipe -Wno-format-y2k checking DEBUGCFLAGS... -g -march=i686 -pipe -Wno-format-y2k checking CFLAGS... -O2 -march=i686 -pipe -Wno-format-y2k checking if we should add to CFLAGS for LFS64 support... -D_LARGEFILE64_SOURCE -O2 -march=i686 -pipe -Wno-format-y2k checking if we should add -D_REENTRANT to CFLAGS... -D_REENTRANT -D_LARGEFILE64_SOURCE -O2 -march=i686 -pipe -Wno-format-y2k checking for object suffix... o checking for Cygwin environment... no checking for mingw32 environment... no checking for executable suffix... no checking for ANSI C header files... yes checking for arpa/nameser.h... yes checking for gnu/libc-version.h... yes checking for locale.h... yes checking for nserve.h... no checking for resolv.h... yes checking for sgtty.h... yes checking for string.h... yes checking for strings.h... yes checking for sys/ioctl.h... yes checking for syslog.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for sys/types.h... yes checking for sys/utsname.h... yes checking for sys/systeminfo.h... no checking for termio.h... yes checking for termios.h... yes checking for time.h... yes checking for utime.h... yes checking for unistd.h... yes checking whether time.h and sys/time.h may both be included... yes checking for sys/un.h... yes checking for UNIX domain sockets... yes checking for sun_len field in struct sockaddr_un... no checking for strerror... yes checking for socket... yes checking for gethostbyname... yes checking if we need to look for -lresolv... no checking if SOCKS5 will be used... no checking for curses library headers... checking for ncurses.h... yes checking for curses.h... yes checking for termios.h... (cached) yes checking for termio.h... (cached) yes checking for sgtty.h... (cached) yes checking for sys/ioctl.h... (cached) yes checking for curses library... yes checking for working const... yes checking for size_t... yes checking for off_t... yes checking for mode_t... yes checking for pid_t... yes checking for uid_t in sys/types.h... yes checking what type main() should return... int checking for 64-bit integral type: long long... yes checking how to print a 64-bit integral type... %lld checking how to scan a 64-bit integral type... %lld checking if everything was available to use the 64-bit integral type... yes checking what type the tv_sec field of struct timeval is... long checking what type the tv_usec field of struct timeval is... long checking for perl... /usr/bin/perl checking for mktemp... /usr/bin/mktemp checking for return type from write... ssize_t checking for size parameter to write... size_t checking for return type from send... ssize_t checking for size parameter to send... size_t checking for size parameter to connect... socklen_t checking for size parameter to setsockopt... socklen_t checking for backlog parameter to listen... int checking for seconds parameter to alarm... unsigned int checking for address parameter to gethostbyaddr... const struct in_addr * checking for size parameter to gethostname... size_t checking types of arguments for select()... int,fd_set *,struct timeval * checking for struct stat64... yes checking for sig_atomic_t... yes checking how to access getopt() global variables... automatic checking for useable _res global variable... yes checking for struct cmsghdr... yes checking for msg_control field in struct msghdr... yes checking for msg_accrights field in struct msghdr... no checking for sys/time.h... (cached) yes checking for getcwd... yes checking for getwd... yes checking for fstat64... yes checking for getdomainname... yes checking for gethostname... yes checking for getpass... yes checking for getpassphrase... no checking for gnu_get_libc_release... yes checking for gnu_get_libc_version... yes checking for inet_aton... yes checking for inet_ntop... yes checking for llseek... yes checking for lseek64... yes checking for lstat64... yes checking for memmove... yes checking for mktime... yes checking for open64... yes checking for pathconf... yes checking for readlink... yes checking for res_init... no checking for setlocale... yes checking for setpgid... yes checking for setpgrp... yes checking for setsid... yes checking for setvbuf... yes checking for sigaction... yes checking for stat64... yes checking for strcasecmp... yes checking for strcoll... yes checking for strdup... yes checking for strerror... (cached) yes checking for strncoll... no checking for strstr... yes checking for strtoq... yes checking for symlink... yes checking for sysconf... yes checking for sysctl... yes checking for sysinfo... yes checking for syslog... yes checking for uname... yes checking for waitpid... yes checking for gethostbyaddr_r... yes checking for gethostbyname_r... yes checking for gethostbyname2_r... yes checking for getlogin_r... yes checking for getpwnam_r... yes checking for _posix_getpwnam_r... no checking for getpwuid_r... yes checking for _posix_getpwuid_r... no checking for getservbyname_r... yes checking for getservbyport_r... yes checking for gmtime_r... yes checking for localtime_r... yes checking for readdir_r... yes checking what sprintf() returns... length of data written checking for snprintf... yes checking for vsnprintf... yes checking if snprintf works correctly... yes checking for sigsetjmp and siglongjmp... yes checking whether setpgrp takes no argument... yes checking whether setvbuf arguments are reversed... no checking string parameter to waddstr... const char * checking whether curses structure has maxx or _maxx field... _maxx checking for getcurx() functionality in curses library... yes checking for getyx() functionality in curses library... yes checking for getmaxx() functionality in curses library... yes checking for getmaxyx() functionality in curses library... yes checking for getbegx() functionality in curses library... yes checking for getbegyx() functionality in curses library... yes checking for touchwin() functionality in curses library... yes checking for beep() functionality in curses library... yes checking for keypad... yes checking for nodelay... yes checking for curs_set... yes checking for doupdate... yes checking for wnoutrefresh... yes checking for long file names... yes checking whether make sets ${MAKE}... yes checking for gtar... no checking for tar... /bin/tar checking how to create TAR files... /bin/tar -c --owner=root --group=bin --verbose -f checking for ranlib... ranlib checking for a BSD compatible install... /usr/bin/install -c checking for pwd... /bin/pwd checking for ccdv... /usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/ccdv checking if shell can test for symlinks... yes updating cache ./config.cache creating ./config.status creating Makefile creating Makefile.bin creating ncftp/Makefile creating libncftp/Makefile creating Strn/Makefile creating sio/Makefile creating sh_util/Makefile creating vis/Makefile creating config.h make[1]: Entering directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/Strn' Compiling DStrCat.c. Compiling DStrFree.c. Compiling Dynscpy.c. Compiling Strncpy.c. Compiling strtokc.c. Compiling DStrCatList.c. Compiling DStrInit.c. Compiling Dynsrecpy.c. Compiling Strnpcat.c. Compiling DStrCpy.c. Compiling DStrNew.c. Compiling StrFree.c. Compiling Strnpcpy.c. Compiling DStrCpyList.c. Compiling Dynscat.c. Compiling Strncat.c. Compiling Strntok.c. Creating library libStrn.a. ranlib "libStrn.a" -rw-r--r-- 1 root root 17716 Sep 13 07:52 libStrn.a Done making Strn. make[1]: Leaving directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/Strn' make[1]: Entering directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/sio' Compiling UAcceptA.c. Compiling UAcceptS.c. Compiling UBind.c. Compiling UConnectByName.c. Compiling UConnect.c. Compiling UNew.c. Compiling URecvfrom.c. Compiling USendtoByName.c. Compiling USendto.c. Compiling main.c. Compiling PRead.c. Compiling PWrite.c. Compiling SAcceptA.c. Compiling SAcceptS.c. Compiling SBind.c. Compiling SClose.c. Compiling SConnectByName.c. Compiling SConnect.c. Compiling SError.c. Compiling SNew.c. Compiling SocketUtil.c. Compiling SReadline.c. Compiling SRead.c. Compiling SRecvfrom.c. Compiling SRecvmsg.c. Compiling SRecv.c. Compiling SSelect.c. Compiling SSend.c. Compiling SSendtoByName.c. Compiling SSendto.c. Compiling StrAddr.c. Compiling SWait.c. Compiling SWrite.c. Compiling DNSUtil.c. Creating library libsio.a. ranlib libsio.a -rw-r--r-- 1 root root 49226 Sep 13 07:52 libsio.a Done. make[1]: Leaving directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/sio' make[1]: Entering directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/libncftp' Compiling c_chdir.c. Compiling c_chdir3.c. Compiling c_chdirlist.c. Compiling c_chmod.c. Compiling c_delete.c. Compiling c_exists.c. Compiling c_filetype.c. Compiling c_getcwd.c. Compiling c_mkdir.c. Compiling c_mlist1.c. Compiling c_modtime.c. Compiling c_opennologin.c. Compiling c_rename.c. Compiling c_rhelp.c. Compiling c_rmdir.c. Compiling c_rmdirr.c. Compiling c_size.c. Compiling c_sizemdtm.c. Compiling c_symlink.c. Compiling c_type.c. Compiling c_umask.c. Compiling c_utime.c. Compiling errno.c. Compiling ftp.c. Compiling ftw.c. Compiling io_get.c. Compiling io_getfiles.c. Compiling io_getonefile.c. Compiling io_gettar.c. Compiling io_list.c. Compiling io_listmem.c. Compiling io_put.c. Compiling io_putfiles.c. Compiling io_putmem.c. Compiling io_putonefile.c. Compiling io_util.c. Compiling lglob.c. Compiling lglobr.c. Compiling linelist.c. Compiling open.c. Compiling rcmd.c. Compiling rftw.c. Compiling rglob.c. Compiling rglobr.c. Compiling u_close.c. Compiling u_decodeurl.c. Compiling u_error.c. Compiling u_fileextn.c. Compiling u_getcwd.c. Compiling u_gethome.c. Compiling u_getpass.c. Compiling u_getopt.c. Compiling u_getpw.c. Compiling u_getusr.c. Compiling u_getutc.c. Compiling u_gmtime.c. Compiling u_localtime.c. Compiling u_misc.c. Compiling u_miscdebug.c. Compiling u_mkdirs.c. Compiling u_pathcat.c. Compiling u_printf.c. Compiling u_rebuildci.c. Compiling u_scram.c. Compiling u_shutdownci.c. Compiling u_signal.c. Compiling u_slash.c. Compiling u_unmdtm.c. Compiling unls.c. Creating library libncftp.a. -rw-r--r-- 1 root root 185220 Sep 13 07:53 libncftp.a make[2]: Entering directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/sio' -rw-r--r-- 1 root root 49226 Sep 13 07:52 libsio.a Done. make[2]: Leaving directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/sio' make[2]: Entering directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/Strn' Done making Strn. make[2]: Leaving directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/Strn' Done. make[1]: Leaving directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/libncftp' make[1]: Entering directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/ncftp' Compiling cmds.c. Compiling cmdlist.c. Compiling ls.c. Compiling main.c. Compiling version.c. Compiling shell.c. Compiling util.c. Compiling readln.c. Compiling progress.c. Compiling bookmark.c. Compiling pref.c. Compiling preffw.c. Compiling trace.c. Compiling spool.c. Compiling spoolutil.c. Compiling log.c. Compiling getline.c. Linking ncftp. Done making NcFTP. make[1]: Leaving directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/ncftp' make[1]: Entering directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/sh_util' Compiling gpshare.c. Compiling preffw.c. Compiling spoolutil.c. Compiling util.c. Compiling getline.c. Compiling version.c. Compiling ncftpget. Compiling ncftpput. Compiling ncftpbatch. Compiling ncftpls. Done making NcFTP shell utilities. make[1]: Leaving directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/sh_util' make[1]: Entering directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/vis' Compiling wgets.c. Compiling wutil.c. Compiling pref.c. Compiling preffw.c. Compiling trace.c. Compiling util.c. Compiling bookmark.c. Compiling version.c. Compiling ncftpbookmarks. Done making NcFTP full-screen utilities. make[1]: Leaving directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/vis' total 861 -rwxr-xr-x 1 root root 230924 Sep 13 07:53 ncftp -rwxr-xr-x 1 root root 145328 Sep 13 07:53 ncftpbatch -rwxr-xr-x 1 root root 106608 Sep 13 07:53 ncftpbookmarks -rwxr-xr-x 1 root root 139812 Sep 13 07:53 ncftpget -rwxr-xr-x 1 root root 101532 Sep 13 07:53 ncftpls -rwxr-xr-x 1 root root 139940 Sep 13 07:53 ncftpput lrwxrwxrwx 1 root root 10 Sep 13 07:53 ncftpspooler -> ncftpbatch Done. ** Please report any problems to http://www.NcFTP.com/contact/ ** make[1]: Entering directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/ncftp' Done making NcFTP. make[1]: Leaving directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/ncftp' make[1]: Entering directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/sh_util' Done making NcFTP shell utilities. make[1]: Leaving directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/sh_util' make[1]: Entering directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/vis' Done making NcFTP full-screen utilities. make[1]: Leaving directory `/usr/ports/unmaintained/ncftp/work/src/ncftp-3.1.6/vis' mkdir "/usr/ports/unmaintained/ncftp/work/pkg/usr" "/usr/ports/unmaintained/ncftp/work/pkg/usr/bin" "/usr/ports/unmaintained/ncftp/work/pkg/usr/etc" "/usr/share/man" "/usr/share/man/man1" 2>/dev/null ..... Installing the programs ..... /usr/bin/install -c bin/ncftp "/usr/ports/unmaintained/ncftp/work/pkg/usr/bin/ncftp" /usr/bin/install -c bin/ncftpget "/usr/ports/unmaintained/ncftp/work/pkg/usr/bin/ncftpget" /usr/bin/install -c bin/ncftpput "/usr/ports/unmaintained/ncftp/work/pkg/usr/bin/ncftpput" /usr/bin/install -c bin/ncftpls "/usr/ports/unmaintained/ncftp/work/pkg/usr/bin/ncftpls" /usr/bin/install -c bin/ncftpbatch "/usr/ports/unmaintained/ncftp/work/pkg/usr/bin/ncftpbatch" ln "/usr/ports/unmaintained/ncftp/work/pkg/usr/bin/ncftpbatch" "/usr/ports/unmaintained/ncftp/work/pkg/usr/bin/ncftpspooler" test -f bin/ncftpbookmarks && /usr/bin/install -c bin/ncftpbookmarks "/usr/ports/unmaintained/ncftp/work/pkg/usr/bin/ncftpbookmarks" ..... Installing the manual pages ..... /usr/bin/install -c -m 644 doc/man/ncftp.1 "/usr/share/man/man1/ncftp.1" /usr/bin/install -c -m 644 doc/man/ncftpget.1 "/usr/share/man/man1/ncftpget.1" /usr/bin/install -c -m 644 doc/man/ncftpput.1 "/usr/share/man/man1/ncftpput.1" /usr/bin/install -c -m 644 doc/man/ncftpbatch.1 "/usr/share/man/man1/ncftpbatch.1" /usr/bin/install -c -m 644 doc/man/ncftpspooler.1 "/usr/share/man/man1/ncftpspooler.1" /usr/bin/install -c -m 644 doc/man/ncftpls.1 "/usr/share/man/man1/ncftpls.1" ..... Finishing up ..... /usr/ports/unmaintained/ncftp/work/pkg/usr/bin: -rwxr-xr-x 1 root root 230924 Sep 13 07:53 ncftp -rwxr-xr-x 2 root root 145328 Sep 13 07:53 ncftpbatch -rwxr-xr-x 1 root root 106608 Sep 13 07:53 ncftpbookmarks -rwxr-xr-x 1 root root 139812 Sep 13 07:53 ncftpget -rwxr-xr-x 1 root root 101532 Sep 13 07:53 ncftpls -rwxr-xr-x 1 root root 139940 Sep 13 07:53 ncftpput -rwxr-xr-x 2 root root 145328 Sep 13 07:53 ncftpspooler Done installing NcFTP. =======> Build result: drwxr-xr-x root/root 0 2003-09-13 07:53 usr/ drwxr-xr-x root/root 0 2003-09-13 07:53 usr/bin/ -rwxr-xr-x root/root 230924 2003-09-13 07:53 usr/bin/ncftp -rwxr-xr-x root/root 139812 2003-09-13 07:53 usr/bin/ncftpget -rwxr-xr-x root/root 139940 2003-09-13 07:53 usr/bin/ncftpput -rwxr-xr-x root/root 101532 2003-09-13 07:53 usr/bin/ncftpls -rwxr-xr-x root/root 106608 2003-09-13 07:53 usr/bin/ncftpbookmarks -rwxr-xr-x root/root 145328 2003-09-13 07:53 usr/bin/ncftpbatch -rwxr-xr-x root/root 0 2003-09-13 07:53 usr/bin/ncftpspooler link to usr/bin/ncftpbatch drwxr-xr-x root/root 0 2003-09-13 07:53 usr/etc/ =======> ERROR: Footprint mismatch found: MISSING drwxr-xr-x root/root usr/man/ MISSING drwxr-xr-x root/root usr/man/man1/ MISSING -rw-r--r-- root/root usr/man/man1/ncftp.1.gz MISSING -rw-r--r-- root/root usr/man/man1/ncftpbatch.1.gz MISSING -rw-r--r-- root/root usr/man/man1/ncftpget.1.gz MISSING -rw-r--r-- root/root usr/man/man1/ncftpls.1.gz MISSING -rw-r--r-- root/root usr/man/man1/ncftpput.1.gz MISSING -rw-r--r-- root/root usr/man/man1/ncftpspooler.1.gz =======> ERROR: Building '/usr/ports/unmaintained/ncftp/ncftp#3.1.6-1.pkg.tar.gz' failed. -- Packages where install failed ncftp From juergen.daubert at t-online.de Sat Sep 13 16:56:16 2003 From: juergen.daubert at t-online.de (juergen.daubert at t-online.de) Date: Sat, 13 Sep 2003 18:56:16 +0200 Subject: [clc-devel] RFC: a script to check availability of updates In-Reply-To: <20030907231643.21bf09ba.sip@varlock.com> References: <20030907231643.21bf09ba.sip@varlock.com> Message-ID: <20030913165616.GA521@jue.netz> On Sun, Sep 07, 2003 at 11:16:43PM +0200, Simone Rota wrote: > Hi everybody, Hi Simone, hi all, > I'm putting together a set of scripts to automatically > check for new releases of packages. I've checked your script and and written my own, because I'm not satisfied with the overall performance when checking a large number of web pages. The attached ruby script has, hopefully, some improvements: - it's multi-threading, a configurable number of threads fetches the pages parallel to each other. Default is a max. of 20 threads, this can be changed at the top of the script (variable threads_max). - a regular expression can be applied to each page, only the matching part is used for comparison and saved for later use. For example: 'apache md5 http://www.apache.de/dist/httpd/ httpd-2[0-9.]*' This is usefully if e.g. daily snapshots are one the same page. - a kind of macro-expansion can be used in the configuration file, e.g you can define '@sf@ http://unc.dl.sourceforge.net' and use later a configuration line like: 'pure-ftpd md5 @sf@/pureftpd/' - restricting the pages to process is possible by applying a regexp on the command-line, e.g. 'ck4up ruby' will only check configuration lines which contains the string ruby. - data's are stored in a gdbm database '~/ck4up/ck4up.dbm', this is, of course, not a improvement but a feature ;) The included sample configuration file is somewhat commented and _MUST_ be manually installed as '~/ck4up/ck4up.conf'. No other docu actually. A 'ck4up -h' gives some help about command-line switches. I've included also a little bash-script (ck4up.sh), which starts mozilla with the different pages, or open them in new tabs, if mozilla is already running. I'm curious about your feedback, and, hopefully, this script will be useful for someone other. I know, ruby isn't a very popular scripting language right now, but give it a try, it's a wonderful and very lightweight language (~5M on my hd). And, maybe, you've it installed already, because you're using yapo ;) kind regards J?rgen -- juergen.daubert at t-online.de -------------- next part -------------- A non-text attachment was scrubbed... Name: ck4up-0.1.4.tar.gz Type: application/x-tar-gz Size: 2467 bytes Desc: not available URL: From sip at varlock.com Sat Sep 13 17:29:12 2003 From: sip at varlock.com (Simone Rota) Date: Sat, 13 Sep 2003 19:29:12 +0200 Subject: [clc-devel] RFC: a script to check availability of updates In-Reply-To: <20030913165616.GA521@jue.netz> References: <20030907231643.21bf09ba.sip@varlock.com> <20030913165616.GA521@jue.netz> Message-ID: <20030913192912.0efe944e.sip@varlock.com> On Sat, 13 Sep 2003 18:56:16 +0200 juergen.daubert at t-online.de wrote: > I've checked your script and and written my own, because I'm not > satisfied with the overall performance when checking a large > number of web pages. The attached ruby script has, hopefully, some > improvements: [cut] I wrote checkup as a sort of proof-of-concept, mainly to propose the mutliple tests idea, giving the user the ability to choose the most appropriate test for a certain port. I know the actual code sucks ;) It's nice to see that at least the idea of a checkup script is interesting and someone is working on such a tool. I'll definitly try your script. > I know, ruby isn't a very popular scripting > language right now, but give it a try, it's a wonderful and very > lightweight language (~5M on my hd). And, maybe, you've it installed > already, because you're using yapo ;) My original idea was to use python for the script, let the flame begin! (just joking) > kind regards > J?rgen Regards, Simone From juergen.daubert at t-online.de Sat Sep 13 18:16:57 2003 From: juergen.daubert at t-online.de (juergen.daubert at t-online.de) Date: Sat, 13 Sep 2003 20:16:57 +0200 Subject: [clc-devel] RFC: a script to check availability of updates In-Reply-To: <20030913192912.0efe944e.sip@varlock.com> References: <20030907231643.21bf09ba.sip@varlock.com> <20030913165616.GA521@jue.netz> <20030913192912.0efe944e.sip@varlock.com> Message-ID: <20030913181657.GB521@jue.netz> On Sat, Sep 13, 2003 at 07:29:12PM +0200, Simone Rota wrote: > My original idea was to use python for the script, > let the flame begin! (just joking) hehe, some times agout I was a python fan also, but I've read somewhere "ruby is what python should be", and I must agree ;) Greetings J?rgen -- juergen.daubert at t-online.de From juergen.daubert at t-online.de Sun Sep 14 11:46:42 2003 From: juergen.daubert at t-online.de (juergen.daubert at t-online.de) Date: Sun, 14 Sep 2003 13:46:42 +0200 Subject: [clc-devel] RFC: a script to check availability of updates In-Reply-To: <20030913165616.GA521@jue.netz> References: <20030907231643.21bf09ba.sip@varlock.com> <20030913165616.GA521@jue.netz> Message-ID: <20030914114642.GA184@jue.netz> Hi again, while looking through the source-location of the gnome ports, I've seen that it could be handy to have a system macro '@NAME@' to simplify the generation and maintenance of ck4up.conf. You can now use the following definitions: '@GNOME@ http://ftp.gnome.org/pub/gnome/sources/@NAME@/2.4/' 'gnome-panel md5 @GNOME@' hopefully not bugging you and kind regards J?rgen -- juergen.daubert at t-online.de -------------- next part -------------- A non-text attachment was scrubbed... Name: ck4up-0.1.5.tar.gz Type: application/x-tar-gz Size: 2640 bytes Desc: not available URL: From giuseppecoviello at tin.it Sun Sep 14 16:16:34 2003 From: giuseppecoviello at tin.it (slash) Date: Sun, 14 Sep 2003 18:16:34 +0200 Subject: [clc-devel] a script to make gnome Message-ID: <20030914161634.GA434@cruxbox.slash.net> hi clc-devel, i think that could be a good idea make a script that automatically build (from ports) and install gnome; what do you think about this? se you soon From danm at gmx.li Sun Sep 14 19:16:00 2003 From: danm at gmx.li (Daniel Mueller) Date: Sun, 14 Sep 2003 21:16:00 +0200 Subject: [clc-devel] a script to make gnome In-Reply-To: <20030914161634.GA434@cruxbox.slash.net> References: <20030914161634.GA434@cruxbox.slash.net> Message-ID: <20030914211600.348e7e05.danm@gmx.li> On Sun, 14 Sep 2003 18:16:34 +0200 "[slash]" wrote: > hi clc-devel, > i think that could be a good idea make a script that automatically > build(from ports) and install gnome; what do you think about this? I think "prt-get grpinst `prt-get quickdep gnome-desktop`" would be enough. BTW: Don't you think From: Coviello Giuseppe looks better than: From: "[slash]" ? :-) bye, danm -- Daniel Mueller mailto:danm at gmx.li Berlin, Germany (OpenPGP: 1024D/F7E7C01F) From giuseppecoviello at tin.it Sun Sep 14 19:31:33 2003 From: giuseppecoviello at tin.it (Giuseppe Coviello) Date: Sun, 14 Sep 2003 21:31:33 +0200 Subject: [clc-devel] a script to make gnome In-Reply-To: <20030914211600.348e7e05.danm@gmx.li> References: <20030914161634.GA434@cruxbox.slash.net> <20030914211600.348e7e05.danm@gmx.li> Message-ID: <20030914193133.GA301@cruxbox.slash.net> * Daniel Mueller (danm at gmx.li) ha scritto: | On Sun, 14 Sep 2003 18:16:34 +0200 | "[slash]" wrote: | | > hi clc-devel, | > i think that could be a good idea make a script that automatically | > build(from ports) and install gnome; what do you think about this? | | I think "prt-get grpinst `prt-get quickdep gnome-desktop`" would be | enough. you're right, i didn't think about this! | | BTW: | | Don't you think | | From: Coviello Giuseppe | | looks better than: | | From: "[slash]" ? | ok, dura lex sed lex | :-) | | bye, danm bye From giuseppecoviello at tin.it Sun Sep 14 21:32:57 2003 From: giuseppecoviello at tin.it (Giuseppe Coviello) Date: Sun, 14 Sep 2003 23:32:57 +0200 Subject: [clc-devel] a script to make gnome In-Reply-To: <20030914211600.348e7e05.danm@gmx.li> References: <20030914161634.GA434@cruxbox.slash.net> <20030914211600.348e7e05.danm@gmx.li> Message-ID: <20030914213256.GA21162@cruxbox.slash.net> * Daniel Mueller (danm at gmx.li) ha scritto: | On Sun, 14 Sep 2003 18:16:34 +0200 | "[slash]" wrote: | | > hi clc-devel, | > i think that could be a good idea make a script that automatically | > build(from ports) and install gnome; what do you think about this? | | I think "prt-get grpinst `prt-get quickdep gnome-desktop`" would be | enough. sorry, this way doesn't build and install all gnome desktop environment; now I (re) think that it's good to make a script to build and install all gnome From warez at crux-it.org Wed Sep 17 23:43:08 2003 From: warez at crux-it.org (Carlo Ghiggi) Date: Thu, 18 Sep 2003 01:43:08 +0200 Subject: [clc-devel] (no subject) Message-ID: <20030917234308.GA5123@crux> -- X-Mailer: Mutt/1.4i on CRUX 1.1 GNU/Linux box | LinuxMachine 204914 Progetto CRUX Italia: www.crux-it.org From warez at crux-it.org Thu Sep 18 20:02:13 2003 From: warez at crux-it.org (Carlo Ghiggi) Date: Thu, 18 Sep 2003 22:02:13 +0200 Subject: [clc-devel] HI Message-ID: <20030918200213.GA1964@crux> Hello to all I'm Carlo, I make part of "Plan CRUX Italy" and are content to make your acquaintance even if only virtual. Made the due presentations I wanted to ask if the ports contained in the directory unmaintained/ they can be "adopts" freely or there are priority. Thanks to all Carlo P.S. I ask first excuse for my wrong one post and also for my little corrected English :) -- X-Mailer: Mutt/1.4i on CRUX 1.1 GNU/Linux box | LinuxMachine 204914 Progetto CRUX Italia: www.crux-it.org From giuseppecoviello at tin.it Fri Sep 19 17:31:42 2003 From: giuseppecoviello at tin.it ( slash ) Date: Fri, 19 Sep 2003 19:31:42 +0200 Subject: [clc-devel] HI In-Reply-To: <20030918200213.GA1964@crux> References: <20030918200213.GA1964@crux> Message-ID: <20030919173142.GC320@cruxbox.slash.net> * Carlo Ghiggi (warez at crux-it.org) ha scritto: | Hello to all | I'm Carlo, I make part of "Plan CRUX Italy" and are content to make your | acquaintance even if only virtual. Made the due presentations I wanted to ask if | the ports contained in the directory unmaintained/ they can be "adopts" freely | or there are priority. | Thanks to all | Carlo | P.S. I ask first excuse for my wrong one post and also for my little corrected | English :) | | -- | X-Mailer: Mutt/1.4i on CRUX 1.1 GNU/Linux | box | LinuxMachine 204914 | Progetto CRUX Italia: www.crux-it.org | _______________________________________________ | clc-devel mailing list | clc-devel at lists.berlios.de | http://lists.berlios.de/mailman/listinfo/clc-devel From giuseppecoviello at tin.it Thu Sep 25 11:23:36 2003 From: giuseppecoviello at tin.it ( slash ) Date: Thu, 25 Sep 2003 13:23:36 +0200 Subject: [clc-devel] handbook's 1.2 sources Message-ID: <20030925112336.GB524@cruxbox.slash.net> hi, anyone can tell me how (and where) I can get the sources in sgml of the handbook 1.2. I must traslate the handbook for the crux-it project. ------------------------------------ Verit?, Beatitudine e Emanazione From jw at tks6.net Thu Sep 25 11:34:17 2003 From: jw at tks6.net (Johannes Winkelmann) Date: Thu, 25 Sep 2003 13:34:17 +0200 Subject: [clc-devel] handbook's 1.2 sources In-Reply-To: <20030925112336.GB524@cruxbox.slash.net> References: <20030925112336.GB524@cruxbox.slash.net> Message-ID: <20030925113417.GD450@hoc> Hi, On Thu, Sep 25, 2003 at 13:23:36 +0200, [ slash ] wrote: > hi, anyone can tell me how (and where) I can get the sources in sgml of > the handbook 1.2. I must traslate the handbook for the crux-it project. You can get them from Per's CVS: http://marc.theaimsgroup.com/?l=crux&m=105890744802946&w=2 Giuseppe, _please_ start using a real name for your CLC communication. We don't want to repeat this over and over again. Regards, Johannes -- Johannes Winkelmann mailto:jw at tks6.net Biel, Switzerland http://jw.tks6.net From giuseppecoviello at tin.it Thu Sep 25 11:46:46 2003 From: giuseppecoviello at tin.it (Giuseppe Coviello) Date: Thu, 25 Sep 2003 13:46:46 +0200 Subject: [clc-devel] handbook's 1.2 sources In-Reply-To: <20030925113417.GD450@hoc> References: <20030925112336.GB524@cruxbox.slash.net> <20030925113417.GD450@hoc> Message-ID: <20030925114646.GA669@cruxbox.slash.net> * Johannes Winkelmann (jw at tks6.net) ha scritto: | Hi, | | On Thu, Sep 25, 2003 at 13:23:36 +0200, [ slash ] wrote: | > hi, anyone can tell me how (and where) I can get the sources in sgml of | > the handbook 1.2. I must traslate the handbook for the crux-it project. | You can get them from Per's CVS: | http://marc.theaimsgroup.com/?l=crux&m=105890744802946&w=2 thank you | Giuseppe, _please_ start using a real name for your CLC communication. | We don't want to repeat this over and over again. yes, you're right, excuse me please; sometimes I don't remember that i must use my real name to comunicate with clc | Regards, Johannes | -- | Johannes Winkelmann mailto:jw at tks6.net | Biel, Switzerland http://jw.tks6.net | _______________________________________________ | clc-devel mailing list | clc-devel at lists.berlios.de | http://lists.berlios.de/mailman/listinfo/clc-devel ------------------------------------ Verit?, Beatitudine e Emanazione From jw at tks6.net Mon Sep 29 08:23:11 2003 From: jw at tks6.net (Johannes Winkelmann) Date: Mon, 29 Sep 2003 10:23:11 +0200 Subject: [clc-devel] new member: Ian Armstrong Message-ID: <20030929082311.GA9014@hoc> Hi everyone, I'm happy to (finally) announce that Ian Armstrong has joined our team as a documentation writer. While we don't have lots of documents for our project, most of them were made by developers and therefore always omit some information which is assumed to be known to everyone ;-) Anyway, the idea is to prepare documents in the Wiki Area of cvstrac to allow a participation of all interested parties and to use this as an input for Ian's work. Means of communication is this mailing list (clc-devel at berlios de). If someone would like to make some comments or add ideas, please speak up now. Ian, I'd like to add two requirements for the documentation: we need HTML output at least, and it would be a plus to be able to edit it without a commercial tool. Looking forward for another improvement of our project's service! Best regards, Johannes -- Johannes Winkelmann mailto:jw at tks6.net Biel, Switzerland http://jw.tks6.net From jw at tks6.net Mon Sep 29 08:26:49 2003 From: jw at tks6.net (Johannes Winkelmann) Date: Mon, 29 Sep 2003 10:26:49 +0200 Subject: [clc-devel] Porting requests Message-ID: <20030929082649.GB9014@hoc> Hey, I'd like to introduce a idea of mine to make sure I don't forget about it ;-) I think it could be a nice idea to have some kind of way to request software to be ported for CRUX. Before everyone goes wild I don't want this to be public, more of an internal thing: I sometimes find software I think would fit very well in our projects, but don't have the experience with this kind of software nor need to port it. In such a case I'd just create a porting request hoping that someone might pick it up. It's just an idea, you know ;-) Kind regards, Johannes -- Johannes Winkelmann mailto:jw at tks6.net Biel, Switzerland http://jw.tks6.net From ika at expressmail.dk Mon Sep 29 08:50:10 2003 From: ika at expressmail.dk (Ian Armstrong) Date: Mon, 29 Sep 2003 10:50:10 +0200 (CEST) Subject: [clc-devel] new member: Ian Armstrong Message-ID: <20030929085010.8CD3C47403@mail.expressmail.dk> On Mon, 29 Sep 2003 10:23:11 +0200, you wrote: >Hi everyone, > >I'm happy to (finally) announce that Ian Armstrong has joined our team >as a documentation writer. While we don't have lots of documents for our >project, most of them were made by developers and therefore always omit >some information which is assumed to be known to everyone ;-) > >Anyway, the idea is to prepare documents in the Wiki Area of cvstrac to >allow a participation of all interested parties and to use this as an >input for Ian's work. Means of communication is this mailing list >(clc-devel at berlios de). >If someone would like to make some comments or add ideas, please speak >up now. > >Ian, I'd like to add two requirements for the documentation: we need >HTML output at least, and it would be a plus to be able to edit it >without a commercial tool. > >Looking forward for another improvement of our project's service! >Best regards, Johannes >-- >Johannes Winkelmann mailto:jw at tks6.net >Biel, Switzerland http://jw.tks6.net >_______________________________________________ >clc-devel mailing list >clc-devel at lists.berlios.de >http://lists.berlios.de/mailman/listinfo/clc-devel Thank you for your welcome. I am glad to be on the team. Unfortunately there will be a bit of a delay before I can start contributing to the documentation. My mother is terminally ill, and I have to make an urgent trip to South Africa. I will, of course, still be reading my e-mail. Greetings to you all. Ian. Ian Armstrong -------------------------------- http://www.expressmail.dk From martin.opel at informatik.fh-regensburg.de Mon Sep 29 11:33:02 2003 From: martin.opel at informatik.fh-regensburg.de (Martin Opel) Date: Mon, 29 Sep 2003 13:33:02 +0200 (CEST) Subject: [clc-devel] Snort 2.0.1 In-Reply-To: <46224.12.146.113.247.1063047502.squirrel@webmail.discordians.net> References: <46224.12.146.113.247.1063047502.squirrel@webmail.discordians.net> Message-ID: On Mon, 8 Sep 2003, Logan Ingalls wrote: > I've made an update for the snort port from 2.0.0 to 2.0.1, which was > released in July. There was an option on the 2.0.0 port (unmaintained, > but packaged by Jeremy Jones) that was strange. It was configured > "--with-flexresp", which first of all is the wrong option for flexible > responses, the correct option is "--enable-flexresp". > > Second, in the documentation, flexresp is marked with "Consider this code > as ALPHA. Heavy testing is needed.". I'm not sure what the general policy > is for CLC contrib ports, but I think that the spirit of Crux is to stick > to stable versions and stable features. I've thus removed this option > (and the dependency on libnet-compat. (Please correct me if I'm wrong) > > The 2.0.1 Pkgfile, .md5sum, and .footprint files are available here: > http://plutor.org/projects/crux/?snort I updated it in our CVS. Bye Martin -- martin opel / fachbereich informatik - fachhochschule regensburg / email: martin.opel at informatik.fh-regensburg.de / web: http://rfhs8012.fh-regensburg.de/~opel/ / phone: +49 941 943-1336, fax: +49 941 943-1426 From martin.opel at informatik.fh-regensburg.de Mon Sep 29 11:55:39 2003 From: martin.opel at informatik.fh-regensburg.de (Martin Opel) Date: Mon, 29 Sep 2003 13:55:39 +0200 (CEST) Subject: [clc-devel] Re: post-install execute bit In-Reply-To: <200309160050.h8G0oawG006268@reveal.localdomain> References: <200309160050.h8G0oawG006268@reveal.localdomain> Message-ID: On Mon, 15 Sep 2003, Robert McMeekin wrote: > Hello Sir, Hi Rob, first of all, please don't call me Sir :) > Would it be possible for you to chmod +x the post-install scripts > for the docbook-* ports in the CLC repository? I can't seem to figure > out how to change the execute bits remotely, and apparently the new > prt-get will not execute pre/post scripts that do not have the execute > bit set. Thanks. Sorry if I'm in error (again). I hope you had a good > vacation (assuming you're back now)! :-) I chmod 555 the post-install,v files in the cvs repository. To all maintainers: please chmod 755 all post-install files, before you add them to the repository to avoid this problem. Thanks Martin -- martin opel / fachbereich informatik - fachhochschule regensburg / email: martin.opel at informatik.fh-regensburg.de / web: http://rfhs8012.fh-regensburg.de/~opel/ / phone: +49 941 943-1336, fax: +49 941 943-1426 From sip at varlock.com Mon Sep 29 11:57:46 2003 From: sip at varlock.com (Simone Rota) Date: Mon, 29 Sep 2003 13:57:46 +0200 Subject: [clc-devel] Porting requests In-Reply-To: <20030929082649.GB9014@hoc> References: <20030929082649.GB9014@hoc> Message-ID: <20030929135746.0cda540a.sip@varlock.com> On Mon, 29 Sep 2003 10:26:49 +0200 Johannes Winkelmann wrote: > Hey, > > I'd like to introduce a idea of mine to make sure I don't forget about > it ;-) Never thought about a notepad? :-P > I think it could be a nice idea to have some kind of way to request > software to be ported for CRUX. Before everyone goes wild I don't want > this to be public, more of an internal thing: I sometimes find software > I think would fit very well in our projects, but don't have the > experience with this kind of software nor need to port it. In such a > case I'd just create a porting request hoping that someone might pick it > up. That is a good idea. An internal list of "wanted" ports could help make CRUX a more complete solution in several fields (server, desktop, thin client...). I'd also extend the idea to /unmaintained ports: someteime I find that some useful progam is no longer maintained and while I don't use it (or use it seldomly) I think it could be a useful addition to /contrib. Regards, Simone From mo at obbl-net.de Mon Sep 29 11:59:21 2003 From: mo at obbl-net.de (mo at obbl-net.de) Date: 29 Sep 2003 13:59:21 +0200 Subject: [clc-devel] new maintainer 'tilman' Message-ID: <20030929115921.21818.qmail@rfhpc8082.fh-regensburg.de> Hi list, we have a new maintainer in our team: His berlios account: tilman His mail: tilman at code-monkey.de His real name: Tilman Sauerbeck Regards Martin Opel From sip at varlock.com Mon Sep 29 15:29:45 2003 From: sip at varlock.com (Simone Rota) Date: Mon, 29 Sep 2003 17:29:45 +0200 Subject: [clc-devel] RFC: clc build machine Message-ID: <20030929172945.369575f6.sip@varlock.com> [Dramatic Prelude] fsck! I'm rewriting this long email after a blackout @ home. My notebook battery suddenly died literally seconds before the power outage and I was left staring at a black screen. The cost of a new battery for my Dell is around 240 euros. Shit. [Back on topic now] I finally managed to dedicate a machine to CLC for port building/testing. We briefly discussed the idea not so long ago in CLC or CRUX Mailing List. Basically it will periodically build and install all ports in /contrib using prt-get for dependencies and log the results. The main aims of this process are essentially two, in order of importance: - Provide a sort of "quality test" for maintained ports: it would be nice to be sure that all ports in /contrib would correctly build and install on a default "blank" CRUX setup. This could be useful for testing proper dependency listing, since it's possible to leave out some deps when building ports on a machine we daily use for "real world" tasks. - Provide binary packages. I asked for this some time ago; while it's a bit premature to add this feature to CLC (and maybe many users/packagers don't like the idea), I will keep binary packages for personal use and eventually upload them somewhere in the net, keeping them separate from CLC. Brief pseudo-code explanation of the process: ------------------------------------------------------ # Initial conditions: only /base ports installed, # with some exception: openssl/h, prt-get, ports, cvsup ports -u activate_giant_fan() activate_liquid_nitrogen_cooling() for port in /contrib: prt-get install 'prt-get quickdep port' # Here we use packages built in this session. # No need to rebuild every package log_single() for port in 'prt-get quickdep port': if port not in /base, /exceptions: prt-get remove port log_all() # html report/summary? move_packages() # move binaries to another loaction so next session # they'll be recompiled ------------------------------------------------------ Questions time: - A confirmation: did we establihsed that /opt ports should be listed as dependencies, didn't we? - This was also briefly discussed before: when a package upgrade (expecially. for libraries) introduces binary incompatibility for dependent packages, we currently don't have a way to make the user aware. In such cases, should we upgrade also the dependent packages (by just increasing release number)? Please note that even if today it's quite easy to "guess" for packages that could need a recompilation, if the port tree will eventually grow, in the future the hunting for such packages could become not-so-trivial. Misc notes: I don't know for sure when the "build machine" will be ready to use, probably sometime next week. I also have no idea how long a full compilation of /contrib ports could take, if the port tree changes "too fast" respect to compilation time many benefits could be lost. (and I could introduce a compile-by-request, compile only changed ports, or similar tricks) If anyone has further suggestions or ideas, it would be gladly accepted. Best regards, Simone From jw at tks6.net Mon Sep 29 16:14:09 2003 From: jw at tks6.net (Johannes Winkelmann) Date: Mon, 29 Sep 2003 18:14:09 +0200 Subject: [clc-devel] RFC: clc build machine In-Reply-To: <20030929172945.369575f6.sip@varlock.com> References: <20030929172945.369575f6.sip@varlock.com> Message-ID: <20030929161409.GB682@hoc.LDS> Hi Simone, Just a quick reply for now: On Mon, Sep 29, 2003 at 17:29:45 +0200, Simone Rota wrote: [...] > [Back on topic now] > > I finally managed to dedicate a machine to CLC for > port building/testing. cool! > The main aims of this process are essentially two, > in order of importance: > > - Provide a sort of "quality test" for maintained ports: good idea > - Provide binary packages. I asked for this some time ago; > while it's a bit premature to add this feature to CLC > (and maybe many users/packagers don't like the idea), > I will keep binary packages for personal use and eventually > upload them somewhere in the net, keeping them separate > from CLC. Having binary packages built on a fresh CRUX installation is something I'd probably use to create customized images for my personal use (e.g. no windowaker but blackbox ;-)). The following is just here for completeness ;-) While I love crux' package management, I fear it might become hairy once binary packages are around; I'm certainly not afraid that you Simone will run into problems (as you know what it's all about), but if Joe User decides to check out crux and wants to install let's say evolution, pkgadd evolution#$VERSION.tar.gz will "just work", while the program won't. I assume there could be scripts to handle this, but it might be hard to forbid all users to use pkgadd directly. The joy of a system without dependencies in built packages ;-) So as a summary I think it's most important to communicate clearly that "binary packages for crux" doesn't mean "RPM-like packages for crux". I'm pretty sure we can reach this goal. > Questions time: > > - A confirmation: did we establihsed that /opt > ports should be listed as dependencies, didn't we? Yes we did, even though this has probably not been implemented for a large number of ports. > - This was also briefly discussed before: when a > package upgrade (expecially. for libraries) introduces binary > incompatibility for dependent packages, we currently > don't have a way to make the user aware. In such cases, > should we upgrade also the dependent packages (by just > increasing release number)? Hard to say. I'm not sure what's the right solution WRT the the ideas behind CRUX' package manangement. Release change for binary incompatible is fine with me (as long as we have a good way to trigger this; e.g. the maintainer of a packages with dependent packages must inform the maintainers of the those). > Misc notes: > > I don't know for sure when the "build machine" will > be ready to use, probably sometime next week. > > I also have no idea how long a full compilation of > /contrib ports could take, if the port tree changes > "too fast" respect to compilation time > many benefits could be lost. > (and I could introduce a compile-by-request, > compile only changed ports, or similar tricks) > > If anyone has further suggestions or ideas, it would > be gladly accepted. If you did not consider it up to now I'd strongly recommend using ccache. Inbetween minor releases of packages (the software) or new releases of the port, the speed gain is really huge. Looking forward to this, Best regards, Johannes -- Johannes Winkelmann mailto:jw at tks6.net Biel, Switzerland http://jw.tks6.net From sip at varlock.com Mon Sep 29 16:57:25 2003 From: sip at varlock.com (Simone Rota) Date: Mon, 29 Sep 2003 18:57:25 +0200 Subject: [clc-devel] RFC: clc build machine In-Reply-To: <20030929161409.GB682@hoc.LDS> References: <20030929172945.369575f6.sip@varlock.com> <20030929161409.GB682@hoc.LDS> Message-ID: <20030929185725.6476f116.sip@varlock.com> On Mon, 29 Sep 2003 18:14:09 +0200 Johannes Winkelmann wrote: > Hi Simone, Hi Johannes, > While I love crux' package management, I fear it might become hairy once > binary packages are around; I'm certainly not afraid that you Simone > will run into problems (as you know what it's all about), but if Joe > User decides to check out crux and wants to install let's say evolution, > pkgadd evolution#$VERSION.tar.gz will "just work", while the program > won't. > I assume there could be scripts to handle this, but it might be hard to > forbid all users to use pkgadd directly. The joy of a system without > dependencies in built packages ;-) > So as a summary I think it's most important to communicate clearly that > "binary packages for crux" doesn't mean "RPM-like packages for crux". > I'm pretty sure we can reach this goal. I can see your point and agree that the users shoul be clearly informed that pkgadd wouldn't suffice for CLC binaries. Incidentally, this is still valid for /opt packages, for example. I thought of a prt-get switch or something similar: prt-get install `prt-get quickdep kdebase` --binary the --binary option would download packages into their dirs (or pkg_dir), then proceed as usual (the binaries are up-to-date and recompilation is not needed). PS: what about a "prt-get depinst portname" command that would automate the quickdep stuff? > > - A confirmation: did we establihsed that /opt > > ports should be listed as dependencies, didn't we? > Yes we did, even though this has probably not been implemented for a > large number of ports. So i must be prepared to see a long list of failed installations in the first log ;-) > > - This was also briefly discussed before: when a > > package upgrade (expecially. for libraries) introduces binary > > incompatibility for dependent packages, we currently > > don't have a way to make the user aware. In such cases, > > should we upgrade also the dependent packages (by just > > increasing release number)? > Hard to say. I'm not sure what's the right solution WRT the the ideas > behind CRUX' package manangement. Release change for binary > incompatible is fine with me (as long as we have a good way to trigger > this; e.g. the maintainer of a packages with dependent packages must > inform the maintainers of the those). Good, even if I'm not sure about the maintainer's responsability (he should have a clue about dependent packages, this could require some work; anyway prt-get dependent should help a lot). It'll be fine to hear from other maintainers too about the 'fake' upgrade issue. Problems arise when new libs are not declared as binary incompatible by their developers while in fact they are: I had some issue in the past with the fox toolkit: a minor upgrade to the lib broke some app. But it could just be that I'm extremely unlucky. > If you did not consider it up to now I'd strongly recommend using > ccache. Inbetween minor releases of packages (the software) or new > releases of the port, the speed gain is really huge. Unfortunately I had some issue with ccache in the past: some port (icewm, ruby if I remember well) failed to compile; disabling ccache solved the prblem. > Looking forward to this, > Best regards, Johannes Thank you very much for your reply, Regards, Simone From jaeger at morpheus.net Tue Sep 30 14:06:00 2003 From: jaeger at morpheus.net (Matt Housh) Date: Tue, 30 Sep 2003 09:06:00 -0500 Subject: [clc-devel] Re: [bug report] mplayer: remote buffer overflow vulnerability In-Reply-To: <20030928194404.18650.qmail@rfhpc8082.fh-regensburg.de> References: <20030928194404.18650.qmail@rfhpc8082.fh-regensburg.de> Message-ID: <3F798DC8.4000603@morpheus.net> clc-devel at berlios.de wrote: > Description: Hi, > I just noticed that mplayer 1.0pre1 (currenly in clc) > has a buffer overflow vulnerability - see http://www.mplayerhq.hu > for details. > A patch should be available at: > http://www.mplayerhq.hu/MPlayer/patches/vuln01-fix.diff > > Contact: sip at users.berlios.de > > User: sip > > http://crux.fh-regensburg.de/cgi-bin/cvstrac/tktview?tn=13 I fixed this, thanks for the bug report. I would have closed the ticket, too, but sip beat me to it. :) Matt (jaeger at freenode/#crux) From jw at tks6.net Tue Sep 30 14:22:47 2003 From: jw at tks6.net (Johannes Winkelmann) Date: Tue, 30 Sep 2003 16:22:47 +0200 Subject: [clc-devel] RFC: clc build machine In-Reply-To: <20030929185725.6476f116.sip@varlock.com> References: <20030929172945.369575f6.sip@varlock.com> <20030929161409.GB682@hoc.LDS> <20030929185725.6476f116.sip@varlock.com> Message-ID: <20030930142247.GA24346@hoc.LDS> Hi, On Mon, Sep 29, 2003 at 18:57:25 +0200, Simone Rota wrote: > On Mon, 29 Sep 2003 18:14:09 +0200 V> Johannes Winkelmann wrote: > > > Hi Simone, > > Hi Johannes, > > > While I love crux' package management, I fear it might become hairy once > > binary packages are around; I'm certainly not afraid that you Simone > > will run into problems (as you know what it's all about), but if Joe > > User decides to check out crux and wants to install let's say evolution, > > pkgadd evolution#$VERSION.tar.gz will "just work", while the program > > won't. > > I assume there could be scripts to handle this, but it might be hard to > > forbid all users to use pkgadd directly. The joy of a system without > > dependencies in built packages ;-) > > So as a summary I think it's most important to communicate clearly that > > "binary packages for crux" doesn't mean "RPM-like packages for crux". > > I'm pretty sure we can reach this goal. > > I can see your point and agree that the users shoul be clearly informed > that pkgadd wouldn't suffice for CLC binaries. Incidentally, this is > still valid for /opt packages, for example. > I thought of a prt-get switch or something similar: > > prt-get install `prt-get quickdep kdebase` --binary this will not prevent Joe from doing prt-get install evolution --binary which will work fine... so prt-get should in this case print a warning "dependencies not satisfied". This is a dependency _checking_, something I don't want to do as long as we have informal dependencies. I was thinking of a new tool (another tool for a different kind of job) codenamed bininst which downloads and installs the package, using either a dependency matrix as http://sto.f2o.org/crux/wiki/DependencesMatrix when there's no ports tree around (think: installation), or prt-get's quickdep. Something like: bininst [-d deps.matrix] -u http://clc.berlios.de/packages evolution bininst would do the following: for each package from the dependency list: download from server (-u; could be configured in bininst.conf) pkgadd || exit on error Of course this could be integrated in prt-get, but for now I'd like to get a feeling of this first and I think a dedicated tool might help to distinuish as binary install vs. ports tree install are quite different. I hope I'll find some time this week to write a small prototype. > PS: what about a "prt-get depinst portname" command > that would automate the quickdep stuff? It used to be there and I removed it as I was afraid that it could imply that dependencies were working. You know, people usually don't bother reading the man page or even the manual, and it would be kind of frustrating to get "bug reports" about prt-get failing to install a package. The current way moved the responsibility away from me to the Packager ;-). Anyway, I guess I'll reintroduce it in one of the future versions. Regards, Johannes [...] > > If you did not consider it up to now I'd strongly recommend using > > ccache. Inbetween minor releases of packages (the software) or new > > releases of the port, the speed gain is really huge. > > Unfortunately I had some issue with ccache in the past: some > port (icewm, ruby if I remember well) failed to compile; > disabling ccache solved the prblem. Same here, OTOH those are only a handful of packages, and when I build new packages (as user first, rebuild with removed docs, root built) then ccache saves me a lot of time. Regards, Johannes -- Johannes Winkelmann mailto:jw at tks6.net Biel, Switzerland http://jw.tks6.net From sip at varlock.com Tue Sep 30 15:24:49 2003 From: sip at varlock.com (Simone Rota) Date: Tue, 30 Sep 2003 17:24:49 +0200 Subject: [clc-devel] RFC: clc build machine In-Reply-To: <20030930142247.GA24346@hoc.LDS> References: <20030929172945.369575f6.sip@varlock.com> <20030929161409.GB682@hoc.LDS> <20030929185725.6476f116.sip@varlock.com> <20030930142247.GA24346@hoc.LDS> Message-ID: <20030930172449.7e90557c.sip@varlock.com> On Tue, 30 Sep 2003 16:22:47 +0200 Johannes Winkelmann wrote: > > I thought of a prt-get switch or something similar: > > > > prt-get install `prt-get quickdep kdebase` --binary > this will not prevent Joe from doing > prt-get install evolution --binary > which will work fine... so prt-get should in this case print a warning > "dependencies not satisfied". This is a dependency _checking_, something > I don't want to do as long as we have informal dependencies. I support your decision not to check for dependencies if the user didn't explicitly asked for the feature from the commandline. Anyway I think we're discussing a non-issue: a CRUX user *should* be aware that installing a package without its deps is something that doesn't work. It is true, as you pointed out, that a source install would immediately reveal the missing dep while a binary install would not. Personally it's something I can live with, since it's easy with prt-get and our 'unofficial' dependencies listings to handle potential problems. > I was thinking of a new tool (another tool for a different kind of job) > codenamed bininst which downloads and installs the package, using either > a dependency matrix [cut] > Of course this could be integrated in prt-get, but for now I'd like to > get a feeling of this first and I think a dedicated tool might help to > distinuish as binary install vs. ports tree install are quite different. > I hope I'll find some time this week to write a small prototype. That would be a great tool. Having it developed as a standalone util has its advantages; more than this, you could eventually wrap the tool from prt-get (as you do with pkgmk) in the future. I'd prefer to see the binary install feature integrated with prt-get and use prt-get as the all-in-one tool for package management on CRUX, but this is a matter of personal taste. There are pros/cons in both solutions, one of this is that the port tree is needed for binary installs if the feature is to be integrated in prt-get. On the other side, we'd have to maintain an extra dependencies chart and the user would at least need an 'external' file. Reasoning strictly from the user's point of view, I think a simple --binary switch in prt-get would be a simpler and "more understandable" solution. Ok, I'll stop my rantings about personal preferences, whatever solution you prefer it would be a great addition to CRUX (ps: thank you very much for your past, present and future work!) > > PS: what about a "prt-get depinst portname" command > > that would automate the quickdep stuff? > It used to be there and I removed it as I was afraid that it could imply > that dependencies were working. What?!? Don't they? :-) > You know, people usually don't bother > reading the man page or even the manual, I for one, since I missed the depinst command in previous releases (or maybe I inconsciously asked for a feature I saw at the time and was recently removed) > Anyway, I guess I'll reintroduce it in one of the future versions. great, I'll use a bash wrapper for the moment. [ccache] > Same here, OTOH those are only a handful of packages, and when I build > new packages (as user first, rebuild with removed docs, root built) then > ccache saves me a lot of time. True, not to count the dozens of Pkgfile adjustements I do before a release ;-). ccache is really a time-saver. > Regards, Johannes Best regards, Simone From Juergen.Daubert at t-online.de Tue Sep 30 16:09:30 2003 From: Juergen.Daubert at t-online.de (Juergen Daubert) Date: Tue, 30 Sep 2003 18:09:30 +0200 Subject: [clc-devel] RFC: clc build machine In-Reply-To: <20030929172945.369575f6.sip@varlock.com> References: <20030929172945.369575f6.sip@varlock.com> Message-ID: <20030930160930.GA174@jue.netz> On Mon, Sep 29, 2003 at 05:29:45PM +0200, Simone Rota wrote: [...] > - Provide binary packages. I asked for this some time ago; > while it's a bit premature to add this feature to CLC > (and maybe many users/packagers don't like the idea), > I will keep binary packages for personal use and eventually > upload them somewhere in the net, keeping them separate > from CLC. Why do we need binaries ? To spare the user from compiling the packages from source, to have a "complete" system up and running as fast as possible whithout any knowledge ? Are we going away from "experienced user" to mainstream distri ? Just my two cents ;) regards J?rgen -- juergen.daubert at t-online.de From sip at varlock.com Tue Sep 30 16:46:09 2003 From: sip at varlock.com (Simone Rota) Date: Tue, 30 Sep 2003 18:46:09 +0200 Subject: [clc-devel] RFC: clc build machine In-Reply-To: <20030930160930.GA174@jue.netz> References: <20030929172945.369575f6.sip@varlock.com> <20030930160930.GA174@jue.netz> Message-ID: <20030930184609.627290b9.sip@varlock.com> On Tue, 30 Sep 2003 18:09:30 +0200 Juergen.Daubert at t-online.de (Juergen Daubert) wrote: > On Mon, Sep 29, 2003 at 05:29:45PM +0200, Simone Rota wrote: > [...] > > - Provide binary packages. I asked for this some time ago; > > while it's a bit premature to add this feature to CLC > > (and maybe many users/packagers don't like the idea), > > I will keep binary packages for personal use and eventually > > upload them somewhere in the net, keeping them separate > > from CLC. > > Why do we need binaries ? To spare the user from compiling the > packages from source, to have a "complete" system up and running > as fast as possible whithout any knowledge ? Are we going away > from "experienced user" to mainstream distri ? Hi J?rgen, thanks for your reply. IMHO binary packages could be useful under certain circumstances: - First, They save a lot of time. For experienced users too ;-) - Machines without gcc: think of thin clients or production environments (or always-online machines: firewalls, servers...) where it's preferred not to have a build environment available for security reasons. - Quick setup of testing machines. - And so on... I understand that you could still not see any benefit of using binaries in the scenarios described above. What I don't completely understand is the binary<->no knowledge association. I don't think a newbie could actually learn something just by watching the output of pkgmk. CRUX has been for me a great way to learn something about Linux, but this is totally unrelated to the fact that it is a source-based distro. The fact that manual configuration is needed for everything you install is the key feature, and this has nothing to do with the way I installed the package. > Just my two cents ;) It's always good to hear different opinions; regarding binary packages I anticipated there would be "negative" reactions, that's why the project will be developed outside CLC. > regards > J?rgen Best regards, Simone