bug#65906: Deja-Dup having trouble with Duplicity being available on new install of Guix
Ubuntu 23.04 host OS, Ubuntu's native Deja-Dup and Duplicity were removed prior to installing from guix. When I installed Deja-Dup, it required duplicity to be installed. I installed it, and it still wasn't found. Deja-Dup requested and I granted permission to install duplicity on its own. Any idea what's going on with that? Deja-Dup definition for your convenience. https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnome.scm#n1815
bug#65890: [PATCH] gnu: Make vice tunable.
From: Csepp * gnu/packages/emulators.scm (vice)[properties]: Set tunable? to #t. --- This fixes the issue with unsupported AVX instructions. gnu/packages/emulators.scm | 1 + 1 file changed, 1 insertion(+) diff --git a/gnu/packages/emulators.scm b/gnu/packages/emulators.scm index 1d50c9ef01..dd1e3e877f 100644 --- a/gnu/packages/emulators.scm +++ b/gnu/packages/emulators.scm @@ -118,6 +118,7 @@ (define-public vice (package (name "vice") (version "3.7.1") +(properties '((tunable? . #t))) (source (origin (method url-fetch) base-commit: 07d43c66d5c11fef61f9846fefb97fa18e4764f1 -- 2.41.0
bug#65890: VICE encounters illegal instruction
Csepp writes: > trying to run a music disk, but even if I pass no parameter, I get the > same error at the end > > % xplus4 TED-Vibes-2.d64:( > Detecting ISA HardSID boards. > Could not open '/dev/port'. > Cannot get permission to access $300. > Detecting PCI HardSID boards. > No PCI HardSID boards found. > > *** VICE Version 3.7.1 *** > > Welcome to xplus4, the free portable PLUS4 Emulator. > > Current VICE team members: > Martin Pottendorfer, Marco van den Heuvel, Fabrizio Gennari, Groepaz, > Errol Smith, Ingo Korb, Olaf Seibert, Marcus Sutton, Kajtar Zsolt, AreaScout, > Bas Wassink, Michael C. Martin, Christopher Phillips, David Hogan, > Empathic Qubit, Roberto Muscedere, June Tate-Gans, Pablo Roldan. > > This is free software with ABSOLUTELY NO WARRANTY. > See the "About VICE" command for more info. > > random seed was: 0x65004c19 > command line was: xplus4 TED-Vibes-2.d64 > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/kernal-318004-05.bin'. > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/basic-318006-01.bin'. > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/3plus1-317053-01.bin'. > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/3plus1-317054-01.bin'. > GTK3MOUSE: Status changed: 0 (disabled) > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/mps803.bin'. > Palette: Loading palette > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/mps803.vpl'. > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/nl10.bin'. > Palette: Loading palette > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/nl10.vpl'. > NL10: Printer driver initialized. > Palette: Loading palette > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/1520.vpl'. > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1540-325302+3-01.bin'. > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1541-325302-01+901229-05.bin'. > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1541ii-251968-03.bin'. > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1570-315090-01.bin'. > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1571-310654-05.bin'. > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1581-318045-02.bin'. > DriveROM: Error - 2000 ROM image not found. Hardware-level 2000 emulation is > not available. > DriveROM: Error - 4000 ROM image not found. Hardware-level 4000 emulation is > not available. > DriveROM: Error - CMDHD ROM image not found. Hardware-level CMDHD emulation > is not available. > Loading system file > `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1551-318008-01.bin'. > Drive: Finished loading ROM images. > Sound: Available sound devices: pulse alsa dummy fs dump wav voc iff aiff > soundmovie > using GTK3 backend: OpenGL > chip_name: TED > screen_size: 384 x 312 > first/lastline: 0 x 0 > gfx_size: 320 x 200 > gfx_position: 32 x 59 > first/last displayed line: 19 x 306 > extra offscreen border left/right: 28 x 228 > screen_display_wh: 0.00 x 0.00 > canvas_physical_wh: 0 x 0 > scalexy: 2 x 2 > sizexy: 1 x 1 > rmode: 1 > aspect ratio: 1.037435 > hstretch: 0 > vstretch: 0 > initializing with width, height: 704 x 574 > GLX version: 1.4 > Getting matching framebuffer configs > Found 6 matching FB configs. > Error - Failed to obtain an OpenGL 3.2 context, requesting a legacy context > > Obtained OpenGL 2.1 context > Vendor: Intel > Renderer: Mesa Mobile Intel® GM45 Express Chipset (CTG) >Version: 2.1 Mesa 23.1.4 > Legacy: yes > Direct GLX rendering context obtained > Swap control support. glXSwapIntervalMESA: 1 glXSwapIntervalEXT: 1 > glXSwapIntervalSGI: 1 > Created render thread 0 > Render thread initialised > Joystick: Linux joystick interface initialization... > Joystick: Warning - Cannot open joystick device `/dev/input/js0'. > Joystick: Warning - Cannot open joystick device `/dev/input/js1'. > Joystick: Warning - Cannot open joystick device `/dev/input/js2'. > Joystick: Warning - Cannot open joystick device `/dev/input/js3'. > Joystick: Warning - Cannot open joystick device `/dev/input/js4'. > Joystick: Warning - Cannot open joystick device `/dev/input/js5'. > Joystick: Warning - Cannot open joystick device `/dev/input/js6'. > Joystick: Warning - Cannot open joystick device `/dev/input/js7'. > Loading keymap >
bug#65889: texlive-acronyms is missing dependencies
Hi Guix!
The following MWE does not compile with pdflatex using the modular
texlive packages:
--8<---cut here---start->8---
\documentclass{article}
\usepackage{acronym}
\begin{document}
\end{document}
--8<---cut here---end--->8---
It yields the following:
--8<---cut here---start->8---
$ guix shell texlive-scheme-basic texlive-acronym -- pdflatex acronym-mwe.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/GNU Guix)
(preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./acronym-mwe.tex
LaTeX2e <2022-11-01> patch level 1
L3 programming layer <2023-02-22>
(/gnu/store/v4m2fj7xhpfs7k5l97p238j1bc2ccppf-profile/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2022/07/02 v1.4n Standard LaTeX document class
(/gnu/store/v4m2fj7xhpfs7k5l97p238j1bc2ccppf-profile/share/texmf-dist/tex/latex/base/size10.clo))
(/gnu/store/v4m2fj7xhpfs7k5l97p238j1bc2ccppf-profile/share/texmf-dist/tex/latex/acronym/acronym.sty
! LaTeX Error: File `suffix.sty' not found.
Type X to quit or to proceed,
or enter new name. (Default extension: sty)
Enter file name:
--8<---cut here---end--->8---
I think this is due to missing dependencies suffix and xstring which are
required to be installed for acronym to work. On page 10 of the package
docs [1] it reads
\RequiredPackage{suffix, xstring}
1: https://ftp.gwdg.de/pub/ctan/macros/latex/contrib/acronym/acronym.pdf
I can provide a patch if desired to add texlive-xstring and
texlive-bigfoot to texlive-acronym’s (propagated-)inputs. The suffix
package appears to be bundled with texlive-bigfoot. Do we want to
unbundle it or simply add texlive-bigfoot to the (propagated-)inputs?
Best
--
Daniel
bug#65881: FSDG violation in alex4
According to alex4's author, its license (GPLv2 or later) applies only to the software, not to any of the data. The data don't have a license specified, and are therefore proprietary. They should either be replaced (if there is a free replacement) or the package removed. Source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035043 https://libregamewiki.org/Talk:Alex_the_Allegator_4 OpenPGP_0x1D43EF4F4492268B.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that)
Op 07-09-2023 om 13:32 schreef Simon Tournier: Hi, On Tue, 29 Aug 2023 at 10:45, Maxim Cournoyer wrote: It's frustrating for users when a package is missing, but it's also frustrating/inefficient for maintainers to stumble upon broken packages when checking if an upgrade broke dependent packages (it takes time to build them just to find out they fail, and researching they already did), so a balance is needed. There is nothing worse as an user to have this experience: guix search foobar oh cool, foobar is there, let try it, guix shell foobar … wait … … stuff are building … … laptop is burning … … wait … Bang! Keeping broken packages is just annoyances. Contributor are annoyed because as said by the paragraph above. And user are annoyed as described just above. > I am in favor to set a policy for removing then. You don't need to keep broken packages, they can be fixed instead. Although given later e-mails, I suppose that this hypothetical policy for removing them would contain things about fixing them instead. It's this focus on 'broken -> delete' that bothers me, why is the first reaction ‘delete them’, not ‘fix them’? Op 11-09-2023 om 16:00 schreef Simon Tournier: If you care about one package that is marked to be removed soon, then you fix it or raise your concern. Else it means no one care and so what is the point to keep broken packages that no one uses? It doesn't mean that. As I wrote previously: We could bump the expiry time to 180 days, or even 365 days (a full year). If nobody opens an issue for a broken package in that amount of time, it's probably not used much if at all and may not be worth the maintenance burden. [...] No, it doesn't mean that that the package is not used much, it could instead mean that the people using the package (or interested in using the package, if it was already broken when they discovered it) thought that the existence of ci.guix.gnu.org means that contributors doing Guix maintenance already know that the package is broken and assumed that it would be fixed, and that a new bug report would just be annoying the contributors because they already have a bug report: the build failure on ci.guix.gnu.org. --- > The more important question is (serious question and *not* for > assigning blame, but to see whether we can improve processes): with > the time we already spent in this discussion, we could have fixed a > lot of packages. Why did we not do that? Speaking only for myself: * (because I chose to mostly not work on Guix anymore for reasons that aren't relevant to this discussion) * if I were to fix broken packages, I would like others to avoid creating new breakage (and if breakage occurs, then fix it it early). (Otherwise, not much point to it ...) Hence, there needs be some discussion to ensure that other people don't do that new breakage in the future. * hearing ‘delete it’ as first reaction to ‘broken package’ is rather demoralising to people fixing packages. It's so ... defeatist. Sure people with this reaction add a few qualifiers to when it is to _not_ be removed, but it sounds rather hollow. Instead of having a ‘removal policy’ that lays down exceptions that indicate when the package should instead be kept, I would rather have a ‘fixing policy’ that has exceptions indicating when the package may instead be removed. In a sense, those are technically equivalent, but the different framing makes a difference in motivation. Best regards, Maxime Devos. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor
Hi Ricardo, Ricardo Wurmus writes: > Ludovic Courtès writes: > >> Hello! >> >> Ricardo Wurmus skribis: >> >>> I don’t know. I’m on holidays now, but I’ve opened yet another ticket >>> to get a definitive answer to my more elaborate variant of “WTF?”. >> >> Did you eventually get feedback from them? > > I got one response to ask for more information, which I supplied. > Nothing since. I requested a response just now. > >> If not, we can start looking for a way to move public-facing services >> elsewhere. (It may not be trivial because bayfront, which is the other >> node we’ve traditionally used for that, is super busy these days.) > > Yeah, I’d really like this to be fixed. It worked pretty well for > years, so these seemingly unnecessary changes and the way they are > applied without any recourse (and without anyone being able to confirm > that they have in fact changed somehing) really bother me. Agreed; I think it's premature to jump ship when we've had such a long and fruitful relationship; let's show some patience and tenacity toward a resolution. -- Thanks, Maxim
bug#65804: Bug report: "You found a bug"
Hi Lasse, Lasse Schlör writes: > As requested by Guix, I am reporting the bug with this email. > > I assume this bug happened upon a temporary loss of the internet connection. > Running the command anew continued fetching/downloading just fine. Seems to be the case, yes. Closing. Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#56567: [BUG] Gnome doesn't recognize applications path for flatpak
Liliana Marie Prikler writes: > Am Sonntag, dem 17.07.2022 um 06:03 + schrieb Jacob Hrbek: >> Why is making a user configuration saner in comparison to making it >> work out of the box? > Because in this instance "making it work out of the box" entails > statefulness that most Guix users would typically like to avoid. Plus, > we are not talking about a very complicated setup here, it's one line > of shell code to drop into your .bash_profile or similar: > > export > $XDG_DATA_DIRS="$HOME/.local/share/flatpak/exports/share:$XDG_DATA_DIRS > " > > Now granted, if you wanted to account for the fact that XDG_DATA_DIRS > could be empty on some systems (some foreign distros rely on the > implicit default), then you'd have to code around that, but that's > again not within the scope of Guix System. Since I am running into this same issue on Sway, *even though* I added that line to my Zsh profile, I don't think the user config route is the right one to recommend. Editing environment variables certainly *seems* easy, but I consider myself fairly adept at Linux and I could not tell you in what order they are loaded, and clearly it matters, since j4-dmenu-desktop gets the wrong variables when launched from Sway, but the right ones when launched from a terminal. Even though Sway was also run from a terminal, via dbus-run-session. So clearly there are a lot of moving parts, and a regular user who just wants desktop apps to work should not be expected to manually edit these files.
bug#65890: VICE encounters illegal instruction
trying to run a music disk, but even if I pass no parameter, I get the same error at the end % xplus4 TED-Vibes-2.d64:( Detecting ISA HardSID boards. Could not open '/dev/port'. Cannot get permission to access $300. Detecting PCI HardSID boards. No PCI HardSID boards found. *** VICE Version 3.7.1 *** Welcome to xplus4, the free portable PLUS4 Emulator. Current VICE team members: Martin Pottendorfer, Marco van den Heuvel, Fabrizio Gennari, Groepaz, Errol Smith, Ingo Korb, Olaf Seibert, Marcus Sutton, Kajtar Zsolt, AreaScout, Bas Wassink, Michael C. Martin, Christopher Phillips, David Hogan, Empathic Qubit, Roberto Muscedere, June Tate-Gans, Pablo Roldan. This is free software with ABSOLUTELY NO WARRANTY. See the "About VICE" command for more info. random seed was: 0x65004c19 command line was: xplus4 TED-Vibes-2.d64 Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/kernal-318004-05.bin'. Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/basic-318006-01.bin'. Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/3plus1-317053-01.bin'. Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/3plus1-317054-01.bin'. GTK3MOUSE: Status changed: 0 (disabled) Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/mps803.bin'. Palette: Loading palette `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/mps803.vpl'. Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/nl10.bin'. Palette: Loading palette `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/nl10.vpl'. NL10: Printer driver initialized. Palette: Loading palette `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/1520.vpl'. Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1540-325302+3-01.bin'. Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1541-325302-01+901229-05.bin'. Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1541ii-251968-03.bin'. Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1570-315090-01.bin'. Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1571-310654-05.bin'. Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1581-318045-02.bin'. DriveROM: Error - 2000 ROM image not found. Hardware-level 2000 emulation is not available. DriveROM: Error - 4000 ROM image not found. Hardware-level 4000 emulation is not available. DriveROM: Error - CMDHD ROM image not found. Hardware-level CMDHD emulation is not available. Loading system file `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1551-318008-01.bin'. Drive: Finished loading ROM images. Sound: Available sound devices: pulse alsa dummy fs dump wav voc iff aiff soundmovie using GTK3 backend: OpenGL chip_name: TED screen_size: 384 x 312 first/lastline: 0 x 0 gfx_size: 320 x 200 gfx_position: 32 x 59 first/last displayed line: 19 x 306 extra offscreen border left/right: 28 x 228 screen_display_wh: 0.00 x 0.00 canvas_physical_wh: 0 x 0 scalexy: 2 x 2 sizexy: 1 x 1 rmode: 1 aspect ratio: 1.037435 hstretch: 0 vstretch: 0 initializing with width, height: 704 x 574 GLX version: 1.4 Getting matching framebuffer configs Found 6 matching FB configs. Error - Failed to obtain an OpenGL 3.2 context, requesting a legacy context Obtained OpenGL 2.1 context Vendor: Intel Renderer: Mesa Mobile Intel® GM45 Express Chipset (CTG) Version: 2.1 Mesa 23.1.4 Legacy: yes Direct GLX rendering context obtained Swap control support. glXSwapIntervalMESA: 1 glXSwapIntervalEXT: 1 glXSwapIntervalSGI: 1 Created render thread 0 Render thread initialised Joystick: Linux joystick interface initialization... Joystick: Warning - Cannot open joystick device `/dev/input/js0'. Joystick: Warning - Cannot open joystick device `/dev/input/js1'. Joystick: Warning - Cannot open joystick device `/dev/input/js2'. Joystick: Warning - Cannot open joystick device `/dev/input/js3'. Joystick: Warning - Cannot open joystick device `/dev/input/js4'. Joystick: Warning - Cannot open joystick device `/dev/input/js5'. Joystick: Warning - Cannot open joystick device `/dev/input/js6'. Joystick: Warning - Cannot open joystick device `/dev/input/js7'. Loading keymap `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/gtk3_sym.vkm'. HOTKEYS: Hotkeys: Initializing. HOTKEYS: Hotkeys: Parsing PLUS4 hotkeys file: HOTKEYS: Hotkeys: OK. AUTOSTART: Autodetecting image type of `TED-Vibes-2.d64'. AUTOSTART:
bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor
Ludovic Courtès writes: > Hello! > > Ricardo Wurmus skribis: > >> I don’t know. I’m on holidays now, but I’ve opened yet another ticket >> to get a definitive answer to my more elaborate variant of “WTF?”. > > Did you eventually get feedback from them? I got one response to ask for more information, which I supplied. Nothing since. I requested a response just now. > If not, we can start looking for a way to move public-facing services > elsewhere. (It may not be trivial because bayfront, which is the other > node we’ve traditionally used for that, is super busy these days.) Yeah, I’d really like this to be fixed. It worked pretty well for years, so these seemingly unnecessary changes and the way they are applied without any recourse (and without anyone being able to confirm that they have in fact changed somehing) really bother me. But if our public services keep getting restricted I agree that we should look for an alternative way to host them. -- Ricardo
bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that)
Hi Arne, On Tue, 12 Sep 2023 at 01:12, "Dr. Arne Babenhauserheide" wrote: > I’m skipping a lot to get only to the most important points (save time > for us all). Good initiative, let me do the same. :-) > That’s why I wrote the following: > >> If we had a way to have placeholder packages (similar to the renamings) >> that emit warnings for missing packages but do not break the build, that >> would reduce the damage done by removing a package. But I think such a >> mechanism must be in place and tested before adding a rule to remove >> packages. > > This would cause us to collect a slowly growing list of removed packages > that will be ignored (except for the warning) in manifests. > > That way we would avoid breaking the setup when removing a package. > > (define-public-removed the-package-variable > (removed-package > (name "the-package-name") > (reason-for-removal "upstream stopped working a decade ago"))) > Here you are defining a policy: 1. set a rule for replacing the package by ’removed-package’ 2. set a rule for effectively removing this package Somehow you are discussing to have a rule to deal with the broken packages. A policy, no? :-) Having a rule to deal with the regular broken packages appears to me a good thing and very helpful to keep Guix reliable. Therefore, we agree that making a policy for dealing with broken packages is worth and it would help to have a better Guix. It appears to me better to know what I can expect as an user than to have some surprise after each “guix pull”. I have in mind the sudden removal of Python 2 packages for instance. With such policy, it would have been smoother, IMHO. That’s said, two minor points that does not matter much. :-) I do not understand your explanations with the manifest because I do not see the difference if one element of your manifest is broken or if this very same element is removed. For the both cases, your manifest is broken, no? From the point of view of the profile generation, broken or removed does not change the result, isn’t it? Broken or removed only changes the process for investigating and try to fix, no? The only case where it could matter is if your manifest relies on package variant. That case, if the package becomes broken, the variant could not be. Well, if that’s the case, I would suggest that you maintain these packages using a plain copy of the inherited package. Because a perfectly working update could break your variant. I mean, if your manifest relies on package variant, then this manifest is highly dependant on the changes whatever the status of the package. In all cases, I share your concerns, and as you, I am time to time bitten by stuff that break. If I am honest, I barely update my base system. Before an update, I carefully check a commit using “guix time-machine” and test that my config works. Somehow I often use the command-line “guix time-machine -- shell -m”. On a side note, I am not convinced we will have the resource to change the package definition as your proposing. That’s another story and it appears to me the part of the discussion for a policy (strategy) for removing packages. I guess. :-) That’s long enough. ;-) Cheers, simon
