bug#40549: More usability issues:
TLDR: there is no "real" bug. :-)
Just a choice to do and document it.
On Fri, 24 Apr 2020 at 10:28, zimoun wrote:
> guix package -I -A # does nothing
> guix package -A -I # list available
Expected.
First line, -I -A' means that '-A' is seen as an argument for '-I'.
Idem for the second line '-A -I', i.e., '-I' is seen as an argument for '-A'.
> --8<---cut here---start->8---> # OK
> guix package --list-generations -p /path/to/profile
> guix package --list-installed -p /path/to/profile
>
> # KO
> guix package -l -p /path/to/profile
> guix package -I -p /path/to/profile
>
> # OK
> guix package -p /path/to/profile -l
> guix package -p /path/to/profile -I
>
> # KO
> guix package -l --profile=/path/to/profile
>
> # Do nothing
> guix package -I --profile=/path/to/profile
>
> # OK
> guix package -l --profile=/path/to/profile -l
> guix package -I --profile=/path/to/profile -I
> --8<---cut here---end--->8---
All are expected too.
Same reason. And the long option works because no argument is
provided by '=' so it fallback to the default one "".
Short options expect an argument so read the next characters as the
value or fallback to the default one "" when there is no next
character.
Fixing this will add complexity on parsing 'args' when building
'opts'. Basically, "guix package -I -p /path/tp/profile" returns an
error because the short option '-I' expect only one argument, read
'-p' and then Guix cannot deals with the option '/path/to/profile' and
so raises an error. See the dance with 'handle-argument' and
'arg-handler'. And "guix package -I '' -p /path/to/profile' works,
obviously. Well, the extra quotes ('') is annoying but I am not
convince that better could be done for short options -- regardless the
order of CLI arguments.
One solution should be add short options as '-AA' or '-II' for such
cases. But I am not convince that such "weird" combination deserves
such attention. :-)
Back to the initial report:
(a) guix package -S 17 -d 18 # KO
(b) guix package -d 18 -S 17 # OK
This is not the same issue than the one described previously. Here
the culprit is 'process-actions'. And composing "action" seems more
than legitimate (composing "query" is questionable).
Why (a) works and (b) not? Because the command-line is transformed
into an alist. And this alist is built reading the command-line from
right to left. Therefore, if you are on the generation 18 and you try
to delete it, Guix raises an error which seems expected. The second
one (b) works because first you switch and then you delete.
Well, that's said, IMHO, two options:
1) the order of CLI does not matter;
2) the order of CLI matters.
Well, the order of 'actions' necessary matters as it is seen with this
example: "switch and then delete" does not end in the same state than
"delete and then switch". Welcome in the classical mess of imperative
package manager. ;-)
Therefore, I am not convinced that something should be fixed. It
comes from the very nature of 'actions': actions is not always
commutative. Otherwise the best is to forbid to provide several
actions with the same transaction; which seems a bad idea -- at least
for me.
However, main of us are used to read from left to right so it seems
more natural to write:
guix package --action1 --action2 # (a)
than
guix package --action2 --action1 # (b)
in other words, the fix should be to simply 'reverse opts' and the CLI
will read (a) instead of the current (b). My only concern is about
backward compatibility.
My opinion based on backward compatibility argument is: let as it is
and document it in the manual.
WDYT?
All the best,
simon
bug#41196: Xfce panel, exo-open: launching applications not working
Hello, while clicking on icons on Xfce panel, it fails to launch applications and throws "Couldn't run command /gnu/store/*hash*-exo-0.12.6/bin/exo-open --launch *Application name* %u There's no such file or directory". I thought I reported the issue somewhere, but my memory tricked me and I confused the issue with the "gio-launch-desktop" bug, which was recently resolved. If this can be resolved by a simple wrapper, unlike the "gio-launch-desktop" bug, I can try fixing it. By the way, the issue is present for like 7 months already. It seems something failed during making the 1.1.0 release and Guix as a distribution needs better procedures for handling the release process to avoid such bugs in the future. A checklist would be good. Maybe making a "Tests" page in the manual, something with the ability to modify the status of test: * panel: works * setting wallpaper: unknown/not tested yet etc. Jan Wielkiewicz
bug#35591: Segfault on flatpak remote-add
Ricardo Wurmus writes: > Ben Sturmfels writes: > >> On Sun, 05 May 2019, Jonathan Frederickson wrote: >> >>> I'm attempting to use Flatpak on my Guix system, and I'm experiencing >>> segfaults when attempting to add a remote repo. Provided below are the >>> output of the command I'm attempting to run, as well as some info >>> about my system. >> >> I learnt on #guix IRC that flatpak works when run with the --user flag: >> >> $ flatpak --user remote-add --if-not-exists flathub >> https://flathub.org/repo/flathub.flatpakrepo >> $ flatpak install flathub org.gnome.Builder >> $ flatpak run org.gnome.Builder >> >> The segfaulting behaviour is still a bug in my opinion, because it's >> extremely user un-friendly, and the requirement for --user is not >> obvious. > > Yes, segfaults are always bugs, unless you forced the program to > load garbage. > > I traced the execution of flatpak and saw that it segfaults right after > failing to created /var/lib/flatpak. Sure enough, after creating it > manually the program no longer segfaults. I reported this here: https://github.com/flatpak/flatpak/issues/3612 I’d say we close this issue here, because the segfault isn’t our fault. Thoughts? -- Ricardo
bug#41182: Profile hooks ignore system and target
Hi, Ludovic Courtès skribis: > Actually all the profile hooks refer to the native derivation. I’ve looked at it and this problem is surprisingly tricky to address. I’ve tried to address it in an API-compatible way, which meant setting the ‘%current-system’ and ‘%current-target-system’ parameters around the hook calls, but that is ugly, hard to get right (dynamic binding and monadic code really don’t go together well :-/), and actually raises another issue (‘mapm/accumulate-builds’ appears to ignore the initial dynamic bindings for these two parameters). Hacky patch attached to illustrate. So I’m very much tempted to instead require each hook to take ‘system’ and ‘#:target’ arguments and pass them to ‘gexp->derivation’. It’ll break the API, in case someone out there has custom profile hooks (unlikely given that it’s not really documented), but I’d say that’s OK. Thoughts? Ludo’. diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm index 59ef5d078b..4f90e9e41d 100644 --- a/gnu/packages/commencement.scm +++ b/gnu/packages/commencement.scm @@ -3013,9 +3013,10 @@ memoized as a function of '%current-system'." '/memoized #'(begin (define memoized - (mlambda (system) exp)) + (mlambda (system target) exp)) (define-syntax identifier - (identifier-syntax (memoized (%current-system)) + (identifier-syntax (memoized (%current-system) +(%current-target-system)) (define/system-dependent linux-libre-headers-boot0 ;; Note: this is wrapped in a thunk to nicely handle circular dependencies diff --git a/guix/profiles.scm b/guix/profiles.scm index 25ff146bdf..58d7e0e450 100644 --- a/guix/profiles.scm +++ b/guix/profiles.scm @@ -1580,6 +1580,18 @@ This is one of the things to do for the result to be relocatable. When TARGET is true, it must be a GNU triplet, and the packages in MANIFEST are cross-built for TARGET." + (define (call-with-system+target system target thunk) +(mlet* %store-monad ((system0 (set-current-system system)) + (target0 (set-current-target (pk 'set-target target))) + (result (thunk))) + (mbegin %store-monad +(set-current-system system0) +(set-current-target target0) +(return result + + (define-syntax-rule (with-system+target system target exp) +(call-with-system+target system target (lambda () exp))) + (mlet* %store-monad ((system (if system (return system) (current-system))) @@ -1592,9 +1604,12 @@ are cross-built for TARGET." #:target target))) (extras (if (null? (manifest-entries manifest)) (return '()) - (mapm/accumulate-builds (lambda (hook) - (hook manifest)) - hooks + (with-system+target +system +target +(mapm/accumulate-builds (lambda (hook) + (hook manifest)) + hooks) (define inputs (append (filter-map (lambda (drv) (and (derivation? drv) @@ -1689,6 +1704,8 @@ are cross-built for TARGET." (match profile (($ name manifest hooks locales? allow-collisions? relative-symlinks?) + (pk 'prof-c system target (%current-target-system)) + ;; (display-backtrace (make-stack #t) (current-error-port) #f 80) (profile-derivation manifest #:name name #:hooks hooks diff --git a/guix/store.scm b/guix/store.scm index 6c7c07fd2d..92158bd658 100644 --- a/guix/store.scm +++ b/guix/store.scm @@ -1899,7 +1899,10 @@ coalesce them into a single call." (values (map/accumulate-builds store (lambda (obj) (run-with-store store - (mproc obj))) + (mproc obj) + ;; #:system (%current-system) + ;; #:target (%current-target-system) + )) lst) store)))
bug#40981: Graphical installer tests sometimes hang.
Hello,
Mathieu Othacehe skribis:
>>> The work-around here is to save the installed SIGTERM handler and reset
>>> it. Then, after forking, the parent can restore the SIGTERM handler. The
>>> child will use the default SIGTERM handler that terminates the process.
>>
>> OK, makes sense. (Another occasion to see how something like
>> ‘posix_spawn’ would be more appropriate than fork + exec…)
>
> Didn't know about that function, but it seems way easier to manipulate
> and less error prone indeed!
Make sure to read “A fork() in the Road” on that topic:
https://lwn.net/Articles/785430/
>>> +# Try to trigger eventual race conditions, when killing a process between
>>> fork
>>> +# and execv calls.
>>> +for i in {1..50}
>>> +do
>>> +$herd restart test3
>>> +done
>>
>> Would it reproduce the problem well enough?
>
> On a slow machine one time out of two, and on a faster machine,
> never. The 'reproducer' I used, was to add a 'sleep' between fork and
> exec, it works way better!
>
> Tell me if you think its better to drop it.
It’s better than nothing, let’s keep it.
>>From 79d3603bf15b8f815136178be8c8a236734a7596 Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe
> Date: Thu, 7 May 2020 18:39:41 +0200
> Subject: [PATCH] service: Fix 'make-kill-destructor' when PGID is zero.
>
> When a process is forked, and before its GID is changed in "exec-command",
> it will share the parent GID, which is 0 for Shepherd. In that case, use
> the PID instead of the PGID.
>
> Also make sure to reset the SIGTERM handler before forking a process. Failing
> to do so, will result in stopping Shepherd if a SIGTERM is received between
> fork and execv calls. Restore the SIGTERM handler once the process has been
> forked.
>
> * modules/shepherd/service.scm (fork+exec-command): Save the current SIGTERM
> handler and reset it before forking. Then, restore it on the parent after
> forking.
> (make-kill-destructor): Handle the case when PGID is zero, between the process
> fork and exec.
I added a “Fixes” line and pushed it.
Thanks a lot!
I can roll a 0.8.1 release soonish (I’d like to add signalfd support
while at it, we’ll see.)
Ludo’.
bug#41140: “guix system” suggests wrong module import when using “remove”
Ricardo Wurmus skribis: > But now I’m curious and I look at the documentation for “remove” from > (rnrs lists): > > -- Scheme Procedure: remp proc list > -- Scheme Procedure: remove obj list > -- Scheme Procedure: remv obj list > -- Scheme Procedure: remq obj list > ‘remove’, ‘remv’, and ‘remq’ are identical to the ‘delete’, ‘delv’, > and ‘delq’ procedures provided by Guile’s core library, (*note List > Modification::). ‘remp’ is identical to the alternate ‘remove’ > procedure provided by SRFI-1; *Note SRFI-1 Deleting::. > > Oh. Bah, R6 is terrible in that respect. > So here are my questions: > > * can we prefer (srfi srfi-1) over (rnrs lists) in the suggestions for > “remove”? I don’t think we should do that. However, listing all the possibilities, as Danny suggests, would be nice. > * can we avoid this by extending modify-services to support “delete” > much like modify-phases, and suggesting to use that instead of > “remove”? That’s the better option! Ludo’.
bug#35591: Segfault on flatpak remote-add
Ben Sturmfels writes: > On Sun, 05 May 2019, Jonathan Frederickson wrote: > >> I'm attempting to use Flatpak on my Guix system, and I'm experiencing >> segfaults when attempting to add a remote repo. Provided below are the >> output of the command I'm attempting to run, as well as some info >> about my system. > > I learnt on #guix IRC that flatpak works when run with the --user flag: > > $ flatpak --user remote-add --if-not-exists flathub > https://flathub.org/repo/flathub.flatpakrepo > $ flatpak install flathub org.gnome.Builder > $ flatpak run org.gnome.Builder > > The segfaulting behaviour is still a bug in my opinion, because it's > extremely user un-friendly, and the requirement for --user is not > obvious. Yes, segfaults are always bugs, unless you forced the program to load garbage. I traced the execution of flatpak and saw that it segfaults right after failing to created /var/lib/flatpak. Sure enough, after creating it manually the program no longer segfaults. -- Ricardo
bug#41140: “guix system” suggests wrong module import when using “remove”
Hi, Ricardo Wurmus skribis: >>From 40c1208cbe9cbfa58ee385ef6ee06b775d309753 Mon Sep 17 00:00:00 2001 > From: Ricardo Wurmus > Date: Sun, 10 May 2020 23:29:38 +0200 > Subject: [PATCH] services: Support DELETE in MODIFY-SERVICES macro. > > * gnu/services.scm (%modify-service): Add clause for DELETE syntax. > (modify-services): Use FILTER-MAP; adjust docstring. > * doc/guix.texi (System Services): Mention alternative syntax. > (X Window): Use MODIFY-SERVICES syntax. I like it! > - #:use-module (srfi srfi-1) > + #:use-module ((srfi srfi-1) #:hide (delete)) >#:use-module (srfi srfi-9) >#:use-module (srfi srfi-9 gnu) >#:use-module (srfi srfi-26) > @@ -272,7 +273,11 @@ singleton service type NAME, of which the returned > service is an instance." > (service type value))) > > (define-syntax %modify-service > - (syntax-rules (=>) > + (syntax-rules (=> delete) > +((_ svc (delete kind) clauses ...) > + (if (eq? (service-kind svc) kind) > + #f > + (%modify-service svc clauses ...))) Best practice suggests that ‘delete’ should be bound (info "(guile) Syntax Rules"): --8<---cut here---start->8--- Although literals can be unbound, usually they are bound to allow them to be imported, exported, and renamed. *Note Modules::, for more information on imports and exports. In Guile there are a few standard auxiliary syntax definitions, as specified by R6RS and R7RS: --8<---cut here---end--->8--- Now, if we export a new ‘delete’ binding from here, it’ll annoy everyone. So perhaps we can keep the srfi-1 ‘delete’ and re-export it, as done in (guix build utils)… though that situation is also annoying because we get warnings saying that it collides with core ‘delete’. Dunno, give it a try! Ludo’.
bug#22705: audacity help doesn't work
Bug #22704 is fixed, so while I get the notification box that tells me that the manual is not installed I can simply click on the link to open it in a browser. It also tells me to go to Preferences if I want to always open the manual in my browser, which works fine. The only way to include the manual is to download the wiki, and we can’t do that reproducibly, so we cannot make it a fixed output derivation. As it’s not feasible for us to include the manual, I’m closing this issue. -- Ricardo
bug#40682: frozen installer in WiFi section -guix 1.1.0
What is the status of this bug? If we have a fix, can we make a new installer image? There are people on #guix having trouble getting online in the installer, and I think they are hitting this issue.
bug#40682: Installer hangs while connecting to WiFi network
Can you tell the user to connect to the network manually instead of getting stuck at graphical wifi connection? That would allow to bypass the problem and continue with the installation.
bug#41132: [core-updates]: Fonts not working on foreign distro (Debian)
Hi Leo, On +2020-05-08 18:52:41 -0400, Leo Famulari wrote: > On Sat, May 09, 2020 at 12:18:46AM +0200, Bengt Richter wrote: > > Didn't I just see a permissions-related bug reminiscent of this go by a > > short while ago? > > Could it be related? Do the dir/file perms look normal? > > Upthread, Tobias pointed out that fc-cache didn't have permissions for > /var/cache/fontconfig, but deleting that didn't seem to make a > difference. Could that be what you were thinking about? No, I think it was about a deferred build action created as root and bits needed for later phase or context, as non-root, were inaccessible. Sorry for the noise. -- Regards, Bengt Richter
bug#41144: core-updates merged!
Hello,
Nicolò Balzarotti writes:
> Hi! I guix pull-ed yesterday night!
> The system continues to work well, but on the boot I get a lot of
> warnings, something like "WARNING: {g#45} importing (guix utils) conflicts
> with an
> existing identifier `delete'" (or something similar, I already forgot
> and don't know where to find the log).
>
> Am I the only one? In that case, I'll reboot and report the correct warning
>
> Many thanks :)
> Nicolò
Yep, you're not alone. I'm have something like this:
--8<---cut here---start->8---
WARNING: (#{ g54}#): imported module (guix build utils) overrides core
binding `
--8<---cut here---end--->8---
--
WBR, Boris Dekshteyn
bug#37207: guix.gnu.org returns Last-Modified = Epoch
Hi, Christopher Baines skribis: > So I think removing the Last-Modified header from the responses will fix > the issue with the Repology fetcher (as it will stop thinking it's > already fetch the file, since it was last modified in 1970), instead it > will just always process the file. > > Removing the Last-Modified header, and maybe the ETag as well from > responses should avoid the issue with web browsers using a cached > version of the page when they probably shouldn't. It would prevent client-side caching altogether. So perhaps we can do that as a stopgap (and it has the advantage of requiring only a tiny config change). Eventually, it’d be nice to have something better, like one of the Etag patches discussed upthread. Thanks, Ludo’.
bug#41058: GNOME Maps fails to start in GNOME
I think, I figured out the root cause of this. GApplication launches
apps through dbus, looking up the respective service in share/dbus-1.
The service for GNOME Maps does not start the actual program, but much
rather a gjs wrapper, which we don't patch -- and which we can't simply
patch, because that leads to other errors, that rival our own when it
comes to how cryptic they are.
I've attached a patch, in which I rewrite the DBUS service to use the
actual program. I have not fully tested this patch, as `guix
environment --ad-hoc gnome-maps` appears not to be strong enough to
influence the gapplication lookup. However, if you launch `gnome-maps
--gapplication-service` in one terminal, then quickly switch to some
other and launch `gnome-maps` normally, the one that spawned the
service is the one that gets used, so claiming the bus in this fashion
*should* work.
Regards,
Leo
From d709692ba02e7f3a4c2f9bd8ca43374131a81a7a Mon Sep 17 00:00:00 2001
From: Leo Prikler
Date: Mon, 11 May 2020 13:30:44 +0200
Subject: [PATCH] gnu: gnome-maps: Patch DBUS service.
* gnu/packages/geo.scm (gnome-maps):
[arguments]<#:phases>: Add patch-dbus-service.
---
gnu/packages/geo.scm | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gnu/packages/geo.scm b/gnu/packages/geo.scm
index 6c68d40..b0d33d9 100644
--- a/gnu/packages/geo.scm
+++ b/gnu/packages/geo.scm
@@ -160,6 +160,12 @@ topology functions.")
(substitute* "meson_post_install.py"
(("gtk-update-icon-cache") "true"))
#t))
+ (add-after 'unpack 'patch-dbus-service
+ (lambda* (#:key outputs #:allow-other-keys)
+ (substitute* "data/org.gnome.Maps.service.in"
+ (("@pkgdatadir@/org.gnome.Maps")
+(string-append (assoc-ref outputs "out") "/bin/gnome-maps")))
+ #t))
(add-after 'install 'wrap
(lambda* (#:key inputs outputs #:allow-other-keys)
(let ((out (assoc-ref outputs "out"))
--
libgit2 1.0.0
bug#37734: Mate doesn't work after guix pull
This was fixed by commit 0bcc1b14fc3e2382406b97577c56e2292b96b8d4 which arrived master with the last core-update merges.
bug#38719: mate-utils build failure
mate-utils is now at 1.24 and the build is green.
bug#39946: mate-utils build fails
In the mean time mate-utils get updated to 1.24 and builds fine on master.
bug#37207: guix.gnu.org returns Last-Modified = Epoch
Ludovic Courtès writes: > Howdy! > > Christopher Baines skribis: > >> Ludovic Courtès writes: >> >>> Since the use of the ‘static-web-site’ service, which puts web site >>> files in the store, nginx returns a ‘Last-Modified’ header that can >>> trick clients into caching things forever: >>> >>> --8<---cut here---start->8--- >>> $ wget --debug -O /dev/null https://guix.gnu.org/packages.json 2>&1 | >>> grep Last >>> Last-Modified: Thu, 01 Jan 1970 00:00:01 GMT >>> --8<---cut here---end--->8--- >>> >>> We should tell nginx to do not emit ‘Last-Modified’, or to take the >>> state from the /srv/guix.gnu.org symlink, if possible. >> >> I ended up looking at this again in relation to Repology [1]. >> >> 1: >> https://github.com/repology/repology-updater/issues/218#issuecomment-525905704 >> >> Going back to that comment, given that the Last-Modified header (and the >> ETag) is wrong, it's probably sensible to remove them. That might even >> fix the issue with Repology fetching the packages.json file. >> >> Alternatively (or in addition), we could run a really simple Guile web >> server that just serves the packages.json file with the right >> Last-Modified value, and have NGinx proxy requests to that server. This >> would be pretty easy to setup I believe, and would allow providing a >> correct value. >> >> Thoughts? > > I think it wouldn’t really help because the Last-Modified issue is > pervasive. It shows for instance when accessing the web site: one often > has to force the browser to reload pages to get the latest version. > > So I’m all for one of the solutions that were proposed earlier. > > WDYT? So I think removing the Last-Modified header from the responses will fix the issue with the Repology fetcher (as it will stop thinking it's already fetch the file, since it was last modified in 1970), instead it will just always process the file. Removing the Last-Modified header, and maybe the ETag as well from responses should avoid the issue with web browsers using a cached version of the page when they probably shouldn't. I realise what I described with using a Guile web server to serve the packages.json file wouldn't help with other pages (unless they're served as well, which is a possibility), but that was just an optimisation over removing the header entirely, as having the Last-Modified header, with a correct value would help the Repology fetcher cache the file. Does that make sense? It still seems to me that a small change to the NGinx config (I think these lines somewhere in the config would do it [1]) would help with the Repology fetcher issue, and the issue you describe with web browsers. 1: add_header Last-Modified ""; if_modified_since off; etag off; signature.asc Description: PGP signature
bug#41025: blueman does not start
Hi Marius! > This phase is no longer necessary after the recent 'core-updates' merge. I don't know, when I tried it did not work. > These paths are "impure": the contents will differ from system to > system, and are also unavailable in e.g. 'guix environment -container'. > It might be better to patch these directories to something nonsensical > like "/no-such-path": that ensures we catch any missing references. > > That's not always feasible though, but hopefully works for this > package. I see. Thanks :-) Regards, RG. 0xAE6EF3046D6F7B57.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
bug#41025: blueman does not start
Hi Pierre!
> Sorry to disappoint :p Sadly this patch does not work yet ;)
> Stay put, almost there! :)
No worries! I have attached updated patch.
No all it needs is "dbus-launch" and "Blueman.Mechanism.service". The
former should be provided by (dbus-service). For the latter, the service
should be run at system-level. So we may need to create a service for
that by extending dbus-root-service. Also, I think it would be good to
add this service as an option to bluetooth-service-type. Like an option
"blueman? #t|#f". When its true, the bluetooth service adds and enables
the blueman-dbus-service. I do not know how to work with services. Help?
Thank you!
Regards,
RG.
From fd54245dbe1c6d387bd71f53f3cc7b3a853916b7 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan
Date: Mon, 11 May 2020 05:54:40 -0400
Subject: [PATCH] gnu: blueman: Update package definition.
* gnu/packages/networking.scm (blueman): Fixes.
[version]: Upgrade to 2.1.3.
[source][method]: Change from url-fetch to git-fetch.
[arguments]<#:phases>['setenv]: New phase.
['patch-python-references]: New phase.
['patch-external-programs]: New phase.
['patch-pulseaudio-libraries]: New phase.
['wrap-blueman-progs]: New phase.
[native-inputs]: Add autoconf, autogen, automake and gobject-introspection.
[inputs]: Add iptables and ppp. Remove adwaita-icon-theme.
---
gnu/packages/networking.scm | 110 +++-
1 file changed, 95 insertions(+), 15 deletions(-)
diff --git a/gnu/packages/networking.scm b/gnu/packages/networking.scm
index 76b0fc1559..5ca1e97ce3 100644
--- a/gnu/packages/networking.scm
+++ b/gnu/packages/networking.scm
@@ -72,6 +72,7 @@
#:use-module (gnu packages adns)
#:use-module (gnu packages algebra)
#:use-module (gnu packages audio)
+ #:use-module (gnu packages autogen)
#:use-module (gnu packages autotools)
#:use-module (gnu packages base)
#:use-module (gnu packages bison)
@@ -113,6 +114,7 @@
#:use-module (gnu packages python-xyz)
#:use-module (gnu packages qt)
#:use-module (gnu packages readline)
+ #:use-module (gnu packages samba)
#:use-module (gnu packages serialization)
#:use-module (gnu packages sqlite)
#:use-module (gnu packages ssh)
@@ -127,50 +129,128 @@
(define-public blueman
(package
(name "blueman")
-(version "2.1.2")
+(version "2.1.3")
(source
(origin
- (method url-fetch)
+ (method git-fetch)
(uri
-(string-append "https://github.com/blueman-project/blueman/releases/;
- "download/2.1.2/blueman-2.1.2.tar.gz"))
+(git-reference
+ (url "https://github.com/blueman-project/blueman.git;)
+ (commit version)))
+ (file-name (git-file-name name version))
(sha256
-(base32 "0wamxdw36c8i3aqwmja5q70fajqwd7inpkvlpkldd54wdxbcd38d"
+(base32 "1vb0zfns4q5d65hnja4c0k11lr38xxhdnkpkzfs6xca3mm6jyi1d"
(build-system glib-or-gtk-build-system)
(arguments
`(#:configure-flags
(list
"--enable-polkit"
-"--disable-appindicator" ; Deprecated
-"--with-systemdsystemunitdir=no" ; Not required
-"--with-systemduserunitdir=no"))) ; Not required
+"--disable-appindicator" ; Not available
+"--without-systemdsystemunitdir" ; Not required
+"--without-systemduserunitdir") ; Not required
+ #:phases
+ (modify-phases %standard-phases
+ ;; Prevent the autogen.sh script to carry out the configure
+ ;; script, which has not yet been patched to replace /bin/sh.
+ (add-before 'bootstrap 'setenv
+ (lambda _
+ (setenv "NOCONFIGURE" "TRUE")
+ #t))
+ ;; Python references are not being patched in patch-phase of build,
+ ;; despite using python-wrapper as input. So we patch them manually.
+ (add-after 'unpack 'patch-python-references
+ (lambda* (#:key inputs #:allow-other-keys)
+ (with-directory-excursion "apps"
+ (substitute*
+ '("blueman-adapters.in" "blueman-applet.in"
+ "blueman-assistant.in" "blueman-manager.in"
+ "blueman-mechanism.in" "blueman-report.in"
+ "blueman-rfcomm-watcher.in" "blueman-sendto.in"
+ "blueman-services.in" "blueman-tray.in")
+ (("@PYTHON@") (string-append (assoc-ref inputs "python")
+ "/bin/python"
+ ,(version-major+minor
+(package-version python))
+ #t))
+ ;; Fix loading of external programs.
+ (add-after 'unpack 'patch-external-programs
+ (lambda* (#:key inputs #:allow-other-keys)
+ (substitute*
+ '("apps/blueman-report.in" "blueman/main/NetConf.py"
+ "blueman/main/PPPConnection.py")
+
