Search in commentsSearch detailsSearch for all wordsTasks I watchTasks not blocking other tasksTasks blocking other tasksBlocker or nonblocker, selecting both filter options doesn't make sense.Has attachmentHide SubTasks

A very nasty bug I wasn’t able to find an answer to.I compiled stuff (buildroot) using menuconfig, the menu display was fine in xfce4-terminal (See screenshot #1)I restarted the config a few days later with the same command :

$ make menuconfig

and this time the display was messed up (See screenshot #2)

After investigation, I noticed a directory (filled with stuff) have been created in my home folder :

.terminfo

I don’t know why. But anyway, if I delete it, then the display is ok again.I noticed that if I use good old xterm terminal, then the display is fine even if the .terminfo directory is present. (it uses “xterm” instead of xterm-256color)

But, with xfce4-terminal (and others, I tried with gnome-terminal, sakura..), the display is messed up if the .terminfo directory is present in my home folder.

I also noticed that if I run the command in a screen session, the issue is not present.

(I open xfce4-terminal)

$ screen
$ printenv TERM
screen.xterm-256color
$ make menuconfig (or htop, or other program using ncurses)

= display ok

but with default :

(I open xfce4-terminal)

$ printenv TERM
xterm-256color
make menuconfig (or htop, or other program using ncurses)

= display messed up if .terminfo directory is present

So I have no idea why this .terminfo directory is generated. What could trigger its generation ? Is that an issue with ncurses or something else ?

An issue was discovered in GNU patch through 2.7.6. There is a segmentation fault, associated with a NULL pointer dereference, leading to a denial of service in the intuit_diff_type function in pch.c, aka a “mangled rename” issue.

Description: Concurrent package ossp in version 1.3.2-15 has got dependencies to systemd, which is contradicting the whole distribution and the used INIT-system. Therefore my request to port this to OpenRC!

The security issues regarding the package which led to the package’s removal from Hyperbola (old WebKit and Vala dependency) have apparently been resolved in recent releases, see the new comment in this bug report and the latest PKGBUILD in Arch’s repo.

Since version 0.100 and later, there are some changes being redesigned from scratch, added three new weights (including extra bold, light and thin) but not italic or oblique styles, AppStream metadata translations from contributors, and more.

its like Lumina Desktop, but its more lightweight and better for Gnu/Linux

:)

Matter of fact, I hope its okay, but the latest stable build, of Draco is vastly better than Lumina. And for this reason I wanted to know if you could put higher priority on this than the Lumina Desktop request.

The Arch version of tinc from the snapshot used by Hyperbola comes with systemd support. Since Hyperbola follows the Init Freedom Campaign , systemd unit files removal is required or add OpenRC init scripts to replace it.

Steps to reproduce:I don't think "steps to reproduce" to be relevant in this case. My forum topic linked above already contains all the necessary info on the subject :) However, one could try compiling glibc and busybox as described here. Yes, these are instructions for debian-like systems. They have to be adapted accordingly

When I was adding this task, I put some long tags on it (html form allowed that) and got an error concerning too long tags field to fit in an sql datatype (max is 40 chars). Task got added anyway (just without tags). I didn’t know that and created it again.

wpa_supplicant may not work properly if directly passed via stdin particularly long or complex passphrases which include special characters. This may lead to errors such as failed 4-way WPA handshake, PSK may be wrong when launching wpa_supplicant.

In order to solve this try using here strings wpa_passphrase <MYSSID> «< “<passphrase>” or passing a file to the -c flag instead:

# wpa_supplicant -i <interface> -c /etc/wpa_supplicant/example.conf

In some instances it was found that storing the passphrase cleartext in the psk key of the wpa_supplicant.conf network block gave positive results (see [2]). However, this approach is rather insecure. Using wpa_cli to create this file instead of manually writing it gives the best results most of the time and therefore is the recommended way to proceed.Problems with eduroam and other MSCHAPv2 connections

This is my issue with wpa_supplicant sadly... and I do not know how to workaround that without a GUI.

but Wpa_Supplicant_gui does not fix it either, it doesn’t even load properly on my other laptop.

It says it cannot get the status of wpa_supplicant when I load it.

This could be an issue if you get rid of NetworkManager for some users.

So yeah, please take a look at my request okay? Wait for 0.3 to be released to add this if possible. I know you guys are overworked, etc... and it doesn’t need to be done now anyhow. ;)