Re: Sourcehut packaging
Ron Nazarov writes: > All Python dependencies of core.sr.ht (which is required by all Python > components of Sourcehut) are now packaged, but it also has 2 npm > dependencies (clean-css and clean-css-cli), these are not yet packaged, > they have the following dependencies (flattened): > * balanced-match > * brace-expansion > * clean-css > * clean-css-cli > * commander > * concat-map > * fs.realpath > * glob > * inflight > * inherits > * minimatch > * once > * path-is-absolute > * source-map > * wrappy (packaged as node-wrappy) That's awesome! How cool would it be to have a Sourcehut service in guix system !? > > This is not very many dependencies compared to jQuery. > > I have not looked at other sourcehut packages yet. -- Joshua Branson (joshuaBPMan in #guix) Sent from Emacs and Gnus https://gnucode.me https://video.hardlimit.com/accounts/joshua_branson/video-channels https://propernaming.org "You can have whatever you want, as long as you help enough other people get what they want." - Zig Ziglar
Re: Document our WIP
On Wed, 2021-03-31 at 14:16 -0400, Leo Famulari wrote: > > Yeah, I agree that it's hard to learn about "what's cooking" when you > first arrive at the mailing lists. > > It's true that wikis tend to get out of date, but I think that it > won't > be too bad for this use case. At least, it won't be worse than the > mailing lists, for newcomers who want to know about longer-term > efforts > like the GNOME upgrade. I am thinking we could establish policy so that the WIP wiki page is an index to mailing list threads, git branches or other "updatable" locations so that it is less likely to need updating and therefore stays updated w.r.t. it's main purpose: finding out about WIP work. The policy would say that one must create a mailing list thread, git branch or else and link it there and **NOT** include original information on the wiki page but rather just link to ML/git/else. We could write such policy at the top of the page so contributors to it can easily see it. What do you think? Léo signature.asc Description: This is a digitally signed message part
Sourcehut packaging
Hello, All Python dependencies of core.sr.ht (which is required by all Python components of Sourcehut) are now packaged, but it also has 2 npm dependencies (clean-css and clean-css-cli), these are not yet packaged, they have the following dependencies (flattened): * balanced-match * brace-expansion * clean-css * clean-css-cli * commander * concat-map * fs.realpath * glob * inflight * inherits * minimatch * once * path-is-absolute * source-map * wrappy (packaged as node-wrappy) This is not very many dependencies compared to jQuery. I have not looked at other sourcehut packages yet. -- Ron Nazarov signature.asc Description: This is a digitally signed message part
Semi-automated patch review
Hello! Cbaines already runs automated patch testing infra at https://data.guix-patches.cbaines.net/ and https://patches.guix-patches.cbaines.net/project/guix-patches/list/ Considering that posting robot messages with test/lint/+ result information on the issues directly and on the ML might get spammy, I suggest that Cbaines could setup something that sends off-list to all the participants or just the poster of the patch being tested, as well as another list like guix-ci-...@cbaines.net that reviewers could voluntarily subscribe to to receive all those off-list messages. Another suggestion is that the infrastructure by Cbaines could include an easy way to lookup CI information from a bug id and that a link to see such CI information could be linked to from Mumi's (issues.gnu.guix.org) UI. But I also really think that mailing the contributors privately is very important so they can get automated feedback and save us time without any additional setup or knowledge required. What do you think? I think it's really important that we move forward on this topic where honestly lots of things have been achieved especially by Cbaines but with poor visibility so no actual usage to aid the review process when we would crucially need such help. Thank you! Léo signature.asc Description: This is a digitally signed message part
Re: Needed: tooling to detect references to buggy */stable packages (was: Re: [PATCHES] ImageMagick security updates without grafting)
On Sun, 2021-04-04 at 16:14 -0400, Mark H Weaver wrote: > Maxime Devo wrote: > > * In some places we have the following pattern: > > > > [...] > I don't understand this. Why would it need to be made unconditional? I don't understand either anymore. > [...] > > At the present time, I'm more inclined to add machinery to automatically > add _implicit_ #:disallowed-references, to enforce this checking at > package build time. This would require rebuilding everything that > depends on a '*/stable' package, which means that this kind of tooling > could not be applied directly to 'master', but would need to go through > 'staging'. That seems good to me. I believe the current plan is: * Add a 'stable' property to the gtk-doc/stable, dblatex/stable ... packages. * Change gnu-build-system, glib-or-gtk-build-system ... to implicitely add packages in inputs, propagated-inputs or native-inputs that have the 'stable' property to #:disallowed-references, unless the package that is being built is a 'stable' package itself. And an idea for the future is: * Implicitely add all packages in native-inputs to #:disallowed-references, unless they are in inputs or propagated-inputs as well. * Verify everything still works well (when cross-compiling and when compiling natively), and fix breakage. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
