Re: issue tracking in git
Il giorno ven, 13/08/2021 alle 16.39 +0200, raingloom ha scritto: > > I think this might be the result of that survey? > https://github.com/bitcoin-core/bitcoin-devwiki/wiki/GitHub-alternatives-for-Bitcoin-Core yes, this is it it seems here was no progress, since then
Re: issue tracking in git
Il giorno ven, 13/08/2021 alle 18.19 +0200, Giovanni Biscuolo ha scritto: > Hi Adriano and Ricardo, thank you for your insights
Re: issue tracking in git
Il giorno ven, 13/08/2021 alle 15.18 +0200, Ricardo Wurmus ha scritto: > > Hi Adriano, > [...] > Was it perhaps Carl Dong? yes, it was Carl Dong Thank you > > I don't remember the name of such person and I am wondering if > > amy > > progress has been achieved on that front > > I don’t think there was a decision to do issue tracking in git. Do you mean a decsion by the bitcoin community ? Or by the Guix community ? > I have no idea how well it works when there’s a lot of “traffic” > in a distributed project, e.g. when there are several comments to [...] > the same issue by different people. Having merge conflicts in the > issue tracker is a headache I’d like to avoid. > I hadn't thought about this This is a potential problem that deservses exploration I think issue tracking in git could be explored starting with smaller projects first Probably Guix is too large and entrenched to be used as a test bed for this kind of explorations I'm asking about the state of the art in this regard because I feel that server based solutions are problematic even for free software oriented organizations And should the bitcoin community explore this a bit, that would be a very interesting development, in my view
issue tracking in git
Hello some time ago, in the context of an on line conference about Guix, someone suggested me that the bitcoin community had run a survey about available solutions for issue tracking in git I don't remember the name of such person and I am wondering if amy progress has been achieved on that front So if they're reading, please, chime in I looked on line and found nothing Thanks
Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo
Il giorno mar, 01/06/2021 alle 08.24 +0200, Leo Prikler ha scritto: > > A sexp-pack would represent the most simple build instructions to > > build a package on its own. Now, of course the current guix- > > builders > > solve that too. But, what I am proposing is to split out the actual > > build step into a package definition, so as to present something > > simpler to Guix. > I don't think this would be simpler to Guix, you'd just create even > more packages, that actually aren't usable. The output could be a collection of .tar.gz files distributed through ipfs, bittorrent, syncthing or rsync Not necessarily packages in the way Guix intends them I understand there's already some work going on to reproduce tarballs in a format convenient to Guix (maybe with proper hashes and metadata ?) for when they get erased by distributors
Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo
Il giorno mar, 01/06/2021 alle 11.11 +0200, Leo Prikler ha scritto: > > The output could be a collection of .tar.gz files distributed > > through > > ipfs, bittorrent, syncthing or rsync > > > > Not necessarily packages in the way Guix intends them > > > > I understand there's already some work going on to reproduce > > tarballs > > in a format convenient to Guix (maybe with proper hashes and > > metadata > > ?) for when they get erased by distributors > Well, ideally Guix would have have ipfs-fetch, bittorrent-fetch etc. > as > methods or fallbacks, but this doesn't solve the problem that's posed > here. You can't just pull the complete source closure of e.g. > Fractal > over the ether and pretend it's just one package. Probably the Fractal package will depend on some others, so it's gonna be a collection 路️ Doesn't that happen already for traditional tarballs ? > We already drop all > vendored dependencies from tarballs, that aren't created by Rust et > al., this does the exact opposite. I'm not sure I understand This does the opposite ? How so ?
Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo
Il giorno mar, 01/06/2021 alle 13.03 +0200, Leo Prikler ha scritto: > Am Dienstag, den 01.06.2021, 12:52 +0200 schrieb Adriano Peluso: > > Il giorno mar, 01/06/2021 alle 11.11 +0200, Leo Prikler ha scritto: > > > > The output could be a collection of .tar.gz files distributed > > > > through > > > > ipfs, bittorrent, syncthing or rsync > > > > > > > > Not necessarily packages in the way Guix intends them > > > > > > > > I understand there's already some work going on to reproduce > > > > tarballs > > > > in a format convenient to Guix (maybe with proper hashes and > > > > metadata > > > > ?) for when they get erased by distributors > > > Well, ideally Guix would have have ipfs-fetch, bittorrent-fetch > > > etc. > > > as > > > methods or fallbacks, but this doesn't solve the problem that's > > > posed > > > here. You can't just pull the complete source closure of e.g. > > > Fractal > > > over the ether and pretend it's just one package. > > > > Probably the Fractal package will depend on some others, so it's > > gonna be a collection 路️ > > > > Doesn't that happen already for traditional tarballs ? > We don't stuff tarball collections into packages. We stuff inputs > into > packages and one input equals one tarball. > > > > We already drop all > > > vendored dependencies from tarballs, that aren't created by Rust > > > et > > > al., this does the exact opposite. > > > > I'm not sure I understand > > > > This does the opposite ? > > > > How so ? > Let's assume we form this sexp-pack and use it as input to some > package. What happens? we wouldn't use a sexp-pack as an input to a guix package in the same way as, as you noticed, we don't feed tarballs as inputs to guix packages A Guix package doesn't depend on some tarballs. It depends on some other Guix packages In the same way, a Guix package wouldn't depend on a sexp-pack. You can think of sexp-pack as an alternative format to tarball With, maybe, some more metadata For example, a sexp-pack could contain a hash of itself and hashes of other _sexp-packs_ it depends on Similarly to how, for example, python packages on pypi express dependecies on other packages in pypi The difference is that, as far as I understand, python packages (those in pypi, not those in Guix) express dependencies in a somewhat loose way Guix packages are stricter sexp-packs could be stricter too, bringing part of the data reconciliation outside of Guix A Guix importer could recursively import sexp-packs the same way the python importer... I'm assuming that a Rust package can be built in a sane way, with dependencies properly sorted out. I know that's possible for javascript packages, I'm not sure about Rust Such a data/packages collection could be used by mainstream linux distributions too, as far as I understand 路️
Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo
Il giorno lun, 31/05/2021 alle 19.47 +0200, Pjotr Prins ha scritto: > On Sun, May 30, 2021 at 09:17:20PM +0200, Konrad Hinsen wrote: > > How about pushing all the other package manager towards producing > > sexp-packs, and helping them to get there? > > I have a feeling they won't be that interested ;). > > My thoughts are that every software package simply consists of files > that need to be compiled (if not interpreted) and be copied in place. > > As Guix takes care of the first and the last - the issue centers > around building. The idea is to dress down these language specific > builders, such as cargo, so you don't have all the included > complexity. > > A sexp-pack would represent the most simple build instructions to > build a package on its own. Now, of course the current guix-builders > solve that too. But, what I am proposing is to split out the actual > build step into a package definition, so as to present something > simpler to Guix. > > I found a cargo -> ninja converter. It is that kind of idea. Guix > would use ninja with rustc instead of cargo. A stripped down cargo > could potentially work too - but cargo is a complex beast. > > A simplified build step would make it easier to troubleshoot these > packages. > > See what I mean? You mean to break the chain introducing an intermediate step With intermediate step, I mean a new kind of entity with its own format I like the idea Many times, breaking long chains makes them more understandable to me It's the old idea of composability, if you want It's like refactoring a huge procedure in several smaller ones It also resembles a sort of ETL process or some sort of "data science" task of "massaging" data for some later analisys phase In a way, doing this would in itself push language communities to think about their approach (of releasing blobs) I doubt they would start such an initiative themselves, they wouldn't have begun releasing blobs in the first place
Re: blog post about shepher user services
Il giorno sab, 22/05/2021 alle 15.49 +0200, Leo Prikler ha scritto: > Hi, > > the blog post you've linked > > https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/ > seems to neither contain mentions of XDG_CONFIG_DIR, nor mcron. > > Did you mean > https://guix.gnu.org/en/blog/2020/gnu-shepherd-user-services/ > instead? yes, I pasted the wrong one, sorry > > FWIW, $XDG_CONFIG_DIR should be $XDG_CONFIG_HOME, I myself always mix > those up as well. Good to know > As far as mcron integration is concerned, it doesn't > look as though this has been done yet and I think work remains to be > done to have mcron running "as a part of shepherd" rather than as its > own daemon. You can right now already run regular cron-jobs through > mcron just how people did before systemd was a thing. You just need > to > make sure you launch mcron as a user service if you want to go with > this particular configuration style, otherwise mcron as a system > service ought to suffice as well. > > Regards, > Leo > Ok, thanks
blog post about shepher user services
There's this blog post: https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/ I have 2 observations about it 1) it mentions a XDG_CONFIG_DIR environment variable. But on my Ubuntu desktop, I find a XDG_CONFIG_DIRS (note the final S) variable. This could be confusing to someone not knowing well their way around. Was this a simple slip ? Or is there any more specific reason for this missing S ? 2) in the end it announces a second post about integrationg Shepherd with mcron to come up with something that could substitute systemd's timer funtionality. It would be interesting to read the second blog post
Gnome Boxes
Gnome Boxes is GUI app that manages virtual machines and OSs images to run in them It's a sort of Qemu for the rest of us. It offers a menu with images of OSs to download and run There are several versions of NixOs, among many others There's a recipe for Guix System by Julien Lepiller, it's here https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/os/guix.gnu.org/guix-1.1.xml.in In their irc channel, the Boxes people infornmed me that they filter out images that have no download url, as it seems to be the case with this recipe In fact, as you can see, the download url is commented out (on line 15) Why is this ? Was there a specific problem with the download url ? It's be nice if I could pach this and have Guix System in the Gnome Boxes menu Thanks
