- crux-devel - lists.crux.nu

[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

[clc-devel] Software licenses
by Jukka Heino 22 Nov '04

22 Nov '04

Hi, Now that Simone Rota has committed his datastudio port into contrib, I began to wonder if CLC has some sort of policy on what software licenses should be allowed in contrib. At least one user was concerned that he might accidentally install software which would require a commercial license for the purpose he's using it for. I, for one, would find something like a "License" field in Pkgfiles useful so that with a quick glance one could see under which terms the software is released (GPL, BSD...). What do others think? Regards, // Jukka

6 5

[clc-devel] RFC: Commit message guideline
by Johannes Winkelmann 20 Nov '04

20 Nov '04

Hi, You might have seen the discussion on labeling security related updates; Jürgen and I have also create a CVSTrac report which looks for the word 'security' in the commit message and lists those [1]. I'd like to suggest the following format for such changes: [security] <portname>: <text> <url> url should point to the advisory or vulnerability decription. Example: "[security] gdk-pixbuf: security update http://www.mandrakesoft.com/security/advisories?name=MDKSA-2004:095" This way, they should be easy to spot in the timeline and reliable to find using our report. How does this sound? We might also do something similar if we have to do a binary incompatible change inbetween releases, but I guess we can discuss this later. Kind regards, Johannes 1 http://clc.morpheus.net:6999/clc/rptview?rn=11 -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net

1 0

[clc-devel] Re: Check-in [703]: fam
by Daniel Mueller 19 Nov '04

19 Nov '04

Hi Nick, thank you for updating the port. Yes, I think that's the proper way to do things. To conclude your rule --> If you know that the maintainer is currently on vacation or you've made an very important security update continue and tag it immediately. This rule is written nowhere, but I think it's a good idea ;-) Again, thank you. danm -- Daniel Mueller Berlin, Germany (OpenPGP: 1024D/E4F4383A) On Thu, 18 Nov 2004 04:34:57 -0700 Nick Steeves wrote: > Hi Daniel, > > Debian updated their patch to v6. I commited a change accordingly, > and am awaiting your approval, via tagging it for CONTRIB-2_0. Is > this the standard protocol within CLC? > > Cheers, > Nick > >

1 0

[clc-devel] Script to find redundant dependencies
by Johannes Winkelmann 19 Nov '04

19 Nov '04

Hi, I finally found a moment to finish my script to find redundant dependencies, that is such which are listed by a direct dependency of a package, like: A lists B and C, B lists C In this case, A doesn't have to list C, so the listing of 'C' is redundant. I've done some tests with ports from contrib and it seems to work fine so far, but I'd still advise you to manually double check whether what it says is true (e.g. by doing a 'prt-get depends' before and after removing the packages listed as redundant). You can find it at http://jw.tks6.net/files/crux/findredundantdeps Kind regards, Johannes P.S.: yeah, the name sucks -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net

2 1

[clc-devel] Re: contrib preparation scripts
by Jay Dolan 19 Nov '04

19 Nov '04

--- Johannes Winkelmann <jw(a)tks6.net> wrote: > Hi Jay, > > I've been pretty busy lately and didn't manage to > join IRC yesterday. So > I'll just guess and send you my scripts to prepare a > big repository of > ports (PrepRep). I commented out certain lines from > preprep.conf, since > I guess they're not all the same right now (jue > moved his repo), and one > of them was a local one to simulate clashes between > ports. > > I guess it might be a good idea to start from > scratch, and I guess > python or perl would be the weapon of choice as we > already discussed at > CRUXCon. Since bash scripts are usually rather > verbose and not too clear > to understand what's going on, here a summary of > what I'd expect it do > do: > > 1. sync a list of repositories to an input directory > - note if a repo can't be synced > 2. Create a list of ports 'contribports' > 2. Find duplicates in 'contribports', and where they > appear > -> send notifications to the crux-contrib mailing > list > -> remove those from 'contribports' > 3. create a list of ports in base and opt > ('coreports') > 4. remove 'coreports' from 'contribports' > // 'contribports' contains now a list of ports > which can be updated in > // the main collection > 5. if a list of 'contribports' which have been > synced the last time is > available, compare the two lists > - note which ports are new, and which one have > gone > 6. update the ports listed in 'contribports' from > the input directory to > the output directory > - create a list of ports that were synced in this > run (to be used the > next time (5.) is called > 7. Mark the ports which are not maintained anymore > (from 6.) as > '# Maintainer: UNMAINTAINED' > 9. Create a new httpup REPO file > (maybe run portspage from vektori) > A. Send a report to the contrib-admin or > crux-contrib, containing: > a) new ports > b) ports newly unmaintained > c) repos that couldn't be synced (from 1.) > B. Send a notification to maintainers who have > conflicting ports > C. Send a notification to maintainers of > repositories which couldn't be > synced (from 1.) > > This is just from the top of my head, so consider > this just a > description what I was trying (or wanting) to do. > Finally, it would be > great if the script would run hourly, but it would > really be a PITA if > people would get notifications hourly; so there > needs to be some kind of > management when the people where notified. > > Reading through this, it seems that this is quite an > interesting task, > but definitely challenging. Actually I'd really like > to do some coding > on this as well, but probably not before mid > december :-/. Maybe you > could ask Matt to set up a CVS (or Subversion) > repository for that. > > Feel free to ask if I don't make any sense! > > So much for now, > Kind regards, Johannes I miss you already. I took my own stab at this (considering that you forgot to actually attach your scripts ;)), and ended up settling on bash :/ The more I thought about it, the more it seemed appropriate. Tools like find and fgrep can be used for just about all of the complicated parts of this task. So take a look at prtsync in my httpup repository, if you will. It works well, is less than 80 lines, and does almost all of what you mentioned in your last mail. I think it would be fine to run just nightly. The ugliest part is actually the call to sendmail. Sweet dreams, I'm spent.. ===== Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

1 0

[clc-devel] Fw: CLC maintainer ?
by Daniel Mueller 31 Oct '04

31 Oct '04

Hi, some time ago I've asked Nick Steevens whether he would like to become a CLC maintainer and join our team. He has a bunch of nice ports located here: http://members.shaw.ca/nick.steeves/ports/index.html The main reason why I've wrote him was that he could be a big help with KDE packages/ports (maybe he could overtake it completely..). He sent me a lot of patches and suggestions so far and I adopted nearly all of them. I'd like to see Nick in our team. You can find some information about him on his webpage: http://members.shaw.ca/nick.steeves Needless to say that I vote for his CLC membership :) bye, danm -- Daniel Mueller Berlin, Germany (OpenPGP: 1024D/E4F4383A) Begin forwarded message: Date: Fri, 15 Oct 2004 23:30:32 -0600 From: Nick Steeves <nick.steeves(a)shaw.ca> To: Daniel Mueller <danm(a)gmx.li> Subject: Re: CLC maintainer ? Hi Daniel, Well, my old Athlon motherboard finally died. A bit of debt later, and now I have a modern system. (Intel D865PERLX, P4 C 2.8ghz, 512MB PC400) Needless to say, it is a very fast system--and makes the debt worth it. :-) The reason that this is significant, is that I think that I can build KDE in 3 hours now. So I can get my initial build onto my system, test it, modify it for package standards, verify, publish...that much faster. Due to this phenomenal speed increase, predicted time for turning out a solid KDE release is six hours, rather then 18-20. To sum things up: do to two unfortunate circumstances (hardware failure and debt) I now have the time necessary to be able to commit to a development position within the CLC! My biographical information can be found at: http://members.shaw.ca/nick.steeves under the "about me" section. KDE-3.3.1 should be ready by Fri 15 Oct 2004 09:00. Unfortunately, I haven't had the chance to gain any CVS experience yet. Sincerely, Nick PS: I've already subscribed to CLC-devel. As you are opting me in, I would appreciate if you would forward this email to the appropriate mailing list. On September 22, 2004 9:28, you wrote: > Hi Nick, > > I've seen a lot of your ports and they (mostly ;-) fit to our CLC > port rules. Would you be interested to become a CLC maintainer ? > > I'd be happy to get some more help with KDE. > > bye, danm > > [1] http://clc.morpheus.net:6999/clc/wiki?p=MaintainerGuidelines

5 5

[clc-devel] questions about Gnome
by Tilo Riemer 29 Oct '04

29 Oct '04

Hello, I just installed and configured Gnome. Almost all gone without problems thanks to the very cool prt-get :-) But I have still some questions: -I can't find the system applet showing cpu load etc. -I can't start the esd because I don't know which device is the right sound device. /dev/snd/pc* does not work. -other questions I can't remember yet ;-) Best regards, Tilo -- Tilo Riemer mailto:riemer@lincvs.org Dresden, Germany http://www.lincvs.org http://www.iapp.de/~riemer/projects

1 0