Port: /home/crux/svn-to-rsync-working-copy/crux-2.2/core/shadow
Url: ftp://ftp.pld.org.pl/software/shadow/shadow-4.0.15.tar.bz2
Reason: curl: (19) Given file does not exist
State: New
Port: /home/crux/svn-to-rsync-working-copy/crux-2.2/opt/lftp
Url: http://ftp.yars.free.net/lftp/lftp-3.4.7.tar.bz2
Reason: curl: (7) couldn't connect to host
State: New
Full report: http://crux.nu/files/check_urls.html
On Mon, 29 May 2006 22:18:20 +0200
Mark Rosenstand <mark(a)borkware.net> wrote:
> -------- Forwarded Message --------
> From: Johannes Winkelmann <jw(a)smts.ch>
> To: crux-devel(a)lists.crux.nu
> Subject: [crux-devel] meeting notes & next IRC Meeting
> Date: Mon, 29 May 2006 09:16:22 +0200
>
> Hi there,
>
> This is a quick notification to let you know about last friday's
> meeting, and the upcoming one next wednesday (may 31).
>
> Last friday, we mainly discussed issues around 2.3 and random ideas
> that came up. Here's a brief summary:
>
> - We'll try to push out 2.3 later this year (Q3/Q4) if possible; it'll
> include at least the following:
> - Xorg 7.1
> - gcc 4.1.x (note that I'd consider it safe to update gcc via ports
> during the 2.2 cycle, but that's up for discussion)
> - glibc 2.4
>
> - Extend setup to handle modular X; one idea which was discussed and
> considered viable was to do grouping, such that one could first select
> the core group, the xorg group, and the [name to be found; remaining
> packages from opt] group
>
> - The idea of dependency handling during 'setup' was brought up, but
> not discussed in detail yet [personal remark: easier with
> dependencies in packages]
> - some devs would like to see easier update procedures, to
> avoid the CD boot/reboot for updates; not discussed in detail
> either, though interesting and definitely wanted by many
>
> - We'll review Matt's ISO scripts and merge them into the svn Makefile
> where appropriate
>
> - Cleaning up the package selection; we want to do that, but didn't
> decide which packages should go or be replaced
>
> - We'll start the public wiki section as soon as we find a volunteer to
> look after it (i.e. check the entries from time to time for spam or
> unwanted stuff).
>
> - we'll set up ck4up on crux.nu to check core ports; jue has kindly
> provided a special version and a configuration file
>
>
> In addition, danm proposed the following three feature additions, noting
> that we claim to utilize on using recent libs and tools:
>
> 1. move /etc/rc.d/net to iproute2
> The consensus here was that we'll move /etc/rc.d/net to iproute2 for
> 2.3 but keep shipping net-tools
>
If iproute2 is smaller/simpler/better in some way to ifconfig, then I'm all
for it.
> 2. use PAM
> This has to be investigated, it's a tough balance between features and
> simplicity; integrating CRUX into certain infrastructures can be
> rather hard without PAM, and the transition seems painful. We need to
> evaluate the impact of this before deciding
>
I think we're better off without it, CRUX is, after all, a distribution following
the KISS way of life, so complexity like this seems wrong. I would probably end up
modifying half of core/opt/contrib to kill PAM from my system and I think others who
enjoy the simplicity of CRUX would probably get annoyed by PAM. I vote that PAM stays
out of CRUX.
> 3. install info pages
> This wasn't all that controversal as it might seem :-). In general, we
> agree that info pages contain important information at times, and we
> have to admit that several users would like to have them; we also
> agree that some consider them junk :-). We to slightly change our
> position on this, such that:
> - we move texinfo to core and require maintainers to have it installed
> (since some packages conditionally install the info pages only if
> texinfo is there)
> - we require that packages install their info pages
> - we extend pkgadd to support hooks such as:
> INSTALL ^usr/info/.*$ NO
>
> Whether 'NO' or 'YES' will be the default here is to be decided, but
> taking this route makes our packages more flexible without sacrificing
> a lot. As a personal remark, the same rule should IMO be used for
> desktop files and icons, i.e. install in general, allow rejection via
> pkgadd.conf.
> If/When we do this, we'll have to (re-)define 'junk' though; some
> might say that this way, we could just as well install /usr/share/doc
> and reject it by default, or even translations. Prepare some arguments
> :-)
>
>
I'm all for this, since some programs (e.g gcc) only document some really good
information in their info pages and I'd like to have that on hand if I wanted to
read over it.
> As a result, we've started a todo list in the wiki:
> http://crux.nu/Main/ToDo
>
> The next IRC meeting will be this coming wednesday, same time (20 CEST).
> I suggest the following agenda:
>
> - Quickly discuss open points from last meeting
> - discuss 'ToDo', and responsibilities in general
> - future of pkgutils (especially WRT the INSTALL feature mentioned
> above)
>
> Please post further discussion points in this thread. We'll do futher
> meetings as needed.
>
>
> Thanks for your attention,
> Johannes
>
--
~predatorfreak
GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
Port: /home/crux/svn-to-rsync-working-copy/crux-2.2/opt/eclipse-sdk
Url: ftp://sunsite.informatik.rwth-aachen.de/pub/mirror/eclipse/R-3.1.2-200601181600/eclipse-SDK-3.1.2-linux-gtk.tar.gz
Reason: curl: (8) This doesn't seem like a nice ftp-server response
State: New
Port: /home/crux/svn-to-rsync-working-copy/crux-2.2/opt/ethereal
Url: ftp://ftp.uni-kl.de/pub/ethereal/ethereal-0.99.0.tar.bz2
Reason: curl: (8) This doesn't seem like a nice ftp-server response
State: New
Port: /home/crux/svn-to-rsync-working-copy/crux-2.2/opt/libtiff
Url: ftp://ftp.remotesensing.org/pub/libtiff/tiff-3.8.2.tar.gz
Reason: curl: (7) couldn't connect to host
State: New
Port: /home/crux/svn-to-rsync-working-copy/crux-2.2/opt/maradns
Url: http://www.maradns.org/download/1.2/1.2.07.5/maradns-1.2.07.5.tar.bz2
Reason: curl: (52) Empty reply from server
State: New
Port: /home/crux/svn-to-rsync-working-copy/crux-2.2/opt/sitecopy
Url: http://www.lyra.org/sitecopy/sitecopy-0.16.3.tar.gz
Reason: curl: (52) Empty reply from server
State: New
Full report: http://crux.nu/files/check_urls.html
[moved to crux-devel]
On Thu, Jun 01, 2006 at 15:12:02 -0500, Jonathan Asghar wrote:
> >I enabled check_urls on crux.nu, it'll run once per day. I assume there
> >are a couple of false positves, like the file:// urls. If you find
> >others please let me know.
> >
>
> woah! ok, good i was worried for a sec there. I was about to say that
> our ML had gone insane!
> Acutally i think it's a great idea honsetly, it's useful....but i dont
> think every day updates, maybe once a week? (but still have it check
> everyday).
> Is that possible?
Depending on how we do it it's a bit harder, although the point of this
is pretty much that we detect failures as early as possible, so I think
running it daily is preferable.
Also note that it won't send out any message if there's no error, so
unless URLs break daily, we shouldn't see warnings every day.
Extending it to send out warnings the day they're detected, but only
weekly reminders might be sensible, although in this case it might be a
good idea to also generate a web page where you can check whether a
particular problem is still present (since we might see temporary server
downtime from time to time).
If time permits, I'll have a look at this tomorrow. I have an idea which
seems pretty easy to install, but would like to verify it first :-).
Regards, Johannes
--
Johannes Winkelmann mailto:jw@smts.ch
Zurich, Switzerland http://jw.smts.ch
Hi,
I wrote a url checker script [1] which checks for the availability of
sources/distfiles. In order to be notified as early as possible of
moved/unavailable source files, I'd like to run it nightly on crux.nu.
For the notification, there are basically three possibilities:
1. send everything to the list; advantages: everyone can fix a broken
url, for example if another maintainers MIA; disadvantages: some more
messages to the list (it's not like we should have broken urls every day
though)
2. send it to the maintainer directly; advantages: no "spamming" of the
list; disadvantages: requires a correctly set and updated Maintainer
field, and won't be seen by others so if the port maintainer has no time
to fix it, the problem will persist for a longer time without anyone
else knowing
3. opt-in mailing list where these notifications go; advantages: seen by
everyone, those not wanting these notifications don't have to subscribe;
disadvantages: being able to unsubscribe kinda defeats the purpose of
this
I'd suggest to go for choice #1, i.e. sending all to the list, however
would like to hear from the other developers whether they don't like
this at all. If there's no overwhelming negative response, I'll enable
this later this week.
Kind regards,
Johannes
References:
1. http://crux.nu/svnweb/CRUX/view/tools/scripts/check_urls
--
Johannes Winkelmann mailto:jw@smts.ch
Zurich, Switzerland http://jw.smts.ch
