Re: LibreSSL?
Hello, Am Fri, Apr 01, 2022 at 10:41:11AM +0200 schrieb Ludovic Courtès: > At first sight, it looks like an easy-to-maintain package: no > dependencies, few users, stable API. > > I tried to update it to 3.5.1 and was proved wrong though: there’s one > test failure in ‘tests/asn1object’ and the Internet doesn’t seem to know > how to address the problem. So it would need a bit more work. > > I’d lean towards keeping it and doing that extra work, collectively, but > I understand this very discussion shows that it’s debatable. at some point in time, my understanding was that we would switch everything to libressl and drop openssl. I have not followed, but from https://lwn.net/Articles/841664/ it looks as if the problems with openssl are more or less solved, at least they are not worse than in libressl. So an option would be to try to switch the existing dependencies to openssl and decide from there. What do you think? Andreas
Re: Release v1.4?
On Fri, Jun 17, 2022, at 11:37 AM, Brian Cully via Development of GNU Guix and the GNU System distribution. wrote: > Ludovic Courtès writes: > >> So plain ‘emacs’ package doesn’t work on Wayland? That sounds >> like a >> recipe for a poor user experience, no? > > The mainline Emacs is not Wayland-native, but it (along with just > about everything else) will run fine under XWayland. It's how I've > been running it for some time now. The user experience is almost > indistinguishable from either the ‘pgtk’ branch or the mainline, > X-only branch. > I'm on a foreign distro, but FWIW I've been using plain Emacs 27 with the KDE Plasma Wayland session on HiDPI displays for over a year, and I have no complaints. In fact, I didn't even realize Emacs wasn't Wayland-native until this thread. I took a look just now at the 'emacs-next-pgtk' package in Guix: it does look a bit nicer in a side-by-side comparison, but it's subtle. Either way, mostly Emacs just looks like Emacs. So I don't think Emacs should be a blocker for enabling Wayland by default. -Philip
Re: guix refresh to a specific version?
Hi, Am 17.06.22 um 17:37 schrieb Ludovic Courtès: It’s currently not possible, but pretty much all the machinery is there, in importers. It’s a low-hanging fruit that I think we should pick! I gave it a try and discovered that we need to discuss the interface and design: One can already specify a version, which defines the package to be updated. The respective place the code has the comment Take either the specified version or the latest one. and this was added by you (Ludo) in 4b9b3cbbc45afa3e374889847d4ab8673b8b2db2 (April 2015): refresh: Allow users to refer to specific package versions. * guix/scripts/refresh.scm (guix-refresh): Use 'specification->package' instead of 'find-packages-by-name'. This allows users to specify things like "qt-4.8.6". Beside this, I'm unconfident about the implementation: Currently refresh passes around package objects and passes this to the updater. When updating to a specific version, we need to pass around both the package and the desired version, which implies case-handling at many places. Any idea how to solve this elegantly? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
