Re: SageMath packaging work
Am Wed, May 22, 2024 at 03:50:43PM +0100 schrieb Sharlatan Hellseher: > https://issues.guix.gnu.org/search?query=SageMath+is%3Aopen > 56729 patch[RFC PATCH 00/10] Add sagemath. > 70924 patch[PATCH 00/10] Add some SageMath standard packages. > Maybe it needs some love to bring to the master branch. Indeed that would be welcome. Concerning #70924, we would need to check with the python-team branch to not duplicate the patches. I will not be available for the next two weeks, but will be happy to take part in patch reviewing after that. Andreas
Re: Scheduling a new release?
Am Tue, May 14, 2024 at 11:41:26AM +0200 schrieb Ludovic Courtès: > As discussed at the 2023 Guix Days (!), we could follow a model similar > to that of NixOS: form a release team (~4 people) dedicated to keeping > track of issues in particular wrt. the installer, and committed to > publishing a release within 4–6 months. (I think several people actually > volunteered back in Feb. 2023. :-)) That is a good approach, of course. The two things I think should happen before a release is merging core-updates, and making a rebuild round (or several rounds? I am unsure whether it is safe to do everything at once) ungrafting everything. Plus testing the installer etc. Andreas
Re: Core updates status
Thanks, Felix and Maxim, for your explanations! Andreas
Re: Core updates status
Hello, Am Mon, May 06, 2024 at 10:47:13AM +0200 schrieb Josselin Poiret: > Maxim Cournoyer writes: > > I don't mind too much; when we re-enable the change we should add a > > phase to the gnu-build-system automatically deleting/moving the libtool > > archives. so that we're covered. > > I agree, although we'll have to be careful since some packages might > need them if they don't use pkg-config! I am a little bit confused by the suggestion; you mean removing all .la files from all packages? I thought they were there for a reason, and usually recorded the dependencies. For instance, doing a "guix build mpc" and looking at libmpc.la, my impression is that I see correct information. Why would one want to force upstream to add a pkgconfig dependency additionally to libtool? Or do I misunderstand the suggestion? Andreas
Re: Changing the defaults for --localstatedir and --sysconfdir?
Am Thu, May 02, 2024 at 11:00:15AM +0200 schrieb Ludovic Courtès: > That was 8 years ago though (eight!). At this point I think defaulting > to /var and /etc would do more good than harm. > What do others think? I have always been in favour of /var and /etc as defaults, and unsurprisingly still am. That would make the "technical" default coincide with the "social" default. Another option discussed at the time, but which would require to start from scratch in a sense, is to have everything Guix related under /gnu. I have always found it weird that the database registering the contents of /gnu/store was not close to /gnu/store; by moving it into /gnu, one could delete/backup/restore the directory easily. Andreas
Re: Vim helper config for Guix
Hello Efraim, Am Thu, Apr 04, 2024 at 09:43:02AM +0300 schrieb Efraim Flashner: > Most of the line indentation works pretty well. Vim, by default for lisp > languages, hardcodes an indent as 2 spaces, and I haven't gotten around > to learning how to write an indentexpr to make it work for guix. As a > result some of the indentation is close but not quite correct actually I would suggest to change to a standard (such as "always 2 spaces") that is easy to remember by a human; as far as I understood, almost nobody knows how this Guix indentation works, one needs to either use Emacs or copy-and-paste. Since mistakes in the current system seem to be unavoidable without special tooling, maybe we should change the definition of "mistake" instead of wasting time for the tooling. I do not know whether there is a reason to sometimes indent only by 1. Andreas
Re: Change logs: usage of square brackets
Am Tue, Apr 23, 2024 at 11:10:14AM +0500 schrieb Nigko Yerden: > I wonder what is the proper usage of square brackets in change logs. > According to https://www.gnu.org/prep/standards/standards.html#Change-Logs > square brackets are used for conditional changes, the name of the condition > is specified inside '[ ]'. However looking over the commit history I mostly > see another usage of '[ ]' for specifying the name of a record field which > content is being changed. It looks like we have created our own conventions that have diverged from the GNU changelog format. That sounds okay to me. Andreas
Re: Managing patches and branches, retrospective and futher changes?
Hello, Am Wed, Apr 24, 2024 at 02:21:56PM +0100 schrieb Christopher Baines: > Let me know if you have any thoughts or questions! in this part: +@item +Minimise the changes on master that are missing on the branch prior to +merging the branch in to master. Merging master in to the branch can be +appropriate for this purpose. I would drop the second sentence. It mildly contradicts the previous "avoid merging master into the branch". Writing "avoid merging" instead of "never merge" already allows for some leeway, I would prefer not to insist on it. Andreas
Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)
Am Thu, Apr 11, 2024 at 02:56:24PM +0200 schrieb Ekaitz Zarraga: > I think it's just better to > obtain the exact same code that is easy to find The exact same code as what? Actually I often wonder when looking for a project and end up with a Github repository how I could distinguish the "original" from its clones in a VCS. With the signature by the known (this may also be a wrong assumption, admittedly) maintainer there is at least some form of assurance of origin. > and everybody is reading. This is a steep claim! I agree that nobody reads generated files in a release tarball, but I am not sure how many other files are actually read. Andreas
Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)
Hello, Am Wed, Apr 10, 2024 at 03:57:20PM +0200 schrieb Ludovic Courtès: > I think we should gradually move to building everything from > source—i.e., fetching code from VCS and adding Autoconf & co. as inputs. the big drawback of this approach is that we would lose maintainers' signatures, right? Would the suggestion to use signed tarballs, but to autoreconf the generated files, not be a better compromise between trusting and distrusting upstream maintainers? Andreas
Re: rewriting history; Was: Concerns/questions around Software Heritage Archive
Am Mon, Mar 18, 2024 at 04:33:49PM +0200 schrieb MSavoritias: > Actually gitlab already is facing something like that and they are doing > what was proposed elsewhere: mapping of UUIDs to display names > https://gitlab.com/gitlab-org/gitlab/-/issues/20960 Interesting, thanks! It is something that maybe could be implemented by Savannah, but it would probably require a bit of thought. And yet again, somehow the mapping uuid<->"real" names would have to be public (people would "git clone" commits with uuids, and would need to locally replace them by "real" names); so people can always keep copies of the mapping over time. I am also not quite sure about the signing process for committers; in principle keys are enough, but in GPG they are tied to email addresses, and I do not know whether we use this in Guix. In the end, my impression is this will not achieve much more than what we already have with the .mailmap approach. In a sense, everyone would use a pseudonym (their uuid), and then we would keep a mapping between these pseudonyms and, well, "real" names or other pseudonyms chosen by the contributors... Hm, this could indeed be implemented exactly with .mailmap, no? We would need to enforce that authors use a uuid of a specific format, and potentially an empty or dummy email address, or another uuid. Then we could keep a .mailmap file. The history of "real" identities would still be visible in the git history, but as said above, anyway we could not prevent people from storing the association information over time. > Right fair. As I have said before SWH does break Guix CoC effectively right > now. > So what Guix does from this point on will effectively dictate if the CoC is > valid or not. Well, the CoC is valid on our communication channels; so what SWH does with our software is outside its scope (that is governed by the license). Andreas
Re: rewriting history; Was: Concerns/questions around Software Heritage Archive
Am Mon, Mar 18, 2024 at 04:03:20PM +0200 schrieb MSavoritias: > Rewriting history is the wrong question imo. I dont think a request to > change all of the history of Guix will be accepted anyway. > A much easier thing to do is to change the approach in the future. And let > all the past history untouched. I was well thinking about the future history as well as the past one... Everything we do now becomes unmutable history in the future; so the question how we can rewrite an a priori unmutable history remains the same, regardless of the date when person X wants to be known as person Y: Also in the future, someone may wish to travel to a time before the change. And the fundamental problem of history rewriting remains; I do not see how we could simplify it. So I do not think that it is "a much easier thing to do". Please feel free to prove me wrong by making a concrete suggestion! Am Mon, Mar 18, 2024 at 04:00:38PM +0200 schrieb MSavoritias: > On 3/18/24 15:12, Simon Tournier wrote: > > Again, this is an incorrect frame, IMHO. Software Heritage (SWH) do the > > things you granted them to do. SWH respects the “ethical” definition of > > “free software”. > You are bringing the legal argument again. The argument that you can do what > you want with Free Software is based around a licence which is a legal > construct of states. I think there is a misunderstanding here, rooted in the use of "you" in "you can do what you want". We need to be clear about whom we are speaking. There is SWH, and what they can do is a result of the free license. The other question is what we as the Guix community want to do (and can do); I would suggest to concentrate in our discussion on the latter, which is where we have agency. Andreas
Re: rewriting history; Was: Concerns/questions around Software Heritage Archive
Hello all, Am Mon, Mar 18, 2024 at 12:26:18PM +0100 schrieb Simon Tournier: > Therefore, it would be more constructive if you come with a > proof-of-concept allowing “history rewrite” and strong “software > identification” property the one thing I can think of, and which would allow time travel to coexist with history rewriting, is an additional layer of metainformation. First of all, when rewriting history, all commits from the bifurcation to an alternate universe must be signed again by the person doing the "time split"; so there is a loss of information there. Second, we need to create a table that associates every old, lost commit hash to the corresponding new commit hash; this should also be signed by the person rewriting history. Of course this will have to be continued to the future: If Guix has n commits and m history rewrites, then the m-th rewrite may have to create a table of n entries that link commit hashes of the m-th rewrite to those of the (m-1)-th rewrite. Total memory would become m*n entries. When doing time travel to a commit hash, one would need to check whether it is available in the current, m-th history rewrite; if not, one would need to look for it in the (m-1)-th rewrite and map it to a commit hash in the m-th rewrite; if not, one would have to look for it in the (m-2)-th rewrite and map it to a hash in the (m-1)-th rewrite, and then check whether or not it has been overwritten in the m-th rewrite. The total time complexity would be m look-ups in tables of size n each. It is a lot of effort; and probably for little gain, since we cannot eradicate each and every fork of the Guix git repo. The old data will still be available at SWH, and probably at random forks on lots of random forges all over the world. As Simon, I think that history, fundamentally, cannot be rewritten: What has happened in the past, has happened in the past. If you have done some public activity as the person known as X, and then change your name to Y, you cannot prevent your past activity to be known under identity X. Also, the time split would have to be publicly documented somehow; if we add as rationale for a history rewrite "person X is now known as Y", not much is gained compared to just keeping the old commits. Not documenting the rationales for history rewrites would not help to instill trust in the codebase, and probably not solve the problem either, since it is quite likely that the request by person X to now be addressed as Y will have been made on the mailing list or some other public forum. So my impression is that the .mailmap approach in the Guix project is a good compromise between acknowledging the wish of people to be known under identity Y, and what can reasonably be achieved to hide identity X. Well, there are things people can do individually: 1) Use a pseudonym P from the start instead of X (which is admitted in the Guix community, just look at a few of the names: there are pseudo- nyms with clearly made-up first and last names, there are very obvious one-word pseudonyms, and maybe some of the names that look like real names are not from the persons' passports, who would know). 2) This does not help, of course, if you are already known as X and want to be known as Y. Then either you can somehow make the change publicly, and transfer your reputation and also the information that you used to be known as X, or disappear as X and reappear as a new person Y and lose X's reputation. Doing both is impossible, I would say. Andreas
Re: (Lx)Qt team in Guix
Hello, Am Thu, Mar 07, 2024 at 08:46:12PM -0500 schrieb Maxim Cournoyer: > I think the reason qt.scm is part of the lxqt team is historical; lxqt-team > predates qt-team. We should probably just remove qt.scm from > lxqt-team's scope. What do you think? > > I'd keep both team separated; I'm interested in maintaining qt upgrades > but not much lxqt. that sounds good to me as well; and I would then encourage 宋文武 and Hilton to join the Qt team, too. Andreas
Re: You're invited to the first patch review session!
Hello, Am Tue, Mar 05, 2024 at 07:19:46PM + schrieb Etienne B. Roesch: > Anything we need to have prepared by Thursday? > I imagine a ubuntu vm running with vanilla guix installed is installed? you should have a means of running Guix, and so that your store gets populated with recent basic things, I would also suggest to run a "guix pull". It can be a virtual machine, a full Guix system, or simply a "foreign" distribution with Guix as a package manager. (I am not sure what you mean by "is installed"; I do not think Steve plans to install a machine shared between the participants, please bring your own!) Then you should clone the git repository as the basis to apply patches, as explained here: https://guix.gnu.org/en/manual/devel/en/html_node/Contributing.html I think reading the first two subsections 22.1 and 22.2 is enough to get started. Notice that building Guix takes a rather long time; on my oldish laptop with two cores, about half an hour. So this should be done before. Looking forward to tomorrow, Andreas
Re: Contribute or create a channel?
Am Sat, Mar 02, 2024 at 11:32:37AM +0100 schrieb Hartmut Goebel: > Maybe using one file per release (and accept duplicate code) would be a > suitable workaround. I think that would be okay if you think it will be easier to maintain (not needing to "roll over" code from an old package at the inheritance root when it is deleted), assuming that the old packages are removed from time to time. Andreas
Re: Guix Days: Patch flow discussion
Hello Dan, thanks for your thoughts! I think I will restrict my replies to guix-devel to keep them in one place; the following are just my personal opinions. Am Thu, Feb 29, 2024 at 03:41:41PM + schrieb Daniel Littlewood: > Something that is not obvious to me when people refer to reviewing patches, is > whether this is purely a matter of adding new packages to the main guix > channel, or of reviewing changes to the system in general, or both. As a > novice, I can imagine becoming comfortable as a package reviewer much more > quickly than as a reviewer of core patches to the system. Both! And indeed what you write is correct, reviewing packages is easier than services, which is probably easier than other changes. (Personally, I feel confident only with packages.) Of course then people should only review things they are comfortable with. > It's also not obvious to me whether you mean exactly "reviewing a backlog of > existing patches" or additionally "increasing the amount of patches submitted > and applied". I feel like both are probably good things but I can't tell what > you're focussing on exactly. If lots of gems were imported from other repos > like RubyGems and PyPi, which as I understand it is currently a > partly-automatic partly-manual process, would that be considered a win? What > about increasing version coverage among those packages that are covered? The discussion was about the backlog; in particular also about negative feelings by contributors of patches that take a long time to be applied. Of course adding more packages is also a welcome activitiy (but only makes sense if enough of them are applied in the end...). We concentrated on "reviewing" to ease the burden of "committers", since reviewing is open to anybody. > One point brought up here is about tooling. I wonder whether there is any > scope > for fully automatic review. I do not think so. Quality is an important aspect of Guix; for instance, we ask for non-marketing descriptions, which would be difficult to test automatically. We already have "guix lint", which does some of the work. And there are fully automated channels such as for CRAN, but which then are potentially of a lesser quality. Notice that "easy" packages are also easy to review; most of the time, there is not much to do about the result of "guix import pypi ...". Things become more tricky when phases need to be added, to understand what is going on, and then I usually also look at comments (or criticise their absence). > I think some people are just scared off socially by the idea of having to > join a > meeting in order to learn how to do reviews well. Agreed, there should not be any "having to join a meeting". The idea of organising one comes from the goal of making the activity more social and less boring. Apart from that, you can start today and need not wait for a bug squashing party :) Andreas
Re: You're invited to the first patch review session!
Am Thu, Feb 29, 2024 at 05:10:56PM + schrieb Daniel Littlewood: > * I think the meeting is at 18:00 UTC, which is the same as 18:00 GMT, > which is the same (on March 7th) as 18:00 London time > Meetup also says 18:00 GMT. Yes, that is the plan! Andreas
Re: Creating 2024 internship page
Hello, Am Thu, Feb 29, 2024 at 12:28:29AM +0100 schrieb Gábor Boskovits: > I had a look at the libreplanet today and tried to add an internship page for > 2024, but it look like I have no permission to create a page in the guix > group. > It also shows me the group main page as protected. Can someone arrange access > for me or create the page and send me the link. It looks like I can edit pages > without any issue once they are created. I do not know where I gathered this magical power, but I can create pages; here it should be: https://libreplanet.org/wiki/Group:Guix/Outreachy-2024 Strangely, it is not (yet?) referenced from the main page https://libreplanet.org/wiki/Group:Guix but I hope it can get you going. Andreas
Rust team branch merged
$ git status On branch master Your branch is behind 'origin/master' by 1438 commits, and can be fast-forwarded. (use "git pull" to update your local branch) $ git log origin/master commit f29f80c194d0c534a92354b2bc19022a9b70ecf8 (origin/master, origin/HEAD) Merge: c034088e37 7947d47c9b Author: Efraim Flashner Date: Wed Feb 28 12:18:45 2024 +0200 Merge branch 'rust-team' Change-Id: Iee31c5de29c357c822f60df4fa8ce758779eb349 Congratulations to the Rust team (aka Efraim) for this big endeavour! Andreas
Re: Core-updates coordination and plans
Hello Felix, Am Mon, Feb 26, 2024 at 07:26:57AM -0800 schrieb Felix Lechner: > How about a 48-hour period every month in which commits are permitted > even if they cause "world rebuilds"? > We could pause the substitute builders during that period. It would get > rid of core-updates forever. a time-based approach sounds like a good idea indeed; if just for things like ungrafting, which are considered extremely low risk. It might still be good to do it in a separate branch instead of master, and to merge it after substitutes are available. Since "guix pull" takes the latest commit from the master branch, users could otherwise end up with a world-rebuild commit without substitutes. So maybe we could have a time window, but also discuss and prepare before- hand which big changes we would like to push? Having a team or a dedicated individual (in both senses of the terms, a designated person with a lot of dedication) to shepherd this through would also be good. Andreas
Re: Proposal to turn off AOT in clojure-build-system
Am Thu, Feb 22, 2024 at 03:57:41PM +0100 schrieb Maxime Devos: > Yes. It appears you are unfamiliar with (...) > It also appears you are unfamiliar with (...) May I suggest to not make assumptions about what other people are familiar with or not? There is no point in claiming that others are less knowledge- able than you; they may know as much or even more than you, and still come to different conclusions. (And even if people were unfamiliar with something, I would object to this haughty tone and suggest a more pleasant way of making suggestions.) For instance concerning the topic at hand, knowing that users may transform packages as they wish to me seems to be independent of which default choice we should make for the distribution. Andreas
Re: Guix Days: Patch flow discussion
Am Fri, Feb 16, 2024 at 11:56:50AM +0100 schrieb Clément Lassieur: > Would it makes sense to have a "does-not-apply" tag too? Should this not appear in the QA page, assuming that once all the new issues are closed, older ones will bubble to the top and be treated by QA? (I am not sure if just looking at the n latests issues is how QA works, but I think so.) Andreas
Re: Committers available for Patch hacking/review meet-up?
Hello, thanks, Steve, for getting things going! Am Tue, Feb 13, 2024 at 02:48:08PM + schrieb Steve George: > We said they'd be every 13 days, for 3 months to see if it has interest. > Proposed calendar: > 7th March (Thursday) I will be around on this day. > 2nd April (Tuesday) > 15th April (Monday) > 3rd May (Friday) > 16th May (Thursday) > 29th May (Wednesday) > Each one held at 19:00 CET / 18:00 BST / 13:00 EST [0] for 1.5 hours. For these, we will have the daylight savings time switch; so maybe we should move to 19:00 CEST. Something we can do later. > What I propose is that we'd do the following: > 1 - 30 mins: a committer runs through their review process, and shows a > recent patch or patches they've reviewed. Really informal showing what they > do. Well, I only ever look at simple packages, and do not think I have anything resembling a process to share. But I will try to be around in any case :) Andreas
Re: QA is back, who wants to review patches?
Am Fri, Feb 09, 2024 at 04:08:45PM +0100 schrieb Tanguy LE CARROUR: > I’m "reviewing" `[bug#68997] gnu: lightning: Update to 2.2.3`… please > find another one! Now that you jump to complicated and not even yet built by QA packages, you are safe from my competition :) Andreas
Re: Guix Days: Patch flow discussion
Hello, Am Fri, Feb 09, 2024 at 05:35:44PM +0100 schrieb Edouard Klein: > Am Thu, Feb 08, 2024 at 07:56:48PM + schrieb Skyler Ferris: > > I'd like to do my part to keep the project in a good state. However, I > > am new to interacting with large FLOSS projects so I'm nervous about > > causing more problems than I solve if I just start doing things. > Same here. no need to be nervous! I would suggest to just start somewhere and learn by doing. For patches, anyway the committer takes the final responsibility; so if you can just add, for instance, "I use this package and it works for me" this will be a useful point. And do not be afraid to make mistakes; I have been taking part in Guix for a long time now, and of course make mistakes from time to time. That happens, and they can be corrected if they occur. What I find important is to be upfront about them, and to ask for help if needed. Andreas
Re: QA is back, who wants to review patches?
Hello, I see a few "Failed to process revision", for instance here: https://qa.guix.gnu.org/issue/68778 While I am not sure why, these look like transient (?) build failures, at least failures not related to the patch in question. What is there to do? Andreas
Re: QA is back, who wants to review patches?
Am Fri, Feb 09, 2024 at 02:53:59PM +0100 schrieb Tanguy LE CARROUR: > Quoting Christopher Baines (2024-02-09 14:44:25) > > Tanguy LE CARROUR writes: > > > Can I safely close it?! > > > > Yep, this unfortunately looks like a case where there was a duplication > > of effort and the original patch got ignored. > > > > It looks like the issue has been closed now. > Not me! As the old German saying goes, "two idiots, one idea" :-) I also immediately jumped to this easy looking patch, came to the same conclusion as you and closed it. This is a lot of review work for a patch where there is nothing to do... Actually the next patch I tried to apply was also already there, and the committer had just forgotten to close the issue. Andreas
Re: bug#68920: Issues with issues.guix.gnu.org (502 Bad Gateway)
Am Tue, Feb 06, 2024 at 09:22:43AM -0500 schrieb Maxim Cournoyer: > Thanks for the report. It occurred a few times in the past weeks, where > the 'mumi' service had to be restarted on Berlin. Let's keep this open > to see if it'll occur again. Otherwise I'll close it in a week or two. It has happened for me last evening, so it does not seem to be definitely fixed. Andreas
Re: Core-updates coordination and plans
Hello, Am Wed, Jan 31, 2024 at 05:44:21PM +0100 schrieb Josselin Poiret: > One conundrum we have for now: glibc 2.38 has a couple of new CVEs, and > we have three options: > 1) change glibc to track the 2.38 release branch → world rebuild. > 2) graft glibc → bad user experience (and we're not supposed to graft > outside of master). > 3) switch to 2.39 → world rebuild + possibly more work fixing new build > failures. I would go for whatever fixes the security problems (obviously) and leads to a faster merge. Probably 1), which, if I understand correctly, means using a newer point release or git commit of glibc-2.38 that fixes the CVEs and has a low chance of fundamentally breaking things. Then in the spirit of feature branches, we could have a feature branch "core-team" (not "core-updates"!; well, I do not care about the names, but about the mental idea we attach to them) updating glibc. 2.39 might delay the merge for more months if things do not go well, but you are probably better placed to judge how big the risks are of a lot of breakage. I am also not that worried about world-rebuilds: We should be able to do a world-rebuild not once or twice a year, but at least every month, say, or maybe every week. If this is not the case currently, it is an infra- structure problem that we should try to address. (Relatedly, we should ungraft more often; there are now packages with over 100 grafts, and in updating the system behind a fast internet line, grafting ends up taking a non-negligible proportion of the total time, even on an SSD.) In any case, thanks for your work on getting things in shape! Andreas
Re: [bug#68606] role of core-updates
Am Wed, Jan 24, 2024 at 02:22:08PM -0500 schrieb Maxim Cournoyer: > Since patchelf is core material, if the rest of the series depend on > that update, it should go to core-updates as well. If I understand correctly, the series just needs patchelf 0.18, which is already in core-updates. So I will wait until core-updates is merged to look at the remainder of the series. Andreas
Re: role of core-updates
Hello, Am Sat, Dec 09, 2023 at 11:33:54AM +0100 schrieb Andreas Enge: > Am Sat, Dec 09, 2023 at 11:16:14AM +0100 schrieb Ludovic Courtès: > > With that in mind, ‘core-updates’ would effectively become the branch of > > the ‘core-packages’ team: the branch where we update packages in these > > files (primarily the toolchain and Guile), perhaps also (guix build > > utils), and that’s all. > > How does that sound? > Sounds good, thanks to you and Maxim for thinking it through! is the current core-updates branch ready for building and merging? I am looking at an issue: https://issues.guix.gnu.org/68606 that adds a patch (updating patchelf) that, as far as I understand, is already available on core-updates. So I feel somewhat blocked for the issue. The last merge was in spring of 2023, I think, and my patch updating wget is lingering in the branch since last July. So I am afraid we are reenacting the problems we had with the historic core-updates branch. It would be nice to merge and to move the branch to its new purpose. Also, https://issues.guix.gnu.org/65200 from last August is blocked by a core-updates merge (it should probably go to the new-style core-updates branch, and would be the starting point of working on bootstrapping from a newer GMP). Andreas
Re: Guix at 37C3 Chaos Communication Congress in late Dec?
Hello, Am Thu, Jan 18, 2024 at 07:22:01PM + schrieb Fabio Natali: > The advantage of a Lisp assembly is the economy of scale. That'd combine > together various projects that were all massively under-represented at > 37c3 - I'm primarily thinking of Guix, Guile, and Emacs as those are the > projects I care about, but there are others too. I think that indeed anything that will assemble the Guix and Guile communities is a good thing! Something to decide by the people who will attend, for me CCC comes at one of the least convenient times of the year. All the best in your community building endeavours! Andreas
Re: Guix at 37C3 Chaos Communication Congress in late Dec?
Hello Fabio, Am Mon, Jan 01, 2024 at 01:49:24PM + schrieb Fabio Natali: > The introductory session on Day 1 wasn't so bad, I think. Given the low > level of feedback on the Fediverse I was expecting very few people, > instead I think we were north of 30 participants! thanks for your report! This is quite amazing. One of the most depressing experiences at a CCC was when I went to a Lisp assembly, and there were at most a dozen people around a table, none of whom used the same Lisp dialect. So gathering so many people around Guix is very encouraging. And my (admittedly dated) experience seems to indicate that there is not much point in joining non-existant Lisp forces. Andreas
Re: [Guix-europe-sac] Shutting down qa.guix?
Hello, Am Sat, Dec 09, 2023 at 11:54:59AM +0100 schrieb Ludovic Courtès: > I think this underlines a collective failure to get our act together. indeed, and besides what Simon mentioned about the bank situation I think there was a certain lack of consistency between deciding on the technical and on the financial questions. And of course the lack of urgency, since anyway things continued thanks to Chris... So thank you for all you have done, Chris, and thank you for taking action now to force us to get our act together! Indeed QA has become a central part of our project infrastructure. I suggest the following, which resolves the lockstep between technology and finance: - Decide that the funds at the FSF pay for the hosting in its current form. Ideally move the billing to Guix Foundation, and then, as we use to do for bayfront, periodically ask the FSF to reimburse the hosting cost. I think we have an informal consensus for this, and just require a formal vote at the Guix spending committee and at the Guix Foundation SAC. - Reimburse Chris for the costs incurred for hosting before this move. As Simon has said, we have a vote for this already, but could also start over with the exact amount once the first point is handled, so that Chris does not pay for future hosting any more. Then in a separate step, other people can discuss about potential technical changes to the hosting situation. It would probably be good to have a small group of people, including Chris at least for a transitory period, who take care of the sysadmin part. Any thoughts on this proposal? Andreas
Re: Unreleased wget
Am Sat, Dec 09, 2023 at 12:47:32PM +0100 schrieb Ludovic Courtès: > I’ve now uploaded a copy of that tarball to ftp.gnu.org/gnu/guix/mirror. > As a rule of thumb, we should always store upstream tarball copies or > variants thereof on that server. Thank you for the fix, and sorry again for my mistake. Andreas
Re: role of core-updates
Am Sat, Dec 09, 2023 at 11:16:14AM +0100 schrieb Ludovic Courtès: > With that in mind, ‘core-updates’ would effectively become the branch of > the ‘core-packages’ team: the branch where we update packages in these > files (primarily the toolchain and Guile), perhaps also (guix build > utils), and that’s all. > How does that sound? Sounds good, thanks to you and Maxim for thinking it through! Andreas
Re: Questions about packages because of license and other
Hello Christian, Am Wed, Dec 06, 2023 at 09:36:06PM +0100 schrieb Christian Miller: > 1. PrismLauncher[0]: The software itself is licensed as GPL3 but it is > used to download and launch a proprietary videogame called > "Minecraft". Since it is itself GPL3 licensed but used for a > proprietary videogame, would it be allowed for upstream or not? > > 2: PCSX2[1]: Software itself is licensed as GPL3 but is used to > emulate a PlayStation 2 (game console), which is highly proprietary > hardware. It is also wishlisted on libreplanet[2]. It requires the > original proprietary BIOS (not distributed by the software) to run. > Since it is a game console, it also requires proprietary video games > (not distributed by the software). since we do not advertise non-free software and do not encourage users to install it, these two are not suitable for inclusion into Guix. > 3. impatient-mode[3]: This is an Emacs mode to write HTML and see it > in realtime rendered in the web browser. It has no license file. In > the file "impatient-mode.el" it says "This is free and unencumbered > software released into the public domain.". Is this suitable for an > upstream package? It looks to me not correctly licensed but I am also > not an expert in this and therefore unsure. This looks okay, we have a license:public-domain. Andreas
Unreleased wget
Speaking of core-updates, I made a mistake during the latest merge last spring. We needed a new wget release and the wget maintainers took some time, so I rolled a "non-release" 1.21.3.24 before the 1.21.4 release (in core-updates, commit 93f9c260ac333ae7b86bfaeeead674fe01d924ce updates wget to the 1.21.4 release, one more reason to hope for a merge soon), for which I stored a .tar.lz on a server of my own. However, this release does not exist (and I actually removed the file from the server, but for the time being keep it still around on my laptop, and it is still available in the build farm); and I did not realise it would break the time machine (which I did not use at the time). Is there a good way forward to allow a way backward? Sorry for the breakage, Andreas
Re: role of core-updates
Am Sun, Nov 26, 2023 at 10:53:46PM -0800 schrieb Andy Tai: > Hi, hope Guix maintainers can clarify the role of the now core-updates > branch; the current documentation does not specify the core-updates > branch as a thing but there are clearly interests and uses of this > branch for package updates not belonging to a feature branch like > gnome and it is useful for, say, updating to the GNU make package > which would have caused world rebuild. Thanks When we started implementing the teams idea, I thought we would get rid of the core-updates branch altogether. I still think it should not exist as such, but be folded into the teams workflow. I am still mildly worried that we have this branch into which many unrelated things get dumped, without a clear responsibility who pushes it forward and on which timeline. There is a "core" team, but this is probably not the same thing: I think there are packages outside of the core team scope that cause now inside the core-updates branch. Andreas
Re: "random check" approach to Guix QA?
Hello, Am Mon, Nov 20, 2023 at 03:11:29PM -0800 schrieb Andy Tai: > Can the same approach be borrowed here, so when there is large number > of impacted packages from a patch, say larger than 200, Guix QA just > randomly select a subset sample out of these packages and build them, > and in case of (new) failures ask the submitter to fix the (new) > failure? And repeat this as needed. This way patches can go thru the > QA process more quickly. notice that this approach requires to build a complete connected subgraph starting with the changed package, so simple random sampling will not work. For instance, if B depends on A, then C_1 to C_1000 depend on B, one needs to always include B. Or if B_1 depends on A, B_2 on B_1, and so on until B_1000 depends on B_999, one would need to only build a few steps on the path. Maybe it would make sense, one day when we have lots of idle build power, to start by building at least the immediate dependents to get an idea? Andreas
Re: Feedback (was Re: Meet Guix at Capitole du Libre in Toulouse)
Hello, Am Wed, Nov 29, 2023 at 05:01:12PM +0100 schrieb Simon Tournier: > Guix on foreign distro: > a) do not interact with foreign distro > => good complement and rolling release > b) containerized shell > => please developers and also "roll-back", although it is more important for keeping a bootable system. > 2. An explanation about what makes Guix different compared to X > where X is: > ii) Nix and NixOS > Sadly, we do not have a clear story for ii) IMHO. I would say "free software only" and "quality" (I am still traumatised by Nix "packaging" texlive through wrapping binary Debian packages). Plus what you mention about the unified programming language throughout. Andreas
Re: Upgrading Guix's security team
Hello, Am Thu, Nov 16, 2023 at 03:22:42PM +0100 schrieb Ludovic Courtès: > Yes, we definitely need a rotation here! I for one have my name there > but regardless of my interest, I have to admit that I’ve been unable to > be sufficiently responsive. It’s time to let new folks take > responsibility. > I think we should make this a fixed-term position, to make it easier for > people to commit to actually being active when needed, with the > understanding that it’s not a commitment for life. all this sounds good. Maybe we should also clean up the mailing list. I am on the list, but not mentioned on the security team site, and will be happy to be removed. (My being here probably comes from a mismatch between being interested in "security" and knowing things about "crypto- graphy", and my inability to act upon concrete situations of security problems in packages.) Andreas
Re: Reproducible Builds 2023 in Hamburg
Am Fri, Nov 03, 2023 at 12:26:52PM + schrieb Christopher Baines: > Oh, and I forgot to say with the help of Bernhard I added Guix support > to [3]. > 3: https://ismypackagereproducibleyet.org/ Exciting, congratulations! Andreas
Re: Meet Guix at Capitole du Libre in Toulouse, nov. 18-19
Am Tue, Oct 24, 2023 at 10:17:01PM +0200 schrieb Vivien Kraus: > > Some of us will be in Toulouse, INP-N7, 26 rue Riquet on 18 & 19 > > november for Capitole du Libre: > > We will stand in Village Associatif. Let us know if you can help us > > at the event. Well, I do not know exactly what means "a stand" since > > it will be the first for me. :-) I guess it mainly consists to be > > around the Guix booth, chat with people about why Guix is awesome! > > and > > maybe demo some Guix features. > > Feel free to share your ideas. :-) Personally I am always drawn to strange hardware. So if anyone coming has a single board computer running Guix (Guix system?), this would be nice to show. Actually we would also need a screen then; I have a spare one, but it would be difficult to transport by bus and train. We need stickers! Julien, were you not the one buying our latest batch? Maybe we could order more, we should have Guix Foundation pay for it. We need flyers! Maybe print a number of reference cards? It looks like the project is missing a promotional flyer to be given to attract newcomers. > Je compte bien y aller ! Chouette! L'idée serait que plus on est nombreux, plus on peut alterner sur le stand et aussi profiter nous-mêmes de quelques présentations et autres stands. Je viens les deux jours, mais arrive assez tard samedi (11h27 à la gare) et repars assez tôt dimanche (17h24 de la gare). Andreas
Re: [workflow] Automatically close bug report when a patch is committed
Hello, Am Wed, Sep 13, 2023 at 09:14:52PM +0200 schrieb Liliana Marie Prikler: > I do wonder how the ChangeId would work in practice. Since it's not > really assigned by the committer, it would have to be generated "on the > fly" and attached to the mail in between, which could result in all > kinds of nasty behaviour like unstable Ids or duplicated ones. this one would be easy to solve: it could just be the hash of something. For instance, it could actually be the commit "number" itself of the commit when it is first created. Andreas
Re: Guidelines for pre-trained ML model weight binaries
Hello, related to this thread, I just came across an entry in Cory Doctorow's blog: https://pluralistic.net/2023/08/18/openwashing/#you-keep-using-that-word-i-do-not-think-it-means-what-you-think-it-means It is already interesting in its disection of the terms "open" vs. "free", which is quite relevant to us (but just echoes the sentiment I had anyway). The end can be seen as an invitation to *not* package neurol network related software at all: by packaging "big corporation X"'s free software, but which is untrainable on anything but big corporations' hardware, we actually help big corporation X to entrap users into its "ecosystem". Andreas
Re: How can we decrease the cognitive overhead for contributors?
Am Mon, Sep 04, 2023 at 10:23:45AM + schrieb Attila Lendvai: > - large backlog. contributions somtimes even fall through the cracks. My impression/hope is that the recent introduction of teams leads to improvements on this front. I am on the science and texlive teams and have been getting emails from the patch submission workflow; so these end up in my inbox and I feel responsible for them. As a consequence, I have been reviewing more commits recently. For this to work, we would need a 100% coverage of modules by teams (a necessary, not a sufficient condition...). A consequence of my focussing on email is that I essentially ignore everything that does not come in by email (well, I also look at the green badges in QA from time to time). So, my impression/hope is that also QA leads to improvements. This does not solve the problem of finite time and competence, however. Andreas
Re: How can we decrease the cognitive overhead for contributors?
Am Mon, Sep 04, 2023 at 08:44:18AM -0400 schrieb brian via Development of GNU Guix and the GNU System distribution.: > > - strict adherence to changelog style commit messages without a > >clearly worded and documented argument about why it's worth the > >effort in 2023. whenever 'C' fails to add an entry to the commit > >message in Emacs, i groan out loud. > Regarding the GNU changelog commits, I really dislike them. They're > redundant busy-work as far as I'm concerned. And while I'd like to say > they're no longer necessary, because we have better tooling As said before, I use them all the time through git log | grep "whatever I am looking for" or the interactive git log then "/" for searching inside the less command; I find it useful to a point that I have moved to this style for all my coding projects. So as far as I am concerned, they are tremendously useful. Well, that may be due to a lack of git knowledge, of course! But while in other projects I often find I need to look at the content of commits, in Guix it is often enough to just look at the changelog. Andreas
Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net
Hello jgart, Am Mon, Sep 04, 2023 at 05:48:05PM + schrieb jgart: > Old tickets are not kept around. > For example, A branch for ticket 51810* does not exist anymore. this is probably due to the fact that the git repo did not yet exist at the time. The oldest issue I see is 60286 from December 2022, which looks compatible with this hypothesis. So this patch fell completely through the cracks! We should indeed spend some time going through old tickets (this, for instance, at first glance looks like it could be applied, others may simply be dropped). Andreas
Re: How can we decrease the cognitive overhead for contributors?
Hello Katherine, thanks for your summary, which contains many points I would agree with and actionable items (disclaimer: I do not promise to act on them). Am Wed, Aug 30, 2023 at 10:11:02AM -0600 schrieb Katherine Cox-Buday: > Here's my understanding of the process to contribute a patch: My process is actually a bit easier... > 5. Create a git worktree for your patch > 6. Run `./bootstrap`, then `./configure --localstatedir=/var > --sysconfdir=/etc` You can drop 6 assuming you do not create a new .scm file. Instead of 5, I usually just branch off from master, or simply work on master itself (for instance, for a simple package update). In the latter case, after creating and sending the patches, a "git reset --hard origin/master" drops all my work. > 8. Make your changes > 9. Build to ensure your changes are workable. > 10. Try and determine how your changes should be factored into individual > commits (sometimes it's not always so clear when changing two things > might > need to be done atomically). > 11. Try and get each commit message close to correct and commit. Usually I start with 10, and then make the changes incrementally. For instance, today I wanted to update a package and change an input. I simply changed the input first, built and made a commit. And then I updated the package, built and invoked ./etc/committer.scm. Admittedly, I also do not do all the checks you mention, like closure sizes or reproducibility of the builds. Andreas
Re: How can we decrease the cognitive overhead for contributors?
Am Wed, Aug 30, 2023 at 02:22:01AM +0200 schrieb Danny Milosavljevic: > Writing the metadata into the commit messages is annoying. It totally should > be automated, especially since Scheme has pretty simple syntax (so it should > be easy to write such a thing/famous-last-words). It should just figure out > which procedures the changed lines were in, automatically. It does exist inside git itself for C code; "git diff" always shows the function in which I make a change. I agree it should be easy to have the same support for scheme. Andreas
Re: SSSD, Kerberized NFSv4 and Bacula
Hello, just a tiny comment to one of your points: Am Thu, Aug 24, 2023 at 07:55:05PM + schrieb Martin Baulig: > 1. GNU Guix is currently using nfs-utils 2.4.3, whereas 2.6.3 is currently > the > latest version. We don't need to upgrade, but I would like to backport > one > change, affecting a single function. This is needed for idmap-daemon to > work with arbitrary plugins. Is there a drawback to updating? We usually ship the latest version (as long as a volunteer does the update, that is); so if there are no compatibility problems, a patch to update to the latest version would be welcome. Andreas
Re: How can we decrease the cognitive overhead for contributors?
Am Wed, Aug 30, 2023 at 08:39:17AM + schrieb Attila Lendvai: > just now i wanted to take a look at mumi's sources, but the link in the > manual (https://git.elephly.net/gitweb.cgi?p=software/mumi.git) times out. There is a mumi package in guix, and it gives the source location as https://git.savannah.gnu.org/git/guix/mumi.git/ So this has become an official guix subproject! Andreas
Re: documentation in TeX Live collections
Hello, Am Mon, Aug 28, 2023 at 06:54:35PM +0200 schrieb Nicolas Goaziou: > Emmanuel Beffara writes: > > I don't understand how "out" and "doc" are different in this respect. The > > "out" output of a collection meta-package has no content of its own and it > > only serves to gather the "out" outputs of its inputs. Similarly, the "doc" > > output would have no content of its own and only gather the "doc" outputs of > > its inputs. How is that inconsistent? > > > Outputs are used to split files to be installed after building > a package. Since meta-packages do not build anything, there is nothing > to install, and therefore, to split. The default output is enough. if I understand things correctly, we would like the following behaviour for propagated inputs in the texlive context: We have these metapackages with propagated inputs; all of these inputs have "out" and "doc". Then we would like to automatically create "out" and "doc" for the metapackage, into which the corresponding "out" and "doc" of their "ingredients" are propagated. Well, more precisely, the metapackages are empty, so it is a bit fuzzy what I mean by "into which" above. We would like the following: - If a user installs metapackage:out, they get all the ingredient:out in their profile. - If a user installs metapackage:doc, they get all the ingredient:doc in their profile. I am quite certain this is not how propagated inputs work, and I do not know whether their behaviour could be changed in this way. The documentation is a bit unclear: https://guix.gnu.org/de/manual/devel/en/guix.html#package_002dpropagated_002dinputs "propagated-inputs is similar to inputs, but the specified packages will be automatically installed to profiles" What is a "package" in this context? I think it means all outputs of a package. But then we should already have all the documentation with the metapackages, right? And indeed, when installing texlive-scheme-medium into my profile, I have lots of downloads such as texlive-tex-ini-files-66594 3KiB 452KiB/s 00:00 ▕██▏ 100.0% texlive-tex-ini-files-66594-doc 1KiB 257KiB/s 00:00 ▕██▏ 100.0% (every package twice with its -doc). So as a first observation, separating the doc output serves no purpose: it will be downloaded anyway, and actually forms the bulk of the whole texmf-dist. The above package is not typical in this respect, here is another one: texlive-upmendex-66594 77B 33KiB/s 00:00 ▕██▏ 100.0% texlive-upmendex-66594-doc 945KiB 2.0MiB/s 00:00 ▕██▏ 100.0% But strangely, $HOME/.guix-profile/share/texmf-dist/doc is just a pointer to /gnu/store/a184f1m1mbwkccxyi86dn4mdamay6lw5-texlive-bin-20230313/share/texmf-dist/doc However, the doc output of texlive-tex-ini-files has a share/temxf-dist/doc with a subdirectory generic/, which thus does not appear in the profile. See also https://issues.guix.gnu.org/65550 I do not really understand what is happening. All outputs are downloaded, but only the out outputs are propagated? If this is true, then I think it would make sense to not split into two outputs, but to always include the documentation in the texlive packages. Andreas PS: Something else that is strange: I end up with $HOME/.guix-profile/share/texmf (without the -dist suffix) that points to /gnu/store/lzq5fd5b2l3341s0da5a1vzhxc1li3yb-asymptote-2.86/share/texmf
Non-committer comments on patches
Hello, Am Sat, Aug 26, 2023 at 07:42:13PM +0200 schrieb kias...@disroot.org: > I would like to hear from committers if non-committer reviews are helpful, > because I don't really know how or what I can comment on for incoming > patches on packages I'm not really familiar with. > Also do "this builds and works locally" comments help? +1 for Liliana's comment on "works locally". "Builds locally" is superfluous, as I always rebuild packages I commit (and there is QA). As a member of the science team, I end up being "responsible" for packages I do not use and cannot really judge. So having a second person comment that a change works as expected, or that an old version can be dropped, or cannot be dropped because everyone in the community uses it, or anything indeed related to the use of the package, is a big help. I have even ended up solliciting comments by people who have worked on the package in the past. I can also imagine a go team, say, of non-committers, and then committing on their behalf when two team members agree with a patch, for instance. (With the goal of adding committer(s) from the team eventually.) Andreas
Re: Why does Guix duplicate dependency versions from Cargo.toml?
Am Fri, Aug 25, 2023 at 03:56:56PM +0100 schrieb (: > Zhu Zihao writes: > > and AFIAK, Maxime Devos is working on new build system called > > "Antioxidant", which can build rust application without cargo (Yes, > > invoke rustc directly!), The new build system will cache the rlib > > intermediate result of crate and share between different builds. > Sadly, I think that's been abandoned :( My impression is that Maxime has left the Guix project, so that the work was naturally abandoned, but there was no conscious decision that it should be dropped. So it would be nice if someone knowledgeable about the topic could pick it up and finish the build system. Andreas
Re: How can we decrease the cognitive overhead for contributors?
Hello, just a quick reply with what I do personally as one irrelevant data point :) Am Fri, Aug 25, 2023 at 08:07:53AM + schrieb Attila Lendvai: > i couldn't even find out which tools are used by those who are comfortable > with the email based workflow. i looked around once, even in the manual, but > maybe i should look again. No tools at all, I would say, which indeed may be a bit inefficient... Or: terminal, mutt, vim, git A bit of web for browsing the manuals (of Guix and Guile) and issues.guix.gnu.org But then I type much faster than I click. > i'm pretty sure most maintainers have a setup where the emailed patches can > be applied to a new branch with a single press of a button, otherwise it'd be > hell of a time-waster. mutt save message to /tmp/x git am /tmp/x or something like this or: git clone https://git.guix-patches.cbaines.net/guix-patches/ git checkout issue-x git format-patch ... then in the development checkout of Guix: git am ...; make; ./pre-inst-env guix build > one fundamental issue with the email based workflow is that its underlying > data model simply does not formally encode enough information to be able to > implement a slick workflow and frontend. e.g. with a PR based model the > obsolete versions of a PR is hidden until needed (rarely). the email based > model is just a flat list of messages that includes all the past mistakes, > and the by now irrelevant versions. For this, I either go to issues.guix.gnu.org to download the newest patches, in case the message is not in my inbox. Otherwise I do not get your point: I keep untreated messages with the latest patch version in my Guix inbox, and file away the others in a separate mbox. So things are not flat, but have two levels: "to be treated" or "done". Nothing to be documented, really, and I do not know whether these are just personal habits or whether others work similarly. These might be the ways of an aging non-emacs hacker... > https://sourcehut.org/ This comes up a lot in the discussion and looks like an interesting solution. It would be nice to be able to accomodate diverse styles of working on Guix beyond (but including) emacs and vim. Andreas
Re: How can we decrease the cognitive overhead for contributors?
Hello, Am Wed, Aug 23, 2023 at 10:27:31AM -0700 schrieb Felix Lechner via Development of GNU Guix and the GNU System distribution.: > > I can't ever seem to get the GNU style commit messages correct. > Neither can I. The style apparently helps with automated maintenance > of the changelog, but I do not understand why a changelog is useful > for a rolling release model. personally, I find them super helpful to grep through commit messages to find changes, like when a file was touched for the last time (now I think that git wizards will have a better solution; but you get the idea). Or when a package was added. Or updated to a specific version. I have ended up adopting the style for all of my other coding projects as well because I find it so useful. For simple updates, there is etc/committer.scm. I use it for package updates. It would be nice if it could handle more cases, such as removing patches. > > I don't use the email-based patch workflow day-to-day > Yeah, I can deal with small inline patches, but Guix requires changes > to be split into many tiny commits. This is explained here: https://guix.gnu.org/de/manual/devel/en/html_node/Sending-a-Patch-Series.html I also cannot remember what to do when there is more than one patch, so I follow this approach every time. (Well, this is a white lie; mostly I propose single patches or work in a branch...) All in all, I think better tooling will be welcome (but is not a joy to write). Am Wed, Aug 23, 2023 at 10:25:58AM -0600 schrieb Katherine Cox-Buday: > * Contributing to Guix is not for you > * It's OK to make lots of mistakes Definitely "no" to the first one, and "yes" to the second one! I think that even when one only contributes from time to time, but regularly, habits will form and mistakes disappear. > * We could support a managed web-based workflow I am all for it if it supplements the email based workflow (every time I need to do a modern style pull request type action, I am completely out of my depths and lost in the web interfaces...). But someone would have to write and maintain them... > * Encourage upstream communities like "Guix 'R Us" Why not, but they also require management (adjusting the schedules of several busy people, for instance). Andreas
Re: poetry: python-poetry?
Am Wed, Jul 26, 2023 at 09:25:43PM -0700 schrieb Andy Tai: > curious poetry is not named python-poetry in Guix as following > convention of most python packages See here: https://guix.gnu.org/de/manual/devel/en/html_node/Python-Modules.html The idea is that "libraries" (or "modules") start with python-, while "applications" do not emphasize the language they are written in. Calibre, for instance, also is not called python-calibre. Of course with script languages there is no clear technical barrier; but a package with lots of binaries will not start with python-, while software that is mainly used in lines "import xyz;" tends to be called python-something. Andreas
Re: pending mate upgrade patches to 1.26
Am Mon, Jul 24, 2023 at 09:28:38AM -0700 schrieb Andy Tai: > Hi, these patches have been merged by Mr. Song (iyzs...@envs.net) . He worked > to get these built without the two extra patches. Thanks So closing the bugs https://issues.guix.gnu.org/64001 and https://issues.guix.gnu.org/64012 ; if this was a misunderstanding, please feel free to reopen them or to submit new patches. Andreas
Re: Scheduled monthly update for (gnu packages astronomy)
Am Sun, Jul 02, 2023 at 10:36:26PM +0200 schrieb Ludovic Courtès: > You’re now well known so pretty much the only thing I would wait for as > a reviewer before applying these updates is (1) a green light from > qa.guix, This looks like it lags behind now. > and (2) a bit of spare time. Ah, we should not wait for the impossible to happen! ;-) The status of the patches is unclear to me, it looks as if some of them have been rewritten and merged by Tobias (maybe this also confuses QA? do the patches still apply?) But I find it difficult to understand what needs to be done still. For instance, there is a patch "stuff: Update to 1.26.0-0.9008dc0", but it is already at version 2.0.1 in master. How about sending a second version for the remaining patches on top of current master? Andreas
Re: python-nbconvert build fails
Am Sun, Jul 23, 2023 at 08:23:36PM +0100 schrieb Christina O'Donnell: > Sorry, I've just seen this is a duplicate of > https://issues.guix.gnu.org/64729. > I should have checked there first! No problem, thanks for the report anyway! The package builds now, so a new "guix pull" should be enough. Andreas
Re: pending mate upgrade patches to 1.26
Hello Andy, Am Mon, Jun 26, 2023 at 12:09:41PM -0700 schrieb Andy Tai: > The state of them is that there are two prerequisites that have passed > Guix QA check: > https://issues.guix.gnu.org/64001 I had a quick look at this patch, but am a bit confused. If I read it correctly, it updates tzdata (which causes a lot of rebuilds, and without updating python-pytz as stipulated by a comment in the code of tzdata), and then it creates a new variable tzdata-next which looks to be the same. Would the good approach not be to update tzdata and python-pytz, and to copy the old version into tzdata-for-tests? It is quite possible I am misunderstanding something, and in any case I would like to defer to someone more knowledgeable about the core packages. Andreas
Re: guidelines for package names (namespaces?)
Am Wed, Jul 05, 2023 at 08:19:48PM + schrieb John Kehayias: > This is a good question and one I wonder about when packaging > sometimes. The general guideline I've seen expressed in Python land at > least (not sure if this is in the manual, but this discussion can go > towards clarifying) is that generally "libraries" get the "python-" > prefix but end user "applications" don't. I believe this is true for > Golang as well, though exceptions abound. See here: https://guix.gnu.org/de/manual/devel/en/html_node/Package-Naming.html https://guix.gnu.org/de/manual/devel/en/html_node/Python-Modules.html https://guix.gnu.org/de/manual/devel/en/html_node/Perl-Modules.html I think there are no explicit rules for other languages, but the Perl and Python approach has been taken as a general model. > a related issue is that currently there are two parallel registries for guix > packages: > 1) module-global variables in the guile module system > 2) the reified package registry of guix. > the relationship between these two is not clear, there are no formal rules, > or even guidelines. they are pretty much orthogonal. See the first link above: "Both are usually the same and correspond to the lowercase conversion of the project name chosen upstream (...)". Andreas
Re: Branch (and team?) for mesa updates
Am Wed, Jul 05, 2023 at 09:47:06AM -0600 schrieb Katherine Cox-Buday: > I disagree with this because it seems like Mesa moves along at a pretty > brisk pace and I feel like we'd be constantly recreating the same branch: > 23.1.3, 2023-06-22 (14 days) > 23.1.2, 2023-06-08 ( 9 days) > 23.0.4, 2023-05-30 ( 5 days) > 23.1.1, 2023-05-25 (15 days) > 23.1.0, 2023-05-10 I doubt we would be able to move at such a brisk pace and update mesa every other week! It is a package with more than 4000 dependents, so in any case it would be good to regroup with somewhat related changes. Andreas
Re: Branch (and team?) for mesa updates
Hello, Am Mon, Jun 19, 2023 at 06:25:04PM + schrieb John Kehayias: > Master can be merged into this branch just prior to a patches going to this > branch with the expectation merging back to master will be soon after and > changes are only affecting packages that won't be touched on master anyway. I > think this should be relatively clean and straightforward, a good use of our > new branching/building strategy. I am a bit wary of branches just sitting around; after a while we will forget whether a branch still needs merging, or is just a placeholder. So I would suggest to delete every branch right after merging, and then branch off of master later when a new patch is going to be applied. This will also create a cleaner history by avoiding a merge. This is compatible with how cuirass works. We can keep the mesa-updates job, and when the branch does not exist, it will just do nothing. You just need to be sure to use the same branch name again next time, and it should be picked up by the cuirass job. Andreas
Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]
Hello, Am Sun, Jun 11, 2023 at 06:10:37PM -0700 schrieb Felix Lechner: > That was probably a misunderstanding. I meant to suggest with some > trepidation that 'master' is merged into the feature branch, and then > the feature branch is merged back into 'master'. I thought the two > merge commits would be signed by the person performing the merges > while the "origin seal" of the accepted change is also preserved. indeed, that is what we had been doing with the very long lived staging and core-updates branches in the past. Well, we used to repeatedly merge the master branch to core-updates, which if I remember well makes the master commits end up first in "git log". So the core-updates specific commits gradually disappear below thousands of master commits. So this is a problem. But Maxim is right about signatures, sorry for forgetting them time and again! One policy would be to *not* merge master back to the feature branch (or maybe just before merging the feature branch to master). This would work well for short-lived branches. Andreas
Re: Changes to the branching/commit policy
Am Sun, Jun 11, 2023 at 10:37:14AM +0100 schrieb Christopher Baines: > My reading of this line is that "adjusted" is probably not the right > word to use, but I think the intent here is to talk about how currently > it's accepted that people can and will push non-controversial changes on > parts they’re familiar with directly to master. I read it the other way round: Right now it is not accepted, but it might be adjusted to allow non-controversial changes in the future. Actually the concept of "non-controversial commits" is probably controversial in itself... Andreas
Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]
Hello, Am Sat, Jun 10, 2023 at 11:17:44PM -0400 schrieb Maxim Cournoyer: > > That to me says this should go to staging. > Correct. Except there's no staging branch anymore. I guess we should > create one? :-) I would say it should go to a team branch; xsystem? Regardless of name, I think the idea behind the team branch concept is that a branch should regroup related changes (as much as possible), but in any case there should be an identified person or group of persons taking responsibility for shepherding the branch up to its merge; and for repairing potential breakage. So we could extend the concept to have a june-2023-disruptive-changes branch, with the aim of regrouping several maybe unrelated changes leading to bigger rebuilds (and identified responsibilities). We should not create a random branch where lots of big changes accumulate for which nobody takes responsibility. The changes suggested at https://issues.guix.gnu.org/63459 remove the staging and core-updates branches from the documentation. Does it leave open problems behind? One thing I wonder about is whether we should not rebase all team branches on master instead of merging master back in. In this way, at least the commits specific to a branch would be visible since they are on top; with the former merging concept of staging and core-updates, they would end up buried deep in the commit history. It could also help keeping changes focused. What do you think? Andreas
Re: ping on a build fix for a build failure (main branch)
Hello Andy,
Am Tue, May 30, 2023 at 10:54:20AM -0700 schrieb Andy Tai:
> Hi, following previous comments (thanks) I have submitted a patch to
> correctly fix a build failure due to compiler warnings, instead of
> avoiding not building tests, on this Guix bug issue:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526
> Please review the patch (which shall be a simple and low risk fix). Thanks!
I have reworked a bit the punctuation of the commit message, shortened
the patch file name and pushed. By this I am closing the two corresponding
bug reports (it would have been enough to send a second version of the
patch to the first bug).
Did you contact upstream? Looking at the test, it looked wrong before and
after your patch...
if (len < token->data.character.len) {
hubbub_token t = { 0 };
t.type = HUBBUB_TOKEN_CHARACTER;
t.data.character.ptr += len;
t.data.character.len -= len;
...
Adding to a previously undefined, now 0 pointer .ptr raised a warning
for a reason, I think; and it looks like the t.data maybe should be
token->data. But it is quite possible that this branch is not even
reached by the test.
Andreas
Re: Changes to the branching/commit policy
Hello Chris, thanks for taking up this issue! I agreed with Ludovic's comments, so things look good now for me. A very minor point: In the section on "trivial" changes, I would drop this sentence (which was already there before): "This is subject to being adjusted, allowing individuals to commit directly on non-controversial changes on parts they’re familiar with." The sentence is meaningless, as everything is all the time subject to being adjusted; and we do not have immediate plans to adjust it. Looking forward to the merge since it clarifies things and removes the staging and core-updates branches not only from our minds, but also the texts. Andreas
Re: qtbase 6.3.2 FTBFS
Hello, Am Wed, May 31, 2023 at 08:20:15PM +0200 schrieb Josselin Poiret: > Does this happen on master? on the lastest master commit, qtbase@6 is available as a substitute (I did not check whether from berlin or bordeaux). Andreas
Re: Do substitutes download slowly for you? / Speeding up substitute delivery/mirrors
Hello, Am Thu, May 25, 2023 at 02:52:24PM +0100 schrieb Christopher Baines: > So please share the output from wget and if you're comfortable doing so, > the rough real world location of where the computer doing the > downloading is. I am in France with a 100Mb/s FTTH link, and download is fast from all of the mirrors. FR 5,59MB/sin 39s US 4,98MB/sin 53s SG 3,56MB/sin 73s The ordering looks consistent to me, but I am still surprised how good the connection is to Singapore! Andreas
Re: Transformations Shell Syntax
Am Tue, May 23, 2023 at 02:12:02PM + schrieb jgart: > > I think your semantics ends up meaning "try to make sense of the version > > field, and give me the package at this version". > Aren't these the current semantics of guix package transformations though? > I'm just proposing shell syntax for them. Yes, indeed. So there already is shell syntax, it is just a bit unweildy and verbose. What disturbs me with your suggestion is that it reuses the same syntax that is already used for a different purpose. So in a sense you do "operator overloading", and the same command line then means different things depending on whether the package version is already provided by Guix or not. Like Simon writes, let us be explicit. Andreas
Re: Transformations Shell Syntax
Hello, Am Tue, May 23, 2023 at 01:24:00PM + schrieb jgart: > I was openly ideating on having shell syntax like we do currently for > emacs-ement@0.9.3, for example, but for a subset of package transformation > options as well. I am a bit wary of too much intelligence in interpreting commands, at the expense of clarity (also for the user - what do they really do?) Right now, "guix build emacs-ement@0.9.3" means "build the package emacs-ement at version 0.9.3, which is available somewhere in my channels". I think your semantics ends up meaning "try to make sense of the version field, and give me the package at this version". This is actually quite different - for instance, it means the package is not vetted by Guix developers. So there may even be security implications. In my opinion we should strive for simplicity in commands, it should always be clear what a specific command line does and not depend on context, and the guix tool should not second guess what we want to do when invoking a given command. Andreas
Re: nudging patches
Hello Remco, Am Fri, May 19, 2023 at 11:48:08AM +0200 schrieb Remco van 't Veer: > Ruby 2.6 is EOL and 2.7 got it's "last" release in march > (https://www.ruby-lang.org/en/news/2023/03/30/ruby-2-7-8-released/). So > I guess 2.6 can be dropped and 2.7 may linger for a while? the announcement states that "After this release, Ruby 2.7 reaches EOL. In other words, this is expected to be the last release of Ruby 2.7 series. We will not release Ruby 2.7.9 even if a security vulnerability is found" So it would be best to try to get rid of it as soon as possible; if security vulnerabilities are not fixed, the working hypothesis is that the package has security vulnerabilities... > > Then there is an internal version ruby/fixed, which is very old, but, > > strangely, ahead of the public minor ruby version, @2.7.7. > It seems the ruby-2.7-fixed var has been orphaned by the latest > core-updates merge. It was used for grafting (used as an "replacement" > in the ruby-2.7 var) and my patch was still depending on that. I can > update the patch by reinserting the grafting bit. WDYT? Oh, I see. I am not familiar at all with grafting. But that would be an option indeed to avoid rebuilding. > > Could the remainder of ruby and other packages be made dependent on @3.2 > > instead of @2.7? > This will probably me a trail and error path leaning on tests included > in the packages. With your findings above about ruby@2.7, this looks like a worthwhile path! Andreas
Re: nudging patches
Am Wed, May 17, 2023 at 04:30:44PM +0200 schrieb Remco van 't Veer:
> What's the preferred / politest way to draw attention to patches (and /
> or bugs) which seem to have been overlooked?
No idea, ideally it should not be necessary ;-)
There is a certain backlog in the QA process so that your patches were not
built out on the build farm. Otherwise I think someone would have applied
(most of) them already.
> And while I have your attention and you're wondering which patches I'd
> like to promote..
> - #62557 [guix-patches]
> [PATCH] gnu: ruby-2.7-fixed: Upgrade to 2.7.8 [fixes CVE-2023-{28755,
> 28756}]
> - #62558 [guix-patches]
> [PATCH] gnu: ruby-3.0: Upgrade to 3.0.6 [fixes CVE-2023-{28755, 28756}].
> - #62559 [guix-patches]
> [PATCH] gnu: ruby-3.1: Upgrade to 3.1.4 [fixes CVE-2023-{28755, 28756}].
> - #62561 [guix-patches]
> [PATCH] gnu: ruby-3.2: Upgrade to 3.2.2 [fixes CVE-2023-{28755, 28756}].
I applied the last three ones, but not the first one, as it requires a very
big amount of rebuilds (more than 8000 dependent packages).
Maybe this could be an occasion for the ruby team to tidy up the
packages. We currently have five publicly visible ruby versions:
$ ./pre-inst-env guix package -A ^ruby$
ruby3.1.4 out gnu/packages/ruby.scm:232:2
ruby2.7.6 out gnu/packages/ruby.scm:163:2
ruby3.2.2 out gnu/packages/ruby.scm:246:2
ruby2.6.10 out gnu/packages/ruby.scm:110:2
ruby3.0.6 out gnu/packages/ruby.scm:215:2
Could the three middle ones be dropped?
Then there is an internal version ruby/fixed, which is very old, but,
strangely, ahead of the public minor ruby version, @2.7.7.
Could the remainder of ruby and other packages be made dependent on @3.2
instead of @2.7?
Andreas
Re: Feature branches
Am Wed, May 10, 2023 at 03:40:31PM +0200 schrieb Andreas Enge: > I just deleted the rust-team branch, we will see what happens. Apparently nothing. Here is an excerpt of /var/log/cuirass.log: 2023-05-10 15:44:10 Fetching channels for spec 'gnuzilla-updates'. 2023-05-10 15:44:19 Fetching channels for spec 'guile'. 2023-05-10 15:44:28 Fetching channels for spec 'guix'. 2023-05-10 15:44:28 evaluating spec 'guile' 2023-05-10 15:44:36 Fetching channels for spec 'kernel-updates'. 2023-05-10 15:44:45 Fetching channels for spec 'master'. 2023-05-10 15:44:54 Fetching channels for spec 'rust-team'. 2023-05-10 15:45:02 Fetching channels for spec 'shepherd'. 2023-05-10 15:45:03 Fetching channels for spec 'source'. 2023-05-10 15:45:12 Fetching channels for spec 'tex-team'. 2023-05-10 15:45:20 next evaluation in 300 seconds 2023-05-10 15:47:36 evaluation 459246 for 'guile' completed 2023-05-10 15:47:36 evaluation 459246 registered 0 new derivations 2023-05-10 15:47:40 evaluation 459201 for 'master' completed 2023-05-10 15:47:40 evaluation 459201 registered 136 new derivations 2023-05-10 15:50:20 Fetching channels for spec 'gnuzilla-updates'. ... Maybe this is a cuirass bug, maybe it is a feature, but it seems to survive without problem to an unavailable branch :) Andreas
Re: Feature branches
Am Wed, May 10, 2023 at 09:23:11AM -0400 schrieb Maxim Cournoyer: > Feel free to remove 'wip-cross-built-rust' Done! > We'd have to try, I would assume it may cause errors in Cuirass (it'd > make sense that it let you know: hey, you've defined a job spec that > won't build anything!) I just deleted the rust-team branch, we will see what happens. Andreas
Tooling for branch workflows
Hello all, the title says it all, I wish to share some conclusions from working on the core-updates merge. Clearly our tooling could be improved for the task; there was some flying by night without instruments, and in the end I merged the branch without being really able to tell how it compared to master... (You may also blame it partially on my lack of patience.) Having feature branches may or may not make things a bit easier, but it will definitely not solve the problems. This mail is also of course a bit politically sensitive: It may look like I am complaining about other people's work, who are volunteers and do what they can, without offering to work on the code myself. So as a preamble, let me express my gratitude to the few people who have been working tirelessly on our tooling and contributing to our infrastructure, without whom big code changes like we did on core-updates (and now on feature branches) would simply be impossible; their work is vital to the project and often not very visible. If I am critical, it is not to diminish their work, but to discuss about a positive path forward; and I hope more people will find the motivation to do infrastructure work, which I think will be decisive for the success of Guix (together with policy and organisational questions). We have two build farms, berlin and bordeaux (which is a good thing for checking reproducibility and for redundancy, but maybe a bit of a problem concerning hardware requirements for "exotic" architectures), running two different CI projects, cuirass and the Guix build coordinator (gbc in the following); both have a very low bus factor (1 to 2?), and it would be nice to get more people onboard. For this, more documentation would be helpful. Both have pros and cons, and are architectured quite differently, so I do not know whether convergence is achievable. I ended up relying mostly on cuirass for reasons I do not completely remember any more. The dashboard with its green and red dots is a very useful tool compared to lists of builds, which become unusable with over 2 packages. The bigger build power on bordeaux is helpful, and I found the web interface of gbc a bit slow and down a bit too often. With this experience, I just filed three wishlist bugs for cuirass: - Topological sorting in cuirass https://issues.guix.gnu.org/63412 The lack of ordering the builds is a big problem wasting a lot of build power; it is solved in gbc and, I think, the reason why the bordeaux build farm fares better for aarch64 with fewer machines. I would tag this as "important". - Evaluation comparison on cuirass https://issues.guix.gnu.org/63414 Without being able to compare a branch to master, it is difficult to decide whether one should merge. This is sort of solved in gbc, but so far the bordeaux build farm has been used more for QA of single patches (or a short list of patches featuring in a single issue) than for building complete branches. - Stop and restart builds in cuirass https://issues.guix.gnu.org/63413 Manual intervention is not easy in cuirass (I spent hours clicking on "restart" or using the REST API with a shell script through wget, which resulted in my IP being banned as a DoS suspect...); and to my knowledge, there is no web interface for doing so in gbc. In both systems one can probably tinker with the underlying databases, but this also does not qualify as "easy". gdb just got a very nice feature on "blocking builds": https://data.guix.gnu.org/revision/8f92dfd9ae7ac491ab7fb4b425799a8c909708a8/blocking-builds?system=aarch64-linux=none_results=50 As I understand them, these are the "first failures", derivations all inputs of which are available, but which fail themselves; so they give the place where work is needed (and repairs will immediately make a difference). Once the topological sorting in cuirass is sorted out, these should be the builds marked as "Failed" (as opposed to "Failed (dependency)"), so with the first issue above handled, they could easily be shown by cuirass as well. This was a long message to say "I filed three bugs", but maybe it can be the starting point to discuss more items on how to go forward with our build and CI infrastructure. Andreas
Re: Substitute not downloading
Am Tue, May 09, 2023 at 11:43:01AM -0400 schrieb Greg Hogan: > I have an up-to-date Guix but am unable to fetch the substitute from > http://ci.guix.gnu.org/build/1332269/details So the link indicates that the build has succeeded "19 hours ago", which would mean on May 9 around 14:30 UTC, which was about an hour before you wrote this message. > Are substitutes only available after the evaluation has completed? > --8<---cut here---start->8--- > $ guix describe > Generation 9May 09 2023 15:18:11(current) > guix c1ffe2f > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: c1ffe2f21bd1b9ba6bd527bbabe130144a69af71 > --8<---cut here---end--->8--- I think the substitute not being available may have to do with the difference between the package being available in the store, and as a nar file for substitution. As I understand it, the first request for a nar can fail, then it is built in the background, and a later request after a timeout will succeed. Hopefully offload specialists can correct potential misconceptions on my side ;-) Andreas
Re: Feature branches
Hello, Am Mon, May 08, 2023 at 01:01:05PM -0400 schrieb Maxim Cournoyer: > - I'd make the team branches permanent; e.g. the 'gnome-team' branch > would always exist, and get synced periodically to master (when enough > built/deemed stable). This should reduce the overhead of constantly > having to adjust the Cuirass specification jobs and serve as an > integration point for the team (the Cuirass job specs would be defined > declaratively in the guix-maintenance repository). I would argument the other way round :) For instance, I would now remove the rust-team branch so that it is clear that currently there is no work on rust. As soon as there is again, the team could spin off a new branch from master. This would avoid having branches around of which we do not know any more what they contain, and whether they contain unmerged changes. $ git branch -a | grep rust remotes/origin/rekados-rust-queue remotes/origin/rust-team remotes/origin/wip-cross-built-rust remotes/origin/wip-rekado-rust-team remotes/origin/wip-rust Can any of these be removed? Or brought up to shape? Notice that this is independent of the cuirass specifications (I think). I think we could keep the specifications on cuirass, but am not totally sure what happens when the branch does not exist. Probably nothing. And then it should be picked up again once it is recreated. > - branches judged too experimental to be merged into their team branch > could be branched from it, with a name such as 'gnome-team/feature-x' > to make it obvious where it should be merged when deemed ready. > Cuirass job specifications for such short lived branches would be > created manually using the Cuirass web interface (users need to be > authorized as can be done following > https://issues.guix.gnu.org/63375). > I don't think team branches should be merged together at any point, > ideally, to avoid loosing the benefits of feature branches (limited > scope). Agreed, if we start branching from branches and merging back, we will probably lose overview. With my take of not having permanent team branches, it might not even be necessary to branch from team branches. Andreas
Re: Feature branches
Am Mon, May 08, 2023 at 10:15:56AM -0700 schrieb Felix Lechner: > How about requiring prior to merging a feature branch that substitutes > exist for all changed derivations? It would prevent build failures and > preempt local builds, and thereby improve the experience for average > users. Taken absolutely, that sounds a bit excessive; but the idea is of course there, the branch should be built out as much as possible. It is probably unavoidable that some things stop working going forward, and I wonder how realistic it is to iron out all problems before a merge. Andreas
Re: RISC-V (riscv64-linux) substitutes are coming
Hello! Am Tue, May 09, 2023 at 02:40:21PM +0100 schrieb Christopher Baines: > This has been somewhat successful, you should be able to see the machine > (named rochor) on the prototype activity viewer [2]. These are exciting news! Does it mean that this bug, for instance: https://issues.guix.gnu.org/50091 can be closed? And maybe others closed or solved that come up when looking for risc? Andreas
Re: rust-team branch merged
PS: Congratulations for getting the first team branch through! And thanks for waiting until the core-updates merge :-)
Re: rust-team branch merged
Hello, Am Tue, May 09, 2023 at 11:54:00AM +0300 schrieb Efraim Flashner: > The way its currently setup all we need to do is re-add aarch64-linux to > the supported-systems of rust-bootstrap and it'll be enabled again, and > build successfully eventually. I am confused by what happened; did you disable rust on aarch64 for everyone, or just building on the farm? If the first, that sounds like a pity, since at worst people can still compile packages by themselves. Andreas
Feature branches (was: 04/09: gnu: mesa: Update to 23.0.3)
Hello, indeed someone™ should update the documentation to describe the new process. Probably we should agree on one before doing that as well... In principle all big updates should go through a feature branch now. However, this does not solve the problem of limited build power in our two build farms. Having feature branches that regroup several related changes should help in not rebuilding too often. In principle it could also be okay to regroup unrelated changes (mesa and gcc, for instance), as long as responsibilities are clear. It should be known who is going to act on what when breakages occur in the branch. And I think there should be some kind of "branch manager" and a time frame for the merge so that the branches are short lived. The goal is to avoid the core-updates experience of random commits being dropped in the same place, while hoping that someone at some later point will sort it all out. So how about this suggestion: A feature branch is created upon request by a team, with a branch manager designated by the team. It is accompanied by a short description of what the branch is supposed to achieve, and in which timeframe. The branch manager has the responsibility to communicate regularly with guix-devel on the state of the branch and on what remains to be done, and requests to merge the branch to master once it is ready, and to subsequently delete the branch. This does not yet explain how the branches interact with continuous integration. The branch manager may or may not have commit rights and may or may not be able to create specifications for cuirass, so the full process should take this into account. As written in a different thread, right now I would also suggest to first build the branch only on x86 and powerpc to not overload our few arm machines, but this is a technical detail. Andreas
Re: Python feature branch
Hello, I wanted to set up automatic building on cuirass for the Python updates branch, but was not sure which one it is: $ git branch -a | grep python remotes/origin/python-updates remotes/origin/wip-python-graphviz remotes/origin/wip-python-mne remotes/origin/wip-python-pep517 Some of these have recent commits, others not; it would be nice if you could clean them up and agree on which one to build. Since we do not have enough aarch64 build power, I would have the branch built only by the other architectures in the first place; we could add aarch64 to build out the branch once we think that it is ready to be merged. Andreas
Re: `mumi send-email' means no more debbugs dance to send multiple patches
Hello Arun, this looks all very nice, thanks a lot! I have a few "bug reports" about "mumi web". When I start it, it runs on 0.0.0.0, port 1.2.3.4; should it not choose a sensible default, such as localhost and 8080? Running mumi web --address=localhost --port=8080 complains that it does not know localhost. When I use 127.0.0.1 instead, it starts. But it complains about 1. : "DatabaseOpeningError: Couldn't stat '/var/mumi/db/mumi.xapian' (No such file or directory)" I wondered if I needed to "mumi fetch" first (in that case, there could be a more friendly error message). But "mumi fetch" fails; it complains about a missing file /var/mumi/data/spool/index.db.realtime (which may be missing because as non-root I cannot create it). Could this be moved to .mumi or .cache/mumi? Anyway, thanks for moving us forward with our tooling, which I think is currently our biggest problem. Andreas
Re: Mesa vulkan layer path fix for core-updates
Hello Kaelyn, thanks for your research! Am Wed, Apr 19, 2023 at 04:07:51PM + schrieb Kaelyn: > * https://issues.guix.gnu.org/62176 can be closed when core-updates is > merged, since core-updates contains mesa 22.2.4 > * Though not exactly mesa-related, https://issues.guix.gnu.org/61364 can > possibly be closed now, and almost certainly once the core-updates merge is > completed. (The ticket is a number of workarounds the user applied in early > Feb to be able to build their system profile using core-updates, to pick up > Mesa 22 for newer hardware support. I'm not sure if any of the patches are > still relevant.) I just closed these two. > * https://issues.guix.gnu.org/58887 looks like an alternate way of solving > the layer path issues that https://issues.guix.gnu.org/59453 also addresses. > Additionally, it adds two new nonstandard VK_*_PATH variables to > vulkan-loader, with at least VK_ILAYER_PATH seeming very similar in > functionality to VK_LAYER_PATH and VK_ADD_LAYER_PATH described at > https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderInterfaceArchitecture.md > * https://issues.guix.gnu.org/58251 would be fixed by > https://issues.guix.gnu.org/59453 > * https://issues.guix.gnu.org/62313 might need a modification to mesa e.g. to > add VDPAU_DRIVER_PATH as a native-search-path (one possible solution; in my > home profile I made VDPAU work by setting > "VDPAU_DRIVER_PATH=/run/current-system/profile/lib/vdpau"). > * https://issues.guix.gnu.org/48868 appears to be the same VDPAU_DRIVER_PATH > issue as https://issues.guix.gnu.org/62313. And leave these to you and anybody who wants to work on them! Andreas
Core-updates merge
Hello all, I have just merged core-updates into master and deleted the branch! This has been a long adventure, which became particularly intensive after the last Guix Days in February. First and foremost many thanks to everyone who contributed to the branch, be it by commits, discussions or by working on the infrastructure. Each and every package is not yet in shape; please feel free to submit patches for your favourite packages that fail to build. In particular: - python-yubikey-manager does not build currently; work to correct this is underway. - R on powerpc does not build; this will also be corrected soon; - aarch64 has very few substitutes; I think this is mainly due to the build farm catching up and not so much to packages not building, but this is difficult to know. If any of these are essential to you, you may wish to wait a little bit longer before a "guix pull", or for the time being pull to a commit just before the merge by issuing guix pull --commit=472706ae2f9160833951a4e4bcc4c206e03097b0 Every end of a story is the beginning of many new ones. Several areas of work have already been identified; I will summarise what came up on the mailing list and who expressed interest to work on it - please feel free to join if a topic interests you, or launch another initiative if you want to work on a different subject! - rust-team already has a branch that is almost ready to be built and merged, as a precursor to the team based workflow that we need to invent (Efraim Flashner). - R on powerpc64le needs to be built by changes to valgrind and lz4 (Simon Tournier, I). - Many Python packages need updates, in particular with the aim of building python-yubikey-manager (John Kehayias, Lars-Dominik Braun, Brian Cully). - There is still work to do to bootstrap GHC until the latest version on i686, and to potentially shorten the bootstrap chain (Lars-Dominik Braun). - OCaml could be simplified by dropping version 4.07 (Julien Lepiller). - After the mesa update is before the mesa update, and it looks like more features can be enabled (Kaelyn Takata, John Kehayias). - Too much in Guix depends on too much else, which makes building things needlessly entangled; in particular time zone data should not be referred to by packages, but be loaded at runtime (Leo Famulari). All the best in your Guix endeavours, Andreas
Core-updates merge, d-1
Hello, people have been working on packages close to the leaves which did not build any more in core-updates; but as far as I can see, nothing major has popped up that would prevent a merge. So unless there is firm opposition, I intend to merge core-updates to master tomorrow as announced, in the early European afternoon. Andreas
Re: [PATCH] gnu: python-shiboken-2: Do not rely on _Py_Mangle being available.
Am Mon, Apr 24, 2023 at 12:01:51PM +0200 schrieb Josselin Poiret: > * gnu/packages/patches/python-shiboken-2-compat.patch: Fix the patch according > to upstream. Pushed! Andreas
Re: Core-updates, the last metres
Hello John, thanks for your report, and the patch work! Am Sun, Apr 23, 2023 at 06:51:27PM + schrieb John Kehayias: > If things continue looking good, are we planning to see the merge in > the next few days? Yes, the plan is to merge on Tuesday. Andreas
Core-updates, the last metres
Hello,
yesterday I updated my system to core-updates. Since I am writing this
message now, you can deduce that it succeeded. Well, there is no reason
you should care, but it could encourage you to do the same. :)
I used commands like "./pre-inst-env guix package/system ...", but this
resulted in strange behaviour; I suppose I may have ended up with a
mixture between old and new guix.
I think the safest approach is to use "guix pull --commit=..." with
a commit from core-updates, or probably just
guix pull --commit=core-updates
Then I would start by updating the system, followed by the user profiles.
Please tell us if there is a show-stopper for the merge!
We already received a first report:
python-yubikey-manager does not build. It should be repaired very shortly
after the merge (the fix is there, but would cause too many rebuilds now);
so if you rely on it, maybe delay updating your system, or hold this one
package back in your profile ("guix package --do-not-upgrade ... -u").
As for the architectures, x86_64 looks good; i686 and powerpc64le look
okay (or at least not much worse than on master; R does not work on
powerpc64le, and should also be fixed shortly after the merge).
For aarch64 it is difficult to say, since the build farm has trouble
keeping up. We brought back a few machines, but they are churning through
the backlog.
Andreas
Re: Latest news on core-updates
Am Fri, Apr 21, 2023 at 07:04:19PM +0200 schrieb reza.housse...@gmail.com: > Consider my praise added as well! Was there already a discussion about adding > liberapay, to at least have some monetary compensation for the hard and > necessary work done by all these volunteers? Thanks for the thanks! Well, the volunteers are volunteers; if you want to donate to Guix (so far, mainly for covering infrastructure costs and Outreachy internships), you can do so at Guix Europe or the FSF. Andreas
Re: [PATCH 0/2] Update gfeeds to 2.2.0.
Hello Liliana, Am Sun, Apr 23, 2023 at 01:45:19AM +0200 schrieb Liliana Marie Prikler: > as with the recent update to Evolution, this is an update to get a > package into a working state again. gfeeds has python-magic as input, which fails on the soon to be merged core-updates. It would be interesting if you could have a look at this package. Thanks! Andreas
Aarch64 on core-updates
Hello, the dashboard is completely red for aarch64 on core-updates: https://ci.guix.gnu.org/eval/397792/dashboard?system=aarch64-linux but when I follow any dependency chain, I end up with the scheduled build of xz: https://ci.guix.gnu.org/build/512146/details So I suppose that this is just a side-effect of our build farm not keeping up on this architecture and prioritising master over core-updates? I could build a simple profile (with the toolchain to compile Guix) on my aarch64 machine. Andreas
Re: Latest news on core-updates
Am Fri, Apr 21, 2023 at 10:20:18AM +0200 schrieb Simon Tournier: > Since Haskell is also broken on master for i686, I guess the option is > to apply on some “feature™ branch” after the merge, right? Yes indeed. > Therefore, if many things are still missing, I suggest to apply #62967 > [2]. It removes the annoyance you spotted out in #62954 [3]. And as I > explained in [4], it will be safe because ’valgrind’ appears only in the > testsuite of ’lz4’ and ’valgrind’ is not even run there. > Doing so, it will fix failures for powerpc64le and will increase the > coverage. CI just disappeared, so I cannot check. If r-minimal builds for powerpc64le on master, then it is justifiable to fix the regression (leaving open the possibility of an immediate revert if the patch introduces problems else- where, which I do not expect). Otherwise I would postpone it until after the merge. Andreas
