Re: Document our WIP
Hi, On Wednesday, March 31, 2021 6:16 PM, Leo Famulari wrote: > On Wed, Mar 31, 2021 at 07:52:30PM +0200, Léo Le Bouter wrote: > > > On Tue, 2021-03-30 at 12:37 +0200, Ludovic Courtès wrote: > > > > > To me, a good way to make sure work remains “in progress” is to post > > > regular updates to this list, and then to write blog posts for the > > > web > > > site whenever an important milestone is reached. > > > I think a web page is likely to quickly become outdated… unless said > > > work transitions from “in progress” to “stalled”. :-) > > > > I feel like using the mailing list fails at solving one concern that is > > discoverability of WIP problems for people to show up and help tackle > > them, even if they were abandonned by the people who started them. Not > > everyone can handle the load of incoming mail in the ML. On the GNOME > > 40 upgrade for example I linked the mailing list thread on the wiki > > page also. The wiki page is also more likely to get outdated if it > > doesnt have great visibility on the GNU Guix official website, that, > > for sure. > > Yeah, I agree that it's hard to learn about "what's cooking" when you > first arrive at the mailing lists. > > It's true that wikis tend to get out of date, but I think that it won't > be too bad for this use case. At least, it won't be worse than the > mailing lists, for newcomers who want to know about longer-term efforts > like the GNOME upgrade. I just sent a patch to include a link to the wiki in the Help page (https://issues.guix.gnu.org/47555). If the patch is applied, I can send a separate patch to update the Help menu as Vincent suggested: Help • GNU Guix Manual • Videos • Cookbook • GNU Manuals • Wiki • IRC Chat • Mailing lists If people think it's ok.
Re: Petition to remove hidden flag from cmake-minimal package
I am using it with pack and the minimal requirement the size down but also prevents a large number of dependencies from being pulled in when building from source. I attached the dependency graphviz dot to illustrate, the resulting png is roughly 7mb. This is only for cmake. On 4/1/21 4:02 PM, Maxime Devos wrote: On Wed, 2021-03-31 at 13:17 -0400, Tom Hiller wrote: Could cmake-minimal be made publicly available as a version of cmake without the documentation dependencies? I believe the only thing preventing this is the hidden flag inherited from cmake-bootstrap. Technically, yes, but why? What's the use case you have in mind? cmake.dot Description: application/msword-template
Re: Petition to remove hidden flag from cmake-minimal package
On Wed, 2021-03-31 at 13:17 -0400, Tom Hiller wrote: > Could cmake-minimal be made publicly available as a version of cmake > without the documentation dependencies? I believe the only thing > preventing this is the hidden flag inherited from cmake-bootstrap. Technically, yes, but why? What's the use case you have in mind? signature.asc Description: This is a digitally signed message part
Re: Cuirass 1.0 released
On Thu, Apr 01, 2021 at 10:23:07AM +0200, Mathieu Othacehe wrote: > We are pleased to announce the release of Cuirass 1.0. Awesome! Your hard work is making a big difference for Guix :) > This is the first official release of Cuirass, the GNU Guix continuous > integration software. Since January, this project is funded through the > NGI0 PET Fund, a fund established by NLNet[1]. Thanks to this support, > we were able to speed up the developments and finally propose this > release. Thank you to NLnet for their support!
Re: Cuirass 1.0 released
Hi Mathieu, Mathieu Othacehe skribis: > We are pleased to announce the release of Cuirass 1.0. > > This is the first official release of Cuirass, the GNU Guix continuous > integration software. Since January, this project is funded through the > NGI0 PET Fund, a fund established by NLNet[1]. Thanks to this support, > we were able to speed up the developments and finally propose this > release. > > Read more about today’s announcement at: > > https://gnu.org/software/guix/blog/2021/cuirass-10-released/ Woohoo, thumbs up! It’s crazy how much you’ve achieved since January, when we were still looking at all these build machines sitting desperately idle. Really happy that you were able to fix this situation and more in so little time! Ludo’.
Re: Finding the channel in which a package is defined
Hi everyone, thanks for your suggestions. My award for the most useful one (to me) goes to Mathieu : > You can run something like: > > --8<---cut here---start->8--- > ,use (guix describe) (gnu packages) (gnu packages linux) > (%package-module-path) > (package-channels strace) > --8<---cut here---end--->8--- Since the information is stored with all packages, it would be reasonable for "guix show" to display it as well. I'll look at this and propose a patch if I succeed. It's a bit surprising at first sight that there are multiple channels. I suspect that the list contains the channels of all inputs as well, recursively, meaning that channel "guix" is present almost everywhere. Cheers, Konrad.
Re: Security patching and the branching workflow: a new security-updates branch
Sorry for duplicated email, On Thu, 2021-04-01 at 16:58 +0200, Ricardo Wurmus wrote: > I don’t think we should have a security-updates > branch, because the role of that branch is effectively taken by > staging. I don't think that's the case because staging is documented for things that do not make too many rebuilds (in which case they'd go to core- updates), and some times security updates do cause rebuilds in the 1800+ and they could not go through staging. The proposed security- updates branch would not have that limitation. We could of course also revisit the policy for staging and prioritize security updates through that branch while also committing to actually merging that branch on schedule. Léo signature.asc Description: This is a digitally signed message part
Re: Security patching and the branching workflow: a new security-updates branch
On Thu, 2021-04-01 at 16:58 +0200, Ricardo Wurmus wrote: > Hi Léo, > [...] > That’s fine. We have no deadlines, so stepping back from what feels > like a heated discussion for a while and revisiting the points later > comes at very little cost. > > Obviously, you don’t *have* to accept other people’s criticism. But > we > collectively aim to act in a collegial fashion, finding consensus > before > forging ahead with changes to processes. I have not been convinced > by > your arguments and your appeals in this discussion. I can’t speak > for > others, but I would consider it very unwise to ignore the lack of > consensus and just start a new branch when that isn’t what the > collective of long-term contributors agrees to do. > > If that’s not what you’re planning to do then my comments carry no > weight. I do want to stress, though, that hurry is usually misplaced > in > the decision-making process of this project. There are only few > exceptions to this and none warrant precipitating a falling-out. > I never planned to go on and create that security-updates branch, it is clear that there's no consensus for that, also it would require other tools we don't have. However what I disagree with Simon is that they think security updates should not be prioritized, which I don't agree with very strongly. They have repeated that many times in various ways and it annoys me that these arguments come up again and again in response to my messages or contributions even though Simon knows I disagree. There's no other problem to me. There's a thing about my personality and I am sorry to be that way, it's that I am ready to question myself but at a point when the demand to question becomes confrontational way rather than in a friendly way I stop being able to. I feel like I have taken into account many criticism and changed my workflow due to that. I am glad people help me improve the contributions I make to GNU Guix. This thread is a proposal, like all others were, and on some comments I feel attacked personally for even mentionning things that are only proposals to me (I don't even think they're good solutions in the absolute sense, I just propose them). Léo signature.asc Description: This is a digitally signed message part
Re: Security patching and the branching workflow: a new security-updates branch
Hi Léo, > Hello Ludo, > > On Wed, 2021-03-31 at 23:29 +0200, Ludovic Courtès wrote: >> It’s unacceptable to call someone “obsessed” just because you >> disagree >> and calling Simon’s comments “harassment” is equally inappropriate. > > I really do feel harassed by their comments, it's not just because I > disagree, it's that I feel they have been following me around in > several of my contributions repeating the same issues, I have heard > their criticism and I do disagree but I don't feel like bringing it up > over and over and over following me around is a great thing to do at > all! I don’t doubt it feels this way for you, but I seriously doubt Simon follows you around and responds to your emails to cause a stink. Since a couple of months Simon has been doing invaluable work to tie up loose ends in bug reports and mailing list discussions; thanks to this tireless work many stalled projects have been able to move forward. Applying the same strategy to finding consensus and establishing the lack of consensus in fresh discussions is very valuable, in my opinion. You started quite a few discussions with lots of recommendations and some controversial points; I think it is obvious that this leads to a discussion of these points, including the unavoidable discussion of misunderstandings (which can be pretty frustrating for all involved). For what it’s worth, I agree with the points made by Leo Famulari, Ludovic, and Simon. I don’t think we should have a security-updates branch, because the role of that branch is effectively taken by staging. >> We’re all passionate about the project, and each one of us looks at >> it >> from a different angle. >> >> You’re new to the project. I think we’re all glad you joined; that >> has >> already boosted security work and the POWER9 port. But we also have >> expectations: that you follow written rules (the code of conduct, the >> “Commit Access” section of the manual), and the unwritten rule that, >> as >> a newcomer, you would humbly listen to suggestions made by more >> experienced contributors. > > I try to listen, and I think I have listened to criticism from many > different people. I think we've reached a point where I could not > listen anymore from Zimoun because I felt we were going in circles. That’s fine. We have no deadlines, so stepping back from what feels like a heated discussion for a while and revisiting the points later comes at very little cost. Obviously, you don’t *have* to accept other people’s criticism. But we collectively aim to act in a collegial fashion, finding consensus before forging ahead with changes to processes. I have not been convinced by your arguments and your appeals in this discussion. I can’t speak for others, but I would consider it very unwise to ignore the lack of consensus and just start a new branch when that isn’t what the collective of long-term contributors agrees to do. If that’s not what you’re planning to do then my comments carry no weight. I do want to stress, though, that hurry is usually misplaced in the decision-making process of this project. There are only few exceptions to this and none warrant precipitating a falling-out. -- Ricardo
Re: Finding the channel in which a package is defined
Mathieu Othacehe writes: package-channels Ah sweet! This is exactly what I was looking for (guix packages) ...here. -_- Thanks, T G-R signature.asc Description: PGP signature
Re: Finding the channel in which a package is defined
Hello Konrad, > Is there a simple way to find out in which channel a given package was > defined? I tried "guix edit" to see the source code, but it shows a file > from a "module-union" directory in the store. You can run something like: --8<---cut here---start->8--- ,use (guix describe) (gnu packages) (gnu packages linux) (%package-module-path) (package-channels strace) --8<---cut here---end--->8--- in a "guix repl" to determine the channel providing "strace". If you replace "strace" by a package provided by my-channel, "package-channels" should return a list containing the default Guix channel as well as my-channel. Mathieu
Re: Finding the channel in which a package is defined
Konrad Hinsen writes: > Tobias, > > Thanks for your reply! > >> Does the ‘location’ field of ‘guix show PACKAGE’ do what you want? > > Taking coreutils as a test case, it displays: > >gnu/packages/base.scm:328:2 > > as a link pointing to: > > > /gnu/store/3qykwxq1mqlin3lrb93s3rzi1ah5xia8-guix-module-union/share/guile/site/3.0/gnu/packages/base.scm > > and that is the same file that is opened with "guix edit". But it's a > copy of the input source file that is part of some channel, so the > provenance is lost. I’m pretty sure that the union file itself is a link. By using “readlink -f /gnu/store/3qykwxq1mqlin3lrb93s3rzi1ah5xia8-guix-module-union/share/guile/site/3.0/gnu/packages/base.scm” you could get the source directory of that file. The prefix will indicate that this is a Guix source checkout, whereas for files from other channels the prefix directory will differ. Still, that’s a bit crude. It might be better to record a channel reference in the package values. -- Ricardo
Re: Security patching and the branching workflow: a new security-updates branch
Hello Ludo, On Wed, 2021-03-31 at 23:29 +0200, Ludovic Courtès wrote: > It’s unacceptable to call someone “obsessed” just because you > disagree > and calling Simon’s comments “harassment” is equally inappropriate. I really do feel harassed by their comments, it's not just because I disagree, it's that I feel they have been following me around in several of my contributions repeating the same issues, I have heard their criticism and I do disagree but I don't feel like bringing it up over and over and over following me around is a great thing to do at all! I did not try to go and yell all around after for example 'guix pull' was broken after some changes to substitutes handling that were pushed for example. I just trust people to do the best. I know people want the best for GNU Guix. I also want the best for GNU Guix. I am not trying to somehow deliberately break GNU Guix. > We’re all passionate about the project, and each one of us looks at > it > from a different angle. > > You’re new to the project. I think we’re all glad you joined; that > has > already boosted security work and the POWER9 port. But we also have > expectations: that you follow written rules (the code of conduct, the > “Commit Access” section of the manual), and the unwritten rule that, > as > a newcomer, you would humbly listen to suggestions made by more > experienced contributors. I try to listen, and I think I have listened to criticism from many different people. I think we've reached a point where I could not listen anymore from Zimoun because I felt we were going in circles. There's different opinions from different places it seems, where some people agree with my way of doing and some others do not, and I felt like I had more approval from other people and that while Zimoun's criticism has been heard I have not acted upon all of their criticism. Is it possible to do that? > The unresolved issues Simon points out are not just technical > problems; > they’re a hindrance to our cooperation and to our well-being as a > group. > It’s completely okay to make mistakes, but it’s not okay to break the > community rules and to dismiss the opinion of others as unimportant. I do not dismiss other's opinion as not important, I disagree, what do you want me to do? We have different way of doing things, if I do them I do them my way, if they do them they do it their way, what else can we do here? > > Please adjust accordingly. I don't feel like that's entirely fair but I always strive to self- improve. > Thanks, > Ludo’. Léo signature.asc Description: This is a digitally signed message part
Re: Finding the channel in which a package is defined
Konrad Hinsen writes: Taking coreutils as a test case, it displays: gnu/packages/base.scm:328:2 Right, it's not guaranteed to match the channel name, but it's usually enough to deduce it. I meant something like: λ guix show nicecat | grep ^location location: nckx/packages/gnuzilla.scm:105:2 Because my channel uses (nckx packages ...) module names. Most channels do something similar. If you're using a third-party channel that shadows (clobbers?) the (gnu packages ...) namespace, I'm not sure what you could do. Kind regards, T G-R signature.asc Description: PGP signature
Re: A new wip-emacs branch
Hi Leo, great that you're improving the emacs-on-guix experience! I'm not sure whether this is related, but a while ago, after an update of emacs, I had an issue where emacs would not start in graphical mode (it segfaulted) until I ran `fc-cache -rv`. Kind regards, pinoaffe
Re: Finding the channel in which a package is defined
Tobias, Thanks for your reply! > Does the ‘location’ field of ‘guix show PACKAGE’ do what you want? Taking coreutils as a test case, it displays: gnu/packages/base.scm:328:2 as a link pointing to: /gnu/store/3qykwxq1mqlin3lrb93s3rzi1ah5xia8-guix-module-union/share/guile/site/3.0/gnu/packages/base.scm and that is the same file that is opened with "guix edit". But it's a copy of the input source file that is part of some channel, so the provenance is lost. Cheers, Konrad
Re: Finding the channel in which a package is defined
Konrad, Konrad Hinsen writes: Dear Guix experts, I'll answer in the meantime. Is there a simple way to find out in which channel a given package was defined? Does the ‘location’ field of ‘guix show PACKAGE’ do what you want? Kind regards, T G-R
Finding the channel in which a package is defined
Dear Guix experts, Is there a simple way to find out in which channel a given package was defined? I tried "guix edit" to see the source code, but it shows a file from a "module-union" directory in the store. Cheers, Konrad
Re: Adding Substitute Mirrors page to installer
Hello, Thanks for this patch, it seems to work fine! > + ;; Extract the substitute URLs of the user configuration. > + (os (read-operating-system > (%installer-configuration-file))) > + (substitute-urls (and=> (find > + (lambda (service) > + (eq? guix-service-type > + (service-kind service))) > + (operating-system-services os)) > + (compose guix-configuration-substitute-urls > + service-value))) We could make the mirror selection a proper step, adding it to (gnu installer record). Then in (gnu installer), you could add: --8<---cut here---start->8--- (installer-step (id 'mirrors) (description (G_ "Mirror substitute server")) (compute (lambda _ ((installer-mirrors-page current-installer) --8<---cut here---end--->8--- This way, you should be able to select the step result in "run-final-page" this way: --8<---cut here---start->8--- (let* ((configuration (format-configuration prev-steps result)) (user-partitions (result-step result 'partition)) (locale (result-step result 'locale)) (users (result-step result 'user)) (mirrors (result-step result 'mirrors)) (install-ok? (with-mounted-partitions user-partitions (configuration->file configuration) (run-config-display-page #:locale locale) (run-install-shell locale #:users users #:mirrors mirrors ...) --8<---cut here---end--->8--- That would avoid the need to parse the resulting configuration file. > +(define (run-substitute-mirror-page) > + (let ((title (G_ "Substitute mirror"))) > +(run-listbox-selection-page > + #:title title > + #:info-text (G_ "Choose a server to get substitutes from. > + > +Depending on your location, the official substitutes server can be slow; \ > +in that case, using a mirror may be faster.") I wonder if it would make sense to select multiple mirrors, as fallback if the preferred mirror is not up to date. We could also add the possibility for the user to add a mirror manually. In that case, the mirror page could look like the "User creation" page, with an "Add" button opening a popup proposing to type a mirror URL or to select one from an existing list. WDYT? Thanks, Mathieu
Cuirass 1.0 released
We are pleased to announce the release of Cuirass 1.0. This is the first official release of Cuirass, the GNU Guix continuous integration software. Since January, this project is funded through the NGI0 PET Fund, a fund established by NLNet[1]. Thanks to this support, we were able to speed up the developments and finally propose this release. Read more about today’s announcement at: https://gnu.org/software/guix/blog/2021/cuirass-10-released/ • About Cuirass is the GNU Guix continuous integration software. It's a general purpose build automation server written in GNU Guile that checks out sources from VCS repositories, execute build jobs and store build results in a database. Cuirass also provides a web interface to monitor the build results. Cuirass is running on GNU Guix build farm[2]. • Download Here are the compressed sources and a GPG detached signature: https://guix.gnu.org/cuirass/releases/cuirass-1.0.0.tar.gz https://guix.gnu.org/cuirass/releases/cuirass-1.0.0.tar.gz.sig Here are the SHA1 checksums: 90a4ddbbb255353a1a90807b5dcc4ec7ed7e cuirass-1.0.0.tar.gz fe46ad674be0c3d1578d2c3950717f1dcf775e1f cuirass-1.0.0.tar.gz.sig • Changes since version 0.0.1 (excerpt from the NEWS file) ** Database *** Switch from SQLite to PostgreSQL *** New test cases covering most of the SQL queries ** Notifications *** New notification mechanism with Email and Mastodon backends *** Add RSS events support ** Remote building *** Add a remote building mechanism *** Add a live build log mechanism *** Honor timeout and max-silent-time package properties *** Add specification and package priorities support *** Add Workers monitoring support with Zabbix ** Evaluation *** Rewrite evaluation mechanism to rely on Guix inferiors. *** Change the specifications format from an association list to a record. *** Use Guix Channels instead of custom Inputs. ** Web *** Add a Workers status page to monitor the remote workers status *** Add actions - Add a specification - Edit a specification - Delete a specification - Cancel an evaluation pending builds - Retry all build of an evaluation - Retry an evaluation - Restart a build *** Improve the specification display *** Fix pagination *** Add build weather support *** Add build history support Please report bugs to bug-g...@gnu.org Join guix-devel@gnu.org and #guix on Freenode for discussions. Thanks to everyone who contributed to this release: 19 Christopher Baines 22 Clément Lassieur 10 Danny Milosavljevic 8 Jan Nieuwenhuizen 1 Jonathan Brielmaier 1 Leo Famulari 177 Ludovic Courtès 143 Mathieu Lirzin 296 Mathieu Othacehe 36 Ricardo Wurmus 1 Robert Vollmert 1 Roel Janssen 6 TSholokhova 1 Tobias Geerinckx-Rice 1 Vincent Legoll Mathieu [1]: https://nlnet.nl/ [2]: https://ci.guix.gnu.org smime.p7s Description: S/MIME cryptographic signature
A new wip-emacs branch
Hello Guix, as at least some of you are hopefully aware, the way Emacs interacts with Guix packaging is unsatisfactory in a few key ways. In particular, each major version upgrade completely breaks Emacs both running and not yet running until environment variables are updated [1]. Also, there are instances of packages breaking each other by installing to common subdirectories [2]. I have opened up a new wip-emacs branch to address these issues. It consists of the patches I wrote in the past few days, that are still awaiting review. (As it is now April 1st, people who only consume the mailing lists by the archives will soon have forgotten about them otherwise). While alternative patches exist, particular the ones written up by Maxim, I believe mine to be the "correct" ones, as they only cause rebuilds to Emacs and its dependants, thereby making them applicable to staging rather than core-updates. (In the past we also had Emacs patches pushed directly to master, since Emacs packages are fairly cheap to build; I want to avoid this here until we can be certain up to some level of reasonable doubt, that they do not cause any issues in the affected packages.) I have so far tested the patches by running my own Emacs manifest in a pure environment, which has not yet led to me declaring .emacs bankruptcy. I would strongly encourage other users of Emacs, particularly those, that have large numbers of Emacs packages in their profiles, to try out the wip-emacs branch and report to me any issues with it/directly push patches to wip-emacs if they're trivial. I don't plan to keep this branch alive for too lang. In one or two weeks time, depending on activity, I will submit its frozen version to review once more. In this frozen version, I will also sign off any commits from others, that I've already reviewed myself. Regards, Leo [1] http://issues.guix.gnu.org/47458 [2] http://issues.guix.gnu.org/45316
