December 2004 - crux-devel

[clc-devel] CLC CVSTrac Notification
by Matt Housh 17 Dec '04

17 Dec '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today Johannes and I set up cvstrac to email maintainers when a ticket assigned to them is created or modified. If the ticket is assigned to 'anonymous' or blank the mail will go to the list. Hopefully this will make it easier to keep track of ticket entry, etc. If you want to filter these messages, the subject line starts with '[CLC Ticket Notification]' and they're sent from crux(a)morpheus.net. Matt (jaeger@freenode/#crux) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBwyzaGFVQ7mavvGgRAs0BAJ9YtpuQRiiC4jtC2HKYCkOi+WD6fACaA2px 5H/AfLmaCWcFyDDuJLWTZn4= =Sbm5 -----END PGP SIGNATURE-----

1 0

[clc-devel] alias support in prt-get
by Johannes Winkelmann 10 Dec '04

10 Dec '04

Hi, I've just uploaded a test version of prt-get (0.5.9-test2) to my personal httpup repo [1] which has support for "aliases", a concept we discussed at CRUXCon; the idea is that a package can have a number of aliases, which can be used to do dependency resolving. The most typical example is probably sendmail and its replacements; in this case, we'd alias all the other MTA's as being sendmail. It's sortof what other package management systems have with "virtual dependencies" or "provides", just adapted. The idea is not to look for generic terms for something and alias all others (think: 'windowmanager', 'browser' etc.) but for dependencies which can be provided by others. A second example is Java, where the Software Development Kit (SDK) provides a Java Runtime Environment (JRE) too. In the future, this infomation should live in the ports itself and be transferred to the package database, but until this is ready, prt-get reads /var/lib/pkg/aliases and gets its information there from. This file is currently really sparse, which is the main reason for this e-mail: I'd like to hear suggestions for possible aliases to include; please send it to the list so we can have a little discussion if needed. What's currently there is the following: <quote> postfix: sendmail j2sdk: j2re </quote> This is also the first step to resolve the issues we have with Java right now; stay tuned for more :-). A few examples from prt-get: $ prt-get depends firefox-java-plugin -- dependencies ([i] = installed) [i] j2re (provided by j2sdk) [...] [i] firefox [i] firefox-java-plugin $ prt-get isinst j2re j2re is provided by package j2sdk $ A possible downside is that there's no way to force prt-get to install j2re if you have j2sdk installed. IMO this is even better this way, but it might not always be wanted; I'm thinking about a --noalias switch to disable alias considerations completely, but I want to give that some thought (and probably wait until someone really wants this). So, as mentioned before, I'd like to hear additions to my "aliases" list. Kind regards, Johannes References: 1. http://jw.tks6.net/files/crux/ports#prt-get -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net

5 9

[clc-devel] CRUX mascot?
by Simone Rota 10 Dec '04

10 Dec '04

Hi there, I know this isn't exactly a top priority, but what about having our own mascot? I was thinking of a moose* such as (merely for giving an idea): http://www.varlock.com/images/moose01.jpg or http://www.varlock.com/images/moose02.jpg but in SVG format and painted with a style close to the gimp's wilber: http://www.varlock.com/images/wilber.png I have a couple of friends that are very good artists and would be happy (I hope!) to contribute. What do you think about the idea? Regards, Simone * I've heard they live in Sweden, even if I didn't see any in Stockholm Center :) -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip(a)varlock.com

6 12

[clc-devel] libgsf name change:
by Nick Steeves 07 Dec '04

07 Dec '04

It's been over two weeks since I opened ticket #37. I still haven't heard back from Jaeger. The impact of the name change of libgsf, to gnome-libgsf is minimal. Affected ports are: contrib/librsvg maol/gnome pazo/planner The slim version of libgsf only depends on glib, and libxml2; and is far more appropriate as a dependency of libwv2. The only issue I can think of, is that of a user who decides to rebuild all installed ports. His current libgsf would be replaced by the new/basic libgsf, which might cause other GNOME packages to fail. I would imagine that a user who would rebuild their system "for the fun of it" or "for new optimizations" would also be knowledgeable enough to post a ticket or message to the mailing list? He would then be made aware of the change to gnome-libgsf. Can I go ahead and: 1. cp libgsf to gnome-libgsf 2. commit my basic libgsf 3. email maol and pazo to tell them about the changes ?? Nick

3 3

[clc-devel] Python 2.4
by Juergen Daubert 07 Dec '04

07 Dec '04

Hi all, as you might have already noticed, Python 2.4 is out. It's nice that things are going onwards, with the drawback that we have a lot of work with such a change, because most of the dependent ports will break. I don't have a clear position how we should deal with such a situation. The python dependent ports, maintained by me, works well after rebuilding, but some will probably not, e.g. bittorent-curses. ok, what can we do ? 1. commit python 2.4 now, fixing all dependent ports 2. wait for CRUX 2.1 3. ... I tend to go with 1. To prepare this, I've added a python 2.4 port to my private repo [1]. What do you think ? thanks for your attention and kind regards Jürgen [1] http://jue.li/crux/ports/#python -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux

6 8

[clc-devel] The question of maintainer protocol
by Nick Steeves 07 Dec '04

07 Dec '04

Hi, Recently I've had quite a time trying to figure out how a CLC member should submit fixes to another maintainer. Documentation on CLC's CVS conduct is conspicuously missing. We should write, or reference a document of procedural guidelines. I would appreciate if everyone would comment on Ticket #38. Thanks, Nick

3 4