Re: building marlin for a 3d printer, what compiler do I use for STM-32 based boards, doing it on an arm64 system?
I've not personally used it, but you're probably looking for gcc-arm-none-eabi signature.asc Description: This is a digitally signed message part
Re: DNSSEC working but SSHFP reported as insecure
> Where am I making a mistake, please ? I think I know the problem. On the client machine, by default glibc doesn't indicate to applications that DNS records were signed via DNSSEC. This is because, how is glibc to know whether the DNS servers it's getting its records from is supposed to be considered trustworthy? It might be some DNS server set up by your ISP or something, and you might not want to place your full trust in them. I believe your server is configured correctly. However, in order for GNU/Linux clients to take advantage of DNSSEC, they typically need to run validating DNS resolvers locally that can be trusted, AND set a glibc option in /etc/resolv.conf letting glibc know that the signatures can be trusted. I'm not a DNS aficionado, so someone please correct me if I got the details wrong signature.asc Description: This is a digitally signed message part
Re: USB WiFi Adapter
I would like to recap some points that've already been shared in this thread and also give some advice for those who want to use libre USB Wi- Fi adapters with Debian GNU/Linux. The best one can do with free software right now is 802.11n. There are two main families of chipsets for USB wireless adapters, ath9k_htc (AR7010 & AR9271) and "carl9170" (AR9170). The latter has some issues with 802.11n setups, so the former should be preferred. AR9271 is never dual-band capable; it is always 2.4GHz only. Whether an AR7010 or AR9170 adapter is dual-band capable depends on what wireless chip it is paired with. In general dual-band capable AR7010 adapters are somewhat challenging to find, but dual-band AR9170 adapters are easy to find. For those interested in the technical details, ath9k_htc uses a custom Xtensa CPU and as such requires a custom cross toolchain. Currently we build this free firmware in Debian completely from source, which is quite an achievement! I'm the current maintainer of open-ath9k-htc- firmware in Debian (more on that package later), but much credit goes to the former maintainer Oleksij Rempel, especially for his encouragement of me. AR9170 uses an ordinary SuperH-2 CPU, and as such the carl9170 firmware can be built with a standard SuperH cross toolchain. I've currently packaged gcc-sh-elf and binutils-sh-elf in Debian Unstable, so that when I get around to it (or when someone I can mentor expresses interest ️) we can build carl9170 from source as well. The firmware for AR9170 (AKA carl9170) is currently shipped in the firmware-linux-free package. However, due to complicated historical reasons, the firmware for ath9k_htc is in a separate firmware-ath9k-htc package, which tragically is not installed by default like all other free firmware is. There is a common misconception that because ath9k_htc adapters don't work out-of-the-box, but because the firmware also happens to be in the non-free firmware-atheros package, that this is actually non-free. That's not true; it's a fluke that the ath9k_htc firmware is in firmware-atheros, and we're working to get it removed from there. So here's what I want to emphasize: if there's a chance you'll be using an ath9k_htc adapter, install the firmware-ath9k-htc package. If you don't know whether the adapter you have (or will have) has ath9k_htc, installing that package won't hurt. In general, for issues such as this, one should consult the Free Software Foundation's Respects Your Freedom program, which certifies devices that are guaranteed to be the best one can do with free software. ThinkPenguin is just one of many vendors that sells USB wireless adapters that work with free software+firmware. Also, neither carl9170 nor ath9k_htc work with the Debian Installer right now, so if one needs to install over Wi-Fi, the Live installer should be considered. Disclaimer: I have been compensated by ThinkPenguin, an FSF RYF vendor, for my Debian wireless packaging work. If anyone has questions on the matter, or would like to help with wireless hacking, anyone is welcome to reach me privately. signature.asc Description: This is a digitally signed message part
devscripts 'bts' mail setup
I'm having trouble configuring bts via ~/.devscripts, though similar settings do work for Reportbug, and I'm looking for help solving this. I want bts to send mail via SMTP, so this is how the relevant lines of .devscripts looks right now. BTS_SMTP_HOST=posteo.de:587 BTS_SMTP_AUTH_USERNAME=jsc...@posteo.net The man page says * BTS_SMTP_AUTH_USERNAME, BTS_SMTP_AUTH_PASSWORD If these options are set, then it is the same as the --smtp-username and -- smtp-password options being used. * --smtp-username=USERNAME, --smtp-password=PASSWORD If a username is specified but not a password, bts will prompt for the password before sending the mail. But bts never prompts for a password, saying only "mailx: Null message body; hope that's ok." Even putting the password in .devscripts doesn't make it work, and the mails don't send. The last thing I tried was setting BTS_SMTP_HELO. "Note that some SMTP servers may reject the use of a HELO which either does not resolve or does not appear to belong to the host using it." My /etc/mailname says X200, the name I gave this computer which clearly doesn't resolve. Is that normal? I put my public IPv4 address in BTS_SMTP_HELO which didn't make a difference. Thanks, I look forward to figuring this out. P.S. please CC me, I'm not subscribed to the list signature.asc Description: This is a digitally signed message part.
devscripts 'bts' mail setup
I'm having trouble configuring bts via ~/.devscripts, though similar settings do work for Reportbug, and I'm looking for help solving this. I want bts to send mail via SMTP, so this is how the relevant lines of .devscripts looks right now. BTS_SMTP_HOST=posteo.de:587 BTS_SMTP_AUTH_USERNAME=jsc...@posteo.net The man page says * BTS_SMTP_AUTH_USERNAME, BTS_SMTP_AUTH_PASSWORD If these options are set, then it is the same as the --smtp-username and -- smtp-password options being used. * --smtp-username=USERNAME, --smtp-password=PASSWORD If a username is specified but not a password, bts will prompt for the password before sending the mail. But bts never prompts for a password, saying only "mailx: Null message body; hope that's ok." Even putting the password in .devscripts doesn't make it work, and the mails don't send. The last thing I tried was setting BTS_SMTP_HELO. "Note that some SMTP servers may reject the use of a HELO which either does not resolve or does not appear to belong to the host using it." My /etc/mailname says X200, the name I gave this computer which clearly doesn't resolve. Is that normal? I put my public IPv4 address in BTS_SMTP_HELO which didn't make a difference. Thanks, I look forward to figuring this out. P.S. please CC me, I'm not subscribed to the list signature.asc Description: This is a digitally signed message part.
