bug#53300: Guix's is unable to correctly package qbittorrent-4.2.5
See https://github.com/qbittorrent/qBittorrent/issues/16139 and
forwarded message.
qbittorrent-4.2.5 declares python dependency on <=3.5.0
(https://github.com/qbittorrent/qBittorrent/blob/5c0378a6845e3484023f4c76893ff9f0e5178460/src/base/utils/foreignapps.cpp#L269)
which causes the program to fail with "Python is required to use the
search engine but it does not seem to be installed"
(https://github.com/qbittorrent/qBittorrent/blob/00f6bb7c8225285a7929426187a1513d247b582b/src/gui/mainwindow.cpp#L1834)
where Guix is only capable of providing python-3.9.6.
From Lepiller's response i understood that our development process is
to patch the package to accept new python which i argue is unhealthy and
hostile towards the upstream as we are putting an unwanted pressure on
their Quality Assurance which may force them to rush the process
As such proposing to package all python versions and enable to use a
version range per dependency.
Also python is notorious for it's dependency on various versions so this
would make all python packages (and packages with similar programming
language limitations) on guix more robust.
Forwarded Message
Subject: Re: Howddya specify max supported dependency version for a
package?
Date: Sun, 16 Jan 2022 09:46:53 +0100
From: Julien Lepiller
Reply-To: Julien Lepiller
To: Jacob Hrbek , help-g...@gnu.org
Simple unhelpful answer, you can't. Guix doesn't work like that. We
don't specify package range or give a package any way to choose itt
dependencies. When you specify a dependency, it's always a reference to
a very specific packaqe (though the reference might evolve with newer
guix revisions). It simplifies package management since there's no
constraint solving or anything of the sort.
For your problem I see two potential solutions: fix the package to allow
our current python version, though there might be a reason why it's not
allowed, or package python 3.5 and use it instead of the current python
version.
HTH
Le 16 janvier 2022 08:03:53 GMT+01:00, Jacob Hrbek
a écrit :
(define-public qbittorrent
(package
(name "qbittorrent")
(version "4.2.5")
(source
(origin
(method git-fetch)
(uri (git-reference
(url"https://github.com/qbittorrent/qBittorrent";)
(commit (string-append "release-" version
(file-name (git-file-name name version))
(sha256
(base32 "1n613ylg6i9gisgk0dbr2kpfasyizrkdjff1r8smd4vri2qrdksn"
(build-system gnu-build-system)
(arguments
`(#:configure-flags
(list (string-append "--with-boost-libdir="
(assoc-ref %build-inputs "boost")
"/lib")
"--enable-debug"
"QMAKE_LRELEASE=lrelease")
#:modules ((guix build gnu-build-system)
(guix build qt-utils)
(guix build utils))
#:imported-modules (,@%gnu-build-system-modules
(guix build qt-utils))
#:phases
(modify-phases %standard-phases
(add-after 'install 'wrap-qt
(lambda* (#:key outputs inputs #:allow-other-keys)
(let ((out (assoc-ref outputs "out")))
(wrap-qt-program "qbittorrent" #:output out #:inputs
inputs))
#t)
(native-inputs
(list pkg-config qttools))
(inputs
`(("boost" ,boost)
("libtorrent-rasterbar" ,libtorrent-rasterbar)
("openssl" ,openssl)
;; NOTE(Krey): Max supported version declared in
https://github.com/qbittorrent/qBittorrent/blob/5c0378a6845e3484023f4c76893ff9f0e5178460/src/base/utils/foreignapps.cpp#L269
("python" ,python-wrapper)
("qtbase" ,qtbase-5)
("qtsvg" ,qtsvg)
("zlib" ,zlib)))
(home-page"https://www.qbittorrent.org/";)
(synopsis "Graphical BitTorrent client")
(description
"qBittorrent is a BitTorrent client programmed in C++/Qt that uses
libtorrent (sometimes called libtorrent-rasterbar) by Arvid Norberg.
It aims to be a good alternative to all other BitTorrent clients out there.
qBittorrent is fast, stable and provides unicode support as well as many
features.")
(license l:gpl2+)))
I am trying to make a patch to fix
https://github.com/qbittorrent/qBittorrent/issues/16139 which is caused
by us using an unsupported python version -> How can i specify that the
package is only allowed to use python 3.2 <= 3.5.0 ?
-- Jacob Hrbek
publickey - kreyren@rixotstudio.cz - 1677db82.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
bug#53301: Ungoogled-chromium lacks VP8 codec support preventing jitsi screensharing
Created wiki entry about the issue https://guix.miraheze.org/wiki/Packages/Chromium On 1/16/22 11:27, Jacob Hrbek wrote: See forwarded message Steps to reproduce: 0. Get ungoogled-chromium 1. Open a call on jitsi e.g. https://jit.si/ILoveKreyren2Much 2. Start a screenshare 3. Join the call from a different browser and expect the screenshare to malfunction either with tab crashing with "Aw, snap" or the screen share changing on black screen and chromium printing this to the console: [18990:23:0116/111829.036853:ERROR:webrtc_video_engine.cc(3446)] Absent receive stream; ignoring clearing encoded frame sink for ssrc 0 [18990:12:0116/111836.246422:ERROR:video_stream_encoder.cc(1827)] Failed to encode frame. Error code: -7 [18990:12:0116/111834.601625:ERROR:video_stream_encoder.cc(1149)] Failed to initialize the encoder associated with codec type: VP8 (1) I assume that we need to include VP8 codec Forwarded Me ssage Subject:Re: Jitsi Meet Screen Sharing with Ungoogled-Chromium Date: Sun, 16 Jan 2022 11:24:28 +0100 From: Jacob Hrbek To: help-g...@gnu.org > Third party not a guix package Those are not supported by GNU Guix and will be met with hostility, because how dare you unfree scum! --- Good thing that i ain't a bad person.. not part of GNU Guix to help! :p Last time i tried it it worked out-of-the-box for me, i tested it now again and also works without problem GNU Guix (374fea0f3bc8035f626cb29e6045130df9ffdaf8) with ungoogled-chromium-97.0.4692.71-1 Which was tested on the https://meet.jit.si instance.. Provide a javascript console log which should have an explanation for this failure.. My current hypothesis is that your chromium doesn't provide a sufficient/sane TURN server and so jitsi crashes. See https://serverfault.com/questions/591837/how-does-chrome -webrtc-select-which-turn-server-to-use-if-multiple-options-are-g on how to change the turn server. ..and to comply with GNU FSDG i have to tell you that using non-ungoogled chromium and 3rd party repos is unethical as it most likely contains nonfree blobs which limit user freedom and contain malware as such i am providing content of ~/.config/chromium in attachment which should make your chromium more libre and i am also encouraging you to use ungoogled-chromium. EDIT: I missed the part with screensharing x.x .. on mentioned chromium it starts printing: [18990:23:0116/111829.036853:ERROR:webrtc_video_engine.cc(3446)] Absent receive stream; ignoring clearing encoded frame sink for ssrc 0 [18990:12:0116/111836.246422:ERROR:video_stream_encoder.cc(1827)] Failed to encode frame. Error code: -7 [18990:12:0116/111834.601625:ERROR:video_stream_encoder.cc(1149)] Failed to initialize the encoder associated with codec type: VP8 (1) in the console when i have screenshare and when someone joins and the screen share changes to a black screen so i believe that this is a bug due to the lack of sufficient VP8 codec. On 1/16/22 10:46, Yasuaki Kudo wrote: Is there anyone here who uses Jitsi Meet to share screens from Guix? Let me know! At least in version 90 of chromium (third party, not a guix package), it used to work. With the current ungoogled-chromium on Guix, the moment someone else connects to the Jitsi session, ungooogled-chromium dies with an 'aw, snap' message. -Yasu -- Jacob Hrbek -- Jacob Hrbek publickey - kreyren@rixotstudio.cz - 1677db82.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
bug#53300: Acknowledgement (Guix's is unable to correctly package qbittorrent-4.2.5)
Invalid it's >=3.5.0 meaning 3.5.0 and up i missread the code On 1/16/22 10:52, help-debb...@gnu.org wrote: Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): bug-guix@gnu.org If you wish to submit further information on this problem, please send it to 53...@debbugs.gnu.org. Please do not send mail to help-debb...@gnu.org unless you wish to report a problem with the Bug-tracking system. -- 53300: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=53300 GNU Bug Tracking System Contact help-debb...@gnu.org with problems -- Jacob Hrbek publickey - kreyren@rixotstudio.cz - 1677db82.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
bug#53238: [PATCH] gnu: tree: Remove stddata feature.
Hello! Apologies for missing this discussion earlier... Maxim Cournoyer skriver: > Hi, > > Olivier Dion writes: > >> On Thu, 13 Jan 2022, Tobias Geerinckx-Rice wrote: >>> Olivier, >>> >>> Thanks again for tracking down this weird bug! >>> >>> Olivier Dion via Guix-patches via 写道： This feature breaks some UNIX utilities. Fix it by disabling the feature. >>> >>> Hm… How long would we have to carry this fork? My fear is we'd >>> do so indefinitely. >> >> I've contacted the maintainer asking for removal of the feature in its >> next release. I'm not sure if this will have some impact. Feel free to >> do the same at , maybe adding more weight >> in the balance would help. >> >>> How about creating a (possibly hidden) tree-without-stddata >>> package variant, to use as input to packages who currently break >>> with this feature enabled? That lets us refcount the need for it. >> >> It's more than just packages, it's also user scripts that can be broken >> and believe me when I say that this is not an easy bug to track down ;-). > > I'm on the fence about this, it does indeed seem an undesirable change, > especially since there's a --json option, but I am not the author of the > 'tree' software. After some consideration (and emails with tree author), I think the best solution is to patch 'password-store' so that it DTRT even in the presence of fd 3. I sent a patch to that effect upstream: https://lists.zx2c4.com/pipermail/password-store/2022-January/004563.html ...and have local patches to apply that in Guix and revert bd4f314bbacaaa56751be3a4769f2082be747d24 and a40ac6271578ea061a8a07b2adbd6032a690ca70. WDYT? signature.asc Description: PGP signature
bug#53238: [PATCH] gnu: tree: Remove stddata feature.
On Sun, Jan 16, 2022 at 06:04:22PM +0100, Marius Bakke wrote: > After some consideration (and emails with tree author), I think the best > solution is to patch 'password-store' so that it DTRT even in the > presence of fd 3. > > I sent a patch to that effect upstream: > > https://lists.zx2c4.com/pipermail/password-store/2022-January/004563.html > > ...and have local patches to apply that in Guix and revert > bd4f314bbacaaa56751be3a4769f2082be747d24 and > a40ac6271578ea061a8a07b2adbd6032a690ca70. > > WDYT? Definitely, this is the right approach. I didn't participate in this bugfix but I think that removing or adding features to packages is not something we should be doing at the level of the distro, except with upstream coordination. Reporting this issue to password-store should have been one of the first steps we took.
bug#53197: [PATCH 0/3] Update WPEWebkit to 2.34.3
On Sun, Jan 16, 2022 at 08:36:45AM +0100, Liliana Marie Prikler wrote: > Hi Leo, hi Guix, > > the following patches update libwpe and wpebackend-fdo to 1.12.0 and > wpewebkit to 2.34.3. I checked that all three of them build, but I so > far haven't > 1. done a libsoup-minimal-2 variant -- there's no dependents of >wpewebkit yet, so it's somewhat pointless. > 2. checked whether the AVX patches from WebkitGTK need to be carried >over, or > 3. tested how this impacts our WebkitGTK builds. > > I'd appreciate if someone could help me out here, because Webkit builds > have a high chance of killing whatever else is running on my machine at > the moment -- or my machine if that fails. Thanks, I'm testing the build of WebKitGtk now. I noticed that GTK 4 depends on wpebackend-fdo. For now, we can change GTK 4 on the master branch, but eventually wpebackend-fdo will be a package that requires grafting to keep up to date.
bug#53197: [PATCH 0/3] Update WPEWebkit to 2.34.3
On Sun, Jan 16, 2022 at 08:36:45AM +0100, Liliana Marie Prikler wrote: > 3. tested how this impacts our WebkitGTK builds. With these patches applied, Epiphany still works in the same way as before. Epiphany is the major test of WebKitGTK functionality in Guix.
bug#53197: [PATCH 0/3] Update WPEWebkit to 2.34.3
Hi, Am Sonntag, dem 16.01.2022 um 13:30 -0500 schrieb Leo Famulari: > I noticed that GTK 4 depends on wpebackend-fdo. For now, we can > change GTK 4 on the master branch, but eventually wpebackend-fdo will > be a package that requires grafting to keep up to date. I'm fine with turning the wpebackend-fdo patch into a graft, I just didn't notice the dependency. > With these patches applied, Epiphany still works in the same way as > before. Great, so we got WebkitGTK working, meaning we only need to disable SSE2 outside of x86-64. I checked the file mentioned in webkitgtk's disable-sse2 phase, and it seems wpewebkit mirrors that. So if I read this correctly you only need to copypasta your old code. Anything else I'm missing?
bug#53309: Newly-added python-piexif fails to patch source due to CRLF(?)
Hullo Hartmut, I'm strangely unable to build python-piexif: patching file tests/s_test.py Hunk #1 FAILED at 9 (different line endings). Hunk #2 FAILED at 580 (different line endings). 2 out of 2 hunks FAILED -- saving rejects to file tests/s_test.py.rej Indeed: $ file tests/s_test.py tests/s_test.py: Python script, ASCII text executable, with CRLF line terminators $ file python-piexif-fix-tests-with-pillow-7.2.pat> python-piexif-fix-tests-with-pillow-7.2.patch: ASCII text At least that's what I guess is the problem. This is worrying since I'd expect all this to be 100% reproducible, and it seems to work fine for both you & Ludo'… Kind regards, T G-R signature.asc Description: PGP signature
bug#52766: guix deploy should have --skip-checks
Hello! Michael Rohleder skribis: > If a customized kernel is build with "non standard" (initrd) modules, one > needs --skip-checks for guix system reconfigure. > This can't be deployed, because guix deploy has no --skip-checks. I addressed that in 084b76a70a6b302529f3450e6d07f1d105a10f7d, not by adding ‘--skip-checks’, but instead by adding a ‘safety-checks?’ field to . This is consistent with the ‘allow-upgrades?’ field that was added to skip downgrade checks. Let me know what you think! Thanks, Ludo’.
bug#52552: [bug#52700] [PATCH 1/2] gnu: Add python-pydbus.
Hello, Aleksandr Vityazev writes: > * gnu/packages/python-xyz (python-pydbus): New variable. This was applied in 4527743f0a2d58d7cdf5abdd74016908eecd66a6 and subsequent commit. Thank you! Regards, -- Nicolas Goaziou
bug#52766: guix deploy should have --skip-checks
Ludovic Courtès writes: > I addressed that in 084b76a70a6b302529f3450e6d07f1d105a10f7d, not by > adding ‘--skip-checks’, but instead by adding a ‘safety-checks?’ field > to . This is consistent with the > ‘allow-upgrades?’ field that was added to skip downgrade checks. > > Let me know what you think! I love it! Thank you very much! (Will test it soon/asap...) signature.asc Description: PGP signature
bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
Hi, Chris Marusich writes: > If nobody has further comments, I will commit the attached version to > master in about 24 hours. I've committed this in 24c3485bb3ffc05e687ef6513ac287b8d3048bab. We still need to update the "guix" package, so even if you run "guix pull" right now, you won't be able to successfully build "guix" after pulling on aarch64-linux yet. I will coordinate with the other people who are helping to make the 1.4.0 release to ensure that this fix makes it into the 1.4.0 release. See this guix-devel email thread for details: https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00296.html -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 signature.asc Description: PGP signature
