Hey guys,
I'm starting a more complete FAQ for the clc. Ya'll can check out the
work in progress at http://tito.homelinux.org/fileserver/faq.html.
My question is: What are some FAQs? I'm working on it but figured that
should ask anyway.
Jonathan Asghar
--- Nick Steeves <Nick.Steeves(a)shaw.ca> wrote:
> Hi Jay,
>
> Under the sync section of the prtsync manpage, the
> email format is specified
> as: EMAIL=user(a)provider.net. It should read:
> EMAIL=user at provider dot
> net, according to those port guideline changes from
> earlier this spring.
> Here's a bit of code to show what I mean:
>
> Line 80
> - email=`fgrep "EMAIL=" $driver | sed "s/EMAIL=//"`
> + email=`fgrep "EMAIL=" $driver | sed -e
> "s/EMAIL=//" -e "s/ at /@/"
> + # is there a better way to guarantee $? is 0?
> + test 1=1
> + # how should one deal with an unpredictable # of
> "dot"?
> + while [ $? -eq 0 ]; do
> + email=`echo $email | sed "s| dot |.|"`
> + echo $email | grep " dot " > /dev/null
> +done
> url=`fgrep "URL=" $driver | sed "s/URL=//"`
> Line 83
>
>
> Cheers,
> Nick
>
Hi Nick,
The EMAIL directive is not required by httpup(8) or
ports(8). It's an extension used only by prtsync,
only on the CLC server. As this address is never
publicly viewed over the web (unlike Pkgfiles), I
think leaving it unobscured is perfectly fine.
However, if others think it'd be a nice feature, I'll
add support for it. I guess people could start
supplying EMAIL in their .httpup files, aleviating
some of the prtsync maintenance, as I currently add
this by hand *g*.
Perhaps a slightly cleaner patch:
email=`fgrep "EMAIL=" $driver | sed 's|EMAIL=||; s| at
|@|; s| dot |\.|'`
This would actually allow either address syntax.
Thanks for poking into this :)
Jay Dolan
Software Engineer, Systems Analyst
Windmill Cycles, Inc.
508.999.4000
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--- Johannes Winkelmann <jw(a)tks6.net> wrote:
> First off all, I think we haven't managed to discuss
> all the items
> mentioned on the wiki page, but mainly because the
> hosting situation is
> not clear at all (on which many of the other tasks
> depend). Multiple
> efforts so resolve this are ongoing, or will start
> this week.
I should have a definite answer this week from UMass
Dartmouth, as to whether or not they'll host us.
> The new contrib collection is online, and as you've
> probably read public
> testing should start soon, certainly within this
> week.
HttpUp maintainers interested in participating, please
email me your .httpup driver files from the email
address you wish to receive clc-contrib@ notifications
at. Also, be sure to tag your ports with .sync files.
> The 'alias' discussion was not really extensive, but
> I guess we'll just
> introduce it and see how it feels, since it's
> completely restricted to
> prt-get at the moment. I plan to make a new release
> of prt-get later
> this week, or next weekend, incorporating the list
> of aliases.
Yay :) Can we review the list of aliases before this
release?
> Jukka has provided lists of ports with broken
> sources, and broken
> dependencies (deps which are not in contrib):
>
http://clc.morpheus.net:6999/clc/wiki?p=BrokenSources
>
> http://clc.morpheus.net:6999/clc/wiki?p=MissingPorts
> I you haven't done so, please check those two lists.
I'll be adopting netpbm, and have indicated so on the
MissingPorts list. If others would do so as well, we
can avoid working to replace the same ports twice.
> Till Biedermann has given us an update on his work
> on a new port
> database, which will be fully integrated in the
> wiki.
Sweet.
> Finally, as a general impression, I liked the fact
> that it was a focused
> meeting and opportunity to discuss issues with
> multiple members of CLC.
> On the other hand, it was a bit long (three days)
> and we had too many
> items listed to discuss (well, we have many
> outstanding issues, but
> still).
>
> I'd like to hear different opinions, but in general,
> I'd consider it a
> good idea to do something like this more regularly,
> say once per month,
> and maybe "just" two days.
>
Yea, that sounds reasonable. Even every-other-month
would be an improvement, and is perhaps a bit more
reasonable.
Jay Dolan
Software Engineer, Systems Analyst
Windmill Cycles, Inc.
508.999.4000
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
Hi,
This is mainly meant for Per and CLC maintainers, but in no way private:
Let's see whether this "bug day" is a good thing: the idea is to focus
on some more or less burning issues and discuss them in a separate IRC
channel (we can always talk about our daily life in #archlinux ;-)).
I added the items from the "roadmap" mail to a wiki page, online at
http://clc.morpheus.net:6999/clc/wiki?p=BugDayTm
Please add/adjust this page at will.
If you feel like discussing about those and other issues, please join
#crux-bugday, from now until saturday.
Kind regards, Johannes
--
Johannes Winkelmann mailto:jw@tks6.net
Bern, Switzerland http://jw.tks6.net
Hi,
The new contrib collection is entering its real testing phase, thanks to
Jay's work setting it up this weekend. I'd like to start public testing
really soon now, and I've gone over the rules document to make sure
participants understand the goals and consequences thereof. I'd
appreciate if those interested of you could read through it, ask
questions, make changes, fix typos etc.
It's the first part on
http://clc.morpheus.net:6999/clc/wiki?p=NewContribRules
(the second part was the original doc).
As soon as this document is in an okay shape, I'd suggest we start the
public testing. I think we should have another meeting _after_ the test
phase (or after a while of testing) with both users, non-clc
participants und us to see whether our idea is good or not.
Thanks for your help,
Regards Johannes
--
Johannes Winkelmann mailto:jw@tks6.net
Bern, Switzerland http://jw.tks6.net
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings, all.
I'd like to start some discussion about explicitly setting sysconfdir
(or confdir or whatever the package uses) back to /etc instead of
letting the default prefix decide it. I'd love to hear what everyone
thinks of this because it's causing me and jdolan at least a few issues.
Here's the problem: XDG-compliant apps (freedesktop.org XDG stuff) look
for XDG_DATA_DIRS and XDG_CONFIG_DIRS (and possibly XDG_DATA_HOME and
XDG_CONFIG_HOME) in the environment and try to use those if they exist.
If they do not, /etc/xdg and /usr/share are the defaults. While this
doesn't sound like a problem from that small description, graveman and
gnome-menus both behave badly under certain circumstances due to these.
gnome-menus first: gnome-menus expects to use XDG_CONFIG_DIRS for its
menu population. If the environment variables are NOT set, the default
/etc/xdg is assumed and you won't see any custom menus or most of the
default editable entries in gnome. If the environment variables ARE set,
the menus appear correctly. But then graveman doesn't work.
graveman uses XDG_DATA_DIRS for its themes/icons/whatever. That would be
fine except that there seems to be a bug (posted but not yet
acknowledged) in how graveman searches for these files. The port
installs files in /usr/share/graveman. If the env vars are not set,
these are found. If they ARE set, XDG_DATA_DIRS will be /usr/share but
graveman for some reason adds the config file name to that as a
directory and goes from there. So you see something like this:
stat64("/usr/share/graveman/graveman.conf/themes/default/Menu-Other-48.png",
0xbfffe8a0) = -1 ENOENT (No such file or directory)
It's appending "graveman.conf" to an otherwise correct
XDG_DATA_DIRS+graveman location. Symlinking graveman.conf to . in
/usr/share/graveman will work around this but that's ugly as hell, IMO.
Openbox also uses these but it doesn't seem to care whether its XDG
configs are in /usr/etc/xdg or /etc/xdg. HOWEVER, if they are in one and
the env var is set to the other, menus fail to work as might be expected.
So here's what I'm getting at: Why do we use /usr/etc? Is it simply
because that's the default when --prefix=/usr is used? If so, does
anyone object to setting --sysconfdir=/etc for those apps which honor
it? This isn't really a lot of apps, it seems mostly gnome stuff.
However, pango and gtk2 at least are included:
jaeger::charon::/usr/etc => ls
bonobo-activation gnome-lite gnopernicus-1.0 pear.conf
esd.conf gnome-vfs-2.0 gtk-2.0 sound
gconf gnome-vfs-mime-magic pango xdg
pear, esound, pango, gtk appear to be affected but this is still a very
small list.
I can understand not wanting to put things in /etc that aren't vital to
the running of the system but on the other hand, things are starting to
fail in weird ways the more apps I install (graveman today was what
really brought this to my attention, though). While it seems we can
force some things to use /usr/etc/xdg instead of /etc/xdg, others just
flat-out don't support a non-default location correctly, from what I'm
seeing.
Thoughts?
- --
Matt Housh (jaeger@freenode/#crux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCe4jnGFVQ7mavvGgRAo6nAJ9Mo9I5asQnepwu4i+OiZPpuLCXSwCfQqsp
DNUfai8k/abGfnIL3hSopxk=
=cS43
-----END PGP SIGNATURE-----
--- Juergen Daubert <jue(a)jue.li> wrote:
> Sorry, but I guess, that you everything-into-/etc
> guys read over one
> important point of Nick's mail:
>
> <quote>
> Also, /etc is usually protected because that is
> /etc/pkgadd.conf's
> default. /usr/etc is usually overwritten with each
> release, which
> insures that the upgrade works out of the box.
> Isn't the latter
> preferable to the support nightmare of persistent
> configuration files
> which might be incompatible in some way with the
> upgraded API?
> </quote>
>
> That's at least important for progs like gtk, sane,
> mutt, nail etc.,
> the settings are important for the applications, but
> the user shouldn't
> ever touch them and they _must_ be overwritten with
> new releases.
>
> kind regards
> Juergen
>
>
I agree. While I expressed distress with
xdg/gnome-menus problems, I do not feel that /etc is
the proper place for all package configurations. In
fact, I'd like to see more ports make use of /usr/etc,
as things like gdm, cups, and ssh end up requiring
lots of rejmerg attention. /etc should be reserved
for very essential, and rather static, system config
files. *If* a user ends up having to edit something
in /usr/etc, he/she should know well enough to make an
addition for it in /etc/pkgadd.conf if he/she so desires.
Jay Dolan
Software Engineer, Systems Analyst
Windmill Cycles, Inc.
508.999.4000
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
Hi,
I think it's time that we try to come up with a roadmap for the time
ahead. There are numerous thing which have been prepared and should be
finalized sometimes in the future. The most important ones that come to
mind are:
1. New server
2. Structure of the CRUX/CLC project
3. Webpage move/merge (new ports db); things currently missing
4. Short revision control tool discussion (also WRT multiple archs)
5. CVS merge contrib -> opt; core group
6. New contrib collection
Less pressing, but also important:
- mailing list concept
- Introducing subprojects
- recruit contributors for subprojects
- webpage
- ports
- tools (self developed stuff)
- docs
- installer ?
- Better responsibilities (kinda goes hand in hand with subprojects)
- non-x86 arch handling
I added "better responsibilities" since there are certain things which
should IMO be defined; e.g. I updated the httpup repos to 2.1, or
created the CVS branch for 2.0; both just because I felt it should be
done now, and no one else had done it so far (and in the case of httpup
people started to wonder...). I don't mind doing those things (also in
the future), but I think having a person explicitely in charge would
give at least me a better feeling.
I'm not sure whether we should organize some IRC/Skype/whatever-meeting
or discuss this in the mailing list, but I feel that we should just do
it sometimes soon, since there are people actively working on some of
these things and I feel bad myself about not providing them more help.
So if you have a moment, please take the time to think about the above,
and how/whether you'd like to discuss this. Comments appreciated, but
not required :-).
Kind regards, Johannes
--
Johannes Winkelmann mailto:jw@tks6.net
Bern, Switzerland http://jw.tks6.net
--- Simone Rota <sip(a)varlock.com> wrote:
> You hope. You've been selected to attend all 3 days
> of the
> meeting (72 hrs) and *manually* log the chat
> sessions
> by typing into a text editor.
> Copy & paste cheating not allowed.
>
> Have fun!
> Simone
>
:[ I suppose I deserve this, for making you guys put
up with me.. *cracks knuckles* let's get started,
then..
;)
Jay Dolan
Software Engineer, Systems Analyst
Windmill Cycles, Inc.
508.999.4000
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
--- Johannes Winkelmann <jw(a)tks6.net> wrote:
> I'd suggest we do a "bug squishing day" inspired by
> debian and others,
> where we all meet in a special IRC room (#crux-bugs)
> to discuss things
> like adapting ports from former maintainers, webpage
> move and similar
> issues. We might also go for a whole weekend to make
> sure everyone has
> the chance to drop by once.
>
> What about next weekend (either Tue-Fri-Sat, or
> Fri-Sat-Sun)? Would that
> work for you guys?
>
Sure. I can set aside at least a few hours next weekend.
Jay Dolan
Software Engineer, Systems Analyst
Windmill Cycles, Inc.
508.999.4000
Discover Yahoo!
Have fun online with music videos, cool games, IM and more. Check it out!
http://discover.yahoo.com/online.html
