- crux-devel - lists.crux.nu

A proposal for the 'xorg' ports repo
by Matt Housh 19 Jun '12

19 Jun '12

Greetings, all, Since Tilman has retired and we've been reapportioning ports to some extent, I have a proposal for the future of the xorg ports repository. I'll keep it simple, the proposal is something like this: My idea is that the 'xorg' repo be adopted by the CRUX core team as far as maintenance and updates are concerned. Any core team member can make updates as needed to the repo following 3 simple guidelines: 1) The set of release tarballs at the x.org releases directory [1] is considered the "base approved" sources for the 'xorg' repository, the current release being X11R7.7 as indicated at the main x.org page [2]. 2) Appropriate updates for xorg-related CVE-IDs (or bugtraq announcements, etc.) are considered approved after testing that the updated version doesn't have any obvious build problems or bugs. In this case it would include a relevant CVE-ID link or the like in the commit message. We already do this most of the time. 3) Module updates from the xorg-announce mailing list [3] are considered approved after the same testing as guideline 2. Of course 2 and 3 will overlap at times as some module updates will likely occur due to CVE (or bugtraq, etc.) announcements. While this sounds a bit forced in writing that's really not my intent. My intent is simply to suggest a way to centralize the 'xorg' repo effort so that it's not a one-man show anymore. Theoretically this should allow us to keep on top of the updates pretty quickly when it's needed. The aforementioned testing obviously isn't a rigorous test of everything, hopefully upstream is doing that for us. It's just the normal expected diligence on the part of the port maintainers to make sure they port they're pushing works. Thoughts, comments, objections, etc.? Matt [1] http://www.x.org/releases/X11R7.7/src/ [2] http://www.x.org/wiki/ [3] http://lists.x.org/mailman/listinfo/xorg-announce

3 2

Retiring
by Tilman Sauerbeck 17 Jun '12

17 Jun '12

Hi, as you know I haven't made significant contributions to CRUX in quite some time. Sadly I don't see this changing in the near future so I made up my mind and decided to retire from CRUX development. I just don't have the extra time and energy to pour into CRUX these days. My apologies for letting you down in recent months. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?

8 7

udev
by Juergen Daubert 16 Jun '12

16 Jun '12

Hello together, as you all may have already noticed, as of version 183 the udev sources has been merged into the systemd sources. At the time I read the first announcement from Kay Sievers that doesn't sound too bad [1] to me, because I got the impression that it would be easy to extract udev from systemd. Unfortunately in practice the whole thing looks like a big, bad issue. It's not possible to configure systemd in a way that udev can be build standalone, but you have to build the complete systemd stuff and manually extract what is needed for udev. Kay's comment on to that issue sounds quite different than the first announcement to me [2]. In the meantime we can see two attempts of other people to submit patches [3][4] to improve the situation, but with no "official" comment yet. Currently we don't have a practical issue with all of that, because we can stick with udev 182 for now. You may ask why I wrote all of this, it's just for your information and to summarize the whole situation. For me the whole udev/systemd source merge looks like a crude effort to force people to use systemd. But what can we do? Good question, in the long run it will be impossible to use udev standalone IMO, so we either have to switch to it or do something completely different. One possiblity might be mdev, a dynamic device/node creation program that comes with busybox, see [5] for a short description, together with devtmpfs which is a kind of devfs, see [6]. Btw, I'm not sure but it looks like our Per had put a comment to that article ;) [7] We, that means Jose, Fredrik and me, have done some initial tests with mdev, it looks not so bad at all. We will continue on testing it and report here our experiences. Thanks for the attention and a nice weekend to all. Juergen [1] http://article.gmane.org/gmane.linux.hotplug.devel/17392 [2] http://article.gmane.org/gmane.linux.hotplug.devel/17444 [3] http://thread.gmane.org/gmane.linux.hotplug.devel/17478 [4] http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/5330 [5] http://git.busybox.net/busybox/plain/docs/mdev.txt [6] http://lwn.net/Articles/331818/ [7] http://lwn.net/Articles/332502/

1 0

Encouraging CRUX community efforts to support CRUX developers.
by Emmanuel Benisty 16 Apr '12

16 Apr '12

Dear CRUX developers, Having the latest and greatest version of ports is the second most important reason I've been using CRUX since almost two years now, starting with one laptop, then a HTPC and finally a router/firewall. Like many others, the main reason is CRUX's utmost simple and elegant design. I'm aware that CRUX developers' team is rather small, that some people may be busy with real life and that they offer their work for free. Please understand that I am *not* complaining in any way, I'm just willing to share some thoughts that may help to facilitate the time consuming, not always exciting task of packaging. If some ports are behind the latest versions, I would imagine that's because CRUX is lacking manpower. On the other hand, I understand that CRUX can't accept any random user as a developer. Most of the time, I've been updating ports by myself, on my machines, but I think it's rather sad that 1. it can't benefit the whole community 2. it's a duplicate effort as sooner or later, the official maintainer will update those ports. I've been posting few patches on IRC or sometimes sent them to maintainers by email but that is not always efficient because if you're too busy to update your ports, you're most likely too busy to review others' patches too. So I've been thinking about the following: What would you think about the creation of a community-patches-queue git repo accessible by, well, CRUX community. This is how it could work: 1. User U has updated port P on his machine, he would then commit a diff patch to community-patches-queue (we could also make a ports repo out of it and encourage people to use and test those ports but that's another story) 2. One (or more?) CRUX developer, available at that time, would volunteer to review and sign-off the patch. 3. Signed-off patches are sent to the official maintainer (or committed to community-patches-acked) so he could review and apply them or just apply them with peace of mind if he's too busy to review them fully (or even let other devs apply them?) Maybe that sounds too complicated for temporary situations but what I can I say is that I'm willing to help (and I'm not the only one, for sure). Sending patches to community-patches-queue would be a way to do so. Thanks in advance for your comments and wishing you all a pleasant Sunday. Cheers, -- Emmanuel

4 4

prt-get depupdate
by Jose V Beneyto 22 Mar '12

22 Mar '12

Hi, I wrote a patch for prt-get that provides a new feature: 'depupdate'. The purpose of this feature is to solve the problem of new deps in the update of a port. An example of this could be a commit to gst-plugins-bad(*), which introduces new dependencies, so in the case you only use the 'update' command, then you'll have an error due to new deps. Bassically, 'depupdate' does the same like 'depinst' but with some differences: [depinst foo] 1. get dependencies of foo, and install missing ones 2. install foo [depupdate foo] 1. get dependencies of foo, and install missing ones 2. update foo What to you think about? Regards, (*) http://crux.nu/gitweb/?p=ports/contrib.git;a=blobdiff;f=gst-plugins-bad/Pkg… -- Jose V Beneyto | http://sepen.it.cx/

4 5

Re: [crux-devel] rc-ng scripts
by Jose V Beneyto 29 Feb '12

29 Feb '12

Hey all, Michael, thanks a lot, your work is too appreciated. This mail, due to my poor English and little time nowadays, probably not cover everything I think, but I've long wanted to send it and should not delay it anymore, so sorry if there is anything that is not well explained or incomplete. I'll try to argue my POV with advantages/disadvantages as better as possible, and if necessary bringing new ideas and proposals. The first thing that comes to my mind is the complexity of the new solution for system initialization files that you have proposed. I think that it's much more complicated than our current one, but I'm always open to new ideas and improvements. I supposse that you worked in this stuff due to solve/optimize issues you found, maybe with lvm/mdadm, but I'm not 100% sure that I got the whole idea, so please correct me if I'm wrong somewhere. Also I noted that ArchLinux has a similar implementation (1) that could be reviewed. *** (about hooks) *** Basically I like user configurable hooks as alternative to rc.local (or complement), and not as an imposition (some hooks are empty files). I'd like to have a minimal rc port, and let people to use as hooks as need it. This would make for rc* init scripts to load only the hooks that were selected by users to use. Personally, I have years managing CRUX systems and I've never needed anything extra apart from a couple of lines in rc.local, as is the case with rc.local/rc.local.conf in OpenBSD systems. Accordingly, I think we might have enough to accommodate all the hooks in a single directory, I like: /etc/rc.conf.d/hooks. Another disadvantage (IMHO) with rc-hooks could be inherited and overlap the config that has established the user. Which brings us back to run rejmerge for all rc-hooks (around 20 hooks maybe?) after each update rc port. That reinforces the idea of having a small rc port. In addition I'd like to review the naming convention. I prefer the one used by ArchLinux (2) which could be housed in the same directory (maybe /etc/rc.conf.d/hooks/) and not lose its meaning: your schema => my proposal --------------------------- multi/early => multi_start sysinit/early => sysinit_start sysinit/late => sysinit_end sysinit/udev-runner1 => sysinit_udev-runner1 sysinit/udev-runner2 => sysinit_udev-runner2 ... Also I found that there are 2 hooks (sysinit/early and sysinit/pre-trigger1) where the second hook is executed immediately after the first one which is meaningless, so in this case both hooks could be merged into one: --- /etc/rc.sysinit --- rc_hook sysinit/early rc_hook sysinit/pre-trigger1 si_udev --- endof /etc/rc.sysinit --- *** (about functions) *** I like most functions you added and/or implemented, new tools from util-linux-ng (like findmnt, etc.) and also new bash syntax and features. Good work!! But why not have all functions in only one file? (maybe /etc/rc.conf.d/functions) So there are about only 30 functions. $ grep 'function .*()' /etc/rc.engine/* | wc -l 30 IMHO code refactoring makes sense when the same function is used from multiple places. If, for example, rc.engine/multi functions are only used from rc.multi script the it makes no sense to separate it into a single file, so the effect would be the same like include only those functions in rc.multi script since no more rc scripts required them. Also I would like to adopt and/or discuss a more consistent naming convention for functions. your schema ----------- rc.engine/all:function __rc_spawner() { rc.engine/all:function rc_srv_start() { rc.engine/lib:function start_kmsg_log() { rc.engine/sysinit:function __si_console() { rc.engine/sysinit:function __si_seed() { rc.engine/sysinit:function si_std() { my proposal ----------- rc_spawner(), rc_srv_start(), kmsg_log_start(), sysinit_console(), sysinit_seed(), sysinit_std(), ... In addition it would be fine to have some functions like start_service(), stop_service() that could be used by services/daemons in /etc/rc.d/* like sshd or others. For example, stop_service() basically could do: stop_service() { local SUCCESS=0 local SERVICE=$1 local PIDFILE=/var/run/$SERVICE.pid #[ $VERBOSE -eq 1 ] && echo -n "Stopping $SERVICE:\t" if [ -f /var/run/$SERVICE.pid ]; then kill $(< /var/run/$SERVICE.pid) if [ $? -ne 0 ]; then SUCCESS=1 rm -f /var/run/$SERVICE.pid fi else killall -q /usr/sbin/$SERVICE # we could use another argument like $BINFILE instead of $SERVICE [ $? -ne 0 ] && SUCCESS=1 fi #if [ $VERBOSE -eq 1 ]; then # if [ $SUCCESS -eq 1 ]; then # echo "[OK]" # else # echo "[FAILED]" # fi #fi } -- note that this is only an idea and of course it could be written better, have global vars like $VERBOSE, etc. *** (lvm/mdadm) *** For what I see, /etc/rc.hooks/sysinit/udev-runner1 is the place where lvm/mdadm lives. Can't be possible to move this stuff to their respective daemons in /etc/rc.d/lvm and /etc/rc.d/mdadm? It could be a clean way and better for boxes where no lvm/mdadm config is required and/or used. *** (miscelaneous) *** Why you added -8 --noclear to inittab? -- c1:2:respawn:/sbin/agetty 38400 tty1 linux ++ c1:2:respawn:/sbin/agetty 38400 -8 --noclear tty1 linux IMHO, I would leave it as is and give users freedom to change or not. Why not move rc.engine/tlkd to functions as tlkd(), or even to /etc/rc.d/tlkd as a complete daemon service? I'm sure I missed something but at least I hope I have expressed my ideas and opinions. Best regards, (1) https://wiki.archlinux.org/index.php/Arch_Boot_Process#.2Fetc.2Frc.sysinit (2) https://wiki.archlinux.org/index.php/Arch_Boot_Process#Custom_hooks -- Jose V Beneyto | http://sepen.it.cx/

1 0

crux ppc project suspended
by acrux 16 Feb '12

16 Feb '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi all, due a lack of working developers, modern hardware and resources after nearly ten years i'm sadly going to suspend the CRUX PPC GNU/Linux project. It's not a full switch off but future updates 'll be discontinued and, anyway, _not_ ensured. all the best, - - --nico - - -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk88RIMACgkQxq34tDeO7Lj/lACeKy8JGgxoug13GFszbcHQ/f0d 1dMAnignY7EXLDWetpvV5R7UTxAYEEcR =Cg29 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk88VPoACgkQxq34tDeO7LgikQCeOlXxeA18oV+xG3H4AN/f29Fe Z/IAn0M4GkAJ6iT6LhjUTlgsYqqTl/ut =yhi2 -----END PGP SIGNATURE-----

1 0

Fw: Re: dhcpcd uses clang if available on the system and it's not always good on linuxppc
by acrux 09 Feb '12

09 Feb '12

hi all, I just received some suggestions from the dhcpcd's author. I guess it could be the right moment to review dhcpcd section in the "Network Configuration" paragraph in CRUX Handbook. --nico Begin forwarded message: Date: Fri, 03 Feb 2012 17:45:35 +0000 From: Roy Marples <roy(a)xxx.name> To: acrux <acrux(a)xxx.it> Subject: Re: dhcpcd uses clang if available on the system and it's not always good on linuxppc On Thu, 2 Feb 2012 12:35:33 +0100, acrux wrote: > [...] (CRUX main project uses dhcpcd as default) I just checked your init script for dhcpcd.... May I make some recommendations? /sbin/dhcpcd -t 10 -h $HOSTNAME eth0 ... /usr/bin/killall -q /sbin/dhcpcd May I recommend this instead? /sbin/dhcpcd -t 10 ... /sbin/dhcpcd -x Firstly, when invoked like that it runs in master mode and handles the situation where you have more than one interface a lot better. Like say a laptop and wired and wireless both connected (and maybe a 4G phone) and dhcpcd will handle routing and DNS correctly, preferring by default wired > wireless > 4G When stopping with -x, the call will spin until dhcpcd has exited, which may or may not be important if the user has defined any hooks that must be called before spinning down the disks. Lastly, is crux using dhcpcd-dbus and dhcpcd-ui(gtk) for a system tray notification of dhcpcd state? Thanks Roy -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/

2 1

CRUX 2.7.1 ???
by Juergen Daubert 13 Nov '11

13 Nov '11

Hi all, yesterday we talked about a possible intermediate CRUX release, called 2.7.1, with the current packages and unaltered toolchain. Matt generously offered to build an updated ISO for that purpose, many thanks for that. I like the idea, because it should be possible to create the ISO without too much additional work. todos in casual order: - update iso.git for version 2.7.1 - create ChangeLog 2.7 -> 2.7.1 - adjust setup-helper, see http://crux.nu/Wiki/TODO28 - do we have any pending ports-updates in opt/xorg? - NEWS entry for our homepage, adjust download page - ...? - ...? Opinions? Any objections against a 2.7.1? best regards Juergen

3 2

rc-ng scripts
by Michal Soltys 02 Nov '11

02 Nov '11

Ok, as promised, this is fresh approach to initscripts. Perhaps a few rough edges here and there, but is thoroughly tested (modulo just-a-moment ago minor changes I did) This version is still "legacy" - that is: mtab is still plain file, and /run is not used. The move to "modern" is pretty trivial, though it will require few minor changes in few packages to keep things tidy. Installation is manual (essentially cp -a -t /etc rc* inittab). It's good (if you mount /usr) to move to /bin: mkfifo, mktemp, setsid. mkfifo is _essential_ there, setsid is optional (ctty for emergency shell), mktemp is essential too (but used first time after /usr mount). git fetch (or fetch-pack, or pull :), check it out, comment. The following changes since commit 01cd72c3f82320be030052a02ea0adbdb74f7886: udev: update to 174 (2011-10-24 18:50:46 +0200) are available in the git repository at: git://git.hasevolq.net/crux.git rc-ng Michal Soltys (1): initial rc-ng commit rc-ng/inittab | 30 ++++ rc-ng/rc.conf | 86 ++++++++++ rc-ng/rc.engine/all | 298 ++++++++++++++++++++++++++++++++++ rc-ng/rc.engine/ckld | 36 ++++ rc-ng/rc.engine/lib | 180 +++++++++++++++++++++ rc-ng/rc.engine/multi | 7 + rc-ng/rc.engine/shutdown | 52 ++++++ rc-ng/rc.engine/single | 7 + rc-ng/rc.engine/sysinit | 305 +++++++++++++++++++++++++++++++++++ rc-ng/rc.fix | 1 + rc-ng/rc.hooks/all/post-umount | 17 ++ rc-ng/rc.hooks/multi/early | 24 +++ rc-ng/rc.hooks/multi/late | 7 + rc-ng/rc.hooks/shutdown/early | 6 + rc-ng/rc.hooks/shutdown/late | 11 ++ rc-ng/rc.hooks/shutdown/pre-umount | 6 + rc-ng/rc.hooks/single/early | 6 + rc-ng/rc.hooks/single/late | 6 + rc-ng/rc.hooks/sysinit/early | 28 ++++ rc-ng/rc.hooks/sysinit/late | 9 + rc-ng/rc.hooks/sysinit/post-mount | 6 + rc-ng/rc.hooks/sysinit/pre-mount | 6 + rc-ng/rc.hooks/sysinit/pre-trigger1 | 6 + rc-ng/rc.hooks/sysinit/pre-trigger2 | 7 + rc-ng/rc.hooks/sysinit/udev-runner1 | 29 ++++ rc-ng/rc.hooks/sysinit/udev-runner2 | 9 + rc-ng/rc.local | 1 + rc-ng/rc.modules | 1 + rc-ng/rc.multi | 15 ++ rc-ng/rc.shutdown | 43 +++++ rc-ng/rc.single | 26 +++ rc-ng/rc.sysinit | 59 +++++++ 32 files changed, 1330 insertions(+), 0 deletions(-) create mode 100644 rc-ng/inittab create mode 100644 rc-ng/rc.conf create mode 100644 rc-ng/rc.engine/all create mode 100755 rc-ng/rc.engine/ckld create mode 100644 rc-ng/rc.engine/lib create mode 100644 rc-ng/rc.engine/multi create mode 100644 rc-ng/rc.engine/shutdown create mode 100644 rc-ng/rc.engine/single create mode 100644 rc-ng/rc.engine/sysinit create mode 120000 rc-ng/rc.fix create mode 100644 rc-ng/rc.hooks/all/post-umount create mode 100644 rc-ng/rc.hooks/multi/early create mode 100644 rc-ng/rc.hooks/multi/late create mode 100644 rc-ng/rc.hooks/shutdown/early create mode 100644 rc-ng/rc.hooks/shutdown/late create mode 100644 rc-ng/rc.hooks/shutdown/pre-umount create mode 100644 rc-ng/rc.hooks/single/early create mode 100644 rc-ng/rc.hooks/single/late create mode 100644 rc-ng/rc.hooks/sysinit/early create mode 100644 rc-ng/rc.hooks/sysinit/late create mode 100644 rc-ng/rc.hooks/sysinit/post-mount create mode 100644 rc-ng/rc.hooks/sysinit/pre-mount create mode 100644 rc-ng/rc.hooks/sysinit/pre-trigger1 create mode 100644 rc-ng/rc.hooks/sysinit/pre-trigger2 create mode 100644 rc-ng/rc.hooks/sysinit/udev-runner1 create mode 100644 rc-ng/rc.hooks/sysinit/udev-runner2 create mode 120000 rc-ng/rc.local create mode 120000 rc-ng/rc.modules create mode 100755 rc-ng/rc.multi create mode 100755 rc-ng/rc.shutdown create mode 100755 rc-ng/rc.single create mode 100755 rc-ng/rc.sysinit

3 12