Re: i686-linux GCC package on x86_64
Danny Milosavljevic writes:
> On Fri, 04 Oct 2019 17:46:43 +0200
> Jelle Licht wrote:
>
>> Mathieu Othacehe writes:
>>
>> >
>> > --8<---cut here---start->8---
>> > (native-inputs
>> > `(,@(if (not (string-prefix? "i686" (%current-system)))
>> >`(("cross-gcc" ,(cross-gcc "i686-unknown-linux-gnu"))
>> > ("cross-binutils" ,(cross-binutils "i686-unknown-linux-gnu")))
>> >'(
>> > --8<---cut here---end--->8---
>> >
>> > that uses the current gcc if you're already building on an i686 system,
>> > or define and use a cross-gcc targeting i686 systems otherwise.
>>
>> This snippet might make a lot of sense to seasoned schemers/guixfolk,
>
> Basically just ignore the birdshit characters to understand what it does :)
>
> The first unquote is to evaluate (%current-system) at the toplevel which is
> what interprets the package definitions in the first place.
>
> "`(,@" is a no-op. Not sure why it's written like that.
>
>>`(("cross-gcc" ,(cross-gcc "i686-unknown-linux-gnu"))
>> ("cross-binutils" ,(cross-binutils "i686-unknown-linux-gnu")))
>
> is like we always write inputs, but it's calling the "cross-gcc" function in
> the
> toplevel in order to get the package to use.
Perhaps it's because of the "if" expression.
>> with the multiple levels of (un)quoting and what not. It does not seem
>> like what somebody with little experience in either would think of by
>> themselves.
>>
>> Would it make sense to have a section/stub in the cookbook about cross
>> compilation?
>
> I don't think that cross-gcc is stable API that much--and it's not
> common that you need it anyway. A normal user just cross compiles
> by using
>
>guix build --target=i686-linux pkg
>
> or better yet, uses qemu to natively compile it for a foreign system
>
>guix build --system=i686-linux pkg
>
> .
>
> The above is only necessary when for some reason your package has
> parts which only compile on one system and other parts which only
> compile on another system--that's very rare.
>
> Nowadays, packages are supposed to be cross-platform, so using cross-gcc
> directly is unnecessary, too.
>
> Right now cross-gcc is not documented, so I guess that counts as
> "not a public interface".
Yeah. I'm inclined to agree with Danny. With Guix, it is best to
cross-compile in the way Danny is suggesting. If there are projects
that require other tricks to cross-compile, perhaps they would be
interesting to discuss. I feel like there may be a lot of "quick and
dirty" projects with non-standard build logic that can't easily be
packaged into Guix for cross-compilation.
That said, I am curious about something. If I want to make a
cross-compiler available for the purpose of hacking around on some code
and cross-compiling it, is there an equivalent to "guix package -i
gcc-toolchain" which will give me a cross-compilation toolchain? My
feeling was that Guix can create cross-compilation toolchains on demand,
but there is no UI exposed for making it available via a guix command,
since people are encouraged to just ask for the cross-built product.
--
Chris
signature.asc
Description: PGP signature
Re: Racket packages: formerly Move DrRacket to a separate output?
Christopher Lemmer Webber writes: > I think nobody has written a Racket importer. I have it as a > longstanding background TODO task but clearly haven't found the > time... despite the fact that I desperately want the feature. I could start working on this, starting tomorrow. I will need a bit of guidance though, shall I open a new thread or use this one?
Re: I don't understand the Curiass WebUI
On Wed, 2 Oct 2019 15:24:26 +0200 Hartmut Goebel wrote: > This would be helpful, esp. if it is placed somewhat prominently. > Another possibility would be improve the search-filters. You probably want something like this: python-sphinx system:x86_64-linux spec:guix-master I was also struggling, but Ricardo showed me this trick. There is much room to improve Cuirass :-) An aggregate view would be really nice. Björn pgpQAugVWsFry.pgp Description: OpenPGP digital signature
Re: Racket packages: formerly Move DrRacket to a separate output?
On Fri, Oct 04, 2019 at 03:23:18PM -0400, Christopher Lemmer Webber wrote: > I think nobody has written a Racket importer. I have it as a > longstanding background TODO task but clearly haven't found the > time... despite the fact that I desperately want the feature. > > I'm just desperate for a lot of things right now! ;) maybe it is a good fosdem hacking project.
Re: Racket packages: formerly Move DrRacket to a separate output?
I think nobody has written a Racket importer. I have it as a longstanding background TODO task but clearly haven't found the time... despite the fact that I desperately want the feature. I'm just desperate for a lot of things right now! ;) - Chris Pjotr Prins writes: > What is the status of creating Racket packages. For a REST API server > I have two dependencies: > > : raco pkg install https://github.com/dmac/spin.git > : raco pkg install https://github.com/BourgondAries/memo.git > > what is the recommended way of packaging them in GNU Guix? > > Pj. > > On Fri, Sep 14, 2018 at 01:44:37PM -0400, Christopher Lemmer Webber wrote: >> Ludovic Courtès writes: >> >> > Hello Pierre, >> > >> > Pierre Neidhardt skribis: >> > >> >> Wouldn't it make sense to move DrRacket to a separate output? I take >> >> that most advanced users use something else (who said Emacs?) and >> >> DrRacket might eat up a decent amount of disk space + extra dependencies >> >> by itself. >> > >> > I don’t think it’s a matter of being an “advanced” user or not (DrRacket >> > is really impressive, with a macro stepper and all sorts of bells and >> > whistles), but I agree with the rationale. :-) >> > >> >> Arch Linux provides racket and racket-minimal: the latter is stripped >> >> from DrRacket: >> >> >> >> https://www.archlinux.org/packages/?q=racket >> > >> > Such a split sounds good to me. What do Chris and other Racketeers >> > think? >> > >> > Cheers, >> > Ludo’. >> >> I'm ok with splitting out racket-minimal and racket, which is a common >> convention these days... even Racket's download page provides "Racket" >> and "Minimal Racket": >> >> https://download.racket-lang.org/ >> >> I'd take the least effort route to doing that though... we aren't ready >> to break each of the Racket "core" packages into their own packages and >> I don't think that would need to hold this back. >> >> - Chris >> >> >>
Re: New outreachy participant introduction
Hi Nardos, nice to meet you! Sorry I couldn't answer sooner. My server was having a bit of troubles and I only received your mail now. It should be fine from now on. I think Gábor already answered your questions nicely, and I have nothing to add. I'd like to encourage you to join our irc at #guix on freenode to meet everyone. If you have any question regarding the process of packaging or about the proposed internships, do not hesitate to ask them here or on IRC. Even if when mentors are not available, others may have answers for you ;) Thank you, Julien Le 3 octobre 2019 18:11:58 GMT+02:00, "Asfaw, Nardos" a écrit : >Hello Guix! > >My name is Nardos, and I am an Outreachy participant from Indiana >University, Bloomington. I am a first time open source contributor >hopeful. I am excite to be here, but I will admit I am also a little >nervous. I welcome feedback as I am here to learn from all of you. I >can be reached at nas...@iu.edu or www.nardos.dev > >I also have a few questions: > >1. I am opting to run Guix in a virtual machine on a kali linux. I >have found this resource: >https://guix.gnu.org/manual/en/html_node/Running-Guix-in-a-VM.html#Running-Guix-in-a-VM. >Given your experience, would this cause a problem down the line? Any >recommendation on running Guix in a virtual machine vs on my PC? > >2. Upon making contributions, where is it posted? and how do I see >feedbacks? I have seen lists of open projects and discussion treads >such as this (https://issues.guix.gnu.org/issue/22138) on the Guix >patch tracker. Are these the issues we currently working on? > > >3. Any beginner tips? and a good place to start? > > >I look forward to working with you all. > > >Thanks, > >Nardos
Re: i686-linux GCC package on x86_64
Hi,
On Fri, 04 Oct 2019 17:46:43 +0200
Jelle Licht wrote:
> Mathieu Othacehe writes:
>
> >
> > --8<---cut here---start->8---
> > (native-inputs
> > `(,@(if (not (string-prefix? "i686" (%current-system)))
> >`(("cross-gcc" ,(cross-gcc "i686-unknown-linux-gnu"))
> > ("cross-binutils" ,(cross-binutils "i686-unknown-linux-gnu")))
> >'(
> > --8<---cut here---end--->8---
> >
> > that uses the current gcc if you're already building on an i686 system,
> > or define and use a cross-gcc targeting i686 systems otherwise.
>
> This snippet might make a lot of sense to seasoned schemers/guixfolk,
Basically just ignore the birdshit characters to understand what it does :)
The first unquote is to evaluate (%current-system) at the toplevel which is
what interprets the package definitions in the first place.
"`(,@" is a no-op. Not sure why it's written like that.
>`(("cross-gcc" ,(cross-gcc "i686-unknown-linux-gnu"))
> ("cross-binutils" ,(cross-binutils "i686-unknown-linux-gnu")))
is like we always write inputs, but it's calling the "cross-gcc" function in the
toplevel in order to get the package to use.
> with the multiple levels of (un)quoting and what not. It does not seem
> like what somebody with little experience in either would think of by
> themselves.
>
> Would it make sense to have a section/stub in the cookbook about cross
> compilation?
I don't think that cross-gcc is stable API that much--and it's not
common that you need it anyway. A normal user just cross compiles
by using
guix build --target=i686-linux pkg
or better yet, uses qemu to natively compile it for a foreign system
guix build --system=i686-linux pkg
.
The above is only necessary when for some reason your package has
parts which only compile on one system and other parts which only
compile on another system--that's very rare.
Nowadays, packages are supposed to be cross-platform, so using cross-gcc
directly is unnecessary, too.
Right now cross-gcc is not documented, so I guess that counts as
"not a public interface".
pgpytuANZ3Zql.pgp
Description: OpenPGP digital signature
Racket packages: formerly Move DrRacket to a separate output?
What is the status of creating Racket packages. For a REST API server I have two dependencies: : raco pkg install https://github.com/dmac/spin.git : raco pkg install https://github.com/BourgondAries/memo.git what is the recommended way of packaging them in GNU Guix? Pj. On Fri, Sep 14, 2018 at 01:44:37PM -0400, Christopher Lemmer Webber wrote: > Ludovic Courtès writes: > > > Hello Pierre, > > > > Pierre Neidhardt skribis: > > > >> Wouldn't it make sense to move DrRacket to a separate output? I take > >> that most advanced users use something else (who said Emacs?) and > >> DrRacket might eat up a decent amount of disk space + extra dependencies > >> by itself. > > > > I don’t think it’s a matter of being an “advanced” user or not (DrRacket > > is really impressive, with a macro stepper and all sorts of bells and > > whistles), but I agree with the rationale. :-) > > > >> Arch Linux provides racket and racket-minimal: the latter is stripped > >> from DrRacket: > >> > >>https://www.archlinux.org/packages/?q=racket > > > > Such a split sounds good to me. What do Chris and other Racketeers > > think? > > > > Cheers, > > Ludo’. > > I'm ok with splitting out racket-minimal and racket, which is a common > convention these days... even Racket's download page provides "Racket" > and "Minimal Racket": > > https://download.racket-lang.org/ > > I'd take the least effort route to doing that though... we aren't ready > to break each of the Racket "core" packages into their own packages and > I don't think that would need to hold this back. > > - Chris > > >
Re: i686-linux GCC package on x86_64
Mathieu Othacehe writes:
>
> --8<---cut here---start->8---
> (native-inputs
> `(,@(if (not (string-prefix? "i686" (%current-system)))
>`(("cross-gcc" ,(cross-gcc "i686-unknown-linux-gnu"))
> ("cross-binutils" ,(cross-binutils "i686-unknown-linux-gnu")))
>'(
> --8<---cut here---end--->8---
>
> that uses the current gcc if you're already building on an i686 system,
> or define and use a cross-gcc targeting i686 systems otherwise.
This snippet might make a lot of sense to seasoned schemers/guixfolk,
with the multiple levels of (un)quoting and what not. It does not seem
like what somebody with little experience in either would think of by
themselves.
Would it make sense to have a section/stub in the cookbook about cross
compilation?
- Jelle
Re: i686-linux GCC package on x86_64
> Works for me to, but I'd like to write a package that depends on GCC
> i686-linux.
You mean a package that uses a compiler able to generate code for
i686-linux? In that case you can have a look to (gnu packages firmware),
where "cross-gcc" packages are used (ovmf-aarch64 package for instance).
You would have to write something like:
--8<---cut here---start->8---
(native-inputs
`(,@(if (not (string-prefix? "i686" (%current-system)))
`(("cross-gcc" ,(cross-gcc "i686-unknown-linux-gnu"))
("cross-binutils" ,(cross-binutils "i686-unknown-linux-gnu")))
'(
--8<---cut here---end--->8---
that uses the current gcc if you're already building on an i686 system,
or define and use a cross-gcc targeting i686 systems otherwise.
Mathieu
Re: irc log hosting questions (with GNUnet eV hat on)
Hi ng0, > I've just asked Ludovic about the possibility to host our 3 IRC channel logs > (libmicrohttpd, gnunet, taler). […] > Are there any other requirements from our side we would have to fullfil (for > current logs) > in case you agree to host the logs? I had to convert the logs from the SQL dump, which was a little painful. We’re now using whatever happens to be the format that ZNC produces. > What would be the requirements if we would decide to convert our old logs to > the log format > used by your logging? I would advise against using the Guix project’s logging solution, because it really isn’t very reliable. It’s literally just a ZNC process with the default log plugin enabled. There’s no proper service for it; the thing is just started manually. The log viewer is primitive: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/goggles.scm For us it’s worth doing this in spite of all this because the logs are stored on our servers. This is pretty much the only advantage to us. If you don’t mind having the logs stored elsewhere there certainly exist better solutions than our chewing gum + duct tape contraption. -- Ricardo
irc log hosting questions (with GNUnet eV hat on)
Hi, I've just asked Ludovic about the possibility to host our 3 IRC channel logs (libmicrohttpd, gnunet, taler). We'd like to talk about this in our next GNUnet team call, which is scheduled for 2019-10-10. Ideally we can get the okay about this (that it would be doable) before the 10th, so that I can talk in detail about this proposal (and point to this thread). Are there any other requirements from our side we would have to fullfil (for current logs) in case you agree to host the logs? What would be the requirements if we would decide to convert our old logs to the log format used by your logging? Furthwermore, I'd like to apologize again for how the logs were handled the past 12 months. Reasoning about why this happened would be too long, just a series of too many bad coincidences and volunteering work. Cheers, ng0 signature.asc Description: PGP signature
Re: i686-linux GCC package on x86_64
Hello Pierre, >> guix build --system=i686-linux -e '(@@ (gnu packages gcc) gcc)' >> >> produces a hash error.) >> >> Any clue? > > Friendly ping! :) > > Mathieu, I think you've got experience with cross-compilation on Guix, > any clue about this? I think the gcc packages defined in (gnu packages gcc) are not meant for users. Instead running: --8<---cut here---start->8--- guix build --system=i686-linux gcc-toolchain --8<---cut here---end--->8--- works for me. Mathieu
