Hi Mathieu
> Is this ok for everybody ?
Cool!
David
Hi Ludo,
> I knew I should have stayed on vacation!
Hope you had a nice vacation :)
> The goals haven’t changed since Day 1 though.
I realize that. When I started using/contributing to guix I was not
fully aware of what that meant.
One important thing that has changed for me is that I no longe
Hi Leo
> Can you clarify whether the key was deleted inadvertently, or if you
> think it was actually "compromised". To me, key compromise means you
> believe that the private key could have been copied by a 3rd party.
Key revocation certificates are generated before something happens.
It is pos
And the Hurd has been in development since 1990, so started at roughly the
same time as the Linux kernel. Misleading information again. Hurd and Linux
started out as competitors.
On Feb 22, 2017 3:44 PM, "Clément Lassieur" wrote:
> Also note how that line was conviniently drawn just barely outsi
Also note how that line was conviniently drawn just barely outside of what
the Linux project was doing at the time, I guess most likely so that he
could still find developers to build his Hurd by saying "Linux does not
respect your freedoms"
On Feb 22, 2017 15:06, "David Craven&q
t and
all of this because of an arbitrary line RMS drew.
On Feb 22, 2017 14:58, "John Darrington"
wrote:
On Wed, Feb 22, 2017 at 02:54:32PM +0100, David Craven wrote:
Exactly why I'm leaving. You prefer to spread and force your religion
on to
people,
No we don
Exactly why I'm leaving. You prefer to spread and force your religion on to
people, and don't really care about anything other than that.
On Feb 22, 2017 05:54, "Mike Gerwitz" wrote:
> On Tue, Feb 21, 2017 at 14:13:45 +0100, David Craven wrote:
> > In most you can n
> In some laptops, you can simply remove and replace the built-in wireless card.
In most you can not. And I don't know of a way to tell if it is
possible without trying it. What about laptops that don't have usb
ports anymore? Are there any free USB-C wifi dongles yet? What about
laptops that have
> While security is important, it's far from being the only reason that
> makes free software important.
> When security and freedom conflicts, I usually prefer freedom.
I agree here too. While security and privacy are a factor for me
it's far from the most important. To me the most important is
i
> Accepting pre-built binaries as part of kernel sources
I don't think this is true either, or has not been for a very long
time (~7y?). If you look at the dates of the commits that added binary
blobs (i.e. the firmware directory), those are many years old. It is
an active effort to move the blobs
> There are many pieces of hardware that are not RYF certified and
> that work without firmware blobs.
I thought I had already argued the fact that, the fact that it works without
firmware blobs, does not mean that it is a more secure device, and in many
cases it may be much worse from a privacy p
> unless they force or persuade other people to use non-free software as well
I hope this isn't a reference to the raspberry pi firmware. If you are
talking about this firmware [0], it boots Linux since the 3rd of Jan
2017. I do not follow the developments closely, but I hardly think
that this is
> I think if you posit a free software project that works in the way you
> describe ("on its own"), it would work very much like Guile works
> right now.
An operating system has to work on all hardware. Asking people to buy a
RYF approved device to run guixsd is no different than apple requiring y
Hello guixers!
I am very grateful for all the things I could learn during my time
here and all the awesome work that you guys put in.
But I wish to leave the guix project and that my savannah account be
removed. This is not a decision I make lightly. The reason why I
decided it was time to move o
And to be clear I never suggested adding the raspberry pi firmware to
a FSDG compliant distribution.
I don't think the suggestion I made actually qualifies the raspberry
pi firmware - or any current firmware for that matter. It was made to
encourage hardware manufacturers that are willing to dip a
> David, I think you need to give up wasting your time trying to convince
> a Gnu/Linux *Libre* list that proprietary kernel blobs are a good idea.
> Most people are here because they care more about freedom than getting
> the support of every manufacturer on the market. If you want to make
> headw
> About that conversation involving some GuixSD user: He gave that kind of
> recommendation so easily? I'm shocked...
The irony is that unless you know as much about hardware as Denis you
ARE USING NON-FREE FIRMWARE. As proven by you suggestion to simply use
a different distro.
Hi Denis,
Thank you for your extensive feedback.
> With that we can still use WiFi by ignoring the intel wifi card and
> using an USB wifi card instead.
I considered using this option but realized that I had a buggy thunderbolt
controller in my laptop, that I can only update from a windows compu
* gnu/system/bootloader.scm (dd, install-grub, install-syslinux): New
procedures.
* gnu/build/install.scm (install-boot-config): New procedure.
(install-grub): Move to (gnu system bootloader).
* gnu/build/vm.scm (register-bootcfg-root): Rename register-grub.cfg-root and
adjust accordingly.
* gnu/system/vm.scm (virtualized-operating-system): Add full-boot?
option. Don't add a %store-mapping when full-boot? is passed. This leads
the grub-configuration-file procedure to look for the kernel and initrd in
/ instead of /gnu/store.
---
gnu/system/vm.scm | 31 ++---
* gnu/system/vm.scm (system-qemu-image/shared-store-script,
expression->derivation-in-linux-vm): Use operating-system-kernel-file and
system-linux-image-file-name.
* gnu/system.scm (system-linux-image-file-name): Add ARM.
---
gnu/system.scm| 9 ++---
gnu/system/vm.scm | 5 +++--
2 file
f --git a/gnu/system/bootloader.scm b/gnu/system/bootloader.scm
new file mode 100644
index 0..6366ba1cc
--- /dev/null
+++ b/gnu/system/bootloader.scm
@@ -0,0 +1,158 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2017 David Craven
+;;;
+;;; This file is part of G
* gnu/system.scm (operating-system-grub.cfg): Pass .
* gnu/system/grub.scm (boot-parameters->menu-entry): New variable.
(grub-configuration-file): Use boot-parameters->menu-entry.
---
gnu/system.scm | 12 +++-
gnu/system/grub.scm | 19 +++
2 files changed, 22 inserti
d-for-boot? #t))
(operating-system-file-systems extlinux-os)
;; Test with $(./pre-inst-env guix system vm bootloader-test.scm --full-boot)
syslinux-os
David Craven (8):
file-systems: Add FAT32 support.
system: Pass to grub.
system: Add extlinux support.
script
* gnu/system/vm.scm (common-qemu-options,
system-qemu-image/shared-store-script): Improve readability.
---
gnu/system/vm.scm | 69 ++-
1 file changed, 38 insertions(+), 31 deletions(-)
diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index a
* gnu/system.scm (operating-system-grub.cfg): Pass .
* gnu/system/grub.scm (boot-parameters->menu-entry): New variable.
(grub-configuration-file): Use boot-parameters->menu-entry.
---
gnu/system.scm | 12 +++-
gnu/system/grub.scm | 19 +++
2 files changed, 22 inserti
* 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 fb32d08a5..04274919e 100644
--- a/guix/scripts/system.scm
+++ b/guix/scri
* gnu/build/file-systems.scm (%fat32-endianness, fat32-superblock?,
read-fat32-superblock, fat32-superblock-uuid, fat32-uuid->string,
fat32-superblock-volume-name, check-fat32-file-system): New variables.
(%partition-label-readers, %partition-uuid-readers, check-file-system): Add
fat suppor
> I had followed some earlier developments but had lost track recently!
> I'm happy to see that they have released the sources of their
> microcontroller chip design.
It's more than a microcontroller chip design. The people behind sifive are
from uc berkeley and also developed a full gcc toolchain
> Is the vendor always trustworthy?
I agree with you. But the thing is that we already bought the device.
It says on the label that the device does A and only A at time x when
we bought the device. The question is do we need to add more trust
than that to the equation.
If we look at security as a
> Note: I don't know if you are talking about Linux-libre in the context
> of the package definition for Guix
Oh, I'm talking about the package definition - not linux-libre itself.
RISCV is a computer architecture like ARM or x86_64. RISCV has simply
not upstreamed their patches yet and has nothi
> "Mark was completely right - it's total BS".
Well I did some work on running guixsd on arm, part of which involved
trying to make the linux-libre package more extensible. Mark
criticized it as not being very well thought out, and I found that it
was not very extensible.
Coming from a background
> Students, mentors, and hackers: please discuss your ideas on this list
> and add them to the wiki page!
RISCV port.
I've made a lot of progress on the bootloader stuff. I'll be posting patches
for commenting soon.
I have a riscv toolchain up and running and it boots the riscv-linux. I rewrote
> If the attacker *is* vendor who supplies the proprietary device then they
> would
> not have to reverse engineer it.
You can always choose not to apply the vendors update. If for example
the company you initially trusted with by purchasing their device gets
bought by another company or you have
Hi Hartmut,
Sorry for my snide remark...
>> This hypothetical attacker is trying to escalate privileges. I don't
>> see how starting an unprivileged process would help with that.
>
> Well, simply by an exploiting a bug in that software. This is a quite
> common case :-)
It is my understanding th
> You read too much between the lines in my words.
> I'm not counting on the certifications of Harmut. I simply agree with
> the reasoning that no client and server should be combined if possible
> to limit the attack surface. That's all.
That may be true. It was my intention to back Ludo. I thin
> Okay. I prefer to wait for the outcome of the discussion around
> server+client merging. I'm in favor of separating for the reasons Harmut
> mentioned.
This is a free software community. Anyone that needs to assert his authority
with external certifications rather than actions and sound reasonin
> And from my point of view Guix already has a medium problem of acceptance
> since it munges development-files and run-time files into one package - as we
> do for all libraries.
By development files I assume you mean header files? I don't see how those can
pose a security problem. Can you elabor
> Would the git repository, or a new git repository (guix-keys.git?) be a
> bad idea? Best case, we craft something which serves as an GNUPG_HOME
> for the keys which then live in the keyring of this thing (compare to
> gentoo-keys, debian-keys, etc).
I don't think that is a good idea. Placing it
> It might be nice to associate with each committer, a list of all keys
> that they have ever used to sign commits in our git repository.
> Keys would be added to the list over time, but never removed.
Sounds good. Where would we put that list? And does that list also
need to be signed? Puh, luck
Hi!
> Revert "import: json: Explicitly ask for JSON data."
> This reverts commit 81e0bc1834490a1a8092c75a0733b15c2b407285.
I reverted this commit in my local repository for now, it breaks the
pypi, crate and some other test I can't recall (gem and/or cpan).
David
> According to "git log --show-signature" on my machine, several recent
> commits by you (including this one) were signed with a different key
> than the one you have registered on Savannah. Savannah has key
> C5E051C79C0BECDB, but your recent commits were signed with key
> 33B9E9FDE28D2C23. How
Hi Maxim
> +1. I don't see how having blobs helps security at all.
Well the problem I was getting at is that things are not as fixed as
they may seem.
Quoting wikipedia:
>> Decreasing cost of reprogrammable devices had almost eliminated the market
>> for mask ROM by the year 2000.
Translation:
* gnu/packages/firmware.scm (seabios): New variable.
---
gnu/packages/firmware.scm | 44 +++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/firmware.scm b/gnu/packages/firmware.scm
index e7d1ce49c..ff4ea1482 100644
--- a/gnu/pack
* gnu/packages/grub.scm (edk2-commit, edk2-version, edk2-origin, ovmf): New
variables.
---
gnu/packages/firmware.scm | 83 +++
1 file changed, 83 insertions(+)
diff --git a/gnu/packages/firmware.scm b/gnu/packages/firmware.scm
index ff4ea1482..9106eec
* gnu/packages/grub.scm (syslinux): New variable.
---
gnu/packages/grub.scm | 63 +++
1 file changed, 63 insertions(+)
diff --git a/gnu/packages/grub.scm b/gnu/packages/grub.scm
index 292d35373..4d9dc819b 100644
--- a/gnu/packages/grub.scm
+++ b/gnu
* 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 @@
Bakke
+;;; Copyright © 2016, 2017 Danny Milosavljevic
+;;; Copyright © 2016, 2017 David Craven
;;;
;;; This file is part of GNU Guix.
;;;
@@ -20,26 +22,33 @@
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix. If not, see <http://www.gnu.org
/gnu/packages/firmware.scm
+++ b/gnu/packages/firmware.scm
@@ -1,6 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2014, 2015, 2016 Ludovic Courtès
;;; Copyright © 2016 Eric Bavier
+;;; Copyright © 2017 David Craven
;;;
;;; This file is part of GNU Guix
> Then OK! But could you add the explanation above as a comment in the
> code?
Yes, it was worded a bit confusingly, sorry. Added a better comment and pushed.
> "an editor which makes using the fopen, and fclose calls of glibc".
You nailed the grammar there! We should probably add this to the
manual as an example of a great synopsis.
> I think the most common convention is to use the latest upstream
> release, and adding revisions on top of it. But no strong opinion.
> I tried packaging 6.03 a while back and it was very difficult. Most if
> the problems seems to be solved here, so thanks for doing this.
In general I agree, bu
> I would simply (replace 'build ...) here, instead of deleting it and
> using add-after.
I think it's a good idea to use small phases. This way it makes it
easier to extend or modify packages with
(package (inherit)). It also doesn't require an ugly (and build-this
build-that).
> Is it not possi
> This also lacks a proper commit log.
Yep, sry this was an accident. I had some patches in my guix directory
already, so when I did git send-email *.patch it sent them all...
LGTM
> 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
Yes it is! :-)
> ...but this is not. What does this flag do?
Enables some test programs... Like xrandr for kms.
> 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 :)
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
* 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
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/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
* 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/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 (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
> 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
> 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
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
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 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
> *** “do something” about compilers that cannot be bootstrapped
Like an optin/optout option? Other than that I can't imagine a solution.
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
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
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
> 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
> 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 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?
This is for new USB-C/Thunderbolt devices. Tested it with an USB-C to
HDMI adapter.
This fixes gnome-session segfaulting on intel skylake.
* 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
* 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/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.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
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
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
+ (arguments `(#:tests? #f
+ #:build-flags (list "build")
+ #:phases
+ (modify-phases %standard-phases
+ (delete 'configure
+(native-inputs `(("opam" ,opam)
+ ("topkg" ,ocaml-topkg)))
+(propagated-inpu
> 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
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
> 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))
> 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`.
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
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!
>
> [ 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 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
1 - 100 of 1013 matches
Mail list logo
