- crux-devel - lists.crux.nu

None
by None 25 Feb '24

25 Feb '24

So I guess it's time to have a close look at http://clc.morpheus.net:6999/clc/wiki?p=CruxConResults and see what we want to and can do for 2.1 :-) To me personally, the following point is most important: - combined httpup collection as new 'contrib' I'll try to start testing this weekend (I'll send another mail on this). If there's anything that you'd like to be ready for 2.1, please let us know so we don't all work on the same things ;-). Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net

1 0

None
by None 25 Feb '24

25 Feb '24

write/create rigths for the wiki. With cvstrac selected pages can be locked (== read-only for anonymous and regular users), unfortunately this requires admim rigths which most maintainters don't have. kind regards Jürgen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux

1 0

Slim git ports driver
by Steffen Nurpmeso 07 Mar '20

07 Mar '20

Hi. How about that change? It will remove all the old stale branches that noone needs for ports, and ensure old and stale data gets garbage collected. It could be improved in that the newest two remain, instead of only the one that is configured in the according /etc/ports entry, but that is for developers only, and i would expect these have their own full tree laying around locally. diff --git a/git/git b/git/git index 654a8c770..51193dd2c 100644 --- a/git/git +++ b/git/git @@ -39,8 +39,15 @@ if [ $? -lt 1 ]; then git diff --pretty=format: --name-status "$BRANCH" origin/"$BRANCH" | sed "s/M\t/ Edit /g; s/A\t/ Checkout /g; s/D\t/ Delete /g" | sort git clean -q -f git reset -q --hard origin/"$BRANCH" + i=`git branch | sed -e '/^*/d'` + if [ -n "$i" ]; then + git branch -q -d $i + i=--aggressive + fi + git gc --quiet $i --prune=all else - git clone -q -b "$BRANCH" "$URL" "$REPOSITORY" + git clone -q --single-branch -b "$BRANCH" "$URL" "$REPOSITORY" + git gc --quiet --aggressive --prune=all ls -1 $REPOSITORY | sed "s/^/ Checkout /" fi --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

1 0

Ship with git drivers
by Steffen Nurpmeso 07 Mar '20

07 Mar '20

Hello. How about that? Works nicely here now (with another patch that'll come). diff --git a/ports/contrib.git.inactive b/ports/contrib.git.inactive new file mode 100644 index 00000000..82b1c5f9 --- /dev/null +++ b/ports/contrib.git.inactive @@ -0,0 +1,3 @@ +NAME=contrib +URL=git://crux.nu/ports/contrib.git +BRANCH=3.5 diff --git a/ports/core.git.inactive b/ports/core.git.inactive new file mode 100644 index 00000000..958ea7fc --- /dev/null +++ b/ports/core.git.inactive @@ -0,0 +1,3 @@ +NAME=core +URL=git://crux.nu/ports/core.git +BRANCH=3.5 diff --git a/ports/opt.git.inactive b/ports/opt.git.inactive new file mode 100644 index 00000000..3427a042 --- /dev/null +++ b/ports/opt.git.inactive @@ -0,0 +1,3 @@ +NAME=opt +URL=git://crux.nu/ports/opt.git +BRANCH=3.5 diff --git a/ports/xorg.git.inactive b/ports/xorg.git.inactive new file mode 100644 index 00000000..b13d7052 --- /dev/null +++ b/ports/xorg.git.inactive @@ -0,0 +1,3 @@ +NAME=xorg +URL=git://crux.nu/ports/xorg.git +BRANCH=3.5 --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

1 0

entropy-saver.c to seed real entropy
by Steffen Nurpmeso 13 Jun '19

13 Jun '19

In short: Linux uses a diverse random system, with an internal pool that is not exposed and the ones which are fed by that one which actually serve user requests. One lengthy examination has been produced by the German BSI: [1] The problem occurred to me once AlpineLinux switched from kernel 4.14 to 4.19: i had hanging boots of half an hour and such on the server VM, as the RNG would not unlock; even on a CoreDuo laptop i saw this: [ 15.706636] random: dnsmasq: uninitialized urandom read (128 bytes read) [ 183.806112] random: crng init done But likely only because i hit a key... I looked around and saw other people with the same problem using the haveged daemon, which is kind of strange as it can generate thousands of bits of hard randomness in a second.Anyway, shortly before Christmas on the LUGA (Linux User Austria) ML that came up again via a Debian user, and that made me write an entropy saver. Because, the thing is, that "writing data to urandom" does no(t) (longer) do anything to /proc/sys/kernel/random/entropy_avail, but that is the value which control locking state of the RNG. As far as i know there is no way to make that happen via the shell. Modern CPUs may offer things, and it may be that on some CPUs Linux offers random.trust_cpu, yet i have no system where that is true. My 8th generation i5 has RDRAND and RDSEED, but still the entropy-saver as attached helps here. What it does is just the same as is done to urandom seed, so i have in /etc/rc # Load random seed /bin/cat /var/lib/urandom/seed > /dev/urandom /sbin/entropy-saver load /var/lib/urandom/entropy and in /etc/rc.shutdown # Save random seed /bin/dd if=/dev/urandom of=/var/lib/urandom/seed count=1 2> /dev/null /sbin/entropy-saver save /var/lib/urandom/entropy So just in case someone sees boot hangs, that will help to unlock the RNG, by not wasting prescious entropy collected during uptime. It has been posted to LUGA and openssl-users in the past, a little bit of feedback i had and is in. [1] https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Li… --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

4 6

pkgutils footprint enhancement
by James Buren 11 Jun '19

11 Jun '19

I observed while working on my pkgutils rewrite that the original wastes time by making two passes through each archive when generating a footprint. I have revised the algorithm to cache the necessary metadata it needs to generate the footprint in a first pass through the archive and then process it all during a second pass through the cached metadata. The observable differences from the original algorithm are as follows. First, the new algorithm takes roughly half the time of the original when generating footprints. Second, the unsorted line order has been changed from the order of their appearance in the original archive to a sorted order by path. I did this to support the faster binary search lookups for the hard links that the original algorithm was doing via a hash table. If this is considered undesirable, I can switch back to using a hash table to retain the original order. I switched it because I didn't want to increase the RAM usage anymore than I already had to for the metadata cache. An auxiliary hashtable would require extra RAM whereas this method allows me to reuse the same array I use for the metadata cache. In practice this should shave a few seconds off large port builds, though it's relative to how much time it spends building the archive and the composition of the resulting package. Thoughts?

1 0

Application for contrib
by Tim 29 Apr '19

29 Apr '19

Hi everybody, I want to apply to help out with contrib. I use CRUX for quiet some time now (10+ years at least), I maintain my own repository [1] publicly since 2018/06/19 and I recently added crux-libreoffice [2], behind closed doors I'm preparing a repository for steam-native ports. I have been hosting some ports before, but this has been around 2010, maybe somebody remembers me from then, I've been hanging out on IRC back then too, but I don't remeber the name I used and since that server I used to host in a shoe box died I lost most of my CRUX related stuff at the time. O:) Let's say the situation looks somewhat better today. If there is anything you want to know in particular, let me know. TimB_ on irc. Have a great sunday, best regards -- Tim Biermann

4 6

Patch to allow pkgmk to rename downloaded tarballs
by Alan Mizrahi 04 Apr '19

04 Apr '19

Hi, When building ports, sometimes source tarballs have names that could collide with other ports. I don't remember it ever happening to me, but it was raised in Flyspray [1], and I guess it could happen. To show it with a sample Pkgfile: name=dotconf version=1.3 release=1 source=(https://github.com/williamh/$name/archive/v$version.zip) So I made a patch that allows renaming the downloaded source files by using an associative array, like this: name=dotconf version=1.3 release=1 declare -A \ source=([$name-$version.zip]=https://github.com/williamh/$name/archive/v$ve… While being compatible with current Pkgfiles. The patch is attached to Flyspray, along with alternative solutions proposed by other people. I also have a patch that allows to continue building a port after it fails, instead of starting from the beginning. If this sounds interesting (and worthy of merging), please let me know. Best regards, Alan [1] https://crux.nu/bugs/index.php?do=details&task_id=923

3 2

crux-install
by Andy Kosela 18 Mar '19

18 Mar '19

Hi, A few months ago I wrote an interactive installation program[1] for CRUX which simplifies installation process from ISO. A few weeks ago I shared it with the CRUX community via CRUX mailing list and received quite a good feedback. The occuring theme was that it would be nice to include it in the future official ISO's as an additional, alternative installation method. Of course I'm very aware that most people running CRUX are very familiar with a traditional, manual installation and they are happy to do the same in the future, but it would benefit everybody to include this small program (10K, shell script). That way the official CRUX install method would still remain the same, but folks wanting to speed it up would be able to issue: $ install And run the interactive install program. The idea behind it came from OpenBSD which IMHO has a very clean and minimalist installation process. Thanks, [1] https://github.com/akosela/crux-install --Andy

1 0

openssl 1.1.1 for 3.5
by Fredrik 01 Nov '18

01 Nov '18

OpenSSL 1.0.2 will be EOL at the end of 2019. Shipping 1.0.2 in 3.5 could really make for a stressful 3.6 release time wise. OpenSSL 1.1.1 is the preferred upstream LTS release and will be supported into 2023. After installing 1.1.1 on my system and rebuilding the broken stuff I have to say I'm surprised how little breakage I see. Compared to my last OpenSSL 1.1.0 test, at least. My list of installed ports that will need need patching is: cyrus-sasl (patched in 2.1.27-rc7) spice-gtk (fixed in 0.35) That's it. /f

1 0