Re: ‘staging’ and GNOME updates

[Timothy Sample]

Hi Ricardo and Ludo,

Ricardo Wurmus  writes:

> Ludovic Courtès  writes:
>> I removed pretty both .cache directories, moved .config sub-directories
>> around, etc., and yet I am still unable to log in into the GNOME account
>> (logging in to a non-GNOME account from GDM is fine.)
>>
>> I even tried upgrading the user’s profile just in case is contained
>> incompatible schemas or who knows what, but that didn’t help.
>>
>> What extra bit of state am I missing?
>
> Do you have ~/.local?  In my earlier tests this contained binary
> notification data that when loaded would lead to a crash.

I’m testing GNOME on ‘staging’ now, and had the same problem (GDM worked
okay, but I could not login).  I fixed it by deleting
“~/.local/share/gnome-shell/notifications”.  I left everything else in
my home directory as it was.

The newer GNOME seems much nicer, so this is pretty cool.  The only
problems I see so far are that I lost my background picture, there’s no
icons or text for NetworkManager on the status bar, and icons aren’t
working for applications in my user profile.  I haven’t updated my
profile yet, so that might help the icons.  We’ll see.

Thanks Ricardo for doing the update!


-- Tim

Re: Deliver important Guix changes to users, please

[Amin Bandali]

Hi Ludo’, all,

On 2019-04-15  2:56 PM, Ludovic Courtès wrote:

[...]

>
> ‘guix pull’ already provides high-level “package news”, but I agree it’d
> be nice to have a way to convey “system news” and perhaps free-form
> messages like Debian’s change logs.
>
> I suppose we could use some specially-formatted Git commits to pass
> messages to users.  I’m afraid it would be hard to get those messages
> translated.
>
> Thoughts?
>

That’s an interesting idea.  Another alternative, perhaps, could be
having a “news” or “breaking changes” section/topic on the Guix blog,
ideally with a dedicated atom feed, where one could follow changes with
drastic change in system and/or package behaviour, or ones potentially
requiring a manual intervention of sorts.  Both Parabola and Hyperbola
have that section on their website, with latest news shown on the front
page.

Thoughts?

Best,
amin

Re: java: How to patch a jar-sources

[Björn Höfling]

On Mon, 15 Apr 2019 17:19:53 +0200
Danny Milosavljevic  wrote:

> (define* (unpack #:key source #:allow-other-keys)
>   "Unpack the jar archive SOURCE.  When SOURCE is not a jar archive
> fall back to the default GNU unpack strategy."
>   (if (string-suffix? ".jar" source)
>   (begin
> (mkdir "src")
> (with-directory-excursion "src"
>   (invoke "jar" "-xf" source))
> #t)
>   ;; Use GNU unpack strategy for things that aren't jar archives.
>   ((assq-ref gnu:%standard-phases 'unpack) #:source source)))

This is only for the case without patches.
 
> Hmm... maybe the patched source gets a random name that doesn't end
> in ".jar"

The problem is before: It occurs during unpacking: The .jar file is
getting handled with "tar xvf". I looked into the source-derivation and
found the pieces. I added this line:

diff --git a/guix/packages.scm b/guix/packages.scm
index c94a651f27..412dfcc04c 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -488,12 +488,13 @@ specifies modules in scope when evaluating SNIPPET."
   (define decompression-type
 (cond ((string-suffix? "gz" source-file-name)  "gzip")
   ((string-suffix? "Z" source-file-name)  "gzip")
   ((string-suffix? "bz2" source-file-name) "bzip2")
   ((string-suffix? "lz" source-file-name)  "lzip")
   ((string-suffix? "zip" source-file-name) "unzip")
+  ((string-suffix? "jar" source-file-name) "unzip")
   (else "xz")))


This brings me a step further: The .jar-file will now be extracted.
Unfortunately, we have this in line number 593:

(let ((directory (first-file ".")))
  (format (current-error-port)
  "source is under '~a'~%" directory)
  (chdir directory)

That means: It is expected that the tarball/zipfile/archive contains a
single directory under which the sources are contained. That seams to
be the case for all .tar.* and .zip archives used within Guix packages.

To verify that, I (randomly) picked the fcgi package and repacked the
tarball, such that sources are directly in the root folder. I then get
this expected error:

[..]
Win32/logdump.dsp
source is under 'acinclude.m4'
Backtrace:
   2 (primitive-load "/gnu/store/phlnb6vy2gqjn75pivpsajyf9mq?")
In ice-9/eval.scm:
619:8  1 (_ #(# "acinclude.m4"))
In unknown file:
   0 (chdir "acinclude.m4")

ERROR: In procedure chdir:
In procedure chdir: Not a directory


Unfortunately, .jar-source-files ARE organized in such a way that
sources are organized directly in the root folder of the jar. I
currently don't see a quick AND nice way to fix this.

Wait, I have this idea:

diff --git a/guix/packages.scm b/guix/packages.scm
index c94a651f27..ffd06de358 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -491,6 +491,7 @@ specifies modules in scope when evaluating SNIPPET."
   ((string-suffix? "bz2" source-file-name) "bzip2")
   ((string-suffix? "lz" source-file-name)  "lzip")
   ((string-suffix? "zip" source-file-name) "unzip")
+  ((string-suffix? "jar" source-file-name) "jar")
   (else "xz")))
 
   (define original-file-name
@@ -584,12 +585,16 @@ specifies modules in scope when evaluating SNIPPET."
(directory (string-drop base (+ 1 dash
   (mkdir directory)
   (copy-recursively #+source directory))
-#+(if (string=? decompression-type "unzip")
+#+(if (or
+   (string=? decompression-type "unzip")
+   (string=? decompression-type "jar"))
   #~(invoke "unzip" #+source)
   #~(invoke (string-append #+tar "/bin/tar")
 "xvf" #+source)))
 
-(let ((directory (first-file ".")))
+(let ((directory (if (string=? decompression-type "jar")
+ "."
+ (first-file "."
   (format (current-error-port)
   "source is under '~a'~%" directory)
   (chdir directory)

But it fails with:

In unknown file:
   ?: 5 [primitive-load 
"/gnu/store/kg3pa52ydp3qjy41wgl0jcx3a98m82x9-guile-2.2.4.tar.xz-builder"]
In ice-9/eval.scm:
 411: 4 [eval # ()]
 399: 3 [eval # ()]
 387: 2 [eval # ()]
 393: 1 [eval # ()]
In unknown file:
   ?: 0 [memoize-variable-access! # #]

ERROR: In procedure memoize-variable-access!:
ERROR: Unbound variable: decompression-type

What's wrong here?

Björn


pgpsCCp0h9rFI.pgp
Description: OpenPGP digital signature

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Ludovic Courtès  writes:
> I removed pretty both .cache directories, moved .config sub-directories
> around, etc., and yet I am still unable to log in into the GNOME account
> (logging in to a non-GNOME account from GDM is fine.)
>
> I even tried upgrading the user’s profile just in case is contained
> incompatible schemas or who knows what, but that didn’t help.
>
> What extra bit of state am I missing?

Do you have ~/.local?  In my earlier tests this contained binary
notification data that when loaded would lead to a crash.

-- 
Ricardo

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Hello,

Ludovic Courtès  skribis:

> Ricardo Wurmus  skribis:
>
>> Turns out that the problem was with a stale /var/lib/gdm – which makes
>> me wonder: we do we have this at all?  “/var/lib/gdm” is the “gdm” user
>> account’s home directory.  But it’s not like this really needs to be
>> persistent, I think.
>
> Yes, I wonder if it’s supposed to be persistent in the first place.  I
> guess ~gdm/.cache can help speed things up maybe, and perhaps there are
> persistent settings too, like the a18n stuff?
>
>> I moved it out of the way and the gdm login prompt appeared within a few
>> seconds.  After restarting xorg-server the directory was recreated.
>
> So I moved ~gdm/.cache and ~/.cache out of the way and restarted
> ‘xorg-server’.  After that, I was still unable to log in

I removed pretty both .cache directories, moved .config sub-directories
around, etc., and yet I am still unable to log in into the GNOME account
(logging in to a non-GNOME account from GDM is fine.)

I even tried upgrading the user’s profile just in case is contained
incompatible schemas or who knows what, but that didn’t help.

What extra bit of state am I missing?

Thanks,
Ludo’.

Re: Introducting myself

[Tanguy Le Carrour]

Le 04/13, Pierre Neidhardt a écrit :
> Welcome!

Thanks!


> > The picture is not all bright however, and things started to get complicated
> > when I tried to customize the system. I've been using Python as my main 
> > language
> > for more than 10 years and Guile is… something that I still have to get 
> > used to!
> > ^_^'
> 
> Guile, Scheme and Lisp-languages in general can be quite a shock at
> first indeed.  But once you've tamed the psychological bias, the reward
> is really worth it I believe: Guile is a very powerful and expressive
> language which empowers you in ways that very few languages out there can.

Can't wait to see that! :-)

Oh, btw, thanks for the very good [A packaging tutorial for Guix][1].
The manual is quite nice, but contains a **lot** of information, so the
one-page article is really a must read!

[1] https://www.gnu.org/software/guix/blog/2018/a-packaging-tutorial-for-guix/

Regards

-- 
Tanguy

New French PO file for 'guix' (version 1.0.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix' has been submitted
by the French team of translators.  The file is available at:

https://translationproject.org/latest/guix/fr.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New French PO file for 'guix' (version 1.0.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix' has been submitted
by the French team of translators.  The file is available at:

https://translationproject.org/latest/guix/fr.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: java: How to patch a jar-sources

[Danny Milosavljevic]

(define* (unpack #:key source #:allow-other-keys)
  "Unpack the jar archive SOURCE.  When SOURCE is not a jar archive fall back
to the default GNU unpack strategy."
  (if (string-suffix? ".jar" source)
  (begin
(mkdir "src")
(with-directory-excursion "src"
  (invoke "jar" "-xf" source))
#t)
  ;; Use GNU unpack strategy for things that aren't jar archives.
  ((assq-ref gnu:%standard-phases 'unpack) #:source source)))

Hmm... maybe the patched source gets a random name that doesn't end in ".jar"



pgpDedTWRK4Da.pgp
Description: OpenPGP digital signature

Re: java: How to patch a jar-sources

[Danny Milosavljevic]

Hi Björn,

for the record, the same happened to me but I got distracted by a new shiny 
thing before I looked why.


pgpMxPfJXmcri.pgp
Description: OpenPGP digital signature

Re: java: How to patch a jar-sources

[Björn Höfling]

On Mon, 15 Apr 2019 14:26:41 +0200
Gábor Boskovits  wrote:

> Hello Björn,
> 
> 
> 
> Björn Höfling  ezt írta (időpont:
> 2019. ápr. 15., H 8:03):
> 
> > Hi Guix,
> >
> > I have a problem combining ".jar" sources with patches.
> >
> > Here is my sources definition:
> >
> > (define-public java-ecj
> >   (package (inherit java-ecj-3)
> >(version "4.6.3")
> >(source (origin
> >  (method url-fetch)
> >  (uri (string-append "
> > http://archive.eclipse.org/eclipse/downloads/drops4/R-";
> >  version
> >  "-201703010400/ecjsrc-"
> >  version
> >  ".jar"))
[..]

> > It looks like guix now wants to extract the jar-sources with "tar",
> > no longer with "jar". How can I tell Guix this is a jar-file to
> > extract from? Do I need to do that manually in a snippet? Any
> > examples? 
> I have not actually done this, as jar files are usually not sources.
> Do we have the source this file was generated from?
> Also what we do in the build system is use zip and unzip for
> extracting jar files.

jar-files can contain sources. The main intended use for this is to show
the sources to the developer in the IDE (Eclipse), but we can also use
it to build from.

As an example, look at the java-jgit package. It downloads from Maven
central a ...-sources.jar.

In my example the ecjsrc-...jar also contains .java source files, the
compiled version with .class files is named without the "src" in the
name.

Going with zip is an option, this might be a work-around. But actually,
I don't want to do everything by hand:

I thought in general you can put "whatever" (supported) file-extension
you like into the "source" field and by extension of the URI it will
select the proper unpacker (i.e. using "tar xvf" for .tar files, "tar
xzvf" for .tar.gz", "unzip" for .zip, etc).

This seams to work when just using the ".jar" URI, without patches (cmp
the java-jgit example). Only after I added the patches, it was trying
to use "tar x..", which of cause will fail on the .jar file. If noone
has a direct solution, maybe it's time for me to get my fingers dirty
and look into the source-extracting code.

Thanks,

Björn


pgpMGuv7i_n6S.pgp
Description: OpenPGP digital signature

Should we upgrade openssl?

[Christopher Lemmer Webber]

>From the openssl website:

> Note: The latest stable version is the 1.1.1 series. This is also our
> Long Term Support (LTS) version, supported until 11th September
> 2023. Our previous LTS version (1.0.2 series) will continue to be
> supported until 31st December 2019 (security fixes only during the
> last year of support). The 1.1.0 series is currently only receiving
> security fixes and will go out of support on 11th September 2019. All
> users of 1.0.2 and 1.1.0 are encouraged to upgrade to 1.1.1 as soon as
> possible. The 0.9.8, 1.0.0 and 1.0.1 versions are now out of support
> and should not be used.

I know, everyone's going to groan hearing this, but maybe given the
above it would make sense to upgrade to the openssl 1.1.0 series before
Guix 1.0 gets out the door?

I guess that would probably require a massive rebuild of core packages
though.

 - cwebb

Re: Deliver important Guix changes to users, please

[Ludovic Courtès]

Hello,

zna...@disroot.org skribis:

> I think it will be the best to have some layer of informative support for 
> updates. Like this:
>
> $ guix system --updates-available
> Commit: 1 [two days ago]
> Changes: some services are available now
>
> Commit: 2
> Changes: [red]Switch to GDM in %desktop-services. If your config is using 
> %desktop-services, you need to check manual pages.[/red]
>
> Commit: 3 (latest)
> Changes: gc clear-generations added
> $ guix package --updates-available=1week
> 90 new packages added.
> 15 packages updated.
> New packages:
> emacs-evil-lio, llgpl-license, ...
> Changed package:
> emacs 26.1 => 26.2
> ...
> That will give some knowledge that your cool config might be wrong after 
> update to the latest commit, where dm was switched to gdm.
>
> I think news should be divided to
> - 'packages news' defining the period,
> - and 'system news', the default period is from your last `guix system 
> reconfigure config.scm` or may be your last generation's date till now,
>
> And sure news should be available from guix command.
>
> There are tools for update guix from substitute servers: local or Internet. 
> There is much info in cgit logs on gnu server... Want to read more with guix.
>
> Would this kind of messages help people to bypass troubles in convenient way?

‘guix pull’ already provides high-level “package news”, but I agree it’d
be nice to have a way to convey “system news” and perhaps free-form
messages like Debian’s change logs.

I suppose we could use some specially-formatted Git commits to pass
messages to users.  I’m afraid it would be hard to get those messages
translated.

Thoughts?

Note that the GDM change could also have been addressed by fixing
‘modify-services’ to report about unmatched service types, for example.

Thanks,
Ludo’.

Re: Hurd status?

[Ludovic Courtès]

Hello Svante,

Svante Signell  skribis:

> Thanks for your reply: I'll start reading on how to use Guix and
> Shepherd. One question about the Hurd stuff: How many of the Debian
> patches to gnumach/mig/hurd/glibc did you apply for your build?

Very few!  You can see them on their page at
.  For instance, we use
stock glibc 2.28 with just the PID magic lookup (for the Hurd bits):

  
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/base.scm?id=v0.16.0-4337-gd8bead6c5d#n619
  
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-magic-pid.patch?id=v0.16.0-4337-gd8bead6c5d

Ludo’.

Re: Let’s translate!

[Ludovic Courtès]

Hi Meiyo,

Meiyo Peng  skribis:

> I can translate the Guix manual into Chinese if no one else is willing
> to do so.  But I don't have much time and will probably miss the
> deadline for Guix 1.0.

Julien and Florian can provide guidance, as you’ve seen.  :-)

As for the deadline: even a partially translated manual can help.  When
you have something that you deem useful (for example, you translated the
intro and the installation sections), then you can probably submit them
to the Translation Project so that we can integrate it.

Thank you!

Ludo’.

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

> Turns out that the problem was with a stale /var/lib/gdm – which makes
> me wonder: we do we have this at all?  “/var/lib/gdm” is the “gdm” user
> account’s home directory.  But it’s not like this really needs to be
> persistent, I think.

Yes, I wonder if it’s supposed to be persistent in the first place.  I
guess ~gdm/.cache can help speed things up maybe, and perhaps there are
persistent settings too, like the a18n stuff?

> I moved it out of the way and the gdm login prompt appeared within a few
> seconds.  After restarting xorg-server the directory was recreated.

So I moved ~gdm/.cache and ~/.cache out of the way and restarted
‘xorg-server’.  After that, I was still unable to log in

You removed all of ~gdm, right?

~/.cache/gdm/session.log shows this (the important bit is “killed by
signal 11” :-)):

--8<---cut here---start->8---
dbus-daemon[2867]: [session uid=30011 pid=2867] Activating service 
name='org.gtk.vfs.Daemon' requested by ':1.1' (uid=3
0011 pid=2878 comm="gsettings get org.gnome.system.locale region ")
dbus-daemon[2867]: [session uid=30011 pid=2867] Successfully activated service 
'org.gtk.vfs.Daemon'

(process:2887): GLib-GObject-CRITICAL **: 13:46:37.032: 
g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (obje
ct_type)' failed

(process:2887): GLib-GIO-CRITICAL **: 13:46:37.036: 
g_volume_monitor_get_mounts: assertion 'G_IS_VOLUME_MONITOR (volume
_monitor)' failed

(process:2887): GLib-GObject-WARNING **: 13:46:37.036: invalid (NULL) pointer 
instance

(process:2887): GLib-GObject-CRITICAL **: 13:46:37.036: g_signal_connect_data: 
assertion 'G_TYPE_CHECK_INSTANCE (instan
ce)' failed

(process:2887): GLib-GObject-WARNING **: 13:46:37.036: invalid (NULL) pointer 
instance

(process:2887): GLib-GObject-CRITICAL **: 13:46:37.036: g_signal_connect_data: 
assertion 'G_TYPE_CHECK_INSTANCE (instan
ce)' failed

[...]

dbus-daemon[2867]: [session uid=30011 pid=2867] Successfully activated service 
'org.gtk.vfs.AfcVolumeMonitor'
GNOME Shell-Message: 13:46:38.700: No permission to trigger offline updates: 
Polkit.Error: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action 
org.freedesktop.packagekit.trigger-offline-update is not registered

(.gnome-shell-real:2928): mutter-WARNING **: 13:46:38.911: Failed to load 
background 
'file:///gnu/store/ga4arkrdndyv52cs062n2l9hgnqfjyaq-gsettings-desktop-schemas-3.28.0/share/backgrounds/gnome/adwaita-lock.jpg':
 Erreur lors de l’ouverture du fichier 
/gnu/store/ga4arkrdndyv52cs062n2l9hgnqfjyaq-gsettings-desktop-schemas-3.28.0/share/backgrounds/gnome/adwaita-lock.jpg
 : Aucun fichier ou dossier de ce type
GNOME Shell-Message: 13:46:38.917: Error loading calendars: Erreur lors de 
l’appel de StartServiceByName pour org.gnome.Shell.CalendarServer : 
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process 
org.gnome.Shell.CalendarServer exited with status 1

(gsd-rfkill:3033): rfkill-plugin-WARNING **: 13:46:38.951: Error setting up 
rfkill: Could not open RFKILL control device, please verify your installation

(gsd-rfkill:3033): rfkill-plugin-WARNING **: 13:46:38.974: Could not open 
RFKILL control device, please verify your installation

(gsd-sharing:3036): sharing-plugin-WARNING **: 13:46:39.063: Failed to StopUnit 
service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.systemd1 was not provided by any .service files

(gsd-sharing:3036): sharing-plugin-WARNING **: 13:46:39.063: Failed to StopUnit 
service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.systemd1 was not provided by any .service files

(gsd-sharing:3036): sharing-plugin-WARNING **: 13:46:39.063: Failed to StopUnit 
service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.systemd1 was not provided by any .service files

(gsd-sharing:3036): sharing-plugin-WARNING **: 13:46:39.070: Failed to StopUnit 
service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.systemd1 was not provided by any .service files
gnome-session-binary[2872]: WARNING: Application 'org.gnome.Shell.desktop' 
killed by signal 11

(gsd-xsettings:3007): xsettings-plugin-WARNING **: 13:46:39.193: Failed to get 
current display configuration state: 
GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected 
from message bus without replying

(gsd-power:3026): power-plugin-WARNING **: 13:46:39.193: Could not create 
GnomeRRScreen: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gnome.Mutter.DisplayConfig was not provided by any .service files


(gsd-media-keys:3022): GLib-CRITICAL **: 13:46:39.199: g_variant_get_va: 
assertion 'value != NULL' failed

(gsd-media-keys:3022): GLib-CRITICAL **: 13:46:39.199: g_variant_unref: 
assertion 'value != NULL' failed
--8<---cut here---end--->8---

> Yup, after moving /home/rekado/.cache o

Re: java: How to patch a jar-sources

[Gábor Boskovits]

Hello Björn,



Björn Höfling  ezt írta (időpont: 2019.
ápr. 15., H 8:03):

> Hi Guix,
>
> I have a problem combining ".jar" sources with patches.
>
> Here is my sources definition:
>
> (define-public java-ecj
>   (package (inherit java-ecj-3)
>(version "4.6.3")
>(source (origin
>  (method url-fetch)
>  (uri (string-append "
> http://archive.eclipse.org/eclipse/downloads/drops4/R-";
>  version
>  "-201703010400/ecjsrc-"
>  version
>  ".jar"))
>  (patches
>   (search-patches
> "java-ecj-buildxml-fix-manifest.patch"
>   "java-ecj-include-props.patch"))
>  (sha256
>   (base32
>
>  "11cfgsdgznja1pvlxkjbqykxd7pcd5655vkm7s44xmahmap15gpl"
> [...]
>
> This worked pretty well until I added the patches:
>
> ./pre-inst-env  guix build java-ecj -K
> ;;; note: source file /home/bjoern/guix/wt/qt/gnu/packages/java.scm
> ;;;   newer than compiled /home/bjoern/guix/wt/qt/gnu/packages/java.go
> building
> /gnu/store/wppz7bix1r4mhddjz6k4alfnxkm919gq-ecjsrc-4.6.3.tar.xz.drv...
> /gnu/store/bl3pxxj6frg0dww8pj5dvh2d1akwvj47-tar-1.30/bin/tar: This does
> not look like a tar archive
> /gnu/store/bl3pxxj6frg0dww8pj5dvh2d1akwvj47-tar-1.30/bin/tar: Skipping to
> next header
> /gnu/store/bl3pxxj6frg0dww8pj5dvh2d1akwvj47-tar-1.30/bin/tar: Exiting with
> failure status due to previous errors
> Backtrace:
>2 (primitive-load "/gnu/store/lg0dlhwf4mfz82697bvfdwi7d86?")
> In ice-9/eval.scm:
> 619:8  1 (_ #f)
> In guix/build/utils.scm:
> 616:6  0 (invoke _ . _)
>
> guix/build/utils.scm:616:6: In procedure invoke:
> Throw to key `srfi-34' with args `(# "/gnu/store/bl3pxxj6frg0dww8pj5dvh2d1akwvj47-tar-1.30/bin/tar" arguments:
> ("xvf" "/gnu/store/1vf8lxrnkgxw0zl8i2m8rf7jxcjg9f5b-ecjsrc-4.6.3.jar")
> exit-status: 2 term-signal: #f stop-signal: #f] 56dd40>)'.
> note: keeping build directory `/tmp/guix-build-ecjsrc-4.6.3.tar.xz.drv-1'
> builder for
> `/gnu/store/wppz7bix1r4mhddjz6k4alfnxkm919gq-ecjsrc-4.6.3.tar.xz.drv'
> failed with exit code 1
> build of
> /gnu/store/wppz7bix1r4mhddjz6k4alfnxkm919gq-ecjsrc-4.6.3.tar.xz.drv failed
>
>
> It looks like guix now wants to extract the jar-sources with "tar", no
> longer with "jar". How can I tell Guix this is a jar-file to extract
> from? Do I need to do that manually in a snippet? Any examples?
>
I have not actually done this, as jar files are usually not sources. Do we
have the source this file was generated from?
Also what we do in the build system is use zip and unzip for extracting jar
files.

>
> Thanks,
>
> Björn
>
Best regards,
g_bor

>

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Heya!

Ricardo Wurmus  skribis:

>> The X.org logs all end up in that directory, so it might a little
>> frustrating for someone having X.org issues if we delete that directory
>> all the time.  I don’t remember if they get copied anywhere else.
>
> Can we cause the logs to be put in /var/log with all the other logs?

I’m not sure because GDM X logs are fundamentally per-user: GDM spawns X
as a normal user, not as root (which is pretty cool!).

Ludo’.

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

Hello,

"pelzflorian (Florian Pelz)"  skribis:

> Deniz at Parabola GNU/Linux-libre discussed a similar issue for
> Parabola today:
>
>   Here what would need to be publicized would be how to blacklist the
> radeon driver at boot, in the case something goes wrong and the user
> is left with a black screen during the boot of linux-libre.
>
>   On Parabola adding "modprobe.blacklist=radeon" to the kernel command
> line does that at boot. This enables users to easily use the
> installation medias.
>
> 
>
> Deniz also wrote that this would break HDMI, but HDMI does not work
> for me in the Guix installer anyway (but possibly it worked for
> others?)

If that’s the best option we have so far, we can do this:

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index d887313132..5776938f10 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -426,6 +426,7 @@ Access documentation at any time by pressing Alt-F2.\x1b[0m
  (target "/dev/sda")))
 (label (string-append "GNU Guix installation "
   (package-version guix)))
+(kernel-arguments '("modprobe.blacklist=radeon"))
 
 (file-systems
  ;; Note: the disk image build code overrides this root file system with

Thoughts?

Ludo’.