LinuxQuestions.org
Page 51 of 318 « First 414950 51 525361101151 Last »
Show 50 post(s) from this thread on one page

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Requests for current-next (15.0-->15.1) (https://www.linuxquestions.org/questions/slackware-14/requests-for-current-next-15-0-15-1-a-4175706801/)

marav 06-09-2022 02:01 PM
KDE Gear 22.04.2

Announcements:
https://kde.org/announcements/gear/22.04.2/

marav 06-09-2022 02:03 PM
Pipewire 0.3.52

Code:
## Highlights
  - Add 44.1KHz to allowed samplerates. The server can now switch by
    default between 48KHz and 44.1KHz.
  - Streams now allocate less resources.
  - Fix some bugs that could make the server crash.
  - Bluetooth now supports the LC3plus vendor codec.
  - Many bugfixes and improvements.

marav 06-09-2022 04:28 PM
Firefox 101.0.1

Release notes:
https://www.mozilla.org/en-US/firefo.../releasenotes/

henca 06-10-2022 02:04 PM
valgrind (and maybe also graphviz)
 
It has been suggested before by others for previous releases, but somehow valgrind has not made it into Slackware.

In my opinion valgrind is very useful for debugging and together with kcachegrind also very useful for performance analysis of programs.

The odd thing is that Slackware includes kcachegrind. However, kcachegrind is not to any use without valgrind. Kcachegrind can also be even more useful together with graphviz.

It is not a big deal to install valgrind and graphviz from other sources like slackbuilds.org , but if valgrind is not included in Slackware you might just as well leave kcachegrind out and let slackbuilds.org pick up that ball.

regards Henrik

amikoyan 06-11-2022 02:42 PM
Quote:
Originally Posted by henca (Post 6359996)
It has been suggested before by others for previous releases, but somehow valgrind has not made it into Slackware.

In my opinion valgrind is very useful for debugging and together with kcachegrind also very useful for performance analysis of programs.

The odd thing is that Slackware includes kcachegrind. However, kcachegrind is not to any use without valgrind. Kcachegrind can also be even more useful together with graphviz.

It is not a big deal to install valgrind and graphviz from other sources like slackbuilds.org , but if valgrind is not included in Slackware you might just as well leave kcachegrind out and let slackbuilds.org pick up that ball.

regards Henrik
I use valgrind and find it helpful for debugging when used with gdb (which is included with Slackware).

I have not tried kcachegrind - will investigate, so thanks for mentioning it.

henca 06-11-2022 06:12 PM
Quote:
Originally Posted by amikoyan (Post 6360225)
I have not tried kcachegrind - will investigate, so thanks for mentioning it.
The way to use it is:

1) compile your program with the -g switch:

gcc -g -o myprogram myprogram.c

2) run your program (valgrind will make this rather slow):

valgrind --tool=callgrind ./myprogram any optional parameters for myprogram

3) run kcachegrind on the generated callgrind.out.<pid>:

kcachegrind callgrind.out.8759

The callee map in kcachegrind quickly shows in which functions your program spends most CPU and you can study how much time is spent in each line of source code. With graphviz dot installed you will also get a call graph.

regards Henrik

marav 06-12-2022 03:46 PM
KDE Frameworks 5.95.0

Announcements:
https://kde.org/announcements/frameworks/5/5.95.0/

ponce 06-13-2022 02:28 AM
just a small note to report that firefox and thunderbird (also the versions in the repo) FTB with the newer cbindgen (0.24.x, installed via the build-deps script)

https://bugzilla.mozilla.org/show_bug.cgi?id=1773259

it's still being debated but this patch fixes the build for the moment

https://raw.githubusercontent.com/ca...cbindgen.patch

Didier Spaier 06-13-2022 03:59 AM
dracut
 
Rationale: one less in-house software (mkinitrd and associated scripts) to maintain. I will check it usage during installation and following a kernel upgrade.

EDIT. let's give two examples:
  1. To embed a LUKS keyfile in the initrd and have it used by init, I had to modify init.
  2. To make a "generic" initrd (not tied to the host where mkinitrd ran) I had to find out which modules to include.
Using dracut this is just a matter of editing a config file and/or providing command-line options.

tramtrist 06-13-2022 06:29 AM
Irssi 1.4.1 is out. Using meson now
https://irssi.org/2022/06/12/irssi-1.4.1-released/

Tonus 06-13-2022 07:21 AM
Quote:
Originally Posted by Didier Spaier (Post 6360572)
Rationale: one less in-house software (mkinitrd and associated scripts) to maintain. I will check it usage during installation and following a kernel upgrade.

EDIT. let's give two examples:
  1. To embed a LUKS keyfile in the initrd and have it used by init, I had to modify init.
  2. To make a "generic" initrd (not tied to the host where mkinitrd ran) I had to find out which modules to include.
Using dracut this is just a matter of editing a config file and/or providing command-line options.
I don't understand (my weak english perhaps).
For 1 I had no change to do in init script.
For 2 it's a matter of how generic you wanna be.
For both you could have sane defaults in /etc/mkinitrd.conf

I might be wrong and would be thankful if you could shed some light...

Edit : misread the 1. But what is the point to encrypt while you give the key ??

teoberi 06-13-2022 08:30 AM
Quote:
Originally Posted by Didier Spaier (Post 6359293)
As Daniel Kiper just posted on the grub-devel mailing list: https://lists.gnu.org/archive/html/g.../msg00035.html

So I suggest to upgrade GRUB from git master as Daniel wrote "Now all the GRUB2 upstream patches are in the GRUB2 git repository too".

You can git checkout 2f4430cc0a44fd8c8aa7aee5c51887667ad3d6c3 I think this is the last commit of this patch set

I suggest to apply this as well to 14.2.
https://lists.gnu.org/archive/html/g.../msg00083.html
Quote:
I am going to release GRUB 2.12 around October 2022.
I am not going to release any of earlier released versions with recent security fixes on top of them.
Good guys:mad:, too bad for GRUB.
Escape who can:)!
Debian patch folder.

LuckyCyborg 06-13-2022 09:21 AM
Quote:
Originally Posted by Tonus (Post 6360606)
For 1 I had no change to do in init script.
Well, in the initrd root exists a script named "init" which is automatically executed by the kernel.

Quote:
Originally Posted by Tonus (Post 6360606)
For 2 it's a matter of how generic you wanna be.
Well, a common misconception is that you should hard code in the initrd which root partition you have.

In fact, you can specify in the bootloader configuration a series of parameters passed to initrd: root, rootfs and rootflags, which usually are enough for a "generic" initrd to do its job for the usual systems.

For further options, someone may need to modify the initrd's init script, then the mkinitrd package.

Quote:
Originally Posted by Tonus (Post 6360606)
For both you could have sane defaults in /etc/mkinitrd.conf
Well, dracut (and any other initrd systems) used by the major distributions are very modular and configurable things.

Quote:
Originally Posted by Tonus (Post 6360606)
Edit : misread the 1. But what is the point to encrypt while you give the key ??
Maybe the Russians have a particular rich imagination, but I can imagine instantly an example: how about a bootable USB dongle, which automatically decrypt the hard drive or its partitions? Walking away with the USB dongle will leave the box in an unbootable and undecryptable state.

However, unfortunately I do not believe that Dracut will be adopted. Because looks that they do not have so much consideration for initrds.

Didier Spaier 06-13-2022 09:30 AM
Quote:
Originally Posted by Tonus (Post 6360606)
I don't understand (my weak english perhaps).
For 1 I had no change to do in init script.
You do, to embed the LUKS key in the initrd (as you realized, cf. your edit)
Quote:
For 2 it's a matter of how generic you wanna be.
My goal was (and still is) to make Slint portable if installed on a removable drive, i.e. be usable with the drive plugged in on pretty much any computer. To do that using dracut you just have to type as root:
Code:
dracut
Using mkinird instead I had to cook a rather fragile code snippet
Code:
portable() {
    [ ! "$PORTABLE" ] && return
    echo "portable" >>$INSTALL/log
    echo "The presence of this file indicates that this system should be portable." > $SLINT/etc/portable
    rootdelay=10
    KERNELVERSION=$(ls $SLINT/boot/vmlinuz-generic-*|cut -d- -f3)
    HOST_AND_STORAGE=$(find $SLINT/lib/modules/$KERNELVERSION/kernel/drivers/ -name "*.ko"|grep -e "/storage/" -e "/host/" -e "/core/"|grep -v -e /staging/ -e /inifiniband/|sed "s,.*/,,;s/.ko//;s/$/:/"|tr -d '\n')
    FS="btrfs:ext2:ext4:f2fs:jfs:reiserfs:xfs:crc32_generic:crc32_pclmul:"
    USB_KBD="uhci-hcd:usbhid:"
    MODENCRYPT="af_alg:algif_skcipher"
    FSTYPE=$(cat $INSTALL/fstype)
    DRIVEPATH=$(cat $INSTALL/drivepath)
    sed "/GRUB_DISABLE_OS_PROBER/s/.*/GRUB_DISABLE_OS_PROBER=true/" $SLINT/etc/default/grub >bof
    mv bof $SLINT/etc/default/grub
    if [ "$ENCRYPT" ]; then
        sed "/#GRUB_ENABLE_CRYPTODISK/s/.*/GRUB_ENABLE_CRYPTODISK=y/
        /GRUB_PRELOAD_MODULES/s/.*/GRUB_PRELOAD_MODULES=\"luks cryptodisk\"/
        /^GRUB_DISABLE_LINUX_PARTUUID/s/.*/GRUB_DISABLE_LINUX_PARTUUID=true/
        /^GRUB_DISABLE_LINUX_UUID/s/.*/GRUB_DISABLE_LINUX_UUID=false/" $SLINT/etc/default/grub >bof
        mv bof $SLINT/etc/default/grub
    fi
    MODULES="$HOST_AND_STORAGE$FS$USB_KBD$MODENCRYPT"
    chroot $SLINT grub-install --target=i386-pc  $DRIVEPATH 1>>$INSTALL/log 2>>$INSTALL/errors
    chroot $SLINT grub-install --target=x86_64-efi --no-nvram --bootloader-id=slint $DRIVEPATH 1>>$INSTALL/log 2>>$INSTALL/errors
    mkdir -p $SLINT/boot/efi/EFI/BOOT
    cp  $SLINT/boot/efi/EFI/slint/grubx64.efi $SLINT/boot/efi/EFI/BOOT/BOOTx64.EFI
    echo "EFI\slint\grubx64" > /SLINT/boot/efi/startup.nsh
    lsblk -l -o uuid,type,name|grep part| \
    sed "s, *\([^ ]*\) *[^ ]*  *\([^ ]*\).*,s;/dev/\2;UUID=\1;," > $SLINT/tmp/part_list
    chroot $SLINT geninitrd 1>>$INSTALL/log 2>>$INSTALL/errors
    if [ "$ENCRYPT" ]; then
        chroot $SLINT cp -a /etc/keys/root$KEYFILE /boot/initrd-tree/$KEYFILE
        chroot $SLINT mkinitrd \
        -k $KERNELVERSION \
        -m $MODULES \
        -K /$KEYFILE \
        -C UUID=$(cat $INSTALL/rootcryptuuid):cryptroot  \
        -w $rootdelay \
        -r UUID=$(cat $INSTALL/rootuuid) \
        -o /boot/initrd-generic-$KERNELVERSION 1>>$INSTALL/log 2>>$INSTALL/errors
    else
        # we run mkinitrd again (after geninitrd) to include the setting
        # -w rootdelay and the modules
        chroot $SLINT mkinitrd \
        -k $KERNELVERSION \
        -w $rootdelay \
        -m $MODULES \
        -o /boot/initrd-generic-$KERNELVERSION 1>>$INSTALL/log 2>>$INSTALL/errors
    fi
    cat <<-EOF >>$SLINT/etc/grub.d/40_custom
    menuentry "Detect and boot installed operating systems" {
    set sg2d_directory="/boot/grub"
    export sg2d_directory
    configfile "/boot/grub/main.cfg"
    }
    EOF
    ( cd  $ISO/boot/grub/
    cp osdetect.cfg tools.cfg main.cfg grub-mkrescue-sed.sh \
    $SLINT/boot/grub/
    )
    chroot $SLINT /usr/sbin/update-grub 1>>$INSTALL/log 2>>$INSTALL/errors
    cat <<-EOF >> $SLINT/tmp/post-install
    if [ ! -f /etc/fstab.orig ]; then
        cp /etc/fstab /etc/fstab.orig
    fi
    sed -f /tmp/part_list /etc/fstab > dummy
    mv dummy /etc/fstab
    sed "/# Initially/d" /etc/fstab > dummy
    mv dummy /etc/fstab
    EOF
    chmod 0755 $SLINT/tmp/post-install
    chroot $SLINT /tmp/post-install 1>>$INSTALL/log 2>>$INSTALL/errors
}
I'd like to make this simpler, more robust and needing less maintenance
Quote:
For both you could have sane defaults in /etc/mkinitrd.conf
I'd be pleased to see these sane defaults...

Quote:
I might be wrong and would be thankful if you could shed some light...
I hope this post answers that.

Quote:
Edit : misread the 1. But what is the point to encrypt while you give the key ??
The key is typed by the user during installation. Indeed it can easily be stolen if the system is running unattended. But in this case anyone having physical access to the machine can do anything with it anyway.The use case I have in mind is rather "my (fully shut down) laptop (or the drive) is stolen while traveling". Then the drive is fully protected, as the initrd is in the root partition, which itself is inside a LUKS encrypted device (decrypted by grub when you type the passphrase before displaying its boot menu).

PS Didn't see the answer from LuckyCyborg before posting.
PS2 Je pourrais écrire en Français (plus facile pour toi comme pour moi) mais c'est interdit par le réglement...

Didier Spaier 06-13-2022 10:16 AM
Quote:
Originally Posted by teoberi (Post 6360630)
https://lists.gnu.org/archive/html/g.../msg00083.html

Good guys:mad:, too bad for GRUB.
Escape who can:)!
Debian patch folder.
Yes I have seen this message from Daniel. And I assume that applying the zillion patches from Debian is too demanding in terms on manpower for Slackware, considering that a cherry pick would be in order as some are for contexts or architectures not in Slackware scope. Further Patrick would need to update the patches too when Debian does it. Too much work for little benefit in my opinion, hence my proposal to just pull from git up to a specific commit, without taking any not yet upstream-ed patch. I would not recommend that for other software, but having followed GRUB development since several years I am pretty sure Daniel would not apply any proposed patch set without a good rationale, a good documentation and serious testing and review.


All times are GMT -5. The time now is 09:07 PM.
Page 51 of 318 « First 414950 51 525361101151 Last »
Show 50 post(s) from this thread on one page