bug#65684: kaidan package is broken and does not start
On Fri, Sep 01, 2023 at 02:00:11PM -0500, bdju via Bug reports for GNU Guix wrote: > I am running Guix System and using Sway (Wayland). > When trying to launch Kaidan from a shell I get the following errors: > 13:58:25.845|qt.qpa.plugin|W|Could not find the Qt platform plugin "wayland" > in "" > 13:58:26.210|default|D|QT_QUICK_CONTROLS_STYLE not set, setting to > "org.kde.desktop" > 13:58:26.704|default|W|QQmlApplicationEngine failed to load component > 13:58:26.704|default|W|qrc:/qml/main.qml:90:29: Type RosterPage unavailable > 13:58:26.704|default|W|qrc:/qml/RosterPage.qml:50:2: Type > RosterAddContactSheet unavailable > 13:58:26.704|default|W|qrc:/qml/elements/RosterAddContactSheet.qml:84:3: Type > Controls.TextArea unavailable > 13:58:26.704|default|W|file:///gnu/store/y7lkx97ylj0aidzsp06b0455kr300b1i-qqc2-desktop-style-5.108.0/lib/qt5/qml/QtQuick/Controls.2/org.kde.desktop/TextArea.qml:15:1: > module "org.kde.sonnet" is not installed > > Based on discussion in IRC it sounds like some inputs are missing, > sonnet and kdeclarative > Other users were able to reproduce this issue on their machine. > > Discussion: https://logs.guix.gnu.org/guix/2023-09-01.log#203513 Fixed in c535374ef4f6c81db94003c626d2464b9c13a867 -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
bug#65809: [mumi] [wishlist] Allow searching subject prefix
Hello, IMO is useful to be able to search for "subject:foo", it's a different search than searching for foo in the body in file mumi/xapian.scm I read: --8<---cut here---start->8--- ;; Index subject and body without prefixes for general ;; search. (index-text! term-generator subjects) (increase-termpos! term-generator) (index-text! term-generator text) --8<---cut here---end--->8--- Is it possible to add such a feature please? Thanks! Gio' P.S.: I did not Cc: Ricardo Wurmus since AFAIU he prefers not to continue developing this -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
bug#65741: Thanks for debugging!
Hi Bruno, I also noticed that message. Thanks for proposing a fix! Kind regards Felix
bug#65808: (accidentally) removing and re-adding user not handled
Sorry, kind of in a hurry, this might be rushed. Short version: I accidentally commented out my user, reconfigured, realized my mistake, rolled back (logging in was tricky, not sure what made it work), had to add a password again with passwd, got new UID, had to chown -R my $HOME, tried to guix pull --roll-back, but had to chown my /var/run/guix/per-user thing too.
bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that)
Hi, On Wed, 30 Aug 2023 at 12:39, "Dr. Arne Babenhauserheide" wrote: > Please don’t remove packages that are broken on the CI. I often had a > case where no substitute was available but the package built just fine > locally. This is not a perfect situation (nicer would be to track why it > doesn’t come from CI — sometimes it’s just a resource problem on the > CI), but if you removed a package I use that would break all updates for > me. Well, I do not think that any policy will mark a package for removal on the first build failure. However, if the same package is still failing after several X or attempts, it means something is wrong. Marking it as a candidate for removal implies: 1. check if the failure is from CI when it builds locally, 2. keep a set of packages that we know they are installable. For instance, ocaml4.07-* packages are failing since more or less April. https://data.guix.gnu.org/repository/1/branch/master/package/ocaml4.07-ppxlib/output-history Does it make sense to keep them? For another example, some perl6-* packages are failing since… 2021. https://data.guix.gnu.org/repository/1/branch/master/package/perl6-xml-writer/output-history Does it make sense to keep them? The usual situation is that CI is able to build the packages. The set of packages that CI is not able to build is very limited and it is the exception. Having a rule to deal with the regular broken packages appears to me a good thing and very helpful to keep Guix reliable. And that rule cannot be based on rare exceptional cases. > If a change in packages breaks my manifest, that is extremely painful. Yeah, and such rule for dealing with broken packages will be helpful for detecting such change and so avoid such situation. Cheers, simon
bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that)
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. The question is the way to detect them. QA can do whatever we want but until people are helping Chris because, IMHO, Chris is already enough busy to keep stuff running, we probably need to keep our process simple enough in order to stay actionable and avoid some vacuum of “coulda, shoulda or woulda”. For what my opinion is worth on that. :-) Cheers, simon
bug#65759: Bug
Hi Sjors, "Sjors Provoost" writes: > Hi Josselin, > > Restarting the command a few times it kept failing at different packages, but > eventually made it through just fine. Glad it ended up working! Maybe an issue of builds OOM'ing, if the machine was already under some load? > The building machine is indeed x86_64-linux, the Bitcoin projects uses cross > compilation to make binaries for macOS (and requires you to download the SDK > and run a script to extract some stuff from it). That's nice to know, thanks! Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#65759: Bug
Oops, forgot to close. Feel free to re-open if something was missing. Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#65725: Acknowledgement (guix pull fails on riscv64)
Hi, much.effort283--- via Bug reports for GNU Guix writes: > Since openssl is already bumped from "1.1.1l" to a version that has > the bug fixed in the development branch, I presume this will be fixed > once the next guix release (1.5) is out? `guix pull` should pull the latest available commit on master, and so it should use the newer openssl version there. Can you retry, after rm'ing .cache/guix/checkouts? If it still mentions 1.1.1l, we might have a bug in `guix pull`. > In the meantime, I wonder if there is a workaround I can apply. I > tried compiling from source, but that seems to fail as well: Unfortunately, the latest source requires a patched po4a that was added very recently. I don't know if you can confidently build all of Guix locally without the doc, I haven't inspected the Makefile too closely. Sorry I couldn't be of much help. Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#65765:
Sharlatan Hellseher writes: > Hi, > > May you provide the way how to reproduce it? > >> guix time-machine --no-channel-files >> --commit=6113e0529d61df7425f64e30a6bf77f7cfdfe5a5 -- build celluloid >> /gnu/store/dps6ra33zfgpga7wig085p5k3bwdxqz2-celluloid-0.25 Hmm, can't reproduce it in a pure shell. Might be related to one of my environment variables. Although it kind of doesn't matter because thanks to GTK it might not even run on my machine. https://github.com/celluloid-player/celluloid/issues/251#issuecomment-278534566
