qt-build-system: Add QT_QPA_PLATFORM=offscreen?
Hi Danny, (forwarding to guix-devel to eventually get more opinions on this) Am 21.01.20 um 23:43 schrieb Danny Milosavljevic: >> + (add-before 'check 'check-setup >> + (lambda _ >> + (setenv "QT_QPA_PLATFORM" "offscreen") >> + #t) > Hmm, would it make sense to do that automatically in qt-build-system ? I would be fine with this, since I find myself adding this snippet quite often when building Qt/KDE applications. But there *might* be cases, where tests fail due to this setting. (While I'm not aware of one, I could imaging some test checks whether it is actually painting.) Thus I propose implementing this in some way to easily disable it if required: Either - by adding this a new phase (as in the snippet shown above), so it can easily be disabled - by adding another keyword-argument (proposal: `#:qpa-platform`, default: "offscreen", if +f, will not be set. WDYT? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | signature.asc Description: OpenPGP digital signature
Re: [bug#39229] qt-build-system: Add QT_QPA_PLATFORM=offscreen?
Hartmut Goebel writes: > Hi Danny, > > (forwarding to guix-devel to eventually get more opinions on this) > > Am 21.01.20 um 23:43 schrieb Danny Milosavljevic: >>> + (add-before 'check 'check-setup >>> + (lambda _ >>> + (setenv "QT_QPA_PLATFORM" "offscreen") >>> + #t) >> Hmm, would it make sense to do that automatically in qt-build-system ? > > I would be fine with this, since I find myself adding this snippet quite > often when building Qt/KDE applications. But there *might* be cases, > where tests fail due to this setting. (While I'm not aware of one, I > could imaging some test checks whether it is actually painting.) > > Thus I propose implementing this in some way to easily disable it if > required: Either > > - by adding this a new phase (as in the snippet shown above), so it can > easily be disabled > > - by adding another keyword-argument (proposal: `#:qpa-platform`, > default: "offscreen", if +f, will not be set. > > WDYT? I think adding this to qt-build-system with the keywords is a good suggestion. ++ Mike
Re: qt-build-system: Add QT_QPA_PLATFORM=offscreen?
On Wed, Jan 22, 2020 at 09:44:02AM +0100, Hartmut Goebel wrote: > Hi Danny, > > (forwarding to guix-devel to eventually get more opinions on this) > > Am 21.01.20 um 23:43 schrieb Danny Milosavljevic: > >> + (add-before 'check 'check-setup > >> + (lambda _ > >> + (setenv "QT_QPA_PLATFORM" "offscreen") > >> + #t) > > Hmm, would it make sense to do that automatically in qt-build-system ? > I was about to suggest this. (ins)efraim@E5400 ~/workspace/guix$ grep QT_QPA_PLATFORM\" gnu/packages/kde*scm | wc -l 41 (ins)efraim@E5400 ~/workspace/guix$ grep define-public gnu/packages/kde*scm | wc -l 124 (ins)efraim@E5400 ~/workspace/guix$ grep qt-build-system gnu/packages/kde*scm | wc -l 27 > I would be fine with this, since I find myself adding this snippet quite > often when building Qt/KDE applications. But there *might* be cases, > where tests fail due to this setting. (While I'm not aware of one, I > could imaging some test checks whether it is actually painting.) > > Thus I propose implementing this in some way to easily disable it if > required: Either > > - by adding this a new phase (as in the snippet shown above), so it can > easily be disabled > > - by adding another keyword-argument (proposal: `#:qpa-platform`, > default: "offscreen", if +f, will not be set. > > WDYT? > I like a new phase before the 'check phase. Are there other things we'd want to add? Looking through kde-framworks.scm the only one I'd feel comfortable adding would be the TZ ones. -- 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
Re: Parameterized packages
zimoun writes:
> I do not understand what you do mean by "does not compose".
>
>
> To me, a package is:
> "./configure && make && make check && make install"
> so I understand why tweak the flags used by "./configure", for example
> change "--with-vlc=" from the default 0 to the tuned 1. Or use another
> compiling toolchain.
> I understand also these flags could require different inputs.
If we reuse your example, a package may very well have --with-vlc and
--with-mpv.
Those flags conflict, so the package definition must know about the
corresponding "package parameters" at the same time to raise the
appropriate error (or choose The Right Option automatically).
Instead, if you'd inherit you'd always overwrite the changes without the
user noticing. This removes a lot of control.
> --8<---cut here---start->8---
> (define (make-you-get VIDEO-PLAYER PYTHON-VERSION WITH-FFMPEG)
> (package
> (inherit you-get
> #:add-inputs
> `(("PLAYER" ,VIDEO-PLAYER))
>,@(IF WITH-FFMPEG)
> ;; FOR MULTI-PART AND >=1080P VIDEOS
> `("FFMPEG" ,FFMPEG)
> #:replace-arguments ...
>#:add-phase ...
> '(
>
> (define-public you-get-vlc (make-you-get 'vlc))
> --8<---cut here---end--->8---
>
>
> Something like that. And everything is more controlled,
What you propose here is essentially the same as what I propose, the
difference is that you wrapped it around `make-you-get` instead of
declaring the parameters inside as a field.
> i.e., no mess with global parameters.
I think there is a misunderstanding, there is no "mess with global
parameters".
Tobias suggestion was to declare the parameters (name, doc and type)
globally, just like we declare record globally.
> What you want to do is: add/remove/replace inputs/arguments so
> #:add-inputs, #:remove-native-inputs, etc.
Not just that, that's the point: we want the possibility to modify
anything, in particular what's inside #:arguments.
> Hum? but months later your system is broken... so I am not convinced
> it is powerful. :-)
>
> It is broken because composing complex system is an hard task. Typing
> helps a bit to detect error at compile time (in this case at building
> package time) but run-time errors will still remain and it will be
> hard time to find them.
Why would it be broken after months? Packagers do the work once and it
works. Of course the package parameters will have to be tested on
update of the package definition. From the user's perspective, the
worst case scenario is that a formerly support parameter goes
unsupported for a given package, in which case we show a warning.
What do you think?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Re: Mumi service
Ludovic Courtès writes: > Hi! > > Ricardo Wurmus skribis: > >> Ludovic Courtès writes: > > [...] > >>> However, the currently packaged snapshot crashes when trying to retrieve >>> information about a bug: >>> >>> --8<---cut here---start->8--- >>> $ /gnu/store/qw2c84gnwk3sgivh2i8x98xx5gx73vxl-mumi-0.0.0-5.8a57c87/bin/mumi >>> GET /issue/22883 >>> In mumi/web/server.scm: >>> 38:9 23 (handler _ _ _) >>> In mumi/web/controller.scm: >>> 38:21 22 (render-with-error-handling _ _) >>>104:21 21 (_) >>> In mumi/web/view/html.scm: >>>274:19 20 (issue-page #) >>> In mumi/messages.scm: >>>185:16 19 (patch-messages 22883) >>> In debbugs/soap.scm: >>>163:19 18 (soap-invoke* # #>> get-bug-message-numbe…> …) >>> 157:7 17 (soap-invoke _ _ . _) >>> In sxml/simple.scm: >>> 143:4 16 (xml->sxml _ #:namespaces _ #:declare-namespaces? _ >>> #:trim-whitespace? _ …) >>> 143:4 15 (loop # () #f _) >>> 143:4 14 (loop # () #f _) >>> 143:4 13 (loop # () #f _) >>> 143:4 12 (loop # () #f _) >>> 143:4 11 (loop # () #f _) >>> 143:4 10 (loop # () #f _) >>> In sxml/upstream/SSAX.scm: >>> 1896:21 9 (_ # #f #>> at sxml/s…> …) >>> In sxml/ssax/input-parse.scm: >>>103:21 8 (next-token _ (#\< #\& #\return) _ _) >>> In ice-9/suspendable-ports.scm: >>>683:15 7 (read-delimited _ _ _) >>>184:27 6 (fill-input # _ _) >>> 72:4 5 (read-bytes # #vu8(10 32 98 121 32 >>> 109 97 …) …) >>> In unknown file: >>>4 (port-read # #vu8(10 32 98 121 32 >>> 109 97 …) …) >>> In web/response.scm: >>>254:22 3 (read! #vu8(10 32 98 121 32 109 97 105 108 46 109 101 115 115 >>> 97 103 …) …) >>> In ice-9/suspendable-ports.scm: >>>284:18 2 (get-bytevector-n! # >>> #vu8(10 32 98 …) …) >>> 72:4 1 (read-bytes # #vu8(10 32 98 >>> 121 32 …) …) >>> In unknown file: >>>0 (port-read # #vu8(10 32 98 >>> 121 32 …) …) >>> In procedure custom_binary_input_port_read: Value out of range: 1024 >>> --8<---cut here---end--->8--- >>> >>> Does that ring a bell, Ricardo? Should we update to a newer snapshot? >> >> This is exactly the same bug I hit when using mumi with (fibers web >> server). With just the regular Guile (web server) it works fine but >> seemingly leaks file handles until it is restarted. >> >> I don’t understand this. > > Could it be that the ‘read!’ procedure of the custom binary input port > (CBIP) returned by ‘make-delimited-input-port’ in (web response) returns > 1024 when ‘count’ is in fact lower than 1024, or something along these > lines? I would try adding ‘pk’ calls there to display ‘count’ and the > return value. > > If that is true, then maybe the underlying issue is that > ‘get-bytevector-n!’ in (ice-9 suspendable-ports) can return a value > greater than ‘count’, presumably in the ‘fill-directly’ case. > > Hmmm! FWIW, this problem also exists when using Guile 3.0. I don’t know when it broke, but obviously there was a time (perhaps a year ago) when it worked fine. Curious. -- Ricardo
Re: Parameterized packages
Hi Pierre,
On Wed, 22 Jan 2020 at 10:54, Pierre Neidhardt wrote:
> zimoun writes:
> > To me, a package is:
> > "./configure && make && make check && make install"
> > so I understand why tweak the flags used by "./configure", for example
> > change "--with-vlc=" from the default 0 to the tuned 1. Or use another
> > compiling toolchain.
> > I understand also these flags could require different inputs.
>
> If we reuse your example, a package may very well have --with-vlc and
> --with-mpv.
>
> Those flags conflict, so the package definition must know about the
> corresponding "package parameters" at the same time to raise the
> appropriate error (or choose The Right Option automatically).
It is the job to './configure' to detect conflicting parameters and
not the job of the package definition, IMHO.
The well-known: crap in, crap out! :-)
> Instead, if you'd inherit you'd always overwrite the changes without the
> user noticing. This removes a lot of control.
Yes, I agree with the current implementation. That's why I wrote: ;-)
<<
And again from my understanding, this is more or less cover by
'inherit'. Or some macrology should be improved in 'package/inherit'
or in 'records.scm', i.e., something more fine grained when
inheriting.
>>
> > --8<---cut here---start->8---
> > (define (make-you-get VIDEO-PLAYER PYTHON-VERSION WITH-FFMPEG)
> > (package
> > (inherit you-get
> > #:add-inputs
> > `(("PLAYER" ,VIDEO-PLAYER))
> >,@(IF WITH-FFMPEG)
> > ;; FOR MULTI-PART AND >=1080P VIDEOS
> > `("FFMPEG" ,FFMPEG)
> > #:replace-arguments ...
> >#:add-phase ...
> > '(
> >
> > (define-public you-get-vlc (make-you-get 'vlc))
> > --8<---cut here---end--->8---
> >
> >
> > Something like that. And everything is more controlled,
>
> What you propose here is essentially the same as what I propose, the
> difference is that you wrapped it around `make-you-get` instead of
> declaring the parameters inside as a field.
The big differences are:
1. the base package is untouched
2. the arguments are locally defined
3. everything is explicit
So less surprises IMHO.
> > i.e., no mess with global parameters.
>
> I think there is a misunderstanding, there is no "mess with global
> parameters".
Where should be defined what you called VIDEO-PLAYER?
the one in ' (PARAMETERS VIDEO-PLAYER PYTHON-VERSION WITH-FFMPEG)'.
Because the symbol needs to be defined somewhere, right?
> Tobias suggestion was to declare the parameters (name, doc and type)
> globally, just like we declare record globally.
It will end with a big mess because there is almost as many
"parameters" as packages.
And 'parameter' means somehow 'symbol', isn't it?
> > What you want to do is: add/remove/replace inputs/arguments so
> > #:add-inputs, #:remove-native-inputs, etc.
>
> Not just that, that's the point: we want the possibility to modify
> anything, in particular what's inside #:arguments.
I am suggesting the same thing. :-)
But instead I am suggesting to pass the modifications 'arguments' via
inheritance mechanism.
> > Hum? but months later your system is broken... so I am not convinced
> > it is powerful. :-)
> >
> > It is broken because composing complex system is an hard task. Typing
> > helps a bit to detect error at compile time (in this case at building
> > package time) but run-time errors will still remain and it will be
> > hard time to find them.
>
> Why would it be broken after months? Packagers do the work once and it
I do not know but it is what Gentoo users are saying.
Well, I know a awesome guy wearing psychadelic T-shirt and former
Gentoo user that explained me that IRL. ;-)
> works. Of course the package parameters will have to be tested on
> update of the package definition. From the user's perspective, the
This adds a lot of workload to packagers, IMHO.
> worst case scenario is that a formerly support parameter goes
> unsupported for a given package, in which case we show a warning.
>
> What do you think?
Well, I am wanting the same thing: be able to modify the 'arguments'
field but I am not convinced by the design you are proposing because I
have the feeling that with such design then mess is coming. :-)
Cheers,
simon
Re: G-Expressions and Scope Preservation
Hello!
Chris Marusich skribis:
> In your paper "Code Staging in GNU Guix" [1], you use the following
> example to illustrate how G-Expressions are hygienic ("they preserve
> lexical scope across stages"):
>
> (let ((gen-body (lambda (x)
> #~(let ((x 40))
> (+ x #$x)
> #~(let ((x 2))
> #$(gen-body #~x)))
>
> You explain that it expands to something like this:
>
> (let ((x-1bd8-0 2))
> (let ((x-4f05-0 40))
> (+ x-4f05-0 x-1bd8-0)))
>
> However, when I write this gexp to disk, it doesn't look like that:
Ah ha! That bit is still in the ‘wip-gexp-hygiene’ branch.
The reason I haven’t merged it, other than I didn’t take the time, is
that the output depends on Guile’s ‘hash’ function, which is not
necessarily stable. Actually, it changed between 2.0 and 2.2, but I
think it’s the same in 2.2 and 3.0. This needs to be checked, because
if it differs, then people will get different results depending on the
Guile version they use, and that’d be a serious issue.
I thought I had mentioned this before, but apparently not:
https://lists.gnu.org/archive/html/guix-devel/2017-07/msg00181.html
https://lists.gnu.org/archive/html/guix-devel/2017-09/msg00093.html
We should also do some more testing to make sure nothing breaks.
Ludo’.
Re: Testing the installer
Hello! Mathieu Othacehe skribis: > That sounds like a nice idea! I guess we can discuss it more deeply > during Guix Days, but here are a few thoughts: > > * Testing from a VM won't cover HW issues with undetected wifi networks > and kmscon rendering issues, but could cover most partitioning issues. Yeah, but for that we need manual testing, there’s no other option. > * This kind of client/server protocol would make even easier to > switch to a gtk graphical installer. Well, if we replace the explicit Newt calls with a higher-level interface, yes. Besides, the protocol may prove useful for accessibility because it provides semantics. > * Before the next release, it would be nice to fix the "installer always > fail when restarted" issue than has been bitten lots of people. Yes! I’ve pushed ‘wip-installer-test’, which implements said protocol. See screenshot below! :-) What’s left to do now is to write an actual test that uses it. Speaking of which, does anyone know if there’s a way to share a Unix-domain socket between a QEMU guest and its host? (Over 9p?) Thanks, Ludo’.
Outreachy project for netlink bindings
Hello Julien, Last round you were interested in mentoring this project. I have sent the previous proposal with slight modifications for this round. You can add yourself as a comentor to it now. Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Outreachy Internationalization for Guix Data Service
Hello Christopher, Could you resubmit the proposal for this round? I believe we left it off in a good state, so you could just copy it verbatim. Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
GSoC status
Hello Guix, I have received the information from the GNU org admins that they submitted GNU for participation in GSoC 2020. They are waiting for feedback, I will keep you updated. In the meantime I created this page: https://libreplanet.org/wiki/Group:Guix/GSoC-2020 based roughly on last year. Please check if you are still willing to mentor the projects you listed. I also have some questions, embedded as comments, so if you have insight on those, then feel free to contact me or simply edit the page accordingly. Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Re: G-Expressions and Scope Preservation
Hi Ludo,
Ludovic Courtès writes:
> Hello!
>
> Chris Marusich skribis:
>
>> In your paper "Code Staging in GNU Guix" [1], you use the following
>> example to illustrate how G-Expressions are hygienic ("they preserve
>> lexical scope across stages"):
>>
>> (let ((gen-body (lambda (x)
>> #~(let ((x 40))
>> (+ x #$x)
>> #~(let ((x 2))
>> #$(gen-body #~x)))
>>
>> You explain that it expands to something like this:
>>
>> (let ((x-1bd8-0 2))
>> (let ((x-4f05-0 40))
>> (+ x-4f05-0 x-1bd8-0)))
>>
>> However, when I write this gexp to disk, it doesn't look like that:
>
> Ah ha! That bit is still in the ‘wip-gexp-hygiene’ branch.
>
> The reason I haven’t merged it, other than I didn’t take the time, is
> that the output depends on Guile’s ‘hash’ function, which is not
> necessarily stable. Actually, it changed between 2.0 and 2.2, but I
> think it’s the same in 2.2 and 3.0. This needs to be checked, because
> if it differs, then people will get different results depending on the
> Guile version they use, and that’d be a serious issue.
>
> I thought I had mentioned this before, but apparently not:
>
> https://lists.gnu.org/archive/html/guix-devel/2017-07/msg00181.html
> https://lists.gnu.org/archive/html/guix-devel/2017-09/msg00093.html
>
> We should also do some more testing to make sure nothing breaks.
>
> Ludo’.
Ah! I see. That explains it. Thank you for pointing this out. I'm
still finalizing my presentation, but if I find time after that, I might
play around with that branch.
--
Chris
signature.asc
Description: PGP signature
