Re: [art] Tiled Wallpaper Art
On Mon, Mar 22, 2021 at 04:07:15AM +0530, Sarthak Shah wrote: > Hello, I put together a tiled svg wallpaper for GuixSD (attached) > using the logo resources in the git repository. > I'm not sure where to submit it Cool! We usually keep this kind of thing in the 'guix-artwork' repository: https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/ And, this is the right place to submit it. I'm CC-ing Luis Felipe, who usually works on our art, and they can help guide you in contributing these tiles :)
Re: Make guix commands pipeable
> I do agree though that it would be nicer to just have '-' as a guix > input arg causing any guix command to read from stdin. Doesnt /dev/stdin work? The only reason it could not is that somehow the file descriptor needs to be seekable. Léo signature.asc Description: This is a digitally signed message part
Re: Why [bug#47081] Remove mongodb?
Hello! > Removing a package and its services is not something to do lightly: > it > breaks user configs with no recourse. > > We must insist on getting more opinions on such matters, and I think > there just wasn’t enough feedback here. I understand it can be > frustrating to wait for input, but in such a case, please do. This > project has always strove for consensus. > > Remember that the opinion of those who’ve been taking care of > security > issues in Guix for years, those who’ve been maintaining MongoDB, > those > who wrote the service and its tests, are invaluable; they must have a > say. I insist: humbly solicit and wait for their feedback. > I understand, and I did not think it was a light thing to do, no one mentionned anything we should do for the remove, so I actually do not know how we handle that but the security/non-free code thing put some urge into the situation, apologizes for moving on and pushing without waiting for more feedback, few people gave their feedback on IRC and by email and that's why I felt more confident doing the actual change. > Now, how do we move forward? IMO we must look for available options > before we remove MongoDB. Are there forks of the original > freely-licensed code base maintained around? That sounds likely. I never heard of any and after some searches even before I pushed the remove commit it remained inconclusive on whether we can rely on a fork. > Are > there backports of the security fixes? Ubuntu Focal maintains a package still but to me they still don't have all the fixes, see: https://packages.ubuntu.com/focal/mongodb-server All in all, I don't think we should keep a package in more-than- maintenance mode when the upstream has decided to change the license, they are uncooperative and making our work harder so I think we should remove the package. It's not like we are an LTS distro like Ubuntu Focal that absolutely must keep a package until the end of the support cycle. It may break configs yes, but actually this had to happen, at the same time they changed to a problematic nonfree license and openssl 1.1.1 is not supported on 3.4.x (Ubuntu uses 3.6.8 instead which also is under AGPL but more recent than our 3.4.10 we had so supports openssl 1.1.1 with some patches they made). I'm not particularily sympathetic to MongoDB. Also are there actually people using the mongodb service on GNU Guix? > What do the previous > contributors to this code think—Chris, Efraim, Marius, Arun? Chris voiced their opinion saying they didnt mind removing the package, I think Efraim said that on IRC also but I am not sure, so let's wait for their input here. > > Léo, please get involved in reaching consensus on a solution. CC'd them, of course, again, sorry. > Ludo’. Léo signature.asc Description: This is a digitally signed message part
Re: Release 1.2.1: status
On Sun, Mar 21, 2021 at 12:00:20AM +0100, zimoun wrote: > We discussed that and I agree. We also discussed some tagging and Maxim > did some tests, IIRC. Please go ahead and let try if it helps to > synchronize. :-) Here is the checklist: https://bugs.gnu.org/47297 I've added a few items, but everyone should add the other tasks they know about.
Re: Release 1.2.1: status
Thanks for the details, zimoun. On Sunday, March 21, 2021 12:16 AM, zimoun wrote: [...] > > Also, I got a backtrace when checking icecat: > > ★★★ > > Backtrace:cecat@78.8.0-guix0-preview1 [archival]... > > [...] > > > ice-9/boot-9.scm:1667:16: In procedure raise-exception: > > In procedure bv-length: Wrong type argument in position 1 (expecting > > bytevector): #f > > ★★★ > > Indeed, there is a bug. Because the source of ’icecat’ raises a case > that is not handled by ’check-archival’ in (guix lint). [...] > Could you open > a bug report for that? Just to not forget to fix it. :-) Done: https://issues.guix.gnu.org/47293
Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2
Hi Léo,
Léo Le Bouter skribis:
> See commit: 82e887ba48c2ba91b17aa9b6b17501e3e0ef4aef
>
> Following discussion around whether it is safe to graft and whether we
> should do so or not, first, I apologize for not doing as rigorous
> checking on this issue as I should have, and also requesting more peer-
> review, I initially believed those two ImageMagick version were ABI
> compatible with unchanged soname so it turns out it would be a rather
> uncontroversial graft to make but now it turns out we have a changed
> soname but whether it is binary (backwards) compatible or not remains a
> question.
Mistakes happen, that’s okay. However, the manual explicitly mentions
“trivial changes” are acceptable without peer review, but as I wrote,
those security updates rarely, if ever, qualify as “trivial”:
https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html
> $ ./pre-inst-env guix environment --ad-hoc libabigail -- abidiff
> $(./pre-inst-env guix build --no-grafts imagemagick@6.9.11-48 | grep -v
> doc)/lib/libMagickCore-6.Q16.so.6 $(./pre-inst-env guix build
> imagemagick@6.9.12-2g | grep -v doc)/lib/libMagickCore-6.Q16.so.7
> ELF SONAME changed
If upstream changed the SONAME, they probably had a reason. A library
with a different SONAME cannot be used as a replacement, period.
It’s also unclear to me that ImageMagick can be meaningfully grafted.
Are there users of libMagick*.so in external packages? That seems
unlikely.
On berlin, I see this:
--8<---cut here---start->8---
$ guix graph -t referrers
/gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g
digraph "Guix referrers" {
"/gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g" [label =
"imagemagick-6.9.12-2g", shape = box, fontname = sans];
"/gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g" ->
"/gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g" [color =
darkviolet];
"/gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g" ->
"/gnu/store/wsw9an4lsnqxalwkvycxaa3y0ybp8rxp-ecl-ltk-0.992" [color =
darkviolet];
"/gnu/store/wsw9an4lsnqxalwkvycxaa3y0ybp8rxp-ecl-ltk-0.992" [label =
"ecl-ltk-0.992", shape = box, fontname = sans];
"/gnu/store/wsw9an4lsnqxalwkvycxaa3y0ybp8rxp-ecl-ltk-0.992" ->
"/gnu/store/wsw9an4lsnqxalwkvycxaa3y0ybp8rxp-ecl-ltk-0.992" [color =
peachpuff4];
}
--8<---cut here---end--->8---
That means ‘ecl-ltk’ is the only package that keeps a reference to
ImageMagick, and thus, it’s the only one that would benefit from the
graft. The graft is useless.
To me that means we should revert this patch series (perhaps with the
exception of bb2427fa28):
2e0ff59f0c gnu: imagemagick/fixed: Redirect old sonames to new sonames.
bb2427fa28 gnu: ImageMagick: Refer to the version number in a more robust way.
bb5d84a048 gnu: ImageMagick: Fix version number in build configuration of
grafted replacement.
852ba914a4 gnu: imagemagick/fixed: Retain version length for successful
grafting.
82e887ba48 gnu: imagemagick: Update to 6.9.12-2 [security fixes].
After that, what we can do, is introduce 6.9.12-2 as an additional
public version of imagemagick. That way, users who run:
guix install imagemagick
get the newer version, the one that includes security fixes.
Could you look into this?
Thanks,
Ludo’.
Re: Make guix commands pipeable
Hi, On Sat, 20 Mar 2021 at 12:13, pkill9 wrote: > I would like to be able to pipe files into guix commands. Well, this work: guix search hello | recsel -C -P name | xargs guix build > Specifically the `guix system build` command, so I can build a system > configuration on a remote Guix system over SSH, i.e. `cat config.scm | > ssh guix system build -`, or perhaps using the > `--expression` flag which would make more sense, e.g. `cat config.scm | > ssh guix system build -e -`. Does “cat config.scm | ssh xargs -0 guix system -e” work? Indeed, maybe some commands are expecting a real file and cannot read from stdin. Cheers, simon
Re: [SPITBALL] Jehanne as another kernel option / porting target
On Sunday, March 21, 2021, raingloom wrote: > On Fri, 19 Mar 2021 20:42:19 +0100 > Vincent Legoll wrote: > > > + '(#:tests? #f ;; No need for tests when you have formal proof > > of correctness > In just about any talk about Idris and Type Driven Development, Edwin > Brady always starts with "you still need tests". > That package is not intended to be included, as it is far from finished, sorry, I should have added " pun intended" with the accompanying smiley ... -- Vincent Legoll
Re: [SPITBALL] Jehanne as another kernel option / porting target
On Fri, 19 Mar 2021 20:42:19 +0100 Vincent Legoll wrote: > + '(#:tests? #f ;; No need for tests when you have formal proof > of correctness In just about any talk about Idris and Type Driven Development, Edwin Brady always starts with "you still need tests".
