- crux-devel - lists.crux.nu

[CRUX][#364] mplayer port not working
by CRUX 15 Oct '08

15 Oct '08

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - miguel (sodamnmad) Attached to Project - CRUX Summary - mplayer port not working Task Type - New Port Version Category - ports - core/opt Status - New Assigned To - CRUX Developers Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - can't download the file: http://gentoo.chem.wisc.edu/gentoo/distfiles/mplayer-1.0_rc2_p27458.tar.bz2 maybe server is down? More information can be found at the following URL: http://crux.nu/bugs/index.php?do=details&task_id=364 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[CRUX][#363] tightvnc port not working
by CRUX 15 Oct '08

15 Oct '08

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. You have been assigned the following task: FS#363 - tightvnc port not working User who did this - miguel (sodamnmad) More information can be found at the following URL: http://crux.nu/bugs/index.php?do=details&task_id=363 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[CRUX][#363] tightvnc port not working
by CRUX 15 Oct '08

15 Oct '08

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - miguel (sodamnmad) Attached to Project - CRUX Summary - tightvnc port not working Task Type - New Port Version Category - ports - core/opt Status - New Assigned To - CRUX Developers Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - tight vnc port doesn't download file, times out More information can be found at the following URL: http://crux.nu/bugs/index.php?do=details&task_id=363 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[RFC] new portdb
by Lucas Hazel 08 Oct '08

08 Oct '08

So it appears I've been handed the "portdb maintainer" hat. My first duty in this roll was to add a few repos to the portdb cacher. But alas the pdbcacher seems to have locked up and I don't have the privileges to kill the process. So rather than find out what's wrong with it, I've decided to write a new one (sans PHP) with a focus on me having to do as little data entry as possible. A few features I have in mind are, * Allow users to add repositories by themselves. * Allow users to create custom collections from other repositories. * Partial and full caching of repositories. * Make more information available, such as processing footprints, md5sums, meta data and verification results. * XML output, RSS feeds, email alerts, etc. * ??? * Profit Does anyone else have any nifty ideas for what could go into a new portdb? -- Lucas Hazel <lucas(a)amacdigital.com.au> AMAC Digital Products Technician 209 Beardy Street, Armidale NSW [phone: +61267711287]

4 5

Proposed git->rsync script updates
by Tilman Sauerbeck 07 Oct '08

07 Oct '08

Hi all, some months ago, I was frustrated with our git_to_httpup script. That script is run every 5 minutes and exports our ports repositories' contents to ~crux/git-to-rsync-working-copy directory structure. Which looks like this: git-to-rsync-working-copy |---crux-2.4 |---core |--- udev |--- rsync |--- ... |---opt |--- ... |---crux-2.5 |---core |--- ... |---opt |--- ... It annoys me that we're exporting *everything* every 5 minutes. I'd prefer if we exported only those repositories that changed, *when* they change, i.e. when some commit is pushed to the repository. This means we'd have to adjust the script that does the exporting. I suggest to make use of git's post-update hook there. That hook would run as the user who does the push, so the httpup area has to be writable by that user. Long story cut short, here's the new directory hierarchy: git-to-rsync-working-copy2 |---core (owned by core) |---2.4 |--- udev |--- rsync |--- ... |---2.5 |--- ... |---opt (owned by opt) |---2.4 |--- ... |---2.5 |--- ... Since we'd switch from "crux-2.4/core" style directories to "core/2.4" or something, we'd have to adjust our *.rsync files. Also we'd need to keep the old rsync area alive for users who are still running old CRUX systems. Advantages: o Updated ports are rsync-able after a very short time and not just after up to 5 minutes. o No more disk thrashing just because another 5 minutes went by even though there was no git activity. Disadvantages: o We'd have to adjust the *.rsync files. Would be doable with the CRUX release (2.5) o The branches that should be exported are currently set in each separate post-update hook, so once a new CRUX version is released, you need to touch {core,opt,contrib,xorg,xfce}.git/hooks/post-update. o More? Opinions? Should we do that switch? I've already written the necessary shell code, it just needs to be put in some separate function that can be sourced from the various hooks. 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?

2 1

IRC meeting tonight
by Johannes Winkelmann 07 Oct '08

07 Oct '08

Hi there, Here's a reminder for tonight's IRC meeting; main focus will be the upcoming 2.5 release progress. Looking forward to seeing you at 20 CEST in #crux-devel. Cheers, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch

1 0

[PATCH] util-linux-ng / mount: mtab created multiple times with -a option
by Jonas Kramer 30 Sep '08

30 Sep '08

Ahoy, some of us had the problem that the "mount -a" in /etc/rc printed "warning: couldn't open /etc/mtab: ..." and that afterwards there were lots of root-fs entries in /etc/mtab. I looked into the problem and found that it is a bug in util-linux-ng 2.14.1, in the mount command. I sent a patch to the util-linux-ng mailing list, but I don't know how long it will take until the patch is in upstream and upstream is updated in the CRUX ports, so I just forward the patch to this list. Feel free to patch your own util-linux-ng ;) However, the warning doesn't go away, since /etc/mtab really isn't there (it's deleted in /etc/rc for some reason), but /etc/mtab isn't that messy anymore. Regards, Jonas Kramer ----- Forwarded message from Jonas Kramer <jkramer(a)nex.scrapping.cc> ----- Date: Tue, 30 Sep 2008 22:36:18 +0200 From: Jonas Kramer <jkramer(a)nex.scrapping.cc> Subject: [PATCH] mount: mtab created multiple times with -a option To: kzak(a)redhat.com User-Agent: Mutt/1.5.18 (2008-05-17) Ahoy. Since util-linux-ng 2.14.1, the following problem occurs with mount. When /etc/mtab does not exist and mount is called with -a, for every mount point that is mounted a root-fs record is added to mtab. This is because get_mtab_info() sets the flag mtab_does_not_exist to 1 when it doesn't find /etc/mtab. However, if it actually finds /etc/mtab, the variable is not reset to 0. So on every subsequent call to get_mtab_info() (as it is the case when mounting several mount points with the -a option), mount will think that /etc/mtab does not exist, even if it was created in the meantime by mount itself. Additionally, create_mtab() does open /etc/mtab with "a+" even though it is only called when mount thinks that /etc/mtab does not exist. So for every mount point that is mounted with -a, another root-fs entry is added to /etc/mtab. The attached patch seems to fix that. Regards, Jonas Kramer -- diff --git a/mount/fstab.c b/mount/fstab.c index 895fd2c..eb38822 100644 --- a/mount/fstab.c +++ b/mount/fstab.c @@ -30,13 +30,20 @@ static int var_mtab_is_a_symlink = 0; static void get_mtab_info(void) { - struct stat mtab_stat; - if (!have_mtab_info) { + struct stat mtab_stat; + if (lstat(_PATH_MOUNTED, &mtab_stat)) var_mtab_does_not_exist = 1; - else if (S_ISLNK(mtab_stat.st_mode)) - var_mtab_is_a_symlink = 1; + else { + var_mtab_does_not_exist = 0; + + if (S_ISLNK(mtab_stat.st_mode)) + var_mtab_is_a_symlink = 1; + else + var_mtab_is_a_symlink = 0; + } + have_mtab_info = 1; } } ----- End forwarded message ----- --

1 0

IRC meeting on the 2.5 release tomorrow
by Johannes Winkelmann 29 Sep '08

29 Sep '08

Hi there, There have been some of preparations for the 2.5 release already (see Tilman's mail), and from what I can see now nothing is stopping us from starting the 2.5 test cycle. To get things going, let's discuss open issues at tomorrow's IRC meeting (20:00 CEST, #crux-devel). If you can't make it, please post your concerns/ideas/requests here on this list. Thanks for your interest, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch

1 0

ATN: nvidia and ati ports
by Lucas Hazel 22 Sep '08

22 Sep '08

The new mesa3d port no longer uses libGLcore, so gl-select does not need to handle these files anymore[1]. It is safe for the nvidia and ati ports to own these files. Please update your ports to reflect these changes as soon as possible. [1] http://crux.nu/gitweb/?p=ports/opt.git;a=commit;h=e0beb0566ca8ab771e90f0da9… -- Lucas Hazel <lucas(a)die.net.au>

1 0

[RFC] experimental dmcrypt support
by Thomas Penteker 18 Sep '08

18 Sep '08

Hello, I set up a wiki page for discussing a possible inclusion of dmcrypt support (+ fully encrypted '/') in CRUX. It lives here: http://crux.nu/Wiki/cryptsetup Comments / Criticism / Suggestions welcome! kind regards, Thomas Penteker --

1 0