Hi,
Here's a short summary of yesterday's meeting; unfortunately, clb
couldn't join us, so I've attached the log. Here's a list of things we
discussed (see http://crux.nu/Wiki/MeetingAgenda for more details):
1. ld.so.conf.d (Flyspray #253)
- starting with CRUX 2.5, we'll have an "include
/etc/ld.so.conf.d/*.conf" line in ld.so.conf, to allow ports to add
files there, this should save some issues/post-install scripts. The
bug report has the full details, including a patch
Action points: merge patch, update handbook
2. Format of .arch files
- we agreed that users should look at dot files, these are for tools; so
my idea to add the "# Arch maintainer" to .arch files doesn't make
sense
Action points: merge Lucas' pkgmk changes
2.1 "Arch maintainer vs. maintainer confusion"
- treach mentions that it will be potentially confusing to users to have
both a "maintainer: " and "arch maintainer: " line in Pkgfiles; we
should discuss this further, I think it's an valid concern
Action point: further discussion needed
3. Bug tracking
- avoid having bugs in "New" state; we want to use that one to determine
which bugs are really new; there's an "Unconfirmed" state to express
you've seen a but, but you're not yet working on it. Once we discuss
it on the ML or IRC, we should go ahead an mark it "Unconfirmed" or
"Assigned"; even more so if we comment on a bug
- assign as many bugs as possible to the right persons
Action point: These are two things everyone can help with
4. "real" IRC meetings
- we want to start with regular IRC meetings, which are more formal that
the casual ones; the main difference is that crucial decision should
be scheduled for these meetings
- I suggest we call it "project meeting", as opposed to "casual
meeting"; other suggestions are highly welcome!
- I'd suggest we do them monthly, to allow everyone to plan in advance;
maybe the first tuesday per month?
- This is just a personal distinction, but I'd for example postpone a
BBQ with friends for one of the "real" meetings but not the casual
ones
Action point: define date and frequency
5. the name "causual developer's IRC meeting" will be kept
6. "notify" hook for contrib
- we've suggested to add a post-commit (actually 'update') hook to the
contrib repo to send out "notify" mails; Jose has brought this up on
the contrib mailing list
Action point: unless there are objections from the contrib crew we'll
add such a hook
7. mailing list for reports
- the mailing list for prtverify and source check will be called
crux-reports unless there's any complaints :-)
Action point: I'll create that list later this week unless someone can
come up with a better name :-)
Finally, we consider moving the starting time to 20:00 CEST, for three
reasons:
- 18:00 is pretty early
- 18:00-23:00 is just too long to keep it efficient
- the attendees of the two meetings we had so far could typically attend
after 20:00
Please comment :-).
Cheers, Johannes
--
Johannes Winkelmann mailto:jw@smts.ch
Zurich, Switzerland http://jw.smts.ch
Hi,
Since the meeting stuff is pretty new, here's a reminder for tonight's
casual meeting. If you have the time and feel like it, please drop by.
Time: 18:00 - 23:00 CEST
Place: #crux-devel on freenode
Here's a short list of items to discuss:
- http://crux.nu/Wiki/MeetingAgenda
- going through new and unassigned bugs
Looking forward to seeing many of you there.
Cheers, Johannes
--
Johannes Winkelmann mailto:jw@smts.ch
Zurich, Switzerland http://jw.smts.ch
Hi there,
Just a quick summary of yesterday's meeting:
Tilman suggested to do a 2.5 release soonish, pushing new versions of
glibc and gcc (and also perl IIRC); the gcc 4.3 update will introduce a
couple of compile failures, many of them can easily be solved (we should
probably prepare some notes with the typical errors). There are a couple
of open tasks in Flyspray due to 2.5, we can probably talk about these
some other time.
We agreed that we want to move the daily source and ports checks to a
dedicated mailing list; I'll look into that and follow up on this once
it's done
The "Public Wiki" was renamed to "Wiki". Next time, we can probably go
through the content and move more stuff from the current homepage to the
wiki area; for example we thought about only having "Handbook" and "Faq"
in the navigation, and move the rest from "Documentation"
Also, we've quickly talked about handling standard situations (new
maintainer, maintainer leaving etc.), and to document the workflow
better; as a short hand task, we want to introduce a script to change
the maintainer field of a list of ports to a magic label, which can then
be used to identify such ports easily, and to optinally remove them
automatically if they've been unmaintained for a certain period of time.
The script to do that should be fairly simple, if someone wants to look
into that please let us know, otherwise we can revive our TaskList.
We also went through the list of open bugs, talking mainly about some
pkgutils bugs/requests.
I had the feeling that the meeting was quite effective, especially since
we also got some actual work done. I think that if we can do this on a
regular base, we can avoid a backlog of changes and/or bug reports to
answer, which is probably in the interest of everyone :-).
That said, next meeting is tuesday next week. Hope to see you there.
Regards, Johannes
P.S. Sorry for the later reminder
--
Johannes Winkelmann mailto:jw@smts.ch
Zurich, Switzerland http://jw.smts.ch
I'm putting together some multilib ports in the style that has been
suggested for the upcoming 64 bit test run. An issue unique to
multilib, compared to pure 64 bit, is that two different sets of
libraries exist on the same system. This also means that there are a
different set of options required for each one to be used by pkgmk.
http://git.die.net.au/cgit/crux/ports/core/tree/pkgutils/x86_64/pkgmk.conf?…
This is the solution Daniel came up with when he first released the
original CRUX64 several years ago. While not ideal, it's a necessary
evil when dealing with multilib.
The issue is that pkgutils requires the port to identify itself as a
compat32 port. The method I'm using currently is to use a .arch file in
the port.
http://git.die.net.au/cgit/crux/tools/pkgutils/commit/?id=e31dab6d68b26811e…
This differs from Daniels original implementation which was to put it
into the Pkgfile using arch=compat32. However, I believe that keeping
it out of the Pkgfile is a much better solution.
Using such a method also has it's advantages in cross compiling for
people who want to build ports for alternative architectures that don't
have the resources to build natively, such as embedded platforms.
I'm just wondering if anyone else had anything to contribute to the
idea, or alternative solutions before I go too far and have another set
of ports that isn't going to be incompatible with CRUX.
--
Lucas Hazel <lucas(a)die.net.au>
