Re: guix import hackage fails with errors, and failed tests
Hi, On Thu, 25 Mar 2021 at 16:23, c4t0 wrote: > zimoun writes: >> The issue with this is that Guix would somehow depend on Haskell. And >> it would not happen: GHC is not bootstrappable, is huge, etc. > > I get the point of bootstrappable guix, and yes GHC is really huge, but > if you're importing a haskell package, doesn't make sense to require the > haskell ecosystem? you'll be having it installed anyways... > > I don't see a problem from the user pov, but I agree with you that is > bad to require a haskell package at testing time. Your mean from the Guix user using Haskell point of view where they already has this huge “guix size cabal-install”. What about the Guix users point of view who are not using Haskell? That’s why Guix does not depend on per language tools for the importers. Without speaking that Guix runs on many architectures other than x86_64. > so... maybe a package that leverages the import system *and* the haskell > ecosystem to aid the haskell package mantainers? > > what would be a good idea to leverage the other packaging system tools > to import packages to guix with out making guix humongous? > > can we have a module with importers that augment the guix 'native' ones > with foreign tools? Well, Guix provides an extension mechanism, see GUIX_EXTENSIONS_PATH. Maybe it is the entry point for what you would like to have. >> I hope that this does not >> prevent you to contribute by adding ghc-events. :-) > > it won't XD > I manage to make a ghc-events.scm package with the hacky patch and > installs just fine in my profile. Cool! > I guess that I'll have to put all the libraries in haskell-xyz.scm and > threadscope (the culprit of this little adventure) in haskell-apps.scm, > right? Yes, I guess. Cheers, simon
Expat 2.3.0 has been released
Hello everyone! Expat 2.3.0 — simplified — brings… - bugfixes, - improvements to both build systems, and - improvements to xmlwf usability. Please see the changelog at [1] for more details. If you have patches for Expat that are still required with version 2.3.0, please send them my way. Thank you! Best Sebastian [1] https://github.com/libexpat/libexpat/blob/R_2_3_0/expat/Changes
Re: cuirass
> The rule for “#search #search-hints” should have a “z-index: 1;” or
> similar, so that the icons don’t overlap the search box.
Like the following ?
diff --git a/src/static/css/cuirass.css b/src/static/css/cuirass.css
index e713b6f..2754415 100644
--- a/src/static/css/cuirass.css
+++ b/src/static/css/cuirass.css
@@ -4,6 +4,7 @@
#search #search-hints {
display: none;
position: absolute;
+z-index: 1;
top: 3em;
background: white;
border: 1px solid #ced4da;
--
Vincent Legoll
Re: cuirass
Vincent Legoll writes: > * The search combobox help popup window > is not on top level, probably on all pages. > So other page elements are displayed over > it. I noticed that too. The rule for “#search #search-hints” should have a “z-index: 1;” or similar, so that the icons don’t overlap the search box. -- Ricardo
cuirass
Hello, I just made a tour of the new cuirass, this is much nicer than when I last visited (a long time ago). Kudos ! I saw a few glitches (with firefox 78.8.0esr) * The "Home" & "Guix logo" buttons bothlink back to the home page (duplicate). * The search combobox help popup window is not on top level, probably on all pages. So other page elements are displayed over it. * Overdirve1 does not have infos (missing zabbix) I have collected a buch of ideas for additions. Should I create bugs for those or just the above list will suffice ? Thanks a lot for the improvements ! PS: Sorry for ENOPATCH but I'm not good at web. -- Vincent Legoll
Re: guix import hackage fails with errors, and failed tests
zimoun writes: > Hi, > > On Wed, 24 Mar 2021 at 16:41, c4t0 wrote: >> zimoun writes: > >> yes! I don't know if is really related with >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35743 and is a layout >> problem or it doesn't know how to parse 'common'. > > I have not read carefully the bug report you mention, neither the > parser. I guess the parser does not know how to parse ’common’. > the bug report is a problem with layout (indentation). Yes you are right, in this case is a problem with the keyword 'common'. > >> running >> $cabal format package.cabal > > You can do that that locally. Well, currently all the importers via > “guix import” should be considered as helpers to ’import’, not as > bullet-proof ’converters’. > > >> I think it might be a good idea to run 'cabal format package.cabal' some >> how, before parsing. That will give us a consistent format that might >> address the #35743 bug also, and remove formatting variance that a >> package mantainer may introduce to make things more legible to him. > > The «somehow» cannot be using Guix. Otherwise, it means that Guix would > depend partly on Haskell ecosystem. That’s why there is a Cabal parser > written with Guile. Somehow. :-) > Oh well, I've made a patch that does something like: (system* "cabal" "format" cabal-filame) and it works. It solves the layout and the 'common' keyword problem. but yes, you'll need to add cabal-install to the environment when running tests. it bothers me that I've used 'system*' and not a foreign function, but it was the easiest to do to see if it works. it annoys me too that we have to re do work done somewhere else, it's a similar problem with editor parsers and language servers. > >> Also is easiest than propagate a set of default options to other >> targets, but I think the best argument is the former. >> >> maybe modify cabal.scm::read-cabal to make a temporary file with the >> input port, run 'cabal format tmp-file' and then change the port to use >> that temp file? > > The issue with this is that Guix would somehow depend on Haskell. And > it would not happen: GHC is not bootstrappable, is huge, etc. > I get the point of bootstrappable guix, and yes GHC is really huge, but if you're importing a haskell package, doesn't make sense to require the haskell ecosystem? you'll be having it installed anyways... I don't see a problem from the user pov, but I agree with you that is bad to require a haskell package at testing time. so... maybe a package that leverages the import system *and* the haskell ecosystem to aid the haskell package mantainers? what would be a good idea to leverage the other packaging system tools to import packages to guix with out making guix humongous? can we have a module with importers that augment the guix 'native' ones with foreign tools? in this case would be ideal to have cabal do all the parsing and make guix talk with, asking the info that it needs to generate the package def. > >> If it's ok, I'll give it a try, for now touching the parser it's a >> little out of my reach. > > Well, if your aim is to produce the Guix definition of ghc-dec, you can > try to run your trick locally. As said, “guix import” are importers and > not converters, which means it helps to produce a Guix package > definition from a package definition i.e., it is not a > bullet-proof converting all the cases; cases probably without a clean > grammar. > ok, I did that. > In other words, to resolve the issue you are pointing, the fix is to > improve the Guix parser of cabal, IMHO. I'll give it a try in the near future, for now I'll do more damage than good. Maybe for the time being, reporting a bug for the 'common' keyword pushing a new test in hackage.scm with a (test-expect-fail 1) and a comment to the bug report? > I hope that this does not > prevent you to contribute by adding ghc-events. :-) > it won't XD I manage to make a ghc-events.scm package with the hacky patch and installs just fine in my profile. I just have to check in runtime with a program that uses it and learn the ropes a little more to push it. I guess that I'll have to put all the libraries in haskell-xyz.scm and threadscope (the culprit of this little adventure) in haskell-apps.scm, right? > > Cheers, > simon Chau! COD.
Re: [opinion] CVE-patching is not sufficient for package security patching
On Thu, Mar 25, 2021 at 03:22:16PM +0100, Mathieu Othacehe wrote: > I recently added a new metric in Cuirass: "Builds count per machine > during the last day". Turns out the overdrive1 with its two workers > seems to outperform the hydra-guix-X running emulated builds on four > workers. That's good to know, thanks!
Re: [opinion] CVE-patching is not sufficient for package security patching
Hello, > Concretely, this would mean a Honeycomb LX2 or Ampere ALTRA workstation, > since I don't believe there are any other aarch64 workstations available > for sale. > > https://www.solid-run.com/arm-servers-networking-platforms/honeycomb-workstation/ > https://store.avantek.co.uk/ampere-altra-64bit-arm-workstation.html I recently added a new metric in Cuirass: "Builds count per machine during the last day". Turns out the overdrive1 with its two workers seems to outperform the hydra-guix-X running emulated builds on four workers. As soon as the other overdrives are back online, the situation will hopefully be a tiny bit better. Buying and hosting other machines such as the ones you mentioned could also help here. The Wireguard tunnel between berlin an the overdrive1 works fine and configuring those machines with something similar to "hydra/modules/sysadmin/overdrive.scm" should be enough to add them as Cuirass workers. Thanks, Mathieu
