GDM and Wayland
Hello Guix! When I was reviewing guix manual, it was mentioned that only gnome has support for wayland. I was wondering why gdm is not showing option to start gnome session using wayland? gdm is part of gnome correct? Regards, RG. signature.asc Description: This is a digitally signed message part
Re: Python package naming: Dots vs hyphens
On Wed, Nov 06, 2019 at 07:49:56AM +0100, pelzflorian (Florian Pelz) wrote: > Shall I rename python-zope-* to python-zope.*? > For new packages I would use whatever upstream uses in regard to '-' vs '.'. For existing ones, how many are there? It might be best to just leave them as-is rather than go through the dance of deprecating the old packages. > I am in the process of packaging mailman 3 which according to the pypi > importer needs packages like > > python-flufl.bounce > python-flufl.i18n > python-flufl.lock > python-lazr.config > python-lazr.delegates > python-zope.component > python-zope.configuration > python-zope.configuration > python-zope.event > python-zope.interface > I've actually last week started working on that. I've only done the python part, haven't searched for any javascript or font-awesome which I'm pretty sure I saw. I've also started working on a service for it which I haven't committed yet, but it looks like it's going to be complex. https://gitlab.com/genenetwork/guix-bioinformatics/blob/master/gn/packages/mailman.scm > > However the zope ones have already been added since 2fc5f186801, but > with a hyphen instead of a dot. Which one is correct? Shall I rename > python-zope-* to python-zope.*? Or shall I correct the pypi importer? > Ignore it? > 'guix package -A python-zope' lists them all as having a dash, I'd just go ahead and make them all dashes. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Python package naming: Dots vs hyphens
Shall I rename python-zope-* to python-zope.*? I am in the process of packaging mailman 3 which according to the pypi importer needs packages like python-flufl.bounce python-flufl.i18n python-flufl.lock python-lazr.config python-lazr.delegates python-zope.component python-zope.configuration python-zope.configuration python-zope.event python-zope.interface However the zope ones have already been added since 2fc5f186801, but with a hyphen instead of a dot. Which one is correct? Shall I rename python-zope-* to python-zope.*? Or shall I correct the pypi importer? Ignore it? Regards, Florian
Re: guix pull failed after 8 hours
Hi Giovanni and everyone, Giovanni Biscuolo writes: > Chris Marusich writes: > > [...] > >> Has anyone run "guix pull" successfully recently? I have been trying >> for days without success. > > I was also able to run guix pull on a foreign system a few hours ago and > on a Guix System a few minutes ago > > do you still have problems? After a few more tries (each of which took multiple hours to fail), it finally succeeded. I guess I just got very unlucky. I've been updating some systems with a fairly old version of Guix, so perhaps that contributed to the very long "guix pull" times. It felt like Guix wanted to compile the whole world just to run "guix pull". Anyway, it's succeeded, so please disregard my original message. Thank you for all your responses! -- Chris signature.asc Description: PGP signature
Re: 'core-updates' Q4 2019
Miguel Arruga Vivas writes: > Hi Kei, > > Kei Kebreau writes: >> Update: Please check out the new wip-gnome-updates branch of the Guix >> git repository for continued updates. The contents of the notabug.org >> link given above will be changed to a notice that says to do this. > > Thank you very much for this huge effort. I've been playing with the > branch and I have a working system, both X11 with GDM and Wayland with > SDDM (I haven't tried hard enough to set up gdm with wayland as only a > change to gdm-configuration doesn't seem to have any effect) and your > branch works great on my machine, do you still have the issue during > boot? I haven't found any (new) problem on the applications I've > tested (x86_64, normal use with almost all of the gnome applications, > not the games though.) > Boot and login worked properly for me after I cleared the contents of my /var/lib/gdm directory (if it's unclear why that directory matters, see https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00421.html for a quick overview). > Nevertheless, I've been reading the patches and I have a couple of > comments about them: > > - The patch for libdazzle only changes the xorg-server, as it already >is at version 3.33.90 in master. It still makes sense as a patch, >but the title indicates a version downgrade. > Good catch! I'd correct this commit message, but I don't know what the rules are for rewriting commit history on Guix WIP branches. For now I'll note your comment and leave the message alone. > - The patch for gedit contains a reference to libgd, wouldn't it be >clearer for the reader/updater to have it defined in a let over the >package definition and use the name in native-inputs? > I'm not sure. I don't know if there is an explicit convention for packaging software that is distributed like this, and the examples of this in the code base (that I've seen, at least) define the third-party library the way I've done it here. I'm open to change on this point though. > - Is there any reason to not patch-out the gtk-icon-update-cache >invocations? If I understand it correctly, this is performed at >profile level, so makes no sense creating a cache at package level, >isn't it? The patches for quadrapassel, gnome-klotski, ghex, >gnome-sudoku, gnome-mines, five-or-more and gedit contain references >to it. Maybe creating a package like xorg-server-for-tests >(perhaps 'gtk-bin-for-build'?) linked to "true" from coreutils would >help in the long term. > I don't think such a reason exists. I could add changes that substitute calls to "gtk-icon-update-cache" with "true" for these packages, but I agree that a better solution may be possible. Perhaps not a package; maybe a new 'patch-gtk-icon-update-cache' phase in the relevant build systems? > As a final comment, the gnome release cycle and the amount of packages > involved is quite big, so again, thank you. > > Happy hacking! > Miguel Thanks Miguel! This comment and review means a lot! Kei
Re: “Guix Profiles in Practice”
Hey Pierre, On Mon, Nov 04 2019, Pierre Neidhardt wrote: As I understand it, the current discussion is about "pinning" profiles. Should any dependency get garbage collected, an environment will need Internet access to refetch the missing parts; I think this is what we are trying to avoid, regardless of how fast `guix environment` is. What about `guix environment --pin` instead of `guix develop`? Have you used `guix environment --root`? In my git checkout of the Guix repository I once ran `guix environment guix --root=.environment`, and now whenever I want to hack on Guix I start a shell and `source .environment/etc/profile`. The .environment symlink is treated as a GC root by Guix, and because I'm not actually invoking Guix there's never a risk that it will attempt to fetch anything from the internet. Upgrading the environment is quite easy, and must be done manually: I delete the existing symlink and run `guix environment guix --root=.environment` again. If I'm feeling paranoid I'll run `guix environment guix` once first to make sure it succeeds, before deleting the old symlink and adding the `--root=.environment` to the end. Carlo
Re: Packaging Jami progress
Hello,
Jan Wielkiewicz ezt írta (időpont:
2019. nov. 5., Ke 17:50):
> Dnia 2019-11-04, o godz. 23:48:00
> Gábor Boskovits napisał(a):
>
> > Hello,
> >
> > This is most probably because fmt is missing from inputs.
> > > This is because SObjectizer is missing from inputs.
> > You can get further info about this in the cmake file:
> > https://github.com/Stiffstream/restinio/blob/master/dev/CMakeLists.txt
>
> I packaged SObjectizer and placed it in the gnu/packages/cpp.scm file.
> I also added SObjectizer and fmt as inputs, but the result is the same,
> even though I tried removing commands, which add the subdirectories
> from CMakeLists.txt. What's the proper way of dealing with situations
> like this? Am I missing something important? Should I copy outputs of
> fmt and sobjectizer into the directories? If so, how can I do this?
>
The inputs should be detected by cmake, and subdirs should only be used if
not found. You could add a phase with copy-recursive if needed. I am not
sure that we can't just simply copy the header into the output, but it's
true that we would lose the tests then.
>
> (add-after 'unpack 'do-not-make-directories
> (lambda _
>(substitute* "dev/CMakeLists.txt"
> (("add_subdirectory(fmt)")
> "") (("add_subdirectory(so_5)") ""))
>#t))
>
> >
> > This does not seem the upstream repo. Could you change it to the
> > upstream one? (Albeit, it seems to be an official mirror.)
> > (https://bitbucket.org/sobjectizerteam/restinio/src/default/)
> > Or if there is a tarball available for the needed version, that would
> > be even better (
> >
> > https://bitbucket.org/sobjectizerteam/restinio/downloads/), but I
> > don't know if these archives are stable.
>
> On the website, they say the software is hosted on github:
> https://stiffstream.com/en/products/restinio.html
Nice... and in the documentation section on the same site they say the
mercurial repository is the upstream, and the github one is the mirror...
>
>
> Also AFAIK git is always reproducible, whereas tarballs can get
> rebuilt, so fetching using git is safer.
>
>
> Jan Wielkiewicz
>
Best regards, g_bor
>
Re: "jar" tool and and reproducible builds - how?
Hello, Danny Milosavljevic ezt írta (időpont: 2019. nov. 5., Ke 16:09): > Hi Gábor, > > > This looks like a jar timestamps issue. Adding a phase similar to > > strip-jar-timestamps in ant-build-system should work. > > It extracts the jar to a temporary directory, resets file timestamps, and > > then repacks it, and resets the timestamp on the archive. > > Could you check if that works for you? > > Yes, the following works and makes it reproducible: > > (arguments > `(#:imported-modules >((guix build utils) > (guix build ant-build-system) > (guix build gremlin) > (guix build syscalls) > (guix elf) > (guix build gnu-build-system)) >#:phases >(modify-phases %standard-phases > (add-after 'install 'strip-jar-timestamps >(assoc-ref (@ (guix build ant-build-system) %standard-phases) > 'strip-jar-timestamps) > That is great. > > But I'd prefer if our "jar" tool did that on its own if SOURCE_DATE_EPOCH > is set--I don't think the code above is maintainable. > Agreed. Could you open a wishlist bug for that, so it is not forgotten. > > The following code does not work (doesn't find ant-build-system): > > (arguments > `(#:modules >((guix build gnu-build-system) > ((guix build ant-build-system) #:prefix ant:) > (guix build utils)) >#:phases >(modify-phases %standard-phases > (add-after 'install 'strip-jar-timestamps >(assoc-ref ant:%standard-phases 'strip-jar-timestamps) > I believe this strip-jar-timestamps code should be moved to the java utils module, so that it can be easier to reuse... Best regards,g_bor >
Re: Packaging Jami progress
Dnia 2019-11-04, o godz. 23:48:00
Gábor Boskovits napisał(a):
> Hello,
>
> This is most probably because fmt is missing from inputs.
> > This is because SObjectizer is missing from inputs.
> You can get further info about this in the cmake file:
> https://github.com/Stiffstream/restinio/blob/master/dev/CMakeLists.txt
I packaged SObjectizer and placed it in the gnu/packages/cpp.scm file.
I also added SObjectizer and fmt as inputs, but the result is the same,
even though I tried removing commands, which add the subdirectories
from CMakeLists.txt. What's the proper way of dealing with situations
like this? Am I missing something important? Should I copy outputs of
fmt and sobjectizer into the directories? If so, how can I do this?
(add-after 'unpack 'do-not-make-directories
(lambda _
(substitute* "dev/CMakeLists.txt"
(("add_subdirectory(fmt)")
"") (("add_subdirectory(so_5)") ""))
#t))
>
> This does not seem the upstream repo. Could you change it to the
> upstream one? (Albeit, it seems to be an official mirror.)
> (https://bitbucket.org/sobjectizerteam/restinio/src/default/)
> Or if there is a tarball available for the needed version, that would
> be even better (
>
> https://bitbucket.org/sobjectizerteam/restinio/downloads/), but I
> don't know if these archives are stable.
On the website, they say the software is hosted on github:
https://stiffstream.com/en/products/restinio.html
Also AFAIK git is always reproducible, whereas tarballs can get
rebuilt, so fetching using git is safer.
Jan Wielkiewicz
Re: guix pull failed after 8 hours
Chris Marusich writes: [...] > Has anyone run "guix pull" successfully recently? I have been trying > for days without success. I was also able to run guix pull on a foreign system a few hours ago and on a Guix System a few minutes ago do you still have problems? Ciao, Gio'. -- Giovanni Biscuolo Xelera IT Infrastructures
Re: Publishing news about Guix on a weekly basis
Hi, To complement, some monthly information about debbugs should be nice too; maybe provided by Mumi. Some time ago [1] Pjotr proposed something like: --8<---cut here---start->8--- Summary Status 31 Outstanding 18 Resolved Severity 49 Normal bugs Classification 22 Patch Available 9 Unclassified Patches older than 1 week: gnu: mumble: Build with 'murmur' server component. Modified 13 days ago; gnu: Add blists.Modified 13 days ago; gnu: Add lush2. Modified 13 days ago; etc. --8<---cut here---end--->8--- And maybe - 5 pointers to easy bugs - 5 pointer to long standing bugs etc. All the best, simon [1] https://lists.gnu.org/archive/html/guix-devel/2017-02/msg01139.html
Re: Profiles/manifests-related command line interface enhancements
Hi Simon, > I am not sure to see which feature is missing. My main point is that the future evolution of functionality (and user interfaces) in this space should take into account usage scenarii, rather than adding features in an ad-hoc fashion. I can of course share a manifest file by putting it in a public repository. But that isn't necessarily the best way. Take the typical example from Docker tutorials: bundling a Web server with some Web application and a database. It's easy to make a manifest file for collecting the required packages. But it would make more sense to me to have a module in a Guix channel that defines a parametrizable super-package for the Web application that has no source code of its own but various inputs and perhaps configuration files. Users can then install several Web apps bundled in this fashion, sharing the Web server. This kind of composition is not possible (currently) with manifest files. > From my point of view, ephemeral (environment) vs persistent (profile) > depends on use-case but at the end the only concern is: how to > populate them? And the only answer should be: declarative (manifest); > the ad-hoc (package -i) should not be the usual way but only a > quick test. I agree. So maybe each profile should have an associated manifest file, with "guix install" merely adding to it and the updating the profile. But then it would make sense for guix to manage manifest files in git repositories by default, to encourage good habits. >> This third dimension also >> raises the question of where the information (profiles, manifests, ...) >> are stored and managed (version control?), > > Profiles are managed by Guix, isn't it? Sure, but how exactly? Right now, a profile is a directory anywhere in the file system that Guix knows about. Recent discussions have proposed alternatives, such as keeping all of a user's profile in some directory defined by convention and referring to them by name. What's the better way to use as a default? I don't know, but I think we should discuss it rather than adding new sub-commands with different behavior and thus adding to the mess. > Manifests are managed by the user. And they does what they wants. ;-) True again, but again, is that the best way to do it? Cheers, Konrad.
Re: Profiles/manifests-related command line interface enhancements
Hi Konrad, On Tue, 5 Nov 2019 at 07:27, Konrad Hinsen wrote: > two dimensions I mentioned, this should include shareable/re-usable > vs. personal. People publish and share Docker images, so why wouldn't > they publish and share Guix super-packages? I am not sure to see which feature is missing. - Channels allow to share package definition; - Publish allows to share pre-built binaries; - Pack allows to share images. So what should be missing should be a central server collecting all to ease, à la DockerHub. >From my point of view, ephemeral (environment) vs persistent (profile) depends on use-case but at the end the only concern is: how to populate them? And the only answer should be: declarative (manifest); the ad-hoc (package -i) should not be the usual way but only a quick test. Therefore ephemeral (environment) vs persistent (package --profile) should be compliant. Especially about composition. However, as discussed elsewhere about manifest and the time-machine patch -- I have not tried yet --, the manifest file perhaps needs more fine control to better describe the channels, substitutes etc.. > This third dimension also > raises the question of where the information (profiles, manifests, ...) > are stored and managed (version control?), Profiles are managed by Guix, isn't it? I mean their information are in generations, from my understanding. Manifests are managed by the user. And they does what they wants. ;-) > and how they are referred to > (name, filename, ...). Do you mean that guix environment -m https://example.com/my-manifest.scm should be possible? All the best, simon
Re: Packaging "single file"
On Tue, 5 Nov 2019, Tanguy Le Carrour wrote: Le 11/04, Jack Hill a écrit : Does this help? It's a perfect example! Thanks! I'll do the same for rofi-pass! Yay, you're welcome. Unfortunatly, I don't have the experience with web testing to be helpful there. Best, Jack
Re: "jar" tool and and reproducible builds - how?
Hi Gábor, > This looks like a jar timestamps issue. Adding a phase similar to > strip-jar-timestamps in ant-build-system should work. > It extracts the jar to a temporary directory, resets file timestamps, and > then repacks it, and resets the timestamp on the archive. > Could you check if that works for you? Yes, the following works and makes it reproducible: (arguments `(#:imported-modules ((guix build utils) (guix build ant-build-system) (guix build gremlin) (guix build syscalls) (guix elf) (guix build gnu-build-system)) #:phases (modify-phases %standard-phases (add-after 'install 'strip-jar-timestamps (assoc-ref (@ (guix build ant-build-system) %standard-phases) 'strip-jar-timestamps) But I'd prefer if our "jar" tool did that on its own if SOURCE_DATE_EPOCH is set--I don't think the code above is maintainable. The following code does not work (doesn't find ant-build-system): (arguments `(#:modules ((guix build gnu-build-system) ((guix build ant-build-system) #:prefix ant:) (guix build utils)) #:phases (modify-phases %standard-phases (add-after 'install 'strip-jar-timestamps (assoc-ref ant:%standard-phases 'strip-jar-timestamps) pgpmZ3w1mmzXx.pgp Description: OpenPGP digital signature
Re: Packaging "single file"
Hi Jack!
Le 11/04, Jack Hill a écrit :
> On Mon, 4 Nov 2019, Tanguy Le Carrour wrote:
> > I intended to ask this question later, but now that ungoogled-chromium
> > has been superseded by icecat, I find myself stuck!
> >
> > Is it possible to package a single file? The "file" being a bash script or
> > a binary. Is there a package definition I can look into for an example?
>
> I've had a need to package a bash wrapper around scp, and the module with it
> is below. It it, I use the trivial-build-system, and replaced occurrences of
> commands the script calls with full store paths.
>
> Does this help?
It's a perfect example! Thanks! I'll do the same for rofi-pass!
> Where are you getting stuck?
I'm stuck with my UI tests! :-(
I was relying on `chromedriver` (packaged with ungoogled-chromium), but now
that it's been deprecated… I'm stuck! ^_^'
`geckodriver` is not packaged with icecat. This is why I wanted to a)
download it or b) package it.
The problem is that a) the version I download does not work (a problem
specific to Guix System, I guess, that would be solved by packaging…
another wild guess) and b) it's a bit of work to package.
But, all of sudden, I wonder if `geckodriver` could not be part of
icecat, like `chromedriver` was part of ungoogled-chromium?!
> (define-module (guix-at-duke packages utils)
> #:use-module (gnu packages bash)
> #:use-module (gnu packages ssh)
> #:use-module (guix build-system trivial)
> #:use-module (guix download)
> #:use-module ((guix licenses) #:prefix license:)
> #:use-module (guix packages))
>
> (define-public duo-scp
> (package
>(name "duo-scp")
>(version "0")
>(source
> (origin
> (method url-fetch)
> (uri "https://gitlab.oit.duke.edu/snippets/82/raw;)
> (sha256
> (base32 "1mrf5451cj8010iq76866dli1hxa31rk8i993arf9dfyzws26v2b"))
> (file-name name)))
>(build-system trivial-build-system)
>(arguments
> `(#:modules ((guix build utils))
> #:builder
> (begin
> (use-modules (guix build utils))
> (let ((source (assoc-ref %build-inputs "source"))
> (ssh (assoc-ref %build-inputs "openssh"))
> (bash (assoc-ref %build-inputs "bash"))
> (script "duo-scp")
> (out (assoc-ref %outputs "out")))
> (copy-file source script)
> (substitute* script
> (("/bin/bash") (string-append bash "/bin/bash"))
> (("scp") (string-append ssh "/bin/scp")))
> (chmod script #o555)
> (install-file script (string-append out "/bin"))
>(inputs
> `(("bash" ,bash)
> ("openssh" ,openssh)))
>(home-page "https://gitlab.oit.duke.edu/snippets/82/raw;)
>(synopsis "User Duo Passcode with scp and login_duo")
>(description "Wrapper script for scp that prompts for a passcode
> before calling scp. This allows the user to supply a passcode from e.g. a
> Yubikey
> to avoid getting a Duo push or phone call when talking to an ssh server that
> uses
> the login_duo script for multifactor.")
>(license license:cc0)))
Thanks again for the snippet!
--
Tanguy
Re: Publishing news about Guix on a weekly basis
On Tue, Nov 05, 2019 at 08:36:46AM +, Christopher Baines wrote: > > Not only good for humans, also good for search engines. I find the > > current package list https://guix.gnu.org/packages/ pretty useful, but > > I would like a search function because one keeps clicking to find a > > certain package. > > So as Pierre points out, there is the Guix-HPC package search. The Guix > Data Service also contains a search function (e.g. [3]). > > 3: > http://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/packages A typical user won't find that. > If there's a need to keep the website as static content, maybe the > JavaScript approach used by the Guix-HPC site could be used on the Guix > Website. It should also be possible to use the Guix Data Service > information for a search feature. > > Otherwise, maybe there could be a search box on the Guix Website, but it > links to packages.guix.gnu.org, which is a package search service (which > doesn't have to be part of the static website). > > > May also be an idea to provide links throught the guix CLI, such as > > > > https://guix.gnu.org/packages/alsa-lib-1.1.9/ > > What were you thinking people might use this for? Speaking for myself: I would use it to go to CI. We do have additional information in that way. But yeah. Pj.
Re: "jar" tool and and reproducible builds - how?
Hello, Danny Milosavljevic ezt írta (időpont: 2019. nov. 5., K, 10:49): > Hi Gábor, > > > What diff remains there? There might be more jars or jmods inside... > > Most of the trickery should be in ant build system. > > This package does not use ant-build-system or any other java build system > since > there are only very few Java tools in nesc (I'm thinking of disabling > those, > too). > > diffoscope states only the following, via "zipinfo -v" on > "lib/ncc/nesc.jar": > > - file last modified on (DOS date/time): 2019 Nov 4 17:10:26 > + file last modified on (DOS date/time): 2019 Nov 4 17:10:56 > This looks like a jar timestamps issue. Adding a phase similar to strip-jar-timestamps in ant-build-system should work. It extracts the jar to a temporary directory, resets file timestamps, and then repacks it, and resets the timestamp on the archive. Could you check if that works for you? > > It's repeated a lot of times. > > No other files but "lib/ncc/nesc.jar" are affected. > apply git send email > > I don't know right now, but have a look later. > > Thanks! > Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Re: "jar" tool and and reproducible builds - how?
Hi Gábor, > What diff remains there? There might be more jars or jmods inside... > Most of the trickery should be in ant build system. This package does not use ant-build-system or any other java build system since there are only very few Java tools in nesc (I'm thinking of disabling those, too). diffoscope states only the following, via "zipinfo -v" on "lib/ncc/nesc.jar": - file last modified on (DOS date/time): 2019 Nov 4 17:10:26 + file last modified on (DOS date/time): 2019 Nov 4 17:10:56 It's repeated a lot of times. No other files but "lib/ncc/nesc.jar" are affected. > I don't know right now, but have a look later. Thanks! pgpFpuyh80ezs.pgp Description: OpenPGP digital signature
Re: Profiles/manifests-related command line interface enhancements
Very good points! We are having very constructive discussions these days about `guix environment` and guix profiles ;) Exciting times ahead! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Profiles/manifests-related command line interface enhancements
Am 05.11.19 um 10:03 schrieb Konrad Hinsen: >> And adding another dimension: spawning a sub-shell (environment) or not >> (profile). > How is this different from the ephemeral vs. persistent dimension? > Creating an ephemeral package set makes sense only if you spwan a > process in it (not necessarily a shell). You are right, these are (almost?) the same. Ephemeral could also be imagined without spawning a some process, but also without registering a "root". But this would not work, since as soon as one runs "guix gc" while such an environment is active, the environment would be destroyed. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Profiles/manifests-related command line interface enhancements
Hi Hartmut, > This becomes even messier if we would implement a "guix develop" > command, which is yet just another version of environment/profile. Yes, I worry also about making more of a mess by implementing special-purpose variants. > And adding another dimension: spawning a sub-shell (environment) or not > (profile). How is this different from the ephemeral vs. persistent dimension? Creating an ephemeral package set makes sense only if you spwan a process in it (not necessarily a shell). Cheers, Konrad
Re: Publishing news about Guix on a weekly basis
Pierre Neidhardt writes: > Pjotr Prins writes: > >> Not only good for humans, also good for search engines. I find the >> current package list https://guix.gnu.org/packages/ pretty useful, but >> I would like a search function because one keeps clicking to find a >> certain package. > > There is such a search function here: > > https://hpc.guix.info/browse > > Would be nice to port it to guix.gnu.org. Indeed. It seems a bit broken for some reason. I've seen it working in the past. I get the following error when I go to the page for a package. Uh-oh... The package is gone! signature.asc Description: PGP signature
Re: Publishing news about Guix on a weekly basis
Pjotr Prins writes: > On Sun, Nov 03, 2019 at 12:19:42PM +, Christopher Baines wrote: >> 1: http://prototype-guix-weekly-news.cbaines.net/en_US/2019/41.html >> 2: http://prototype-guix-weekly-news.cbaines.net/en_US/2019/42.html > > I think it would be useful to show a rolling report of upgraded/added > packages. We used to have the mailing list for that and now debbugs. That sounds like something that should be possible with the Guix Data Service, I've added a timeline style table for package versions on a branch (e.g. [1]), and it's possible to compare revisions to see the changes, but it should be possible to construct a page that gives the changes for multiple revisions. 1: http://data.guix.gnu.org/repository/1/branch/master/package/guix > A simple page that can be reloaded to see the latest with version info > and link outs to the builds would be rather useful. Then, on a weekly > basis, create an overiew. So the Guix Data Service doesn't currently know about builds, but this is something I'm looking to change [2], as it opens lots of new possibilities. Including creating a page as you describe. 2: https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00467.html > Not only good for humans, also good for search engines. I find the > current package list https://guix.gnu.org/packages/ pretty useful, but > I would like a search function because one keeps clicking to find a > certain package. So as Pierre points out, there is the Guix-HPC package search. The Guix Data Service also contains a search function (e.g. [3]). 3: http://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/packages If there's a need to keep the website as static content, maybe the JavaScript approach used by the Guix-HPC site could be used on the Guix Website. It should also be possible to use the Guix Data Service information for a search feature. Otherwise, maybe there could be a search box on the Guix Website, but it links to packages.guix.gnu.org, which is a package search service (which doesn't have to be part of the static website). > May also be an idea to provide links throught the guix CLI, such as > > https://guix.gnu.org/packages/alsa-lib-1.1.9/ What were you thinking people might use this for? Thanks, Chris signature.asc Description: PGP signature
Re: Profiles/manifests-related command line interface enhancements
Am 05.11.19 um 07:26 schrieb Konrad Hinsen: > In Guix we have ephemeral (environment) vs. persistent (profile), ad-hoc > (package -i, environment from package lists, ...) and declarative > (manifests). It's a bit of a mess. +1 This becomes even messier if we would implement a "guix develop" command, which is yet just another version of environment/profile. And adding another dimension: spawning a sub-shell (environment) or not (profile). -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Help on search (was: List of failing packages)
Am 04.11.19 um 16:26 schrieb Ricardo Wurmus: > For previous builds you can use a query like > >icecat spec:guix-master system:x86_64-linux Would be great if the page would contain a small help on this. I'm using this too seldom, so I just can not remember it. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: "jar" tool and and reproducible builds - how?
Am 04.11.19 um 18:18 schrieb Danny Milosavljevic:
> I tried
>
> (substitute* "tools/Makefile.in"
> ((" jar cf \\.\\./nesc.jar")
>" zip -0 -X ../nesc.jar META-INF/MANIFEST.MF "))
>
> but that doesn't seem to be enough.
The ant-build-system contains phases dealing with this. Have a look at
guix/buid/ant-build-system.scm, near the bottom. Noteble this runs
"strip-jar-timestamps twice!
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Re: Publishing news about Guix on a weekly basis
L p R n d n writes: > As for the cadence, I'm not really sure. 1 Month seems nice because it > gives probably enough time for people to write one or two sentences on > whats happening without to much of a burden for each post. Or if we go > for a weekly post, I think we should stick with automatic posts. I fear, > human written informations (highlights) would be lost in the flow, > otherwise. I was definately thinking about monthly, some other projects do that successfully. Maybe both could work as well, the monthly post could almost be a digest. > Could we use guix pull --news datas here? Yeah, I was thinking about this too. I might try and get the data in to the Guix Data Service, at which point it'll be trivial to pull in to the posts. > One little thing that could be nice, IMHO, is to add the last commit > used for the diff to let people pull from it. Or even a full copy-patable > 'guix pull commit=...'. And if, the message is posponed 24h (or anything > convenient) after the commit has been pushed, it could be a handy way > for users to pull from a recent commit, yet with (probably) substitutes. > What do you think? So currently there a link at the bottom of the posts: "View comparison data", which links to the Guix Data Service page where the data is fetched from, and that does give the commit (at least in the short form). But yeah, adding the full commit to the post sounds like a good idea. Thanks, Chris signature.asc Description: PGP signature
