Re: December 2020 (old) bugs squashing!

[zimoun]

Hi,

On Sat, 05 Dec 2020 at 20:42, "Bonface M. K."  wrote:

> Just curious, how do you get debbugs to show
> forgotten patches. I'm only beginning to use it
> now ...

Forgotten patches are just old patches. ;-)


What I do with Emacs is: “M-x debbugs-gnu“ to have all the bugs and
patches; with something in my config file as:

  (setq
   debbugs-gnu-default-packages '("guix-patches" "guix")
   gnus-summary-line-format "%I%(%[ %n%]%) %s\n"))

Then I scroll down the buffer, generally M-> and I look for the state
normal in red; which means no answer in the thread.  And I pick one from
my interest, or hitting p to move.  In any case, it is worth to read all
of them. :-) Next, I try to understand and/or to reproduce.  Three
cases:

 a) lacking info so reply for asking more details
 b) appear to me not-a-bug anymore so ask for status
 c) real bug so report/update what I did

In addition, I have an Org-mode to track what I open and then remind me
3 weeks later in my agenda.  If no answer, I mark it as moreinfo with
’M-x debbugs-gnu-send-control-message’ (C).  Otherwise I add an item to
my TODO list to work on it if I feel enough annoyed.  Time to time, when
I attend to boring meeting, I review all the moreinfo and close some if
they are too old, ask again if I am not confident.


Reading the bugs via Debbugs, I do ‘M-x org-capture’ (C-ctth blabla C-c
C-c) then stash the link of the bug ’M-x my/guix-issue’ and start the
reply ’M-x gnus-summary-wide-reply-with-original’ (R), edit, and ’M-x
message-send-and-exit’ (C-c C-c), assuming that Emacs is configured to
send email. :-)


Snippet of my config:

--8<---cut here---start->8---
  (define-key gnus-summary-mode-map "R" 'gnus-summary-wide-reply-with-original)
  (define-key gnus-article-mode-map "R" 'gnus-summary-wide-reply-with-original)

  (setq
   org-capture-templates
   (backquote
(("t" "Todo")
 ("th" "Hunt" entry
  (file+headline "~/org/todo.org" "Bug Hunt")
  ,(my/org-templates-file "todo-bug.org"))
  org-capture-templates-contexts
  '(("th" ((in-mode . "gnus-summary-mode")))
("th" ((in-mode . "gnus-article-mode")
--8<---cut here---end--->8---

where the capture is:

--8<---cut here---start->8---
* TODO  [#C] Bug %?:hunt:
  SCHEDULED:  %(org-insert-time-stamp (org-read-date nil t "+3w"))
  :LOGBOOK:
  CLOCK: %U--%U =>  0:00
  :OPEN: %U
  :END:
  :PROPERTIES:
  :Open: %U
  :Subject: %:subject
  :Date: %:date
  :MessageID: %:message-id
  :END:
--8<---cut here---end--->8---

and the helper is:

--8<---cut here---start->8---
(defmacro defun-bug->url (name url  docstring)
  "Macro returning yankage #bug URL.

The `interactive' function that the macro returns is then referred by NAME.

Please provide a DOCSTRING."
  (let ((fun (intern (symbol-name name)))
(doc (concat docstring "\n\n"
   (format "Yankable result: `%sNUMBER'." url
`(defun ,fun (number)
   ,doc
(interactive
 (list
  (progn
(when (not (boundp 'debbugs-gnu-bug-number))
  (setq debbugs-gnu-bug-number -2))
(read-string
 (format "Bug number (%s): " debbugs-gnu-bug-number)
 nil nil debbugs-gnu-bug-number
  (let ((str (format "%s%s" ,url number)))
(kill-new str)
(when current-prefix-arg
  (browse-url str))
(message (format "%s killed." str))

(defun-bug->url my/guix-issues "http://issues.guix.gnu.org/issue/;
  "Add URL of bug NUMBER to `kill-ring'.")
(defun-bug->url my/guix-debbugs "https://debbugs.gnu.org/cgi/bugreport.cgi?bug=;
  "Add (old) URL of bug NUMBER to `kill-ring'.")
--8<---cut here---end--->8---


Last, there is one point I do not like with the Emacs front-end of
Debbugs is that the network is required.  Well, I would prefer dump all
the mbox and work with Emacs+Notmuch but I have not yet configured that.
If someone has tip, please share. :-)

Or maybe fetch from issues.guix.gnu.org the Mumi maildir+mu database.

Hope that helps,
simon

Re: Staging branch

[Leo Famulari]

On Sun, Dec 06, 2020 at 03:20:50PM -0500, Leo Famulari wrote:
> `guix refresh --list-dependents` doesn't dependencies that go through
> build systems, unfortunately. You could do `git grep ruby-build-system
> gnu/packages`, choose some test packages, and let the build farm sort
> out the rest.

Marius shared this Guile snippet:

--
$ ./pre-inst-env guile
scheme@(guile-user)> (use-modules (guix build-system ruby) (gnu packages) (guix 
packages))
scheme@(guile-user)> (fold-packages (lambda (package result) (if (eq? 
(package-build-system package) ruby-build-system) (cons (package-name package) 
result) result)) '())
$1 = ("ruby-i18n" "ruby-data_uri" "ruby-rubocop-performance" 
"ruby-range-compressor" "ruby-rr" "ruby-pry" "ruby-highline" 
"ruby-websocket-driver" "ruby-webmock" "ruby-cucumber-core" "ruby-ae" 
"ruby-notiffany" "ruby-gem-hadar" "ruby-sanitize" "ruby-thread-safe" "ruby-ox" 
"ruby-morecane" "ruby-loofah" "ruby-htmlentities" "ruby-sequel" 
"ruby-permutation" "ruby-fast-gettext" "swagger-diff" "bundler" 
"ruby-json-schema" "ruby-thor" "ruby-multipart-post" "ruby-test-construct" 
"ruby-mail" "ruby-sporkmonger-rack-mount" "ruby-daemons" "ruby-hamster" 
"ruby-prawn-manual-builder" "ruby-tzinfo-data" "ruby-spinach" 
"ruby-bio-commandeer" "ruby-atoulme-saikuro" "ruby-fivemat" "ruby-colorize" 
"ruby-hydra" "ruby-rc4" "ruby-rb-fsevent" "ruby-ruby-prof" "ruby-jwt" 
"ruby-rexml" "ruby-oauth2" "ruby-childprocess" "ruby-hoe-git" "ruby-blankslate" 
"ruby-nio4r" "ruby-bio-logger" "ruby-cliver" "ruby-prawn-icon" "ruby-builder" 
"ruby-rack" "ruby-rb-inotify" "ruby-slop" "ruby-erubis" "ruby-tomparse" 
"ruby-rack-protection" "ruby-terminfo" "ruby-bump" "ruby-character-set" 
"ruby-shoulda-context" "ruby-minitest-bacon" "ruby-coderay" "ruby-aruba" 
"ruby-sass" "ruby-mspec" "ruby-prawn-table" "ruby-parser" "ruby-backport" 
"ruby-chunky-png" "ruby-spectroscope" "ruby-multi-json" "ruby-pry-editline" 
"ruby-open-uri-cached" "ruby-ptools" "ruby-power-assert" "ruby-parallel" 
"ruby-sass-listen" "ruby-unindent" "ruby-shellany" "ruby-text" "ruby-commander" 
"ruby-rubocop-ast" "ruby-term-ansicolor" "ruby-rake-compiler" "ruby-mkmf-lite" 
"ruby-log4r" "ruby-json" "ruby-code-statistics" "ruby-sqlite3" "ruby-gettext" 
"ruby-ruby-engine" "ruby-rubocop" "ruby-simplecov-html" 
"ruby-minitest-reporters" "ruby-forking-test-runner" "ruby-guard" 
"ruby-rspec-expectations" "ruby-maruku" "ruby-systemu" "ruby-rainbow" 
"ruby-ansi" "ruby-utils" "ruby-cucumber-tag-expressions" "ruby-fuubar" 
"ruby-benchmark-ips" "ruby-rspec-mocks" "ruby-net-scp" "ruby-mini-portile" 
"ruby-rspec-wait" "ruby-given-core" "ruby-minitest-pretty-diff" "ruby-hocon" 
"ruby-ast" "ruby-pry-byebug" "ruby-sorcerer" "ruby-pkg-config" "ruby-globalid" 
"ruby-packnga" "ruby-rspec" "ruby-middleware" "ruby-rubyzip" "ruby-racc" 
"ruby-simplecov" "ruby-rack-test" "ruby-rdoc" "ruby-mime-types" 
"ruby-useragent" "ruby-rouge" "ruby-regexp-parser" 
"ruby-wayback-machine-downloader" "ruby-prawn" "ruby-puma" "ruby-creole" 
"ruby-git" "ruby-gimme" "ruby-mime-types-data" "ruby-addressable" "ruby-cutest" 
"ruby-method-source" "ruby-em-websocket" "ruby-cucumber-wire" 
"ruby-sys-filesystem" "ruby-mercenary" "ruby-mimemagic" 
"ruby-cucumber-html-formatter" "ruby-mathn" "ruby-netrc" "ruby-byebug" 
"ruby-instantiator" "ruby-haml" "ruby-unf" "ruby-omniauth-oauth2" "ruby-locale" 
"ruby-rest-client" "ruby-redcloth" "ruby-idn-ruby" "ruby_version" "ruby-fakefs" 
"ruby-oj" "ruby-progressbar" "ruby-cuke-modeler" "ruby-treetop" "ruby-execjs" 
"ruby-cucumber-create-meta" "ruby-omniauth" "ruby-bacon-colored-output" 
"ruby-asciidoctor-pdf" "ruby-progress_bar" "ruby-markaby" "ruby-yard-tomdoc" 
"ruby-deep-merge" "ruby-rouge" "ruby-ffi-rzmq" "ruby-regexp-property-values" 
"ruby-heredoc-unindent" "ruby-wwtd" "ruby-contracts" "ruby-tdiff" "ruby-varint" 
"ruby-polyglot" "ruby-marcel" "ruby-multi-test" "ruby-afm" "ruby-ruby-parser" 
"ruby-qed" "ruby-net-http-persistent" "ruby-sys-uname" "ruby-octokit" 
"ruby-sawyer" "ruby-minitest-moar" "ruby-sdoc" "ruby-backports" 
"ruby-public-suffix" "ruby-pygmentize" "ruby-xml-simple" "ruby-rubytest" 
"ruby-connection-pool" "ruby-byebug" "ruby-ascii85" 
"ruby-command-line-reporter" "ruby-minitest-global-expectations" "ruby-net-ssh" 
"ruby-eventmachine" "ruby-open4" "ruby-css-parser" "ruby-mustache" 
"ruby-net-http-digest-auth" "ruby-lumberjack" "ruby-minitest" "ruby-docile" 
"ruby-thin" "ruby-mustermann" "ruby-rjb" "ruby-faraday" "ruby-minitest-tu-shim" 
"ruby-rspec-core" "ruby-orderedhash" "ruby-dep" "ruby-concurrent" "mailcatcher" 
"ruby-sinatra" "ruby-powerpack" "ruby-shoulda" "ruby-cucumber-expressions" 
"ruby-rspec-expectations" "ruby-sprockets" "ruby-rake" "ruby-brass" 
"ruby-options" "ruby-minitar" "ruby-warden-oauth2" "ruby-multi-xml" 
"ruby-listen" "ruby-asciidoctor" "ruby-prawn-svg" "ruby-tilt" 
"ruby-ffi-rzmq-core" "ruby-sassc" "ruby-pdf-core" "ruby-gherkin-ruby" 
"ruby-crack" "ruby-coveralls" "ruby-yard-with-tests" "ruby-nokogiri-diff" 
"ruby-nokogiri" 

Re: bug#45069: BUG: Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces

[Jesse Dowell]

Hi All,

I believe the recommended suggestion is Debian specific is it not?

My kernel supports user namespaces and doesn't expose that file at that
location.

The only way I can work around the issue is to downgrade guix to the commit
on the master branch right before 8bc5ca5160db3d82bd5b6b2b7ed80c96f42bd33e

guix pull --commit=0d5d1bdf911659f60601058e8e1678187b7ba664
--allow-downgrades

Best,
Jesse

On Sun, Dec 6, 2020 at 12:03 PM zimoun  wrote:

> Hi,
>
> Please try the recommendation. Have you tried it?
>
>   please set /proc/sys/kernel/unprivileged_userns_clone to "1"
>
> As root, you just do:
>
>   echo 1 > /proc/sys/kernel/unprivileged_userns_clone
>
> then “guix environment -C” should work as expected.  To do the trick
> automatically with Sheperd, I do not know, but I am sure that the
> systemd equivalent
>
>   echo "kernel.unprivileged_userns_clone = 1" > /etc/sysctl.d/local.conf
>   sysctl --system
>
> seems doable with Guix System.
>
>
> On my system, and I need explanations if it does not work similarly on
> yours, I simply do:
>
> --8<---cut here---start->8---
> $ guix environment -C --ad-hoc hello -- hello
> guix environment: error: cannot create container: unprivileged user cannot
> create user namespaces
> guix environment: error: please set
> /proc/sys/kernel/unprivileged_userns_clone to "1"
>
> $ su -
> Password:
> # echo 1 > /proc/sys/kernel/unprivileged_userns_clone
> # logout
>
> $ guix environment -C --ad-hoc hello -- hello
> Hello, world!
> --8<---cut here---end--->8---
>
> Hope that helps,
> simon
>
>
>
>

Re: BUG: Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces

[yasu]

Hi Zimoun,

I tried as you suggested but it didn't work...


   root@guix ~# echo "kernel.unprivileged_userns_clone = 1" >
   /etc/sysctl.d/local.conf
   -bash: /etc/sysctl.d/local.conf: No such file or directory
   root@guix ~# sysctl --system
   root@guix ~# logout
   ~$ guix environment -C
   guix environment: error: cannot create container: unprivileged user
   cannot create user namespaces
   guix environment: error: please set
   /proc/sys/kernel/unprivileged_userns_clone to "1"


Now, if this posting were to be belived, I think this term
   kernel.unprivileged_userns_clone

   is specific to Debian Linux, and does not exist outside of that circle.
   
   It disables a bit of "hardening" that Debian patches into their 
   distribution kernel. If you're not running such a kernel, it will
   fail 
   and not do anything, as such a setting doesn't even exist in the
   mainline Linux kernel.


   I wonder how this term came in to Guix in the first place?

   -Yasu


   On Sun, 2020-12-06 at 17:56 +0100, zimoun wrote:
   > Hi,
> 
> Please try the recommendation. Have you tried it?
> 
>   please set /proc/sys/kernel/unprivileged_userns_clone to "1"
> 
> As root, you just do:
> 
>   echo 1 > /proc/sys/kernel/unprivileged_userns_clone
> 
> then “guix environment -C” should work as expected.  To do the trick
> automatically with Sheperd, I do not know, but I am sure that the
> systemd equivalent 
> 
>   echo "kernel.unprivileged_userns_clone = 1" >
> /etc/sysctl.d/local.conf
>   sysctl --system
> 
> seems doable with Guix System.
> 
> 
> On my system, and I need explanations if it does not work similarly
> on
> yours, I simply do:
> 
> --8<---cut here---start->8---
> $ guix environment -C --ad-hoc hello -- hello 
> guix environment: error: cannot create container: unprivileged user
> cannot create user namespaces
> guix environment: error: please set
> /proc/sys/kernel/unprivileged_userns_clone to "1"
> 
> $ su -
> Password:
> # echo 1 > /proc/sys/kernel/unprivileged_userns_clone 
> # logout
> 
> $ guix environment -C --ad-hoc hello -- hello 
> Hello, world!
> --8<---cut here---end--->8---
> 
> Hope that helps,
> simon

Re: Staging branch

[Leo Famulari]

On Sun, Dec 06, 2020 at 07:11:49PM +, Ryan Prior wrote:
> It would be great if we can update the default Ruby to 2.7.2. Is there a
> process for updating Ruby I can follow to help out?

I don't know about Ruby in particular. The general process for updating
a "compiler" package is to update the package and then try rebuilding
everything that uses the build system in question.

`guix refresh --list-dependents` doesn't dependencies that go through
build systems, unfortunately. You could do `git grep ruby-build-system
gnu/packages`, choose some test packages, and let the build farm sort
out the rest.

Re: guix pack file enumerator?

[Ryan Prior]

On December 6, 2020, Ricardo Wurmus  wrote:
> What do you think about adding an output format that is no format at
> all
> but a file enumeration printed to stdout? That way I could use “guix
> pack” to produce a list of files to transfer and use that to transfer
> only the unchanged files. Alternatively, perhaps we could have a
> “directory” format that merely copies (or links) the files to a new
> directory root.

These suggestions comport nicely with the Unix-philosophy and something
like that should probably be implemented for people who want to build
their own deploy systems like you're describing.

Additionally, I think that the use-case of "deploy this software to some
server that doesn't have Guix installed" is important enough that we
might want to support it explicitly such that "guix deploy" does the
right thing, doing minimal work to bring the target deployment up-to-
date. Is that feasible?

Re: Staging branch

[Ryan Prior]

On December 6, 2020, Leo Famulari  wrote:
> Are there any other changes we should make on [staging]?

It would be great if we can update the default Ruby to 2.7.2. Is there a
process for updating Ruby I can follow to help out?

Re: Declarative and Minimalistic Computing devroom CfP

[Manolis Ragkousis]

Hello Arun,

Yes it is a typo, it should have been the 20th.

I will update it
https://libreplanet.org/wiki/FOSDEM2021-devroom-declarative-and-minimalistic-computing

Thank you,
Manolis

On Sun, 6 Dec 2020 at 20:03, Arun Isaac  wrote:
>
>
> > = Important dates: =
> >
> >   - Dec 15th 2020:  submission deadline for talk proposals
> >   - Dec 15th 2020:  submission deadline for recordings
>
> Is there a typo here? Are the submission deadlines for the talk
> proposals and the recordings both on Dec 15?
>
> >   - Dec 31th 2020:  announcement of the final schedule
> >   - Feb  6th 2021:  FOSDEM!
> >
> > https://libreplanet.org/wiki/FOSDEM2021-devroom-declarative-and-minimalistic-computing

Re: [support-re...@gandi.net: [GANDI] guixsd.org expires in 60 days]

[Leo Famulari]

On Sat, Dec 05, 2020 at 10:41:50PM +0100, Tobias Geerinckx-Rice wrote:
> I think you misunderstood my (and Ludo's) point, which was to prevent
> possible abuse of a name still in common use.  For whatever reason, outside
> of our little echo chamber people say GuixSD, not Guix System.  Squatting
> guixsd.org will attract plenty of traffic to whatever message the squatter
> wishes to spread.  I don't have a strong opinion either but don't think the
> cost savings cover that risk.

Right. When I saw the plan to release the domain, I started planning to
purchase it myself. For better or for worse, people are still saying
"GuixSD".


signature.asc
Description: PGP signature

Re: Declarative and Minimalistic Computing devroom CfP

[Arun Isaac]

> = Important dates: =
>
>   - Dec 15th 2020:  submission deadline for talk proposals
>   - Dec 15th 2020:  submission deadline for recordings

Is there a typo here? Are the submission deadlines for the talk
proposals and the recordings both on Dec 15?

>   - Dec 31th 2020:  announcement of the final schedule
>   - Feb  6th 2021:  FOSDEM!
>
> https://libreplanet.org/wiki/FOSDEM2021-devroom-declarative-and-minimalistic-computing


signature.asc
Description: PGP signature

Staging branch

[Leo Famulari]

Hello,

I just pushed a fix for #40832 (alsa-lib cannot find its plugins) to a
new 'staging' branch on Savannah.

The plan is to start building it next Friday, December 11.

Marius is planning to update Qt and Mesa in this round.

Are there any other changes we should make on this branch?

Leo


signature.asc
Description: PGP signature

Re: [support-re...@gandi.net: [GANDI] guixsd.org expires in 60 days]

[zimoun]

Hi,

On Sat, 05 Dec 2020 at 22:41, Tobias Geerinckx-Rice  wrote:

> I think you misunderstood my (and Ludo's) point, which was to 
> prevent possible abuse of a name still in common use.  For 
> whatever reason, outside of our little echo chamber people say 
> GuixSD, not Guix System.  Squatting guixsd.org will attract plenty 
> of traffic to whatever message the squatter wishes to spread.  I 
> don't have a strong opinion either but don't think the cost 
> savings cover that risk.

Thanks for the clarification.  I have no opinion because I am unable to
evaluate the risk.


All the best,
simon

Re: BUG: Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces

[zimoun]

Hi,

Please try the recommendation. Have you tried it?

  please set /proc/sys/kernel/unprivileged_userns_clone to "1"

As root, you just do:

  echo 1 > /proc/sys/kernel/unprivileged_userns_clone

then “guix environment -C” should work as expected.  To do the trick
automatically with Sheperd, I do not know, but I am sure that the
systemd equivalent 

  echo "kernel.unprivileged_userns_clone = 1" > /etc/sysctl.d/local.conf
  sysctl --system

seems doable with Guix System.


On my system, and I need explanations if it does not work similarly on
yours, I simply do:

--8<---cut here---start->8---
$ guix environment -C --ad-hoc hello -- hello 
guix environment: error: cannot create container: unprivileged user cannot 
create user namespaces
guix environment: error: please set /proc/sys/kernel/unprivileged_userns_clone 
to "1"

$ su -
Password:
# echo 1 > /proc/sys/kernel/unprivileged_userns_clone 
# logout

$ guix environment -C --ad-hoc hello -- hello 
Hello, world!
--8<---cut here---end--->8---

Hope that helps,
simon

Re: bug#45069: BUG: Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces

[Tobias Geerinckx-Rice]

yasu 写道：
Now, I don't use Debian at all (I use Guix System) and do you 
think
this is a Bug in Guix (in that this Debian specific word should 
never

even be mentioned in Guix?)


It's not Debian-specific.  It is a bug in Guix.

It should try to create a namespace and properly report an error 
iff that fails, not prematurely abort after farting about in 
/proc.


A separate unprivileged-user-namespace-supported? is broken by 
design.  Reverting commit 8bc5ca5 works around this but it wasn't 
to blame.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: non-root store

[Pjotr Prins]

On Sun, Dec 06, 2020 at 03:57:00PM +0100, Ricardo Wurmus wrote:
> A common complaint about Guix is that it requires root permissions to
> install, which is “scary” and may seem unnecessary on single-user
> systems.  By wrapping guix-daemon so that it uses file system
> virtualization (via user namespaces, proot, or the glibc debug hack) we
> could eliminate this obstacle.

We have started providing Guix built Docker containers. Works for many
users. But yes, a native install would be much nicer.

> What do you think?  Am I missing something obvious?

I have run the guix-daemon with proot as a user in the past. So it
should be possible with user namespaces.

https://github.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org#run-guix-daemon-in-proot

Once you have it in proot you can install software and even build
binaries on a relative path.

It is just a bit too much for the average user. 

Pj.

Re: December 2020 (old) bugs squashing!

[Bonface M. K.]

Ricardo Wurmus  writes:

> Bonface M. K.  writes:
>
>> Just curious, how do you get debbugs to show
>> forgotten patches. I'm only beginning to use it
>> now ...
>
> Debbugs doesn’t have a built-in mechanism to query forgotten issues.
> Mumi implements “forgotten-bug-numbers”, which has the following
> docstring:
>
>   "Return the numbers of issues that are open but haven't seen any
> activity for a while.  The duration is given by SECONDS-AGO, which
> defaults to 30 days."

Thanks for the feedback :)

-- 
Bonface M. K. 
Humble GNU Emacs User / Bearer of scheme-y parens
Curator:  / Twitter: @BonfaceKilz
GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F


signature.asc
Description: PGP signature

non-root store

[Ricardo Wurmus]

Hi Guix,

recently I’ve been playing with “guix pack -RR” and I’m very happy to
see how well it works.  Now I wonder if we could use the very same
mechanism to wrap guix-daemon and let it manage a store directory that
is not located at /gnu/store.

Surely somebody has already tried this?

A common complaint about Guix is that it requires root permissions to
install, which is “scary” and may seem unnecessary on single-user
systems.  By wrapping guix-daemon so that it uses file system
virtualization (via user namespaces, proot, or the glibc debug hack) we
could eliminate this obstacle.

What do you think?  Am I missing something obvious?

-- 
Ricardo

BUG: Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces

[yasu]

Hi,

I really don't know much about Linux but it looks like the problem I
reported has something to do with Debian?

https://unix.stackexchange.com/questions/303213/how-to-enable-user-namespaces-in-the-kernel-for-unprivileged-unshare

Now, I don't use Debian at all (I use Guix System) and do you think
this is a Bug in Guix (in that this Debian specific word should never
even be mentioned in Guix?)

To summarize this bug again:

The Bug:
The container command no longer works,  after the commit
8bc5ca5160db3d82bd5b6b2b7ed80c96f42bd33e.
guix environment -C


Additional Information:
Instead of working as it did until the commit, the command now
dies with the following error mesage:
guix environment: error: cannot create container:
unprivileged user cannot create user namespaces
guix environment: error: please set
/proc/sys/kernel/unprivileged_userns_clone to "1"

The message "please set
/proc/sys/kernel/unprivileged_userns_clone to "1",
seems irrelevant to Guix System users as it may only relate to
Debian users.
I don't know why this Debian specific message is here in the
first place...  

Disclaimer :-):
I am assuming this is indeed Debian specific (I tried to
install LinuxLinux (the Guix default) but failed - my AMD graphics card
won't allow me to even boot, unless I use regular Linux.)

I scanned for the phrase in LinuxLibre source code but there
was no mention of it:
~/Downloads$ tar -xf linux-libre-5.9.12-gnu.tar.xz
~/Downloads$ cd linux-5.9.12/
~/Downloads/linux-5.9.12$ rg -i unprivileged_userns_clone


Just FYI: the problem phrase is indeed found in the Debian
Kernel Patch:
~/co/debian$ rg -i unprivileged_userns_clone

linux/debian/patches/debian/add-sysctl-to-disallow-
unprivileged-CLONE_NEWUSER-by-default.patch
25:+extern int unprivileged_userns_clone;
27:+#define unprivileged_userns_clone 0
36:+if ((clone_flags & CLONE_NEWUSER) &&
!unprivileged_userns_clone)
47:+if ((unshare_flags & CLONE_NEWUSER) &&
!unprivileged_userns_clone) {
65:+extern int unprivileged_userns_clone;
77:+.procname   = "unprivileged_userns_clone",
78:+.data   = _userns_clone,
96:+int unprivileged_userns_clone;





Cheers,
Yasu




commit 8bc5ca5160db3d82bd5b6b2b7ed80c96f42bd33eAuthor: Paul Garlick <
pgarl...@tourbillion-technology.com>Date:   Thu Dec 3 16:00:18 2020
+
linux-container: Correct test for unprivileged user namespace
support.
Fixes ;.Reported by Paul Garlick
.
* gnu/build/linux-container.scm (unprivileged-user-namespace-
supported?):Return #f when the 'userns-file' does not exist.
diff --git a/gnu/build/linux-container.scm b/gnu/build/linux-
container.scmindex 4a8bed5a9a..3870b50907 100644--- a/gnu/build/linux-
container.scm+++ b/gnu/build/linux-container.scm@@ -44,7 +44,7
@@   (let ((userns-file
"/proc/sys/kernel/unprivileged_userns_clone")) (if (file-exists?
userns-file) (eqv? #\1 (call-with-input-file userns-file read-
char))-#t)))+#f)))

On Sat, 2020-12-05 at 09:20 +0900, yasu wrote:
> Hi Pj,
> Thank you for you reply (and your wonderful Hacking Guide 
> https://gitlab.com/pjotrp/guix-notes/blob/master/HACKING.org)!
> I tried the command and it didn't work...
> I use Guix System (not  a foreign distribution) as described at the
> bottom 
> -Yasu
> 
> On Fri, 2020-12-04 at 19:55 +0100, Pjotr Prins wrote:
> > On Fri, Dec 04, 2020 at 05:32:08PM +0100, zimoun wrote:
> > > Have you tried to do the recommandation?
> > > 
> > >  please set /proc/sys/kernel/unprivileged_userns_clone to "1"
> > 
> > As root:
> > 
> > echo 1 > /proc/sys/kernel/unprivileged_userns_clone
> > 
> > Yes, it is common on Debian and such.
> > 
> > Pj.
> 
> root@guix ~# echo 1 > /proc/sys/kernel/unprivileged_userns_clone-
> bash: /proc/sys/kernel/unprivileged_userns_clone: No such file or
> directory
> root@guix ~# guix system describeGeneration 5631  Dec 05 2020
> 09:09:16  (current)  file name: /var/guix/profiles/system-5631-
> link  canonical file name:
> /gnu/store/qqzk4kvrhxjcia3hcq3xqrcdi36azzz9-system  label: GNU with
> Linux 5.9.12  bootloader: grub-efi  root device: label: "my-root" 
> kernel: /gnu/store/9a93vpq4aa1c3adiaaa3blwc18r9r7zz-linux-
> 5.9.12/bzImage  channels:guix:  repository URL: 
> https://git.savannah.gnu.org/git/guix.git  branch:
> master  commit:
> 86d635b85035086d21c319f31f628761df5c82e5nonguix:  repository
> URL: https://gitlab.com/nonguix/nonguix  branch:
> master  commit: b08ea529d4d36468b20ef4aff6dc87b3de0eff70guix-
> chromium:  repository URL: 
> https://gitlab.com/mbakke/guix-chromium.git  branch:
> master  commit: 2de450b92e5f2624d4f964407686934e22239f7b 
> configuration file: /gnu/store/hlma107m2004g6qq00ihm190am5mh9z0-
> configuration.scm

Cuirass WAL size issues

[Christopher Baines]

Hey,

I've been chasing some performance issues in the Guix Build Coordinator
and thought that the size of the WAL file was a contributing factor.

I believe SQLite checkpoints the WAL file after transactions commit, if
the WAL is over 1000 pages in size. At least for the Guix Build
Coordinator though, that didn't seem to be working/happening as the WAL
file seemed to just grow and grow.

I think I'm making some progress on that. It seems that if you don't
reset or finalise statements after you're finished with them, bad things
happen. I think one of these bad things is that WAL checkpointing stops
happening. When I got that to happen in the Guix Build Coordinator, I'm
no longer seeing errors when I try and manually run checkpoints now.

Switching focus to Cuirass, I think it's got similar issues. I've pushed
a few commits to this branch [1], the important one being [2] which
rewrites a few procedures to call sqlite-reset when the statement is
finished with, rather than calling it before starting to read from the
statement.

1: https://git.cbaines.net/guix/cuirass/log/?h=sqlite-statement-reset-fixes
2: 
https://git.cbaines.net/guix/cuirass/commit/?h=sqlite-statement-reset-fixes=e09bc606f25bad11b39c9fae49139ac03b88697c

If this makes sense, I can spend the time writing some changelog entries
for the commits, and push them. What do you think?

Thanks,

Chris


signature.asc
Description: PGP signature

guix pack file enumerator?

[Ricardo Wurmus]

Hi Guix,

“guix pack” is great for deployment of applications to servers that
don’t have Guix.  For a project I have a “deploy” target in my Makefile
that essentially does this:

cat $(shell guix pack -RR -e '(load "guix.scm")' -S /bin=bin) | ssh 
remote-server "tar xvzf - -C /where/i/want/it"

This is fine for small deployments, but it’s a little annoying that it
transfer *all* the files, even those that haven’t changed.  So I thought
I could use rsync here, but it’s inconvenient that “guix pack” will do
what it was designed for and produce a single file bundle.

What do you think about adding an output format that is no format at all
but a file enumeration printed to stdout?  That way I could use “guix
pack” to produce a list of files to transfer and use that to transfer
only the unchanged files.  Alternatively, perhaps we could have a
“directory” format that merely copies (or links) the files to a new
directory root.

-- 
Ricardo