Re: Plan for a release!

2020-03-06 Thread John Soo
Hi Guix,

In addition I think issue #38544 (gparted segfaults) should be addressed before 
a release.  I would imagine that partitioning is an activity that happens a lot 
around new installs.

- John


Re: rust (build system) deficits

2020-03-07 Thread John Soo
Hi Hartmut,

I agree with you. It seems like a problem for cargo to solve to me.  Efraim 
tried to use the .rlib files to make library files and found it was not really 
an option.

There are more problems, too. The way inputs are done doesn’t fit well with the 
rest of guix tooling and doesn’t really follow functional package management 
concepts.

One possibility to try is to rethink the cargo-{development-}inputs fields and 
only require the source from rust library inputs. Then to build the 
executables, it would only require one compile and we could keep ci checking 
the current libraries.

The cargo build system also has a specialized transitive closure computation. I 
believe the reason cargo-{development-}inputs are specified in arguments is for 
the special purpose of that closure computation. Can someone tell me if I’m 
wrong on that?

As far as I can tell, the point of the specialized transitive closure 
computation is to deal with cyclic dependencies.  Again, please someone correct 
me if I’m wrong on that.

If the rust closure functions successfully deal with cyclic dependencies, then 
wouldn’t the other closure computations benefit from the same function?

I would like to take a stab at bringing the rust build system package 
definitions closer to others.

My proposal is to:
* move cargo-{development-}inputs into inputs, requiring only the source from 
libraries.
* either:
  - move the rust closure function so all packages use it
Or
  - adjust the transitive closure function such that it works on normal inputs 
rather than arguments
* Do not build rust packages by default. Only run tests.
* as a corollary to the previous item: Default skip-build? to #f but do run 
tests even if skip-build is #f and tests? is #t

What do you all think, Hartmut, guix?

- John 


Re: rust (build system) deficits

2020-03-08 Thread John Soo
Hi Hartmut,

> On Mar 8, 2020, at 10:16 AM, Hartmut Goebel  
> wrote:

The much more serious issue is that we are not able to build non-trivial
Rust applications: Given a package which needs to add phases, e.g. for
fixing Cargo.toml, we would need to run each package's phases when
building any depending package.

Hmm. Can you elaborate more on “not able to build non-trivial rust 
applications”?  It seems like we have finally made some progress on building 
some rust apps.  Patching a library Cargo.toml seems like an excellent job for 
source patches or snippets. Modifying an executable’s Cargo.toml to refer to 
guix-vendor happens during a phase that matters (because the executable will be 
built).

We also already have solutions for removing censored code for c library 
wrappers.

Clearly the situation is not ideal, but I do think there are improvements to 
take just with what we have now.

Kindly,

John


Re: rust (build system) deficits

2020-03-08 Thread John Soo
Also I should just say thank you for taking interest in the cargo-build system. 
Please let me know if I’m missing something.

John


Re: rust (build system) deficits

2020-03-09 Thread John Soo
Hi Hartmut,

> On Mar 9, 2020, at 2:26 AM, Hartmut Goebel  
> wrote:
> 

A second dependancy is "sequoia-openpgp", which requires rhe lalrpop
parser generator for building.

Now when building `sequioa-sqv`, I need to add all these dependencies again:

- nettle-src, since it is "optional" for nettle-sys - and the phase was
not executed.
- bindgen, since it is required to build nettle-sys
- lalrpop, since it is required for building sequoia-openpgp

That is a lot of work! I know because I did all of those for pijul in this 
channel github.com/jsoo1/guix-channel.  Want to compare notes? What are you 
working on? 

Also I found the recursive crate importer very helpful, even if it was 
imperfect. Are you using the importer or doing the work by hand?

And as Efraim mentioned, optional dependencies in the cargo sense are not 
optional for guix definitions.

Good luck,

John





Re: rust (build system) deficits

2020-03-09 Thread John Soo
Hi Hartmut,

> My point is less the work, but the non-transitive declarations:
nettle-sys is an multi-indirect input for sequioa-sqv, still the later
needs to specify these dependencies.

Totally agree. I think everyone agreed, too.  A few months ago we decided that 
the package inputs should match as close to exactly the dependencies listed in 
Cargo.toml so as to avoid specifying transitive dependencies in the package 
definition. 

The importer does solve the transitive dependencies but there is a bug. Version 
numbers of cargo dependencies are not used which can sometimes cause the 
problem you describe. I really hope the fixes get merged soon because it is a 
real pain. 

> This importer does not solve the declarations, and IMHO it should not
anyway - as the are dependencies of another packages, which might change over 
time.

I’m not sure I fully understand why the recursive importer should not solve the 
transitive dependencies. Could you elaborate further?

If you are suggesting that guix refresh won’t pick up the changes, then I think 
agree with you. That I believe is an artifact of using arguments rather than 
inputs to specify dependencies.

Kindly,

John


Re: Brainstorming features for issues.guix.gnu.org

2020-03-26 Thread John Soo
Hi Ricardo!

I love the idea of a smoother download/review process. I think I would
be happier with a curl-able endpoint to download patches from. I think
it might compose with other tools a little more smoothly. Other than
that, nothing really comes to my mind.

I only just started using it more frequently since it stopped timing out
so frequently.

Kindly,

John



Re: Brainstorming features for issues.guix.gnu.org

2020-03-30 Thread John Soo
Ricardo Wurmus  writes:

>> It is hard to find how patchsets differ - let alone where
>> revisions start and end.
>
> Do you have an idea how to improve this?  Should we use, for example,
> the message subject to detect revisions?  (E.g. [PATCH 3/3] will
> indicate that the end of the patch set has been reached.)
>
> How would we indicate different patch sets visually?  Should there be
> links somewhere to jump to patch sets?

Hmm. I don't know if I have a good answer yet. I think I like the
debbugs threaded view. Here are a couple ideas:

* Allow expansion/collapse of diffs
* Provide a thread view and a view of just one patchset (maybe computed
  via [PATCH 3/3] or by attachments as you mention)
* Provide an interdiff view between revisions
* Only show the most recent patchset like some large commercial products

I like the thread view idea since this is an email workflow, afterall.

It has been improving a lot and I am already using it a lot more now that
it has its own database.

John



Re: bug#30435: libreoffice: Fonts don't show up after install

2020-04-02 Thread John Soo
Hi there,

I think this is the same issue as 26877.

Can font information be compiled into a fonts.conf?

- John



Mistaken authorship on some commits

2020-04-02 Thread John Soo
Hi Guix!

I think I am reported as the author of commits

0cc8cdbe1b0018ec37b1de9032c9eca884bedb6e
a97b943b5590c6406a85cb0f2f03fa69d7e3b7d8
c26fd5648c2a24dbd71f4c0851f8b5eced75e0f1

I did not author these, though it would have been likely.

Thank you so much, maintainers.

- John



Re: Adding a %desktop-packages

2020-04-03 Thread John Soo
Hi there,

I am on board with providing some predefined lists of packages.

I raised the idea of providing smaller lists of packages that might go
well together instead of one large %desktop-packages. One reason to do
this, for instance, might be to not make someone who wants to use btrfs
always import the ext4 packages. Or not lock someone into using nettools
if they are using iproute2, etc.

Similarly, I think that many users, myself included, use a manifest file
to manage user packages. It would help to have finer grained
package lists so that the manifests could reuse them and not be
requiring system basics along with it.

What do you think?

- John



Re: TLS certificates for web browsers in guix environment --container

2020-04-21 Thread John Soo
Hi Pierre,

I think you need the nss-certs package in the environment, to start. Does 
adding them help?

- John


Bump stackage LTS

2020-04-22 Thread John Soo
Hi Guix,

Stackage and ghc have moved quite a bit since our stackage and ghc versions.  
Would it be ok to start work on bumping our package set to a newer set of 
working packages and compilers?  What is the state of the wip-haskell branch?

Kindly,

John




Re: GNU Guix maintainer collective update

2020-05-04 Thread John Soo
Hello Guix and Ricardo,

> There's a new blog post about a recent update to the GNU Guix maintainer
> collective [0].  I won't repeat the blog post here, but in a few words,
> Ricardo Wurmus is stepping down from his role and Mathieu Othacehe
> is joining in.

I would like to echo the sentiment that Guix is nice software but has
even nicer leadership and community. Thank you so much for your service,
Ricardo.

I hope to see you around.

> Let's also welcome Mathieu Othacehe in his new role!  Congratulations,
> Mathieu!  :-)

Congratulations Mathieu!

Kindly,

John Soo



Request for proposals on Rust and Go build systems (RE: Medium-term road map)

2020-05-07 Thread John Soo
Hi Guix,

I lost the specific thread on the medium-term road map that applies.  A
few suggestions have been made to improve updates the source-only build
systems we have (Rust and Go). I would like to suggest that we do make
changes to these and put them on the road map.

Can we put together some complaints and proposals for the rust and go
build systems? It would be nice to first get some informal ideas and
then see if we can't mostly agree on a final set of items to work on.

I have the following issues:

* The loop-breaking procedure is widely applicable: most other
  transitive dependencies should have loops in their dependency graphs
  broken. So far, only the cargo-build-system has such a loop-breaking
  procedure.

* It will be hard to track down breaking changes when a source-only
  library package is updated.  guix refresh --list-dependents usually
  shows how many packages would be effected by changing a package.  Rust
  packages, at least, do not show any dependent packages for libraries.

In the past, I have seen other complaints:

* Outputs from the cargo-build-system don't use dynamic linking.

* Namespacing of cargo packages is not good.

My suggestions:

* Move the dependency loop-breaking procedure from the rust build system
  to a utils location.  Use the procedure in more (if not most other)
  build system's transitive dependency resolution.

* Figure out a mechanism whereby source-only packages are registered by
  guix refresh --list-dependents. I had suggested moving
  #:cargo-dependencies to inputs, for instance.

I hope to hear from you soon!

- John



Re: Towards a graphical installer?

2020-05-11 Thread John Soo


raingloom  writes:

> Can the TUI installer be used with a screen reader? AFAIK it can't but
> I'd love to be proven wrong.

I was just thinking about accessibility in Guix recently. I was
wondering something similar.

> Anyway, there are also other accessibility options that are useful. High
> contrast, magnifier, sticky keys, etc. GNOME provides these.
> Even if you aren't blind or disabled in general, you might just have to
> install an operating system without a working screen one day.

I would love to think more about accessibility in other parts of the
Guix System, too. I thought I found a terminal screen reader recently
but I can't remember where it was.

- John



Re: Returning to the project

2020-06-26 Thread John Soo
Hey welcome back Brett!

I was hopeful about the formal methods working group! Also all your work on the 
MLton toolchain was very interesting. I don’t think any work has been done on 
those since you left off :)

Good to see you,

- John


Re: RUNPATH problem building Rust 1.40.0

2020-06-30 Thread John Soo
Hi Matthew and Ludo,

I’ve been using the rust versions (up to 1.44) from this patch set without 
issue:

http://issues.guix.gnu.org/40957

Hope that helps,

John



Re: The rust:cargo output - why?

2020-07-23 Thread John Soo
Hi Jakub,

I agree.  

In my mind, anything that would be installed via rustup add component would be 
a separate output. 

Aside from that, to reduce closure size, Maybe the docs can go into a separate 
output?

But cargo is quite integral to the rust workflow I was very confused by cargo 
as a separate output for a long time. 

- John


Re: merge wip-haskell?

2020-08-06 Thread John Soo
Hi Ricardo,


Nice! Sounds good to me. There are a couple other bits of work I’d like to see 
make it in.

I believe there was also some work being done to de-duplicate flags sent to gcc 
sent by ghc (this was the only thing keeping stack from building). 
I hope that can make it in, too!

If there is any way we can bump the default ghc to 8.8.x, that would be 
excellent, too.  I think something like that makes sense on staging though.

Thanks for working on it!

- John


On Aug 6, 2020, at 1:14 AM, Ricardo Wurmus  wrote:

Hey there,

wip-haskell contains commits that do a number of things aimed to reduce
the closure of packages:

1) make the “out” (and “lib”) output independent from “doc”
2) add a “doc” output to more packages
3) add a “static” output for all Haskell packages containing the “.a” files
4) change ghc-pandoc (and ghc-pandoc-citeproc) to use static linking

Number 1 required some smelly hackery: the generated configuration file
is edited to remove the “haddock-html” field.  One unfortunate effect of
doing this and moving the .haddock files is that there are now
complaints about unresolvable links in generated documentation.  I don’t
know if we can avoid this, but it seems like a small price to pay for
independent “doc” outputs.  (Otherwise we’d have to download huge “doc”
outputs even if we don’t want them.)

Number 3 required circumventing bug 41569.

Number 4 is by far the ugliest change of them all.  In order to
statically link packages we need to add all the “static” outputs of all
Haskell inputs *and* the “static” outputs of *their* Haskell inputs.
This is not easily accomplished, so I ended up using “package-closure”
on all direct inputs, and then filtered the result to packages with
names starting with “ghc-”.  If there was a more appropriate tool I’d
use it, but I don’t think it exists.

The result is a much reduced closure for ghc-pandoc and all packages
using it (such as R markdown).  We should probably rename “ghc-pandoc”
to “pandoc”, while we’re at it, because now the package contains the
executable.

I suppose we could change this so that “ghc-pandoc” is the usual library
package with a new “pandoc” package inheriting from “ghc-pandoc”.  I’ll
give that a try soon.

I’d be happy to hear your comments about all of this, and I’m looking
forward to merging this branch into “master” soon.

-- 
Ricardo




Re: merge wip-haskell?

2020-08-07 Thread John Soo
Hi Jakub,

I could see splitting the static output being useful but I would rather wait 
until some evidence that the closure size would be too large. Also I’m not sure 
propagation is necessary for dependents to find libraries or use paths from an 
input.

Thoughts?

John

On Aug 7, 2020, at 8:04 AM, Jakub Kądziołka  wrote:

On Thu, Aug 06, 2020 at 10:13:46AM +0200, Ricardo Wurmus wrote:
> Number 4 is by far the ugliest change of them all.  In order to
> statically link packages we need to add all the “static” outputs of all
> Haskell inputs *and* the “static” outputs of *their* Haskell inputs.
> This is not easily accomplished, so I ended up using “package-closure”
> on all direct inputs, and then filtered the result to packages with
> names starting with “ghc-”.  If there was a more appropriate tool I’d
> use it, but I don’t think it exists.

Perhaps we should work on making propagated-inputs per-output? That way,
:static could propagate the :static output of the dependencies.

This would also be useful in other situations. For example, a package
might contain both a binary and a library, and the library must
propagate its dependencies to make the header files work.

I don't know what a good syntax for this would be.

Thoughts?

Regards,
Jakub Kądziołka



Re: merge wip-haskell?

2020-08-07 Thread John Soo
Hi Ricardo and Jakub,

Ah ok. Sorry I had forgotten the point of the thread.  Sounds like a plan!

- John

On Aug 7, 2020, at 8:59 AM, Ricardo Wurmus  wrote:


Jakub Kądziołka  writes:

>> On Fri, Aug 07, 2020 at 08:12:36AM -0700, John Soo wrote:
>> I would rather wait until some evidence that the closure size would be too 
>> large. Also I’m not sure propagation is necessary for dependents to find 
>> libraries or use paths from an input.
> 
> Ricardo already explained that this is indeed the case.

Yes, and for the case of pandoc it’s significant.  The closure of
ghc-pandoc is >3GiB right now and with the changes it’s <200MiB.  This
affects lots of R packages that need Rmarkdown, and lots of bioinfo
packages.

There's no doubt that moving the static libs to their own output has a
significant impact on closure size.

-- 
Ricardo



Re: Improving CI throughput

2020-08-24 Thread John Soo
Hi Ludo and Guix,

I am not sure how much I can devote to the problem, but bpf now works in guix. 
The bpftrace scripting language is there if it might help.

Hope that helps a little,

John


Re: merge wip-haskell?

2020-08-28 Thread John Soo
On another note:

Does anyone know why idris, agda, and purescript are failing?

I have only been able to do very little recently to look at them.

- John



Re: merge wip-haskell?

2020-08-29 Thread John Soo
Nice!  Thanks Tim!



Re: getting started with the texlive importer

2020-09-10 Thread John Soo
Nice work!

That bug has been around for years I think.

Thanks!

John



RFC: subcommand to pause/resume builds

2020-11-02 Thread John Soo
Hi Guix!

I was looking to pause a long build today and asked on IRC how to
accomplish pause/resume.  It seems this is possible already with the
following:

kill --signal SIGSTOP|SIGCONT {pids-of-build-process-tree}

There is already a command to list the processes associated to guix
commands: guix processes.  Perhaps pause/resume can be a subcommand or
set of flags to guix processes. The following is the first thing that
comes to mind:

guix processes --pause package-name ... --resume package-name ...

What do you think?

Thanks!

- John



Re: RFC: subcommand to pause/resume builds

2020-11-03 Thread John Soo
Hello!

I want to preface all this by saying this is not a huge priority to me.
pause/resume would just be a nice quality of life improvement.

Ludovic Courtès  writes:

> First, note that the daemon is unaware of “packages”, it only knows
> about “derivations”.

Agreed. I was thinking mostly about the best interface for a user. But
if derivations are too low-level I can see not being able to use the
package name.

> Second, ‘guix processes’ is nice but it uses low-level heuristics to
> determine what daemon sessions are open, what their clients are, and
> what they’re building; it resorts to heuristics because the daemon as it
> stands doesn’t have a way to communicate its current state.  It works
> well in practice, but still I wouldn’t go too far building around it.
>
> Last, you’d need to send SIGTSTP to the whole process group of the
> build, like so (I think, haven’t tried):
>
>   sudo kill -TSTP -123

Ah right, I got that advice on IRC also but I don't actually know how to
do it. Thanks!

> where 123 is the “SessionPID” shown by ‘guix processes’.  However, doing
> so may affect build results: processes in the build environment might
> handle SIGTSTP specially, which can have side effects.  It’s an
> observable action.

I thought of the side effects after sending the email. Makes sense to
me. Does that mean it is not worth including?  Given that the source and
state of a build do not change while paused, if a build tool changes its
outputs after paused/resumed is it still reproducible?

The other part that would make it difficult is that maybe different
build-systems respond differently to different signals. A simpler to
implement alternative might just be to provide a way to send an
arbitrary signal to the process tree. Given some builds might respond
un-reproducibly to it, a warning could be provided.

In any case, such a subcommand not a high priority to me as a user,
though sometimes I long to pause guix build ungoogled-chromium.

Thanks again,

John



Re: RFC: subcommand to pause/resume builds

2020-11-03 Thread John Soo
Hello Tobias :),

Tobias Geerinckx-Rice  writes:

> Ludo',
>
> Ludovic Courtès 写道:
>> First, note that the daemon is unaware of “packages”, it only knows
>> about “derivations”.
>
> Derivations have a (file) name, which can be matched with a regex
> allowing one to, say, ‘pause libreoffice’.  It works in practice.
> I do this often & it's *extremely* convenient.

This feels close to little sed/awk pipelines.  Which is not to be
entirely dismissive. I like the compositionality of these tools.  In
fact I mentioned earlier that it might be good to send arbitrary
signals. But why not let kill (shell or scheme) do that?  All we would
need is to filter and format pids in a composable way (on the scheme
side and the shell side). That has the benefits of remaining agnostic on
side effects in builds (let the user decide what they are comfortable
with) and being more composable.

Maybe flags like this would be enough:

guix processes --session= ...

to get something like


1212
343434
...

> Sometimes even necessary, because I have a habit of starting too many
> builds ;-)  It's nice not to lose 6h of work.

Indeed. This already saved me hours after learning it yesterday.

> Not every handy hack needs to be upstreamed though.  ‘It's fugly’ is a
> strong argument in Guixland, and I like that.

Same.

> T G-R, now thinking about acronyms like ‘CRIU’ and what a next-level
> hack would look like...

Yeah seems like functional build systems would ideally be
order-independent, pause/resumable, and the build steps time-travelable
themselves. But that's a cool aside for now.

Thanks for the tips!

John



Re: RFC: subcommand to pause/resume builds

2020-11-03 Thread John Soo
After further review, I realize that guix processes already formats
for recutils. I never think to reach for that tool, but it seems
good.



Re: RFC: subcommand to pause/resume builds

2020-11-03 Thread John Soo
After even further investigation,

Does guix processes output the desired rec format? It seems hard to
select the child process pid:

ChildProcess: 16923: guile --no-auto-compile -L 
/gnu/store/8a0wry8cvr405ha8d8bpjyzj5dzghigd-module-import 
/gnu/store/mh1fkn1d9c9mg6hihxvjngxmn3qjmp38-ungoogled-chromium-86.0.4240.111-0.c34a56d-guile-builder
ChildProcess: 31859: 
/gnu/store/ah16zr8mmfkqy23rr7jy5a842ca1q9h1-guile-3.0.4/bin/guile \ 
/gnu/store/xi3jc6476vyv2vmcsfa1xkpqbxp1apk6-guix-1.1.0-27.1c21468/bin/.guix-real
 substitute --query
ChildProcess: 31869: 
/gnu/store/ah16zr8mmfkqy23rr7jy5a842ca1q9h1-guile-3.0.4/bin/guile \ 
/gnu/store/xi3jc6476vyv2vmcsfa1xkpqbxp1apk6-guix-1.1.0-27.1c21468/bin/.guix-real
 offload x86_64-linux 0 1 0

After perusing info recutils some, I expected the output to be more
like:

ChildProcessPID: 16923
ChildProcessCommand: guile --no-auto-compile -L 
/gnu/store/8a0wry8cvr405ha8d8bpjyzj5dzghigd-module-import 
/gnu/store/mh1fkn1d9c9mg6hihxvjngxmn3qjmp38-ungoogled-chromium-86.0.4240.111-0.c34a56d-guile-builder

ChildProcessPID: 31859
ChildProcessCommand: 
/gnu/store/ah16zr8mmfkqy23rr7jy5a842ca1q9h1-guile-3.0.4/bin/guile \ 
/gnu/store/xi3jc6476vyv2vmcsfa1xkpqbxp1apk6-guix-1.1.0-27.1c21468/bin/.guix-real
 substitute --query

ChildProcessPID: 31869
ChildProcessCommand: 
/gnu/store/ah16zr8mmfkqy23rr7jy5a842ca1q9h1-guile-3.0.4/bin/guile \ 
/gnu/store/xi3jc6476vyv2vmcsfa1xkpqbxp1apk6-guix-1.1.0-27.1c21468/bin/.guix-real
 offload x86_64-linux 0 1 0

But even that does not capture that the child processes all belong to
the session.

I must be missing something about the rec format or querying.

Any clues?

Thanks,

John



RFC: subcommand to pause/resume builds

2020-11-04 Thread John Soo
 
 

 
 
 
Hello Guix, 

 
I just sent a patch to normalize the output of processes with bug number 44460. 
The allows me to compose recutils with kill to get the desired effect of 
pausing all process trees for the things I want without any convoluted 
implementation.I think I would be satisfied with such a patch and nothing 
else.
 

 
Thanks again!
 

 
John
 
 
 
 

 
 

Re: RFC: subcommand to pause/resume builds

2020-11-06 Thread John Soo
Hello everyone,

Ludovic Courtès  writes:

>> After perusing info recutils some, I expected the output to be more
>> like:
>>
>> ChildProcessPID: 16923
>> ChildProcessCommand: guile --no-auto-compile -L
>> /gnu/store/8a0wry8cvr405ha8d8bpjyzj5dzghigd-module-import
>> /gnu/store/mh1fkn1d9c9mg6hihxvjngxmn3qjmp38-ungoogled-chromium-86.0.4240.111-0.c34a56d-guile-builder
>
> Yes, that would be nicer.

I sent in patch https://issues.guix.gnu.org/issue/44460 to address
it. With that I don't see any reason to consider a subcommand.


> However, note that if you fiddle with child processes, your warranty is
> void!  :-)

Definitely agreed.

> You’d be interfering with build processes, thus potentially changing
> their result in an uncontrolled way.

Like Mark said, I have seen tests potentially time out, and I have to agree.

I am done discussing a subcommand. I'll shift attention to #44460.

Thanks for listening to little old me :).

Have a nice weekend,

John



Re: Anybody please help improving rust crates importer

2020-11-07 Thread John Soo
 Hello Hartmut, 

 
There is a patch set that has slightly bit rotted that does what you want.
It could use a little polish but any work on it would be appreciated:   
http://issues.guix.gnu.org/38408
 

 
Thanks for thinking about the rust ecosystem in guix!
 

 
- John
 

Re: Announcing emacs-guix-packaging

2020-11-13 Thread John Soo
Hi Zomoun,

zimoun  writes:

> $ ag '\(@' --scheme $(guix build emacs-guix -S)
> /gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/actions.scm
> 200:((@@ (guix scripts build) log-url) store file))
>
> /gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/system.scm
> 55:   ((@@ (gnu system) operating-system-firmware) os)))
>
> /gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/pack.scm
> 31:  (map (@@ (guix scripts pack) compressor-name)
> 32:   (@@ (guix scripts pack) %compressors)))
> 40:  (@@ (guix scripts pack) %formats)))
>
> /gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/profiles.scm
> 123:  (@@ (guix scripts package) search-path-environment-variables))
>
> On the other hand, we could ask if these should not be part of the API.
> The “(guix scrip )” seems a good clue. ;-)
>
> From my point of view, your concern is not a real issue here.

I agree. However I do think those bindings from (guix scripts ...) are
good candidates to be public. Programmatic access to things that cli
users already knows is probably a nice entrypoint for anyone wanting to
start using guix as a scheme library.

I sent patches to expose those bindings: https://issues.guix.gnu.org/44619

> Well, maybe invoking “guix repl” is the fastest way to write plumbing
> interfaces avoiding the tough binding.

Is inferior-lisp an option? Or is it more specifically used for Common
Lisp family lisps?

Thanks,

John



Fixing and maintenance of emacs-guix (guix.el)

2020-11-13 Thread John Soo
Hi Guix,

emacs-guix (also known as guix.el) has been broken for some time.

I submitted https://gitlab.com/emacs-guix/emacs-guix/-/merge_requests/8
to support guix versions >= 1.1.  However, two changes also have to
occur for proper support.

* Some bindings will need to be exposed on the guix side. I submitted
  patches for this already: https://issues.guix.gnu.org/44619

* The guix package in gnu/packages/package-management.scm will need to
  refer to a commit including those patches.

That leads to a more nebulous question: should there be "stable" and
"unstable" versions of the guix package in guix?  Stable might be pinned
to a release, but guix-unstable might be updated occasionally.

What do you think?

- John



Re: Reviving Emacs-Guix

2020-11-13 Thread John Soo
Hi everyone,

Ludovic Courtès  writes:

> Any Emacser around willing to take care of it at least in “maintenance
> mode”?  It seems like fixing the issues we currently have wouldn’t be
> too hard.  Then we can tag a release.

I think I can do it. I can't promise a lot of new work but I can at
least fix bugs.

> I think it would be beneficial longer-term to have the Emacs-Guix repo
> in the Guix group on Savannah, from the perspective of Conway’s law¹;
> it’s also probably a safe way for the project to deal with contributor
> churn.  But if whoever volunteers prefers to maintain it elsewhere, so
> be it!

Good idea.

Sounds good to me,

John



Re: Fixing and maintenance of emacs-guix (guix.el)

2020-11-13 Thread John Soo
Hi Ludo,

Ludovic Courtès  writes:

> As I wrote in another message before reaching this one, my understanding
> is that “we” now have to take over maintenance of Emacs-Guix.  As part
> of that process, we can discuss what interfaces would be useful to
> Emacs-Guix and arrange to keep them stable.
>
> I think we can do more if the two are developed hand in hand.  Let’s see
> what we can achieve!

Exciting!

What do we do next?

- John



Re: GNU Guix 1.2.0rc1 available for testing!

2020-11-16 Thread John Soo
 
 

 Hello,
 

 
I have a fix for emacs-guix. Once I make the repository on savannah, that patch 
should be easy to make.I may be able to get to that around Wednesday.
 

 
- John
 

Re: libgccjit and gccemacs

2020-11-21 Thread John Soo
Hello Andrea, Formbi, and Guix,

I got gccemacs and the no-x version to compile. They do not run
entirely correctly and the closure size is quite large. That said, it
feels snappy!

I submitted patches to issue 44775: https://issues.guix.gnu.org/issue/44775

If someone could investigate the retained closure references and
missing references to the store, that would help a lot!

Thanks and good luck,

John



Re: [sr #110376] Creating an Emacs-Guix Git repository for Guix

2020-11-21 Thread John Soo
Hi Ludo and Guix,

Ludovic Courtès  writes:

> URL:
>   
>
>  Summary: Creating an Emacs-Guix Git repository for Guix
>  Project: Savannah Administration
> Submitted by: civodul
> Submitted on: Mon 16 Nov 2020 10:14:27 AM CET
> Category: Additional Git repositories
> Priority: 5 - Normal
> Severity: 3 - Normal
>   Status: None
>  Assigned to: None
> Originator Email:
> Operating System: None
>  Open/Closed: Open
>  Discussion Lock: Any
>
> ___
>
> Details:
>
> Hello,
>
> Could you create an "emacs-guix" Git repository as a sub-directory under
> "guix"?
>
> It will contain code currently hosted at
> .

I'm sorry I haven't gotten around to this. I am not too familiar with
the Savannah workflow. What exactly do we want to do?

Is this a submodule that I can submit as a patch to "guix"? Or do I need
to create a submit a project for inclusion on Savannah?

Also, what does it mean to be a subdirectory of guix?

Thanks,

John



New emacs-guix location

2020-11-24 Thread John Soo
 
 

 
 
 
 Hello Alex and Guix,
 
 
 
 Hope you are well.I volunteered to maintain some version of emacs-guix 
recently. How do you feel about a fork moving to Savannah?
 
 
 
 Best wishes,
 
 
 
 John Soo
 
 
 

 
   

Re: FreeCAD fails to compile

2020-12-05 Thread John Soo
 Nice work Ekaitz! 

 
I worked hard on freecad, it is quite a difficult program to package. That was 
a weird issue that I asked about on the freecad forums. Perhaps it is fixed 
upstream now, which would be excellent. Thanks for keeping it up to date!
 

 
- John
 

Re: Guix day: Summary fo rust BoF session

2020-12-11 Thread John Soo
Hi Hartmut and Sébastien,

I started with some talking points which I will attach. We did not get
to everything though. Mostly we discussed the possibility of using
system dependencies and installing actual compiled artifacts.  Someone
mentioned that the possibility of using system dependencies came up on
the #rust IRC channel.  After some research, I think I may take a look
at it soon.

The other topic I remember coming up were some packaging idioms and
module organization.  I think consensus was generally reached that we
should try to keep package definitions based on "domain" or "use" rather
than by language - i.e. put rust web libraries in a web module. I think
the newer crates-graphics and other modules are decent examples of
this. In future, perhaps we move packages out of rust-apps.scm though.

In other news, I am glad the importer is merged now! Congratulations!

- John

#+TITLE: (BoF) Rust + Cargo Discussion

Rust has come a long way since I started using Guix in 2018: crate importer,
cargo-build-system, bootstrapping with mrustc, etc. I use Guix to write Rust
for work everyday now!

Still a long way to go.  Some topics below (add your own before we start).

* Topics

** Improved, semantic versioning-aware, crate importer
   - New work in https://issues.guix.gnu.org/44560
   - Original issue https://issues.guix.gnu.org/38408

** rustfmt as an output of rust
   - Open patch in https://issues.guix.gnu.org/42295
   - Other candidates include rls/rust-analyzer, clippy, racer

** Keeping rust versions up to date
   - On a 6 week release cycle, perhaps we need rust-updates branch?
   - I have been using version 1.46 without issue

** Packaging idioms
   - How best to remove vendored sources?
   - How to propagate the required environment variables.
   - When to include minor version in package variable name?

** guix refresh does not pick up dependencies between rust dependencies
   #+begin_src bash
   guix refresh --list-dependent rust-serde
   #+end_src

   #+RESULTS:
   : No dependents other than itself: rust-serde@1.0.117

** Incremental compilation/shared libraries possible?
   - Use the store as a registry?
   - $CARGO_OUT_DIR to put artifacts in build outputs
 https://github.com/rust-lang/cargo/issues/6790
   - cargo metadata, guile-toml, cargo-build --manifest-path=...?

** Packaging efforts and updates
   pijul patches available.

   Others waiting to submit.
   - teip
   - skim
   - dog
   - sd
   - zoxide
   - tealdeer

** Collaboration with Rust community directly
   - Start with communication, maybe advance to RFC?
   - Collaborate with Nix to understand how to make cargo work better for
 functional package managers?

** Wasm32 target support
   - May need to patch-cargo-checksums of Cargo


Re: Staging branch

2020-12-13 Thread John Soo
 Hello there, 

 
Is there any chance this could make it to staging before the merge?
 

 
http://issues.guix.gnu.org/42295
 

 
Thanks!
 

 
John
 

Re: Staging branch

2020-12-13 Thread John Soo
 Hello, 

 
icecat, ungoogled-chromium, alacritty, ripgrep, exa and others depend on it at 
least. I have been using the patches for a few weeks.  
 

 
What do you think?
 

 
- John
 

Re: Staging branch

2020-12-13 Thread John Soo
 Hi Leo, 

 
The patch adds an extra output, leaving the compiler unchanged so nothing 
should be effected in runtime as far as I know.  
 

 

 
- John
 

Re: Staging branch

2020-12-13 Thread John Soo
 As far as I understand it, it adds just enough to the rust package 
definition to add the extra rustfmt output. 

Re: Staging branch

2020-12-13 Thread John Soo
 Thank you! Let’s test! 

Re: Discussion: How to package rust crates now and in future?

2020-12-18 Thread John Soo
 Hey Hartmut,  

  
I’m not sure which way I fall here. I think probably keepijg ci on for most 
crates makes sense if we can work instead towards real shared libraries.
  

  
In any case, I would like to propose a working group for rust. Perhaps we can 
meet monthly in jitsi or elsewhere.
  

  
What do you think?
  

  
- John
 

Re: Packaging elm-compiler 0.19.1

2020-12-31 Thread John Soo
 Hi Matthew,  

  
I’m not 100% sure how guix handles the ghc “boot” libraries but I think time is 
installed alongside ghc. Doing guix environment --pure --ad-hoc ghc -- ghc-pkg 
list gets me time-1.9.3. So I do think the version bounds should be satisfied 
without any other dependency. Mind sharing more of the package definition?
  

  
- John
 

Re: Staging branch

2021-01-02 Thread John Soo
 Hi there, 

 
Is staging not running in ci?It looks like the last time it ran was just 
before the rustfmt output of rust (commit 48926b5).Did changing rust@1.46 
somehow keep ci from running on staging?
 

 
Maybe I am missing something.
 

 
Any clues?
 

 
John
 

Re: Packaging elm-compiler 0.19.1

2021-01-02 Thread John Soo
Hi Matthew,


Matthew Kraai  writes:

> I think that elm-compiler is built with GHC 8.6.5, not GHC 8.8.3. 
> When I run `guix environment --pure --ad-hoc ghc@8.6.5 -- ghc-pkg
> list`, its output contains `time-1.8.0.2`.  I tried changing the
> definition of `ghc-8` in `haskell.scm` from `ghc-8.6` to `ghc-8.8`,
> but then `integer-logarithms` fails to build.  Maybe I have to upgrade
> to the latest LTS Haskell.

The haskell-build-system respects a #:haskell argument like so:

(arguments
 `(#:haskell ,ghc-8.8 ...))

That way you don't end up bumping the default ghc for everyone while
updating one package.

I tried your definition with ghc@8.8 as above and some new packages were
not in constraints.  Can you go from there and update the
"update-constraints" phase as you go? Maybe that will be enough.


Thanks!

- John



Re: Staging branch

2021-01-02 Thread John Soo
Hi Guix,

Leo Famulari  writes:

> It is supposed to be running, but something has broken. This does happen
> from time to time...

Ah well...

For what it is worth I have rebased on staging and reconfiguring my
system on it built successfully.  Also my manifest built successfully.

I don't have many effected packages though [1].

Thanks again,

John

[1] My packages:

(define-public languages
  '("agda"
"agda-ial"
"cedille"
"coq"
"idris"
"ocaml"
"purescript"))

(define-public utilities
  '("aspell"
"aspell-dict-en"
"bpftrace"
"cups"
"direnv"
"docker-cli"
"dog"
"emacs-no-x"
"exa"
"fd"
"fish"
"fish-foreign-env"
"fzy"
"gdb"
"global"
"groff"
"make"
"pijul"
"pinentry"
"recutils"
"ripgrep"
"rlwrap"
"shellcheck"
"skim"
"time"
"tlsdate"
"tokei"
"tmux"
"unzip"))

(define-public browsers
  '("icecat"
"lynx"
"ungoogled-chromium"))

(define-public desktop-tools
  '("alacritty"
"alsa-utils"
"clipmenu"
"compton"
"dbus"
"dunst"
"garcon"
"libnotify"
"libreoffice"
"mpv"
"my-dmenu"
"pulseaudio"
"scrot"))

(define-public fonts
  '("mkfontdir"
"mkfontscale"
"font-dejavu"
"font-iosevka"
"font-iosevka-term-slab"))

(define-public haskell-tools
  '("ghc"
"hlint"
"hoogle"))

(define-public ocaml-tools
  '("opam"))

(define-public rust-tools
  '("rust"
"rust:cargo"
"rust:rls"
"rust:rustfmt"))

(define-public guile-tools
  '("guile"
"guile-colorized"
"guile-readline"
"guile-syntax-highlight"))

(define-public pdf-tools
  '("texlive"
"zathura"
"zathura-pdf-mupdf"))

(define-public xorg-tools
  '("gcc-toolchain"
"ghc-dbus"
"ghc-xmonad-contrib"
"setxkbmap"
"xcape"
"xdg-utils"
"xdotool"
"xev"
"xfontsel"
"xinit"
"xinput"
"xlockmore"
"xmessage"
"xmobar"
"xmonad"
"xrandr"
"xsel"
"xsetroot"
"xwallpaper"))

(define-public emacs-packages
  '("emacs-anzu"
"emacs-avy"
"emacs-cmake-mode"
"emacs-company"
"emacs-company-coq"
"emacs-company-math"
"emacs-counsel-projectile"
"emacs-csv-mode"
"emacs-cql-mode"
"emacs-dash"
"emacs-debbugs"
"emacs-dhall-mode"
"emacs-direnv"
"emacs-dired-git-info"
"emacs-diredfl"
"emacs-docker"
"emacs-dockerfile-mode"
"emacs-ediprolog"
"emacs-eglot"
"emacs-elfeed"
"emacs-elf-mode"
"emacs-elm-mode"
"emacs-emmet-mode"
"emacs-evil"
"emacs-evil-anzu"
"emacs-evil-commentary"
"emacs-evil-escape"
"emacs-evil-leader"
"emacs-evil-magit"
"emacs-evil-org"
"emacs-evil-surround"
"emacs-evil-tmux-navigator"
"emacs-f"
"emacs-fill-column-indicator"
"emacs-fish-completion"
"emacs-fish-mode"
"emacs-flycheck"
"emacs-flycheck-elm"
"emacs-flycheck-rust"
"emacs-forge"
"emacs-geiser"
"emacs-goto-chg"
"emacs-graphql-mode"
"emacs-graphviz-dot-mode"
"emacs-guix"
"emacs-haskell-mode"
"emacs-haskell-snippets"
"emacs-ibuffer-projectile"
"emacs-idris-mode"
"emacs-imenu-list"
"emacs-ivy"
"emacs-let-alist"
"emacs-magit"
"emacs-markdown-mode"
"emacs-merlin"
"emacs-multi-term"
"emacs-nix-mode"
"emacs-nodejs-repl"
"emacs-ob-restclient"
"emacs-origami-el"
"emacs-prescient"
"emacs-projectile"
"emacs-psc-ide"
"emacs-recutils"
"emacs-reformatter"
"emacs-restclient"
"emacs-rust-mode"
"emacs-s"
"emacs-slime"
"emacs-slime-company"
"emacs-sml-mode"
"emacs-solarized-theme"
"emacs-systemd-mode"
"emacs-terraform-mode"
"emacs-tuareg"
"emacs-vimrc-mode"
"emacs-web-mode"
"emacs-wgrep"
"emacs-which-key"
"emacs-xclip"
"emacs-xterm-color"
"emacs-yaml-mode"
"emacs-yasnippet"
"proof-general"))



Commit Access to Emacs-Guix

2021-01-11 Thread John Soo
Hello Guix,

I have taken up maintainership of the new home of Emacs-Guix on
Savannah.  This message is signed with the key I will be using to sign
commits on Emacs-Guix.

Thank you!

John


signature.asc
Description: PGP signature


Emacs-Guix repository location moved to Savannah

2021-01-11 Thread John Soo
Hi Guix!

Emacs-Guix has a new home!  I just pushed
a42f66cb40a9e60611f429a403b08dbed29bae02 to Emacs-Guix on Savannah.

My first order of business will be fixing the broken subcommands.  I
don't use many of them, though.  If you have a command you want fixed,
please let me know and I will priortize it.

What do you think about having conversations about Emacs-Guix on
guix-devel?

Kindly,

John



Re: New emacs-guix location

2021-01-11 Thread John Soo
Hi Alex!


Alex Kost  writes:

> Hello, I am fine, thanks!

I hope you are still well!

>
>> I volunteered to maintain some version of
>> emacs-guix recently. How do you feel about a fork moving to Savannah?
>
> You (and all the Guix people) are free to do whatever you think is
> appropriate.  Emacs-Guix is a free software after all.
>
> So if you will maintain the "official" (used by Guix) version of
> Emacs-Guix at Savannah, I will only be happy that I don't have this
> burden anymore.

I just pushed to savannah, so consider yourself unburdened :) Thank you
for your work and maintainership.

> As for me, I will continue to use my version of Emacs-Guix and to adjust
> it for my needs.

Sounds good :)

> And thank you for your latest commits that fixed Emacs-Guix for the
> current versions of Guix and Geiser!

My pleasure.

Kindest wishes,

John



Re: Emacs-Guix repository location moved to Savannah

2021-01-12 Thread John Soo
Hi Pierre!

Pierre Neidhardt  writes:

>
> - guix-devel-build-package-definition
>
>   It seems that Geiser chokes on it because of the output.
>   I don't know if this can be worked around somehow.
>   If not, an alternative would be to invoke the `guix repl` executable
>   instead of using Geiser.
>
> - guix-devel-download-package-source
>
>   Make it work with all kinds of sources, such as git URLs.

Ok, noted.

>> What do you think about having conversations about Emacs-Guix on
>> guix-devel?
>
> No strong opinion!

Alright, it would be most convenient to me if we can have conversations
on guix-devel. Is that ok by the guix group?

Thanks!

- John



Re: Emacs-Guix repository location moved to Savannah

2021-01-12 Thread John Soo
Hi Tobias,

Tobias Geerinckx-Rice  writes:

> Hi,
>
> John Soo 写道:
>> Emacs-Guix has a new home!  I just pushed
>> a42f66cb40a9e60611f429a403b08dbed29bae02 to Emacs-Guix on Savannah.
>
> Thank you for taking care of this, and innumerable thanks to Alex for
> creating and maintaining emacs-guix for so many years.

Yes, many many thanks to Alex for their work over the years.

>> My first order of business will be fixing the broken subcommands.  I
>> don't use many of them, though.  If you have a command you want
>> fixed,
>> please let me know and I will priortize it.
>
> I use it very infrequently and it currently won't start:
>
>  Starting Guix REPL ... [2 times]
>  geiser-repl--connection: No Geiser REPL for this buffer (try M-x
>  run-geiser)
>  Starting Guix REPL ... [2 times]
>  geiser-repl--wait-for-prompt: No prompt found!
>
> Probably my fault somewhere.  Still, it would be nice if this ‘just
> worked’ for those who don't have and want a custom Geiser set-up.

Does it still not start? As of (guix) commit
f98e3adcd533a4a4c5482343a26d01076e946f92 I at least can start a repl
without a crash.

>> What do you think about having conversations about Emacs-Guix on
>> guix-devel?
>
> I think that's a good idea & better than creating a separate list.
>
> Where do you accept patches?  The one below is untested.

That's also a good question.  I would prefer to use the existing
guix-patches.  Is that ok by the standard mailing list administrators?

As to the patch, I would like to apply it.  Is Guix System still the
preferred name? I thought another renaming took place.  I am possibly
very out of date on that info though.

Best regards,

John



Re: Emacs-Guix repository location moved to Savannah

2021-01-12 Thread John Soo
Hi Ryan,

Ryan Prior  writes:

> How do you feel about removing commands that nobody feels like fixing? It 
> might help Emacs-Guix build a reputation for reliability.

I plan on trying to fix them all, but I may remove some if they are just
not possible any longer.

> I think it's a good idea. Conversing regularly on this list will keep people 
> abreast of what state things are in. Moving conversation to a dedicated
> channel likely means nobody would read, which disincentivizes writing. If 
> discussion on this list reaches a level of volume where it's annoying, that's 
> the
> signal to explore alternate channels.

Thanks, good point.  I think we'll stay here until it gets too noisy (if
it is ok by the adminstrators).

Best regards,

John



Re: Emacs-Guix repository location moved to Savannah

2021-01-12 Thread John Soo
Hi Pierre,

I forgot to answer your other question.  Emacs-Guix is a sub-project of
Guix on Savannah https://savannah.gnu.org/projects/guix it is "Emacs
interface to GNU Guix".  The repository is available at
https://git.savannah.gnu.org/cgit/guix/emacs-guix.git.

- John



Re: Emacs-Guix repository location moved to Savannah

2021-01-12 Thread John Soo
> I can't think of a better place nor can I imagine we'll be overwhelmed
> by emacs-guix patches.
>
> (And if we are, that's probably a good thing at this point?)

That is my thought, too.

>> As to the patch, I would like to apply it.  Is Guix System still the
>> preferred name?
>
> Yep.  There's also no separate ‘System’ logo anymore[0].  Guix System
> being merely a different earthly manifestation of the one eternal
> Guix.
>
>> I thought another renaming took place.  I am possibly
>> very out of date on that info though.
>
> Nope.

Ok, I pushed 825ab772f7f64700a9914ccbf9b079eb6aef6461 with a slight
modification to the commit message.

Thanks!

John



Re: Staging branch [substitute availability aarch64-linux]

2021-01-13 Thread John Soo
 I’ve been working on ghc and making some progress. I’d love to have more 
support for rust but I’m not sure what the issue is.

Re: [Emacs-Guix] make: Error 255

2021-01-16 Thread John Soo
 Hi zimoun, 

 
What exactly did you do? It sounds like you checked out emacs-guix and ran make?
 

 
- John  
 

Re: [Emacs-Guix] make: Error 255

2021-01-16 Thread John Soo
 Hi zimoun,  

  
What about using guix to build like:
  

  
guix build -f guix.scm
  

  
I believe that is how that file is meant to work.
  

  
I’m not sure it entirely answers your question on how to test but maybe 
something like this would work:
  

  
guix environment -L . --ad-hoc emacs emacs-guix -- emacs -Q
  

  
What do you think?
  

  
- John
  

 

[PATCH] gnu: alacritty: Update to 0.7.1.

2021-02-17 Thread John Soo
  
  

  
  
  
Hey Tobias and Nicolás,  

  
I added alacritty some time ago but I do use it every day.I don’t use 
Wayland (yet) though so I can’t say whether the hack in question is working. I 
can confirm that the update is just fine on X though.
  

  

  
Sorry for not keeping it more up to date!I think the alacritty project 
itself has been slow to make releases, to be fair, though.Thanks for taking 
a look at it!
  

  
- John
  
  
  
  

  
 

hg-fetch with subrepos

2018-12-01 Thread John Soo
Hi guix!

Thanks and please bear with my first ever mailing list post.  I was trying to 
package coin3d (https://bitbucket.org/Coin3D/coin/wiki/Home) as it is now under 
a bsd3 license.  The hash of the repo always changes. I think this is due to 
the .hg files not being recursively deleted for the subrepositories 
(https://www.mercurial-scm.org/wiki/Subrepository). Does anyone have any 
insights?

Thanks!

John

Re: hg-fetch with subrepos

2018-12-02 Thread John Soo
Thanks!

That patch looks familiar :D Looking forward to it.

John

On Sun, Dec 2, 2018 at 1:59 PM Ludovic Courtès  wrote:

> Hello,
>
> Björn Höfling  skribis:
>
> > And I stumbled upon that problem too. Ludovic explained me on IRC: The
> > problem is the metadata directory ".hg": It contains metadata that is
> > not fixed. For normal hg-repositories, it will be stripped away, but
> > not recursively for those with sub-repos.
> >
> > I have a patch that works. I just wasn't sure if it goes to master or
> > to staging, as it could affect the java-packages as well.
>
> Such a patch can go to ‘master’: it won’t trigger any rebuild because,
> by definition, the content hash of an ‘origin’ is known in advance
> (these are “fixed-output derivations.”)
>
> However, we should audit current uses of ‘hg-fetch’ with recursive
> sub-repos because there hashes are most likely wrong already.
>
> > I'm attaching what I have here, will prepare an official patch tonight
> > or tomorrow.
>
> Awesome.  FWIW this patch already LGTM.  :-)
>
> Thanks,
> Ludo’.
>


Re: Brain storming cool Guix features

2019-01-04 Thread John Soo
Yes, good ideas! I’m curious if per-user packages could be declared in the 
system configuration. I think nixOS has that feature now and I’m a little 
jealous...

> On Jan 4, 2019, at 8:10 AM, Pierre Neidhardt  wrote:
> 
> Very nice ideas, in particular the manifest-file option!
> 
> Note that something like ~/.config/guix/manifest.scm would probably be a 
> better
> fit for user-profile manifests.
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz/



Packaging FreeCAD

2019-01-09 Thread John Soo
Hello everyone,

I started packaging FreeCAD in a personal channel 
(https://www.github.com/jsoo1/guix-channel). Has anyone already started or want 
to collaborate?  I’m currently working on the python Shiboken library 
dependency which I could use some help on. There are a few other things that 
need shoring up like licensing research, making other dependencies work and 
generally getting the thing to compile. 

All the best,

John


Re: Packaging FreeCAD

2019-01-11 Thread John Soo
Hey Paul,

I did not know Debian changed their version of opencascade. I will have to 
double check that they are using OCCT for FreeCAD still. 

- John

> On Jan 11, 2019, at 1:35 AM, Paul Garlick 
>  wrote:
> 
> Hi John,
> 
> This is good news indeed for Guix-using engineers and architects.  I
> shall follow developments with interest.
> 
> I can look after the OpenCASCADE dependency too.  This package is due
> an update but upstream development has been slow of late.  Debian have
> switched to the OCCT version for FreeCAD and I am thinking that it
> would be best for Guix to follow suit.  This would entail the
> introduction of a new opencascade-occt package, which I plan to do
> soon, if no-one beats me to it!
> 
> Best regards,
> 
> Paul.
> 
> 
> 



Re: Packaging FreeCAD

2019-01-15 Thread John Soo
Hi Paul,

Thank you for saving me the headache!  I’ll keep this posted with progress. 

- John 

> On Jan 14, 2019, at 4:42 AM, Paul Garlick 
>  wrote:
> 
> Hi John,
> 
>> I did not know Debian changed their version of opencascade
> 
> There are two versions of OpenCASCADE in Debian, named 'liboce' and
> 'libocct'.  'occt' is the upstream variant, 'oce' is the community
> maintained variant.  Historically, Debian has switched between the two
> as licence requirements dictated.  
> 
> Currently, both are packaged and FreeCAD version 0.17 depends on
> liboce.  However, libocct is being more actively maintained and I
> believe the intention for Debian FreeCAD version 0.18 is for the
> dependency to switch to libocct.
> 
> Best regards,
> 
> Paul.
> 



Re: Merging ‘wip-newt-installer’ in master?

2019-01-16 Thread John Soo
Hi all!

I was working on adding more configuration options to the kmscon service. Do 
you think the service can take advantage of the config file, too?

Thanks!

John

> On Jan 16, 2019, at 10:25 AM, Ludovic Courtès  wrote:
> 
> Hi again!
> 
> I pushed a few commits to ‘wip-newt-installer’.
> 
> I was able to test it with (roughly):
> 
>  guix system disk-image --file-system-type=iso9660 gnu/system/install.scm
>  qemu-img create -f qcow2  /tmp/t.img 2100M
>  qemu-system-x86_64 -enable-kvm -m 512 -cdrom /gnu/store/…-image.iso \
>-hda /tmp/t.img
> 
> The config file was properly generated (hurray!).  The actual
> installation eventually failed because substitutes are taken from
> hydra.gnu.org, and somehow at one point it would try to download
> linux-libre, which would fail (quite surprisingly: I’d expected the
> download fallback to work, dunno what happened.)
> 
> Anyway, can we rebase the branch on ‘master’?
> 
> It seems to me that it’s in a good shape.  The installer is really
> pleasant to use!
> 
> Thanks,
> Ludo’.
> 



Re: Plan for fish shell in Guix.

2019-01-21 Thread John Soo
Hi,

I’m trying it now. Everything seems to work pretty well! Thanks so much! This 
has been one major issue for me for a while!

- John

> On Jan 21, 2019, at 12:32 AM, Meiyo Peng  wrote:
> 
> Hello everyone,
> 
> Thank you for your patience.
> 
> I investigated the problem and chose to parse /etc/profile from fish
> rather than generate separate configuration files for fish.  I think
> this will make the Guix project easier to maintain in the future.
> 
> I looked NixOS's solution.  They choose this approach too, but their
> patch is more complex.  I implemented my patch in a minimalistic manner.
> 
> The patch has been sent to guix-patc...@gnu.org:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34153
> 
> I set fish as my login shell and every thing is working well.  Please
> try the patch and report bugs if you are interested.
> 
> Thanks.
> 
> 
> --
> Meiyo Peng
> https://www.pengmeiyu.com/
> 



Re: Plan for fish shell in Guix.

2019-01-21 Thread John Soo
Hello,

I just have one issue with the patch so far:  I can’t seem to unset an 
abbreviation. An old configuration file seems to be “sticking” around for lack 
of better term. Otherwise, good stuff!

John

> On Jan 21, 2019, at 12:32 AM, Meiyo Peng  wrote:
> 
> Hello everyone,
> 
> Thank you for your patience.
> 
> I investigated the problem and chose to parse /etc/profile from fish
> rather than generate separate configuration files for fish.  I think
> this will make the Guix project easier to maintain in the future.
> 
> I looked NixOS's solution.  They choose this approach too, but their
> patch is more complex.  I implemented my patch in a minimalistic manner.
> 
> The patch has been sent to guix-patc...@gnu.org:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34153
> 
> I set fish as my login shell and every thing is working well.  Please
> try the patch and report bugs if you are interested.
> 
> Thanks.
> 
> 
> --
> Meiyo Peng
> https://www.pengmeiyu.com/
> 



Re: Plan for fish shell in Guix.

2019-01-21 Thread John Soo
Ah! Makes sense! I haven’t had a chance to use 3.0 yet! I’ll try that and see.

> On Jan 21, 2019, at 5:24 PM, Meiyo Peng  wrote:
> 
> Hi John,
> 
> John Soo writes:
> 
>> I just have one issue with the patch so far: I can’t seem to unset an
>> abbreviation. An old configuration file seems to be “sticking” around
>> for lack of better term. Otherwise, good stuff!
> 
> This is most likely caused by the transition from fish 2.7 to fish 3.0.
> Fish 3.0 automatically migrates your abbreviations to a new storage
> format.  Please have a look at the man page of `abbr`.  You should now
> manage you abbreviations with:
> 
> #+begin_SRC sh
>  abbr --show
>  abbr --add ec emacsclient
>  abbr --erase ec
> #+end_SRC
> 
> --
> Meiyo Peng
> https://www.pengmeiyu.com/



Re: “Which important packages fail to build?”

2019-01-26 Thread John Soo
Hi,

I think icecat is ok. I’m probably wrong about this but what I understand is 
that icecat is being rebuilt after the rust bootstrap got merged. Upgrading 
icecat now requires building several versions of the rust compiler. I hope a 
substitute becomes available soon since it really does take a long time. I have 
a pretty nice set of hardware and it took nearly a day. I can’t imagine on an 
older machine.

- John

> On Jan 26, 2019, at 8:57 AM, Joshua Branson  wrote:
> 
> Ludovic Courtès  writes:
> 
>> Hello Guix!
>> 
>> I’ve just added a new ‘--coverage’ option to ‘guix weather’.  The goal
>> is to answer the question: “which important packages fail to build?”, or
>> at least, “which important packages have no substitutes?”.  I believe
>> this is what we want to know in particular to determine whether a branch
>> can be merged.  Demonstration:
>> 
>> $ ./pre-inst-env  guix weather --substitute-urls=https://ci.guix.info -c 10
>> computing 8,983 package derivations for x86_64-linux...
>> looking for 9,343 store items on https://ci.guix.info...
>> updating substitutes from 'https://ci.guix.info'... 100.0%
>> https://ci.guix.info
>>  64.7% substitutes available (6,048 out of 9,343)
>>  18,642.5 MiB of nars (compressed)
>>  54,068.6 MiB on disk (uncompressed)
>>  0.018 seconds per request (164.6 seconds in total)
>>  56.8 requests per second
>>  'https://ci.guix.info/api/queue?nr=1000' returned 504 ("Gateway Time-out")
>> updating substitutes from 'https://ci.guix.info'... 100.0%
>> 2502 packages are missing from 'https://ci.guix.info' for 'x86_64-linux', 
>> among which:
>>58  kcoreaddons@5.49.0  
>> /gnu/store/8v69bzi29rla9q952ajgpsvsb7k955l6-kcoreaddons-5.49.0
>>47  kcoreaddons@5.49.0  
>> /gnu/store/8v69bzi29rla9q952ajgpsvsb7k955l6-kcoreaddons-5.49.0
>>46  qgpgme@1.11.1   
>> /gnu/store/rgvjzck002diandc1nhkw0dy1p9zqaw2-qgpgme-1.11.1
>>37  perl-http-cookiejar@0.008   
>> /gnu/store/2npd0vs3ipyqms06kbgh7ialp9n0fr6m-perl-http-cookiejar-0.008
>>30  qgpgme@1.11.1   
>> /gnu/store/rgvjzck002diandc1nhkw0dy1p9zqaw2-qgpgme-1.11.1
>>26  ocaml4.02-ppx-deriving@4.1  
>> /gnu/store/siv42br9h06i1zhmmj6s2qian45zacgm-ocaml4.02-ppx-deriving-4.1
>>18  ruby-ansi@1.5.0 
>> /gnu/store/p5adbp7bhvjzpjxr8brnfm52imqc4f07-ruby-ansi-1.5.0
>>16  cl-rt@1990.12.19
>> /gnu/store/vs9ddw7avffmnzxcknvyazay29vihy28-cl-rt-1990.12.19
>>16  ecl-rt@1990.12.19   
>> /gnu/store/765znwnf4bxdaz82akx60pkx2ac59fyn-ecl-rt-1990.12.19
>>13  ecl-trivial-gray-streams@0.0.0-1.0483ade
>> /gnu/store/lyj6w0p9v3kfkzmar1pd46qlg36zp7dd-ecl-trivial-gray-streams-0.0.0-1.0483ade
>>11  ruby-brass@1.2.1
>> /gnu/store/jxf63lbwv2rg95pf5zmznjzv8s367xqc-ruby-brass-1.2.1
>>11  ruby-rspec-expectations@2.14.5  
>> /gnu/store/6dacx02mn2skwbiajfwnx1q0fk5iw05y-ruby-rspec-expectations-2.14.5
>>11  ruby-rspec-mocks@2.14.6 
>> /gnu/store/9lirirccwslkghpps1al23m7pdi5yw1b-ruby-rspec-mocks-2.14.6
>>11  ruby-rspec-core@2.14.8  
>> /gnu/store/xrpaql4jldvvd08im37x8k42crsxpip0-ruby-rspec-core-2.14.8
>>11  ecl-slynk-boot0@1.0.0-beta-2.cbf84c3
>> /gnu/store/l23p319knfzygsc38zxf7l5g892bqy1z-ecl-slynk-boot0-1.0.0-beta-2.cbf84c3
>>11  python2-oslotest@3.4.0  
>> /gnu/store/7f87w09iinxv06dld394x7w47chcy3ip-python2-oslotest-3.4.0
>>10  pt-scotch@6.0.5a
>> /gnu/store/gw4mzjlwlf010ijhyznhr5sjmpxizl9v-pt-scotch-6.0.5a
> 
> As an aside, should Icecat be on this list?  I keep having to use "guix 
> package
> --do-not-upgrade=icecat -u", because Icecat takes forever to build, and
> I'm not certain that I have enough memory to build it.
> 
> However,
> 
> #BEGIN_SRC sh
> icecat --version
> #END_SRC
> 
> #+:RESULTS:
> GNU IceCat 60.3.0
> 
> 
> BUT why does guix package -u try to rebuild Icecat?
> 
> #BEGIN_SRC sh
> guix package -u
> guix package: warning: package 'jmacs' no longer exists
> substitute: updating substitutes from 'https://ci.guix.info'... 100.0%
> building /gnu/store/r583x6jd6qlb7im42c0awmj6jvi1g13c-icecat-60.3.0-gnu1.drv...
> #END_SRC
> 
> 
> P.S. jmacs is my attempt to have a "custom" Emacs.  It's basically Emacs
> with additional modules installed.
> 
> Thanks,
> 
> Joshua
> 
> --
> Joshua Branson
> Sent from Emacs and Gnus
> 



Haskell dependencies for custom cabal builds

2019-02-11 Thread John Soo
Hi Guix,

I’ve been working on some Haskell packages and got stuck recently and I didn’t 
know why until I realized the cabal files have `build-type: Custom` 
(http://hackage.haskell.org/package/termonad-1.1.0.0/termonad.cabal). I always 
get missing dependencies even though I have the dependencies listed in `inputs` 
(haskell-gi-base and friends in the example above). What do I need to do to fix 
this?

Thanks!

John

Re: Haskell dependencies for custom cabal builds

2019-02-11 Thread John Soo
Thanks Tim,

I’ll check out git-annex as a start. Custom Cabal builds would be a nice 
feature to add to the haskell-build-system. Would it be sufficient to add some 
extra argument to the build system?

Best,

John

> On Feb 11, 2019, at 12:19 PM, Timothy Sample  wrote:
> 
> Hi John,
> 
> John Soo  writes:
> 
>> Hi Guix,
>> 
>> I’ve been working on some Haskell packages and got stuck recently and I 
>> didn’t know why until I realized the cabal files have `build-type: Custom`
>> (http://hackage.haskell.org/package/termonad-1.1.0.0/termonad.cabal). I 
>> always get missing dependencies even though I have the dependencies listed 
>> in `inputs` (haskell-gi-base and
>> friends in the example above). What do I need to do to fix this?
> 
> You might be able to take some inspiration from git-annex, which I
> believe has the same problem.
> 
> In short, the issue is that the haskell-build-system unsets
> “GHC_PACKAGE_PATH” before calling “runhaskell Setup.hs”.  This is
> because it assumes that “Setup.hs” will use Cabal in a pretty direct
> way, and that Cabal will setup the required packages from the command
> line (Cabal complains if you try to use “GHC_PACKAGE_PATH”, because it
> wants to be in control of the environment).  If the custom build code
> needs dependencies, they will not be available (unless it does what
> Cabal does and reads package paths from the command line and sets
> everything up from within Haskell).
> 
> For git-annex, I was able to skirt the problem.  I don’t know how to
> solve it.  If you keep “GHC_PACKAGE_PATH” set, the Cabal part of the
> build will likely complain.  However, without it, the custom part of the
> build can’t find its dependencies.
> 
> That’s about all I can recall right now.  I hope that helps at least a
> little bit!  :)
> 
> 
> -- Tim



Re: Haskell dependencies for custom cabal builds

2019-02-12 Thread John Soo
Hi there,

I did a little digging this morning and it seems like runhaskell is probably 
deprecated in favor of runghc. Do we expect anyone to be using hugs or jhc?  
Runghc also supports ghc flags. I still need to do some more research here but 
the Haskell configure phase deliberately unsets GHC_PACKAGE_PATH. I assume it 
does this because runhaskell supports many Haskell compilers. If custom cabal 
builds are rare, I would suspect that non-ghc builds are even rarer. Would it 
be possible to replace runhaskell with runghc? Or parameterize the command?

Thanks,

John

> On Feb 12, 2019, at 8:06 AM, Timothy Sample  wrote:
> 
> Hi John,
> 
> John Soo  writes:
> 
>> I’ll check out git-annex as a start. Custom Cabal builds would be a
>> nice feature to add to the haskell-build-system. Would it be
>> sufficient to add some extra argument to the build system?
> 
> At this point, I don’t know what the argument would do.  :)
> 
> The solution I came up with for git-annex only works for git-annex.  I
> had to carefully read the build code, and carve out certain parts so
> that they could run in different environments.  It is not something that
> could be enabled by an argument.
> 
> The only idea I have would be switching from using “runhaskell Setup.hs”
> to using the “cabal” executable.  Hopefully, Cabal would set up the GHC
> package database before running the custom code.  If it worked, it could
> be enabled by a build-system argument.  I’m definitely just guessing
> here, though.  If you wanted to test this, you could copy out code from
> “guix/build/haskell-build-system.scm” into custom phases in your
> package.  If it proves useful, we could adapt it into the build system.
> 
> So far, custom builds have been extremely rare, so these issues are not
> very well explored.
> 
> 
> -- Tim



Re: Haskell dependencies for custom cabal builds

2019-02-12 Thread John Soo
Thanks Tim!

Good to know! Thank you. Looking again at the call to runhaskell in the 
configure phase, then.  It does accept --package-db as an argument. Is it 
feasible to parse GHC_PACKAGE_PATH into the correct package paths instead of 
using the environment variable?

Thanks!

John

> On Feb 12, 2019, at 11:21 AM, Timothy Sample  wrote:
> 
> Hi John,
> 
> John Soo  writes:
> 
>> Hi there,
>> 
>> I did a little digging this morning and it seems like runhaskell is
>> probably deprecated in favor of runghc. Do we expect anyone to be
>> using hugs or jhc?  Runghc also supports ghc flags. I still need to do
>> some more research here but the Haskell configure phase deliberately
>> unsets GHC_PACKAGE_PATH. I assume it does this because runhaskell
>> supports many Haskell compilers. If custom cabal builds are rare, I
>> would suspect that non-ghc builds are even rarer. Would it be possible
>> to replace runhaskell with runghc? Or parameterize the command?
> 
> I don’t see how this would help.
> 
> From the build system code,
> 
>Cabal errors if GHC_PACKAGE_PATH is set during 'configure', so unset
>and restore it.
> 
> The issue that git-annex has is that it wants to use some packages
> before calling into Cabal.  If “GHC_PACKAGE_PATH” is set properly, it
> will find the packages, proceed normally until calling Cabal, and then
> error because Cabal doesn’t like “GHC_PACKAGE_PATH”.  Cabal wants to
> setup the package search path from the command line arguments instead.
> On the other hand, if “GHC_PACKAGE_PATH” is not set, Cabal would
> theoretically work, but we never get there!  The custom “Setup.hs” code
> errors out with missing packages before ever calling Cabal.
> 
> I don’t think that switching from “runhaskell” to “runghc” changes that.
> 
> 
> -- Tim



Re: Haskell dependencies for custom cabal builds

2019-02-12 Thread John Soo
Thanks Marius,

I’m feeling quite out of my depth here so thanks for the background. It seems 
like maintaining a fork effectively might be a lot more work. Is there really 
no other good way to accomplish a custom build?

John

> On Feb 12, 2019, at 11:44 AM, Marius Bakke  wrote:
> 
> Hello!
> 
> Timothy Sample  writes:
> 
>> Hi John,
>> 
>> John Soo  writes:
>> 
>>> Hi there,
>>> 
>>> I did a little digging this morning and it seems like runhaskell is
>>> probably deprecated in favor of runghc. Do we expect anyone to be
>>> using hugs or jhc?  Runghc also supports ghc flags. I still need to do
>>> some more research here but the Haskell configure phase deliberately
>>> unsets GHC_PACKAGE_PATH. I assume it does this because runhaskell
>>> supports many Haskell compilers. If custom cabal builds are rare, I
>>> would suspect that non-ghc builds are even rarer. Would it be possible
>>> to replace runhaskell with runghc? Or parameterize the command?
>> 
>> I don’t see how this would help.
>> 
>> From the build system code,
>> 
>>Cabal errors if GHC_PACKAGE_PATH is set during 'configure', so unset
>>and restore it.
>> 
>> The issue that git-annex has is that it wants to use some packages
>> before calling into Cabal.  If “GHC_PACKAGE_PATH” is set properly, it
>> will find the packages, proceed normally until calling Cabal, and then
>> error because Cabal doesn’t like “GHC_PACKAGE_PATH”.  Cabal wants to
>> setup the package search path from the command line arguments instead.
>> On the other hand, if “GHC_PACKAGE_PATH” is not set, Cabal would
>> theoretically work, but we never get there!  The custom “Setup.hs” code
>> errors out with missing packages before ever calling Cabal.
> 
> FWIW here is the upstream issue:
> 
> <https://github.com/haskell/cabal/issues/3728>
> 
> Note that it was "fixed" briefly by these commits:
> 
> <https://github.com/haskell/cabal/pull/3753>
> 
> Unfortunately it was later reverted due to breaking some edge(?) cases,
> and a Nix-specific workaround that I don't really understand was merged:
> 
> <https://github.com/haskell/cabal/pull/4193>
> 
> I wonder if we should try picking the original Cabal fix from ttuegel,
> maybe as a separate package if it really is a breaking change.  Thoughts?



Re: Packaging FreeCAD

2019-02-14 Thread John Soo
Hello Guix,

I have some small updates and asking for help on freecad (I’m working from my 
channel github.com/jsoo1/guix-channel). I have been getting a little stuck 
building the pyside2 dependencies. It seems like freecad is moving from the 
pyside1 tools (Shiboken and pyside) to pyside2 for the 0.18 release (see 
https://wiki.qt.io/Qt_for_Python). These packages have a custom setup.py that I 
could use a hand porting to a guix package. As far as I understand, building 
upside would complete all the required third party packages listed on the 
freecad wiki: https://www.freecadweb.org/wiki/Third_Party_Libraries. 

- John

> On Jan 14, 2019, at 4:42 AM, Paul Garlick 
>  wrote:
> 
> Hi John,
> 
>> I did not know Debian changed their version of opencascade
> 
> There are two versions of OpenCASCADE in Debian, named 'liboce' and
> 'libocct'.  'occt' is the upstream variant, 'oce' is the community
> maintained variant.  Historically, Debian has switched between the two
> as licence requirements dictated.  
> 
> Currently, both are packaged and FreeCAD version 0.17 depends on
> liboce.  However, libocct is being more actively maintained and I
> believe the intention for Debian FreeCAD version 0.18 is for the
> dependency to switch to libocct.
> 
> Best regards,
> 
> Paul.
> 


Re: Packaging FreeCAD

2019-02-15 Thread John Soo
Thanks so much Paul! This is really helpful!

> On Feb 15, 2019, at 9:20 AM, Paul Garlick 
>  wrote:
> 
> Hi John,
> 
>> I have been getting a little stuck building the pyside2 dependencies
> 
> There has been an effort to package pyside2 for Debian.  This has been
> completed in the last six months. 
> 
> A good place to look for information is 
> https://tracker.debian.org/pkg/pyside2
> 
> You can browse the source code and follow the links to the 'debian'
> directory, which contains the files that govern the packaging process. 
> In general for Debian packages, the 'rules' file is worth reading and
> the 'patches' directory has the changes to the upstream code.  
> 
> One element that could be important in Guix is an update of patchelf to
> a recent commit (see 'update-patchelf.patch' in the patches directory).
> 
> Best regards,
> 
> Paul.
> 



Re: Some more rust/cargo insights

2021-06-07 Thread John Soo
Hi Hartmut and Pjotr,

My feeling on this is that we should partner with the Rust community to make 
shared library support from cargo a priority. Specifying an output directory is 
currently a nightly feature, that could be helpful.

In general Rust tooling does not compose with existing tools. I believe they 
will be amenable to the thought that it should. If Rust wants to be used in the 
linux kernel, for instance, it should be easy to use with Make.

Rust has a very well documented rfc process and we can at least bring it up 
that way. I brought up the possibility of collaboration between rust and 
functional package managers on the rust Zulip, even. They seemed to like the 
idea.

Another path we should checkout is to see what Debian does. My understanding is 
that they figured something out. Worth a shot, but I’d rather the problem be 
fixed upstream. It will just take collaboration.

Kindly,

John

> On Monday, Jun 07, 2021 at 5:04 AM, Hartmut Goebel 
> mailto:h.goe...@crazy-compilers.com)> wrote:
> Am 07.06.21 um 10:28 schrieb Pjotr Prins:
> > Exactly my idea. One challenge will be that the source of dependencies
> > need to be available - think of it as include files. One thing we
> > could do as ship them as part of the Guix package. Or have a separate
> > one for sources. We do that for include files already.
>
> Well, the current cargo-build-system already handles the source
> dependencies.
>
> We need to aim towards pre-built libraries (rlib, much like .a files in
> C, I assume)
>
> When cargo calls rustc, the command looks like:
>
> LD_LIBRARY_PATH='$PWD/target/release/deps:/gnu/store/…-rust-1.45.2/lib' \
> rustc … src/lib.rs --crate-type lib \
> -L dependency=$PWD/target/release/deps \
> --extern
> xmlparser=$PWD/target/release/deps/libxmlparser-53596ac1828b1c97.rmeta
>
> Thus I assume one could pass the rlib's of all dependencies in -L and
> the respective mata-data in --extern
>
> --
> Regards
> Hartmut Goebel
>
> | Hartmut Goebel | h.goe...@crazy-compilers.com |
> | 
> https://urldefense.com/v3/__http://www.crazy-compilers.com__;!!IKRxdwAv5BmarQ!KvLeCSlBvF9faFS6qJxYA0Rl0AuuhxYx7oxMtZXdbILpmv_Rz4n8swX7_p74sQ$
>  | compilers which you thought are impossible |
>
>


Re: Some more rust/cargo insights

2021-06-07 Thread John Soo
Oh my goodness, I’m so sorry for the top quote.

Re: Create branch for Haskell build changes and updates?

2021-07-07 Thread John Soo
Hey Guix,

I’m very happy to see some movement on haskell support.

We try to track the stack package set for a given ghc version. Updating to ghc 
8.10.4, then, means updating to stackage lts 18.1.

One other issue that should be addressed is that cabal-install will need to be 
updated to 3.x. I have tried but I don’t know how to build it.

I also nominate updating the ghc-profile-hook. It needs some work to be fully 
functional. Perhaps a search-path would be the way to go there?

Kindly,

John Soo



Re: Desktops on non-x86_64 systems

2021-11-27 Thread John Soo
Hi Guix,

I had the same thought as Maxim. In my quest for arm support for ghc, I thought 
about using a cross-compiled version. Is this possible or even desirable? I 
think for rust and ghc it would be very helpful - if somewhat less principled 
than a bootstrap all the way up (on the same computer).

I'm curious what the consensus is here.

Kindly,

John



Re: Packaging rust-analyzer is not necessary.

2022-03-26 Thread John Soo
Hi Paul And Maxime,

> Even if you didn't succeed at updating _all_ dependencies, if you
> have patches for some of them, please send them.  It will help people
> in the future with updating rust-analyzer or other rust packages.

I had a patchset (here: https://issues.guix.gnu.org/46162) adding rust-analyzer 
and the rest of the other tools that come part of the rust tree. I think it 
would not be too much work to add if added as outputs/companion packages to 
rust itself.

> For many people, a vaguely recent-ish version would be sufficient.  At
> least, that's the case for C, GCC and Clang.
> ...
> It might be possible to do "cargo xtask install --server", but many
> advantages of Guix would be lost.


That worked for me. I was using guix' rust tooling for my job. I much prefer 
using guix over rustup/cargo. I just had to patch rust a lot and my patches 
haven't made it in (yet?).

> Indeed, e.g. it would be nice to figure out how to eliminate #:skip-
> build?, replace #:cargo-inputs by regular inputs, figure out how to
> stop having to package multiple versions of the same package.

My gut feeling is still that the functional package managers need to 
collaborate with the rust/cargo team. Rust itself just does not lend itself 
well to the model.  It is a shame since we share many of the same goals 
(reproducibility and reliability come to the top of mind).

Kindly,

John



Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

2022-04-27 Thread John Soo
Hi Gio!

I am very sorry I have let it slip. If there are patches I need to get to, I 
can put them in to emacs-guix. I believe we should get the savannah version up 
to snuff and use that as the one in guix.

My apologies again. I may be able to look into it this weekend if that's 
alright.

Kindly,

John



Re: Packaging FreeCAD

2019-03-09 Thread John Soo
Hi guix,

Just a quick update. I have little to report on freecad. I am still stuck
packaging pyside2. I have looked over the debian packaging rules but I am
unfamiliar with their packaging process. I did some research and it looks
as though they are using the normal pybuild process with some alterations
to some paths afterward.  The package completely fails to compile for me
and I am no expert on python build tooling. Here's what I have tried so far
and the error: https://paste.debian.net/1072533. Any help would be very
appreciated.

Thanks,

John

On Fri, Feb 15, 2019 at 6:33 PM John Soo  wrote:

> Thanks so much Paul! This is really helpful!
>
> > On Feb 15, 2019, at 9:20 AM, Paul Garlick <
> pgarl...@tourbillion-technology.com> wrote:
> >
> > Hi John,
> >
> >> I have been getting a little stuck building the pyside2 dependencies
> >
> > There has been an effort to package pyside2 for Debian.  This has been
> > completed in the last six months.
> >
> > A good place to look for information is
> > https://tracker.debian.org/pkg/pyside2
> >
> > You can browse the source code and follow the links to the 'debian'
> > directory, which contains the files that govern the packaging process.
> > In general for Debian packages, the 'rules' file is worth reading and
> > the 'patches' directory has the changes to the upstream code.
> >
> > One element that could be important in Guix is an update of patchelf to
> > a recent commit (see 'update-patchelf.patch' in the patches directory).
> >
> > Best regards,
> >
> > Paul.
> >
>


Re: Packaging FreeCAD

2019-03-12 Thread John Soo
Thanks Efraim!

That helped a lot. I Switched to version 5.11.3 and swapped qt for qtbase
and some extra qt libraries and that moved me past the one blocker. Now I
am faced with another challenge. I packaged Shiboken 1 previously when I
did not realize freecad moved to pyside2; in that process I followed the
nix packaging strategy of building all the bundled libraries separately.  I
am now running into the same issues I had prior to splitting up Shiboken 1
while building pyside2. The python build system in pyside2 shells out to
cmake for most of the build process.  That means it does not use
cmake-build-system. Does pyside2 need to be split into parts now? It is
more challenging for pyside2 that Shiboken 1 because the sources for all
the libraries are shipped together.  Here's the source, for reference:
https://code.qt.io/cgit/pyside/pyside-setup.git/

Thank you all,

John

On Sun, Mar 10, 2019 at 7:25 AM Efraim Flashner 
wrote:

> On Sun, Mar 10, 2019 at 02:14:15AM +0000, John Soo wrote:
> > Hi guix,
> >
> > Just a quick update. I have little to report on freecad. I am still stuck
> > packaging pyside2. I have looked over the debian packaging rules but I am
> > unfamiliar with their packaging process. I did some research and it looks
> > as though they are using the normal pybuild process with some alterations
> > to some paths afterward.  The package completely fails to compile for me
> > and I am no expert on python build tooling. Here's what I have tried so
> far
> > and the error: https://paste.debian.net/1072533. Any help would be very
> > appreciated.
> >
> > Thanks,
> >
> > John
> >
> > On Fri, Feb 15, 2019 at 6:33 PM John Soo  wrote:
> >
> > > Thanks so much Paul! This is really helpful!
> > >
> > > > On Feb 15, 2019, at 9:20 AM, Paul Garlick <
> > > pgarl...@tourbillion-technology.com> wrote:
> > > >
> > > > Hi John,
> > > >
> > > >> I have been getting a little stuck building the pyside2 dependencies
> > > >
> > > > There has been an effort to package pyside2 for Debian.  This has
> been
> > > > completed in the last six months.
> > > >
> > > > A good place to look for information is
> > > > https://tracker.debian.org/pkg/pyside2
> > > >
> > > > You can browse the source code and follow the links to the 'debian'
> > > > directory, which contains the files that govern the packaging
> process.
> > > > In general for Debian packages, the 'rules' file is worth reading and
> > > > the 'patches' directory has the changes to the upstream code.
> > > >
> > > > One element that could be important in Guix is an update of patchelf
> to
> > > > a recent commit (see 'update-patchelf.patch' in the patches
> directory).
> > > >
> > > > Best regards,
> > > >
> > > > Paul.
> > > >
> > >
>
> I haven't tried building it myself yet, but two things come to mind:
> Try using qtbase instead of qt, it has a much smaller footprint and will
> likely be requested when it's time to include the package in Guix.
>
> You're using version 5.12.1, and in Guix we have qt 5.11.3. It's likely
> the errors you're getting are because the version of Qt is different.
>
> --
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
>


Packaging for guix

2019-03-27 Thread John Soo
Hello pyside maintainers,

Hope you are all well.  I am looking to package freecad for the guix package 
manager for which pyside is a dependency. I’m having some trouble packaging 
pyside as the build and environment for guix (like nix) are quite different 
from a Debian style system. There a quite a few differences:

 -  the prefix for installation directories is in a unique directory specific 
to the package
 - cmake and python require many particular environment variables and flags
- library and linking paths are very different and often source shebangs and 
linking paths need to be patched to point to the correct paths
 - the build process happens in an isolated build environment apart from any 
system directories
 - probably more that I haven’t come across yet

I’ve tried using the provided python build process but I get several build 
errors, let alone runtime issues. Would anyone be able to point me in a 
direction to patch pyside for such a packaging system? Currently I’m stuck 
building Shiboken. I’d particularly like guidance on how to setup cmake to 
build it correctly (mostly the ability to provide our particular flags and 
variables). Any help would be greatly appreciated.

Thank you,

John


Re: Packaging for guix

2019-03-28 Thread John Soo
Hi Ricardo,

Thanks.  I've been hacking in my channel and master usually has my current
work: https://github.com/jsoo1/guix-channel/blob/master/python-pyside.scm -
current commit is 59f6da3.

Aside
- I would like to patch most of the working and compatible packages in the
channel back into guix, but freecad has been taking all my guix hacking
time.  I've attached the build log since there are some errors building
both the apiextractor package and the shiboken library.  Note that
python-pyside.scm includes work on version 1 of the Shiboken library. That
build seemed ok but freecad is moving to pyside2.  I followed nix's
strategy of building the packages separately and using cmake-build-system
instead of python (
https://github.com/NixOS/nixpkgs/blob/2d656a9729739e8ca5486058a76669d0ea4442df/pkgs/development/python-modules/pyside/shiboken.nix#L33)
for version 1. Pyside 2 is bundled into a single repository so I am not
sure I can do the same thing for it. Thanks again!

- John



On Thu, Mar 28, 2019 at 10:46 AM Ricardo Wurmus  wrote:

> [- pyside]
>
> Hi John,
>
> > I’ve tried using the provided python build process but I get several
> > build errors, let alone runtime issues. Would anyone be able to point
> > me in a direction to patch pyside for such a packaging system?
> > Currently I’m stuck building Shiboken. I’d particularly like guidance
> > on how to setup cmake to build it correctly (mostly the ability to
> > provide our particular flags and variables). Any help would be greatly
> > appreciated.
>
> Could you show us the package definition you have so far?  Can you also
> show us what errors you get?
>
> --
> Ricardo
>
>


p52jx2x4c7s2ybx4mj4gv8m97mnaxr-python-pyside-2-v5.11.3-1.4018787.drv.bz2
Description: Binary data


Re: Software Heritage & Guix

2019-03-29 Thread John Soo
I didn’t even know! That’s so cool.  I love guix! Thanks Ludo!

> On Mar 29, 2019, at 9:05 AM, Ludovic Courtès  wrote:
> 
> Hello!
> 
> I’ve written a post on the Software Heritage support in Guix:
> 
>  
> https://gnu.org/s/guix/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive/
> 
> Happy reading!  :-)
> 
> Ludo’.
> 



Re: Introducing myself

2019-04-18 Thread John Soo
Hi Tanguy,

I just realized you said you wanted an fzf replacement. I recommend fzy. It’s 
not quite as full featured as fzf but it gets the job done. 

- John

> On Apr 18, 2019, at 1:19 PM, Tanguy Le Carrour  wrote:
> 
> (I've just realised that there was a typo in the subject… shame on me!
> … fixed… unfortunately the Internet never forgets!!)
> 
> 
> Le 04/17, Pierre Neidhardt a écrit :
>> Tanguy Le Carrour  writes:
>>> I'll try to package my favourite tools that
>>> are currently missing: ack, fd, fzf, udiskie, poetry, pyenv…
>> 
>> Suggested alternatives:
>> 
>> - ack -> the-silver-searcher (ag)
> 
> Thanks! I came across this one some time ago. This might be the
> perfect time to evaluate/adopt it!
> 
> 
>> - fzf -> Emacs with Ivy or Helm
> 
> arg… this is the much feared moment when I have to confess that I'm…
> a faithful Vim user! ^_^'
> 
> 
>> - udiskie -> See discussion here:
>>  https://lists.gnu.org/archive/html/help-guix/2018-03/msg00331.html.
>>  At some point, we could supersede both udiskie or home-baked scripts
>>  with Guix/Shepherd user services.
> 
> I'm really happy with my Bspwm [1] setup, even if it comes with absolutely no
> removable media management! I used to use `udiskctl`, but I have to
> admit that one quickly gets attached to `udiskie`.
> 
> [1]: https://github.com/baskerville/bspwm
> 
> 
> I guess the real struggle will be replacing dependency management
> in my Python projects. But that's a totally different topic!
> 
> Regards
> 
> -- 
> Tanguy
> 



Re: [PySide] Packaging for guix

2019-04-19 Thread John Soo
Hi Cristián,

Thank you! I have been following the cmake path and it seems to be working
better than before. If I find more issues, I will ask.  Thanks again!

- John

On Wed, Apr 10, 2019 at 9:47 AM Cristián Maureira-Fredes <
cristian.maureira-fre...@qt.io> wrote:

> Hello John,
>
> I'm not familiar with guix, but if the CMake approach doesn't work [1]
> and the setuptools also doesn't work [2],
> maybe you can share some of the logs related the build errors
> so we can see how what's precisely the issue.
>
> Cheers
>
> [1]
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/shiboken2
> [2] https://wiki.qt.io/Qt_for_Python/GettingStarted/X11
> ________
> From: PySide  on behalf of John Soo <
> js...@asu.edu>
> Sent: Thursday, March 28, 2019 06:21
> To: pys...@qt-project.org
> Cc: guix-devel@gnu.org
> Subject: [PySide] Packaging for guix
>
> Hello pyside maintainers,
>
> Hope you are all well.  I am looking to package freecad for the guix
> package manager for which pyside is a dependency. I’m having some trouble
> packaging pyside as the build and environment for guix (like nix) are quite
> different from a Debian style system. There a quite a few differences:
>
>  -  the prefix for installation directories is in a unique directory
> specific to the package
>  - cmake and python require many particular environment variables and flags
> - library and linking paths are very different and often source shebangs
> and linking paths need to be patched to point to the correct paths
>  - the build process happens in an isolated build environment apart from
> any system directories
>  - probably more that I haven’t come across yet
>
> I’ve tried using the provided python build process but I get several build
> errors, let alone runtime issues. Would anyone be able to point me in a
> direction to patch pyside for such a packaging system? Currently I’m stuck
> building Shiboken. I’d particularly like guidance on how to setup cmake to
> build it correctly (mostly the ability to provide our particular flags and
> variables). Any help would be greatly appreciated.
>
> Thank you,
>
> John
> ___
> PySide mailing list
> pys...@qt-project.org
> https://lists.qt-project.org/listinfo/pyside
>


Re: [PySide] Packaging for guix

2019-04-27 Thread John Soo
Hi Cristián and Ricardo,

A quick update: Shiboken2 builds! Thanks for your guidance!  I may have
more questions when building freecad itself, but this was very helpful.
Thanks again!

- John

On Fri, Apr 19, 2019 at 1:06 PM John Soo  wrote:

> Hi Cristián,
>
> Thank you! I have been following the cmake path and it seems to be working
> better than before. If I find more issues, I will ask.  Thanks again!
>
> - John
>
> On Wed, Apr 10, 2019 at 9:47 AM Cristián Maureira-Fredes <
> cristian.maureira-fre...@qt.io> wrote:
>
>> Hello John,
>>
>> I'm not familiar with guix, but if the CMake approach doesn't work [1]
>> and the setuptools also doesn't work [2],
>> maybe you can share some of the logs related the build errors
>> so we can see how what's precisely the issue.
>>
>> Cheers
>>
>> [1]
>> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/shiboken2
>> [2] https://wiki.qt.io/Qt_for_Python/GettingStarted/X11
>> 
>> From: PySide  on behalf of John Soo <
>> js...@asu.edu>
>> Sent: Thursday, March 28, 2019 06:21
>> To: pys...@qt-project.org
>> Cc: guix-devel@gnu.org
>> Subject: [PySide] Packaging for guix
>>
>> Hello pyside maintainers,
>>
>> Hope you are all well.  I am looking to package freecad for the guix
>> package manager for which pyside is a dependency. I’m having some trouble
>> packaging pyside as the build and environment for guix (like nix) are quite
>> different from a Debian style system. There a quite a few differences:
>>
>>  -  the prefix for installation directories is in a unique directory
>> specific to the package
>>  - cmake and python require many particular environment variables and
>> flags
>> - library and linking paths are very different and often source shebangs
>> and linking paths need to be patched to point to the correct paths
>>  - the build process happens in an isolated build environment apart from
>> any system directories
>>  - probably more that I haven’t come across yet
>>
>> I’ve tried using the provided python build process but I get several
>> build errors, let alone runtime issues. Would anyone be able to point me in
>> a direction to patch pyside for such a packaging system? Currently I’m
>> stuck building Shiboken. I’d particularly like guidance on how to setup
>> cmake to build it correctly (mostly the ability to provide our particular
>> flags and variables). Any help would be greatly appreciated.
>>
>> Thank you,
>>
>> John
>> ___
>> PySide mailing list
>> pys...@qt-project.org
>> https://lists.qt-project.org/listinfo/pyside
>>
>


Additional system fonts - Feature request/help request

2019-04-27 Thread John Soo
Hi Guix!

I have been looking into a different TTY font both for fancy glyphs and
unicode support.  I also looked into kmscon for keybindings and additional
fonts, too. I like being able to specify a console font as a service. I
can't use Tamzen, for instance, though, since the console font directory is
only pointing to the store location for the kbd package's fonts (I found
that under man setfont).  Similarly, for kmscon, trying to provide an
additional font for the service fails because no system fonts are
configured for the system profile.  I would like to be able to:
 - provide extra user defined fonts as part of the operating system
configuration, or
 - somehow be able to use more fonts than those that come with kbd and
 - Be able to configure additional fonts for kmscon

How would that be done?

Thanks!

John


Re: [PySide] Packaging for guix

2019-05-03 Thread John Soo
Hi again PySide and Guix maintainers,

Thanks for your help so far. After building Shiboken2, Pyside2 and
PySide2-Tools are still required for FreeCAD. In building Pyside2, I get
the error in the attached paste. Clang 6.0.1 and LLVM 6.0.1 are installed
and I have set the CLANG_INSTALL_DIR and LLVM_INSTALL_DIR vars to their
respective paths.  I have also included the package definition in the paste
for the Guix maintainers, if they have any input.

https://paste.debian.net/1081332/

There also seem to be some more issues finding various extra QT libraries
but I'd like to do one thing at a time.

Thanks again for all your help!

- John

On Sat, Apr 27, 2019 at 3:31 PM John Soo  wrote:

> Hi Cristián and Ricardo,
>
> A quick update: Shiboken2 builds! Thanks for your guidance!  I may have
> more questions when building freecad itself, but this was very helpful.
> Thanks again!
>
> - John
>
> On Fri, Apr 19, 2019 at 1:06 PM John Soo  wrote:
>
>> Hi Cristián,
>>
>> Thank you! I have been following the cmake path and it seems to be
>> working better than before. If I find more issues, I will ask.  Thanks
>> again!
>>
>> - John
>>
>> On Wed, Apr 10, 2019 at 9:47 AM Cristián Maureira-Fredes <
>> cristian.maureira-fre...@qt.io> wrote:
>>
>>> Hello John,
>>>
>>> I'm not familiar with guix, but if the CMake approach doesn't work [1]
>>> and the setuptools also doesn't work [2],
>>> maybe you can share some of the logs related the build errors
>>> so we can see how what's precisely the issue.
>>>
>>> Cheers
>>>
>>> [1]
>>> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/shiboken2
>>> [2] https://wiki.qt.io/Qt_for_Python/GettingStarted/X11
>>> 
>>> From: PySide  on behalf of John Soo <
>>> js...@asu.edu>
>>> Sent: Thursday, March 28, 2019 06:21
>>> To: pys...@qt-project.org
>>> Cc: guix-devel@gnu.org
>>> Subject: [PySide] Packaging for guix
>>>
>>> Hello pyside maintainers,
>>>
>>> Hope you are all well.  I am looking to package freecad for the guix
>>> package manager for which pyside is a dependency. I’m having some trouble
>>> packaging pyside as the build and environment for guix (like nix) are quite
>>> different from a Debian style system. There a quite a few differences:
>>>
>>>  -  the prefix for installation directories is in a unique directory
>>> specific to the package
>>>  - cmake and python require many particular environment variables and
>>> flags
>>> - library and linking paths are very different and often source shebangs
>>> and linking paths need to be patched to point to the correct paths
>>>  - the build process happens in an isolated build environment apart from
>>> any system directories
>>>  - probably more that I haven’t come across yet
>>>
>>> I’ve tried using the provided python build process but I get several
>>> build errors, let alone runtime issues. Would anyone be able to point me in
>>> a direction to patch pyside for such a packaging system? Currently I’m
>>> stuck building Shiboken. I’d particularly like guidance on how to setup
>>> cmake to build it correctly (mostly the ability to provide our particular
>>> flags and variables). Any help would be greatly appreciated.
>>>
>>> Thank you,
>>>
>>> John
>>> ___
>>> PySide mailing list
>>> pys...@qt-project.org
>>> https://lists.qt-project.org/listinfo/pyside
>>>
>>


  1   2   >