> Here is the complete patchset so you can apply it locally with git am <
> ocaml.patchset. I hope that's enough.
Thanks! Applied beautifully.
> One more addition: I will only send a rebased patch series after
> all patches have been reviewed.
> I think running “guix lint” is essential before submitting patches to
> the mailing list, because it avoids wasted effort for a lot of common
> mistakes.
It is my opinion that it is to early to
> Can we package rust nightly instead?
> The ABI is stable nowhere, but nightly has all the features while
> stable is limited.
I doubt that this solves any underlying problem. This was one of my
initial thoughts too. I've already tried these superficial hacks that
try to avoid the problem. But I'
> Both can happen at the same time and help each other. I/we need
> these patches, and I think keeping this branch around on our (my)
> side will help finding bugs in the cargo build-system. I just
> hope it won't be another year until it all works well enough.
Well if you'd like to help there, I
+ (ocaml-forge-origin name version 1627
+"0cyj6sfdvzx8hw7553lhgwc0krlgvlza0ph3dk9gsxy047dm3wib"))
I changed this to be ocaml-forge-uri.
There are multiple reasons why I think it's a better idea:
* if one ever writes an ocaml updater then it can use the existing
code to update the ha
Looks like the license is expat.
Or it could go into a separate build-system. There are quite a few kde
phases that could go in there. Either way, I'm fine with it.
> + (source
> + (origin
should be (source (origin
> + (home-page
> + "https://github.com/sol/markdown-unlit#readme";)
> + (synopsis
> + "Literate Haskell support for Markdown")
> + (description
> + "This package allows you to have a README.md that at the same time is a
(h
+(arguments `(#:phases (modify-phases %standard-phases (delete 'check
The standard way of doing this is with #:tests? #f.
> The thing is tests are passed during 'build. This is activated by the
> --enable-tests argument, that is enabled by #:tests? #t.
Ah I see. Then it makes sense. I was a bit hasty with this. I already
pushed the first 20 packages. Sorry about that, I'll change it back.
If you take a little more
> If you take a little more care with the commit message conventions and
> coding style, we might be able to convince Ludo to give you commit
> access, since you are clearly our local ocaml expert :)
Not that I have any say in this and apologize if I'm overstepping...
> I understand the concerns of David Craven regarding
> ‘cargo-build-system’, though OTOH I’m tempted to think
> ‘cargo-build-system’ is probably not so bad if it managed to build all
> this. ;-) But anyway, I’ll David and you figure out what the best
> approach is!
I haven'
100644
--- a/gnu/build/file-systems.scm
+++ b/gnu/build/file-systems.scm
@@ -1,5 +1,6 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2014, 2015, 2016 Ludovic Courtès
+;;; Copyright © 2016 David Craven
;;;
;;; This file is part of GNU Guix.
;;;
@@ -71,67 +72,69 @@
>> -(define (read-ext2-superblock device)
>> +(define (ext2-read-superblock device)
>
> I’d prefer to keep the previous name, which is more conventional I think
> and more readable.
WDYT about ext2:read-suberblock? It's used within guile for example
stat:block or stat:size.
David
Pushed with your suggestions, thanks! :)
* gnu/build/file-systems.scm
* gnu/system/file-systems.scm
* gnu/system/linux-initrd.scm
---
gnu/build/file-systems.scm | 51 +++-
gnu/system/file-systems.scm | 64 -
gnu/system/linux-initrd.scm | 28 +++-
Hi!
It doesn't quite work yet, but wanted to know if you think that moving
checking the file systems outside the mounting procedure to be a good
idea or not.
Alternatively I could try moving all of the file-system-checking to
the build side, but I wanted to use gexps so that we can avoid this:
-
* gnu/packages/audio.scm (ardour)[inputs]: Add eudev.
---
gnu/packages/audio.scm | 1 +
1 file changed, 1 insertion(+)
diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index f3a337925..5e22c1f22 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -223,6 +223,7 @@ names
These variants are no longer needed.
This reverts commit 45591fd7fde1a400a416cb99939f6dd766445f94.
---
gnu/packages/algebra.scm | 17 -
gnu/packages/audio.scm | 4 ++--
gnu/packages/music.scm | 4 ++--
3 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/gnu/packa
Ah yes it makes more sense now, thank you!
David
> What commit(s) made these variants obsolete? When I added them fftw and
> fftwf did not install the threaded variants that Ardour was looking
> for. Has either ardour or fftw been updated since then or has something
> else changed?
>
> In any case, if Ardour now builds without these variants th
Ludo added the pthread-variant procedure, it's not used anywhere else
so I don't know if we want to keep it around or not.
+ (add-before 'install 'create-dest-dirs
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+ (mkdir out)
+ (mkdir (string-append out "/bin")
+ (replace 'install
+ (lamb
* gnu/packages/linux.scm (btrfs-progs/static): New variable.
---
gnu/packages/linux.scm | 30 ++
1 file changed, 30 insertions(+)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 10dbf20a2..dcf079e64 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packa
Courtès
-;;; Copyright © 2016 David Craven
+;;; Copyright © 2016, 2017 David Craven
;;;
;;; This file is part of GNU Guix.
;;;
@@ -238,56 +238,70 @@ warning and #f as the result."
(else
(apply throw args
-(define (partition-predicate read
* gnu/build/file-systems.scm (%btrfs-endianness, btrfs-superblock?,
read-btrfs-superblock, btrfs-superblock-uuid,
btrfs-superblock-volume-name, check-btrfs-file-system): New variables.
(%paritition-label-readers, %partition-uuid-readers): Add btrfs
readers.
* gnu/system/linux-initrd.scm (li
* gnu/build/file-systems.scm (check-file-system): Use file-system type
specific checker.
(check-ext2-file-system): New variable.
---
gnu/build/file-systems.scm | 55 +-
1 file changed, 35 insertions(+), 20 deletions(-)
diff --git a/gnu/build/file-sy
the basic test does not exercise the file-system detection logic
Nope, everything seems good - the bug report is definitely due to not
updating guix since 4. Dez.
Also requires this patch:
[PATCH] gnu: e2fsck/static: Only copy e2fsck.
* gnu/packages/linux.scm (e2fsck/static)[arguments]: Only copy e2fsck.
[synopsis, description]: Adjust accordingly.
---
gnu/packages/linux.scm | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
/file-systems.scm
+++ b/gnu/build/file-systems.scm
@@ -1,6 +1,6 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2014, 2015, 2016 Ludovic Courtès
-;;; Copyright © 2016 David Craven
+;;; Copyright © 2016, 2017 David Craven
;;;
;;; This file is part of GNU Guix
* gnu/packages/rust.scm (rustc)[arguments]: Retain binutils. Add
wrap-rustc phase.
Problem reported by Ben Woodcroft .
---
gnu/packages/rust.scm | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index 97d0d7cb0..ae0
An idea: How about adding tests for packages?
A simple compile check for a compiler or something like that. The
problem with manual testing is that the environment could hide bugs.
This would make sure that dependencies are retained and programs are
wrapped etc.
Useful or not?
+(define-public fluid
+ (package
+(name "fluid")
+(version "0.8.0")
+(source (origin
+ (method url-fetch)
+ (uri (string-append
+"https://github.com/hawaii-desktop/fluid";
+"/releases/download/v" version "/"
+
Never mind, fluid 0.8.0 didn't have any tests yet.
> Additionally they are not the same fluid, lirios is the merge of
> some other project which did "qml" before and of this hawaii.
I believe that fluid was forked from hawaii to papyros and that the
main developer of hawaii and fluid is now the main developer of lirios
and lirios-fluid. Sorry if i
Hi Jose,
Some changes I made:
* change module name to (gnu packages nim).
* reorder imports alphabetically.
* added you to the copyright header.
* added a comment as to why the tests are disabled.
* returned true after substitute*
* used (zero? (system* "./install.sh" ...
* removed new line after
> Thanks for cleaning *the stupid mess* I made with this particular package.
> Sorry for that, I'll start to calm down and check my patches before
> submitting.
Not at all! Their just details... You did all the important stuff :)
Cheers,
David
> What’s wrong with using “fsck.extN” like we did before?
fsck.extN is exactly the same binary as e2fsck when compiled
statically. This reduces the e2fsck/static package to a third of it's
previous size.
David
2016 Efraim Flashner
+;;; Copyright © 2016 ng0
+;;; Copyright © 2016 David Craven
+;;;
+;;; This file is an addendum to GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free
* gnu/system.scm (operating-system-bootloader-configuration-file,
kernel->bootloader-label, bootloader-device): Rename variables.
* guix/scripts/system.scm (install-bootloader*,
profile-bootloader-entries, system->bootloader-entry): Rename
variables.
(install, perform-action, %default-optio
* guix/scripts/system.scm (%options, show-help): Adjust accordingly.
---
guix/scripts/system.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index 274325ab3..bb9e478d6 100644
--- a/guix/scripts/system.scm
+++ b/guix/scri
These three files should be bootloader agnostic. This doesn't make
them that yet, but it is a first step in that direction.
> Wow!
Don't get too excited yet... :)
>> NOTE: Builds 6634/18623.
> What does this note mean?
That it only builds to a third.
guix download
https://commondatastorage.googleapis.com/chromium-browser-official/chromium-53.0.2785.101.tar.xz
warning: failed to install locale: Invalid argument
St
> Don't get too excited yet... :)
Packaging chromium is a pain in the ass... There was talk on IRC about
inox, so I submitted my progress so far.
* gnu/packages/tls.scm (gnutls)[native-inputs]: Make perl a native input.
---
gnu/packages/tls.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm
index e577421fa..55e4d66f8 100644
--- a/gnu/packages/tls.scm
+++ b/gnu/packages/tls
> What do you think?
I want to clearly separate the bootloader configuration file stuff
from the bootloader stuff. I think that we shouldn't have to even
specify a bootloader tag at all (it defaults to #f).
We can have a default bootloader entry printer that just prints all
the important informat
> Tell me about it! I've been secretly maintaining a Chromium branch over
> at https://github.com/mbakke/guix/commits/chromium . It's frequently
> rebased.
Looks awesome!
> One thing that worries me about Inox is that version 53 is very old and
> likely contains known vulnerabilities. Do you know
> Do you know what perl is used for in gnutls? I see it contains no
> references, but I also tried building without perl and everything seems
> fine. Perhaps we can just remove it?
Anyone against simply removing perl as a dependency?
> Looks good to me, but this should be applied to 'core-updates
> I actually picked most of the patches from ungoogled-chromium (which
> includes inox and iridium), but skipped "high maintenance" ones. This
> started as an attempt to package that very project, but they were
> lagging too far behind upstream IMO.
Ah yes, I saw it now. Including the Warning in t
So finished building chromium finally!
A major issue:
* no hidpi scaling: didn't there use to be an enable_hdpi flag?
Recompiling with enable_hdpi=true see if that works
and some issues minor issues:
* ugly font: is new times roman the default? what do other distros do?
* menu has a dark backg
I agree on this patch. The renaming is not very good and breaks
things. It needs to be done in smaller steps. The one that renames the
flag could be done dough, since that doesn't break anything and
changes the cli interface. The sooner we can do that the better IMO,
because it is a user facing cha
Awesome stuff!
>> * no hidpi scaling: didn't there use to be an enable_hdpi flag?
>> Recompiling with enable_hdpi=true see if that works
> Oops, let us know!
I think that the flag was removed and is the default now. I expect
that the problem is that some dependencies need to be added to the
wrapper. I'm not usi
Hi Dave,
Someone can always extend the configuration with more options, I don't
think that all options need to be exposed to make the service useful.
I don't think we should hold up patches that can easily be extended later
and don't break anything.
David
Hi!
>
> [ 12.079023] [drm] Initialized radeon 2.48.0 20080528 for :01:00.0 on
> minor 0
> [ 13.253525] input: HDA Intel MID Mic as
> /devices/pci:00/:00:1b.0/sound/card0/input18
> [ 13.253746] input: HDA Intel MID Headphone as
> /devices/pci:00/:0
Hi John,
I looked at adding btrfs support, and noticed that there was a lot of
trailing white space. Please remove trailing whitespace before
pushing...
Looks really nice!
David
Hi!
I cannot reproduce the issue on current master, sorry!
make check-system TESTS="separate-store-os" would show if there's a
problem with multiple file-systems using labels.
If you want more help with your issue please come and visit us on IRC...
David
> make check-system TESTS="separate-store-os" ？ build guix from sources?
Assuming you have a default guixsd installation with no modifications,
you should be able to run `guix pull` to get the latest sources and
`guix reconfigure`.
> will erroneously return #t when (file-system-mount-point fs) evaluates
> to "/gn" and (%store-directory) to "/gnu/store". Will it not???
The trick is to revert the arguments:
(string-prefix? (%store-directory) (file-system-mount-point fs))
You're the boss :)
Currently have to study for exams, then I'll be working on adding a
system test for efi which will involve a bunch of work - building
coreboot - add tianocore payload and making qemu flags more
configurable (the idea being that we can add system tests for uboot
using the coreboo
> Surely this means that the Makefile is wrong?
I think that in projects that use Makefiles it's the expectation that
incremental compilation only works in "most" cases.
I really like ninja - I think it is un-opinionated and has solid
fundamentals. I think that a cool project would be to write a
+ (arguments `(#:tests? #f
+ #:build-flags (list "build")
+ #:phases
+ (modify-phases %standard-phases
+ (delete 'configure
+(native-inputs `(("opam" ,opam)
+ ("topkg" ,ocaml-topkg)))
+(propagated-inpu
Hi Rohit,
> Is it possible to run two init processes?
No it is not.
> beginners who are frustrated by standard distro
Why are you frustrated with standard distro?
> easily get all the features of guixsd on a standard linux distribution.
You can run guix on a standard linux distro.
> It will
Hi Marius,
What do you think about moving the chromium package into a separate
repo? I have some other packages that won't be accepted into guix. It
would be nice to have a place to put these and maybe sometime add a
guix publish service for it later. I can't expect my mother to compile
chromium h
* gnu/packages.scm (replace-input): New procedure.
---
gnu/packages.scm | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/gnu/packages.scm b/gnu/packages.scm
index 0aa289d56..2535e10b1 100644
--- a/gnu/packages.scm
+++ b/gnu/packages.scm
@@ -53,7 +53,9
* gnu/packages/gnome.scm (mutter): Update to HEAD.
[native-inputs]: Add autoconf, automake and libtool.
[arguments]: Add autoreconf phase.
---
gnu/packages/gnome.scm | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/gnu/packages/gnome.scm b/gnu
* gnu/packages/gnome.scm (gnome-disk-utility): New variable.
---
gnu/packages/gnome.scm | 50 ++
1 file changed, 50 insertions(+)
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 5fbd0c111..955ac610a 100644
--- a/gnu/packages/gnome
* gnu/packages/version-control.scm (git-crypt): New variable.
---
gnu/packages/version-control.scm | 41
1 file changed, 41 insertions(+)
diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index 03ae398bd..84eafdd93 100644
---
* gnu/packages/linux-libre-4.9-x86_64.conf
* gnu/packages/linux-libre-4.9-i686.conf
---
gnu/packages/linux-libre-4.9-i686.conf | 1 +
gnu/packages/linux-libre-4.9-x86_64.conf | 1 +
2 files changed, 2 insertions(+)
diff --git a/gnu/packages/linux-libre-4.9-i686.conf
b/gnu/packages/linux-libre-
* gnu/packages/glib.scm (appstream-glib): New variable.
---
gnu/packages/glib.scm | 45 -
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index 7c61ab3d2..83afa38ae 100644
--- a/gnu/packages/gli
* gnu/system/install.scm (installation-os)[packages]: Add gptfdisk.
---
gnu/system/install.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index ad234fd9c..944d9f7e7 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install
This fixes gnome-session segfaulting on intel skylake.
This is for new USB-C/Thunderbolt devices. Tested it with an USB-C to
HDMI adapter.
I was surprised that linux-libre works on the dell xps 13. I'm
considering buying an atheros wifi card, since that's the only thing
that does not work. Does anyone know how to find out if there is a
BIOS whitelist/blacklist? So it's just ARM boards that don't work with
linux-libre?
> I was surprised that linux-libre works on the dell xps 13. I'm
> considering buying an atheros wifi card, since that's the only thing
> that does not work. Does anyone know how to find out if there is a
> BIOS whitelist/blacklist? So it's just ARM boards that don't work with
> linux-libre?
I'm h
> I don't think the firmware needs to be uploaded at all to the AR9285 device.
I don't understand:
1. free firmware - anyone can update the firmware
2. binary blob - the vendor can update the firmware
3. fixed at manufacturing time - no one can update the firmware
Option 1 is obviously superior
Hi Danny,
> For example, let's say Intel had non-updateable microcode on its CPUs and it
> included a backdoor. If anyone *ever* found it, nobody would trust Intel ever
> again - and Intel couldn't sweep it under the rug because millions of
> physical chips that include the backdoor would be in
Mmh, I think that forcing binary blobs out of the linux kernel is only
useful if vendors move more work into the driver and silicon instead
of firmware that cannot be updated, since each flash device is a
security risk. But it could also backfire. The thunderbolt firmware
for example is only update
Motivation:
We want to be able to exercise our freedoms in all parts of our
computing systems. This leads to the benefits of higher security and
maintaining hardware devices after their end of life.
Background:
All peripheral devices work roughly the same.
Host Controller Interface <-> Link Layer
> *** “do something” about compilers that cannot be bootstrapped
Like an optin/optout option? Other than that I can't imagine a solution.
Hi Taylan,
> Being freely redistributeable doesn't make a blob free software
> obviously, so endorsing such blobs would be out of the question as per
> the core principles of the FSF. Correct me if I misunderstand.
The requirements I proposed for the definition of free firmware is
already more t
Hi Christopher,
I like to understand things. For me the most important thing is that I
have the documentation available to me and can study how it works. For
most modern chips there is simply no documentation available to me.
But I guess you are right, even if I think that some hardware that
works
Hi guix,
Currently we use propagated inputs to specify propagated compile time
dependencies when they are needed by the header files or pkg-config
files or when they are needed at runtime. In addition we have the
mechanism of wrap-program to avoid having runtime dependencies being
propagated so th
> Thoughts?
Actually it's a bad idea because it changes the semantics of native to
mean compile-time instead of the current semantics which means native
=P
> I think relying on unreleased software is fine when that is known to fix
> security issues. In other cases, we should stick to upstream releases
> IMO: it’s upstream’s job to decide when a commit can be considered a
> release.
It's the 3.22.2 branch so it contains only backported bugfixes. Arch
* gnu/packages/grub.scm (seabios): New variable.
---
gnu/packages/grub.scm | 38 ++
1 file changed, 38 insertions(+)
diff --git a/gnu/packages/grub.scm b/gnu/packages/grub.scm
index 292d35373..a775e213c 100644
--- a/gnu/packages/grub.scm
+++ b/gnu/packages/grub
---
gnu/packages/base.scm | 1 +
gnu/packages/glib.scm | 3 ++-
gnu/packages/gnome.scm | 1 +
gnu/packages/gtk.scm| 2 +-
gnu/packages/webkit.scm | 3 ++-
5 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index c75e03828..b50dd57c
* gnu/packages/grub.scm (grub): Add prefix.
---
gnu/packages/grub.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/grub.scm b/gnu/packages/grub.scm
index c6716a2f6..292d35373 100644
--- a/gnu/packages/grub.scm
+++ b/gnu/packages/grub.scm
@@ -24,7 +24,7 @@
* gnu/packages/grub.scm (ovmf): New variable.
---
gnu/packages/grub.scm | 82 +++
1 file changed, 82 insertions(+)
diff --git a/gnu/packages/grub.scm b/gnu/packages/grub.scm
index a775e213c..4da01ceb9 100644
--- a/gnu/packages/grub.scm
+++ b/gnu/pac
---
gnu/packages/xdisorg.scm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/xdisorg.scm b/gnu/packages/xdisorg.scm
index ee83934ca..42fa0cc1b 100644
--- a/gnu/packages/xdisorg.scm
+++ b/gnu/packages/xdisorg.scm
@@ -273,7 +273,7 @@ rasterisation.")
(define-p
yright © 2016, 2017 David Craven
;;;
;;; This file is part of GNU Guix.
;;;
@@ -20,29 +22,34 @@
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
-(define-module (gnu packages grub)
- #:use-
* gnu/packages/grub.scm (syslinux): New variable.
---
gnu/packages/grub.scm | 54 +++
1 file changed, 54 insertions(+)
diff --git a/gnu/packages/grub.scm b/gnu/packages/grub.scm
index 4da01ceb9..2e692a100 100644
--- a/gnu/packages/grub.scm
+++ b/gnu
Ups, sry these patches aren't ment for the ML. Also please ignore the
libdrm and epiphany patches!
---
gnu/packages/gnome.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 955ac610a..e6dd2e306 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -3684,7 +3684,7 @@ work and the interface is well tested
> Too late :) Are these packages working? I would really like to have
> SeaBIOS, OVMF and syslinux in Guix!
Those are for the ML, the other three are accidents :)
> ...but this is not. What does this flag do?
Enables some test programs... Like xrandr for kms.
Yes it is! :-)
> Could you clarify the commit log (like “Add CONFIG_HOTPLUG_PCI=y.”), and
> mention “For USB-C/Thunderbolt devices. Tested it with an USB-C to HDMI
> adapter.” in the log as well?
It's actually a duplicate definition. Missed it when searching the
file, it was probably missing from my custom buggy
LGTM
401 - 500 of 1013 matches
Mail list logo
