Re: The problem of packaging Minetest mods/games
On Wed, May 20, 2020 at 00:36:44 +0200, Leo Prikler wrote: >> Could we for example place the mods in the ~/.minetest/games folder? > That's not very functional of you. In theory, you can put stuff there, > but not using Guix. As an example, Stepmania reads all its > configuration, data and cache from ~/.stepmania-, so that's of > course where I put the data – data, that is already unfit to be managed > by Guix due to licensing issues, mind you. In the case of Minetest > mods/games, that folder quickly gets stale however, so I'd not suggest > doing so unless you really need to. I still think it ought to search ~/.minetest/games, though, for those things that may not be installed using guix. For example, minetest has a built-in means of downloading games/mods. While it's best to use a package manager, it also breaks functionality if it doesn't work both ways. -- Mike Gerwitz signature.asc Description: PGP signature
Re: bug#33844: Rename ghc-pandoc to pandoc
On Thu, Feb 27, 2020 at 14:10:15 +0100, zimoun wrote: > Well, your comment is pointing: a) that the description is badly > written and b) the 'relevance' score is too rough. [...] > The real problem is not the non-obvious name (ghc-pandoc instead of > simply pandoc) but it is: a) some descriptions are badly written and > b) the 'relevance' scoring function is not enough "smart" to detect > them. Thank you for taking the time to explain this. -- Mike Gerwitz signature.asc Description: PGP signature
Re: bug#33844: Rename ghc-pandoc to pandoc
On Wed, Feb 26, 2020 at 12:23:14 +0200, Efraim Flashner wrote: > On Wed, Feb 26, 2020 at 11:06:30AM +0100, Pierre Neidhardt wrote: >> swedebu...@riseup.net writes: >> >> > Reason: it is used standalone to convert between formats. >> >> I agree. What do other people think? > > This is language specific, but like other language-specific packages > this is a package people would specifically search for as 'pandoc' and I > agree, it should be renamed. Ah, for the record, I had searched for pandoc using `guix package -s pandoc` in the past and didn't find what I was looking for, and so fell back to a Debian system. It turns out what I wanted was ghc-pandoc after all. But if I would have put a little bit more effort into looking, perhaps I would have figured that out; I was in a hurry. Thanks for making this change! -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 signature.asc Description: PGP signature
Re: Maintainer (no longer) needed for Linux-libre and IceCat packages
On Wed, Oct 16, 2019 at 03:06:23 -0400, Mark H Weaver wrote: > Thank you Ludovic, and thanks to all for the kind words. In light of > recent events at the FSF, I've had a change of heart and have decided to > return to the Guix project. Although I welcome more help with these > packages, I will resume my previous role, doing what I can to keep our > Linux-libre and IceCat packages up-to-date, as soon as my commit rights > on Savannah are restored. This is wonderful news! -- Mike Gerwitz signature.asc Description: PGP signature
Re: Docker and singularity containers
On Sat, Jan 05, 2019 at 17:14:31 +0100, Ricardo Wurmus wrote: > That’s easier: with “guix pack”. We would create a Cuirass job to build > a pack regularly. We’d need to add support for hooks to publish the > generated pack on DockerHub, though we could just as well host them > ourselves. Last I checked, an account couldn't be registered on DockerHub without running non-free JS. Here's a thread on emacs-devel where I raised this issue: https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00114.html But I haven't verified this since. After an account is registered, though, their APIs can be used without having to use DockerHub's web interface. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Missing fonts issue with GNU Icecat
On Thu, Dec 27, 2018 at 14:43:23 +0100, Daniel Gerber wrote:
> Resolved by applying this advice (which is output when running `guix package
> -i pango` explicitly, but not when pango is installed as a dependency -- or
> I missed it):
>
> ```
> The following environment variable definitions may be needed:
> export
> XDG_DATA_DIRS="$HOME/.guix-profile/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
> export
> GIO_EXTRA_MODULES="$HOME/.guix-profile/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES"
> ```
Thanks for sharing. I can confirm that setting only XDG_DATA_DIRS works
in a container to solve the font issue. Setting XDG_DATA_HOME works as
well.
I don't need to set GIO_EXTRA_MODULES in order to get it to work (I
don't even have that directory on in my profile).
--
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com
signature.asc
Description: PGP signature
Re: Missing fonts issue with GNU Icecat
On Fri, Dec 28, 2018 at 16:07:12 +0100, Ricardo Wurmus wrote:
>> ```
>> The following environment variable definitions may be needed:
>> export
>> XDG_DATA_DIRS="$HOME/.guix-profile/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
>> export
>> GIO_EXTRA_MODULES="$HOME/.guix-profile/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES"
>> ```
>
> I’m glad you figured this out. I wonder if this means that we should
> change the icecat package to set these variables (e.g. by adding a shell
> wrapper).
Only XDG_DATA_DIRS (or XDG_DATA_HOME) are needed for me in a
container. Is GIO_EXTRA_MODULES actually needed for anything? I don't
even have a `lib/gio' directory in my profile.
> What do others think?
Yes, please. IceCat is effectively completely broken without this on
foreign distros and within containers. It looks like on GuixSD
XDG_DATA_DIRS is set in /etc/profile; I never had to set it manually.
But the presence in /etc/profile implies to me that there are other
packages that require this variable to be present. Should those
packages also have wrapper scripts?
--
Mike Gerwitz
signature.asc
Description: PGP signature
Re: NPM importer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Nov 20, 2018 at 22:12:18 +0100, swedebugia wrote: > I wonder how many are free software? 90%? 50%? > > I hope we can automate this some way. The JavaScript community has poor licensing practices, and the culture is somewhat hostile to the ideals of the free software movement (they focus on permissive licensing to empower non-free software developers using those libraries). The package.json has a license field, but package.json is often auto-generated and I think is MIT Expat by default. It is metadata---I can't imagine it carries any legal weight by itself. Consequently, we'd have to fall back on COPYING or LICENSE files (of various sorts) in the projects. Even then, a project may contain things under various licenses. Further, since there tend to be many really small packages, if _any_ one of those is missing proper license information, then anything that depends on it will be non-free. Since npm doesn't ensure that its packages are actually free, the odds of there being some sort of licensing issue---just by sheer number---are probably higher than we would like them to be. I'm not suggesting malice; it may be accidental, or maybe someone knows nothing about licensing and simply never attached a license to begin with (making it non-free by default).[0] There's also the risk of any of these projects using incompatible licenses. Both GitLab and GitHub detect licenses on projects. I forget the name of the software they use to do that (and it may not be the same for both of them), and it's probably not perfect, but something like that may help with automation. [0]: https://blog.github.com/2015-03-09-open-source-license-usage-on-github-com/ (as of 2015) - -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJb9Le7AAoJEIyRe39dxRuijsQP/19DjT/G4/806rbtECrZAOeB DhsWG6fm4rFkv9VbdVgKFASF2qIYSmq8p3yiVHwaNNoV0HcUurK/Gz44880S9EPO EnHoN7naBYEzv1JRkGFdiHh6eEeUsGPdt4RB1/bunjY4K3EOfeSVQWWeXlDjI4GK KKsLqNto00ESiwkDW2FOvElnUwfkFa1i+mtc48PbNtoy0VPie9kid51NDQLw4fZG 4VTU+kExeBHriq1AsNREWOQB2Ctg09ydkrzTvzlg4kucnFp8S3ohvbLoSoPil0YH 09hihN/sSwtws2BkMjgB2cO/y46MZeRsvazDD6ZZNyz3PqVZYsPa+5F0eFp7MlpV a56lsND20IEtmITUZsaIx+W4F71iLJPIVWMN0NZA/rMgEntWSgexSx3w9RFZNYWH m3UAyACIV9M9WDlTN/OJ/Q98clJ8G3AcZ3M5hKMyvtupctMWxZmDhY3dEGGeavvv AKIXJ0Qau0mi9HFvT4eusfyih01kCFGddMcUCkY7QY6yuDxg1hHglM75t6YHvfwP 4lZlCywwC6UMazpv0QO6KMOhq7pwEVsXvn9agZR9gd5d18H+6EMv0AogNrh2a48u HFtRNSMx4woFxXUGd2P50/Zy8hJFyijMbLyksLkxfr7HcTfJ+hUGb1e94xuEdZzr xR/YjftLIOSzNUV9y20y =F0Yh -END PGP SIGNATURE-
Re: openssh vulnerability
On Tue, Oct 16, 2018 at 21:20:30 -0400, Christopher Lemmer Webber wrote: > https://www.libssh.org/2018/10/16/libssh-0-8-4-and-0-7-6-security-and-bugfix-release/ > > seems serious? Very... Fortunately that's libssh and not OpenSSH[0], but with that said, it does appear to be packaged in Guix and there are a couple packages that use it. [0]: You had me very worried from your subject line! -- Mike Gerwitz signature.asc Description: PGP signature
Re: More stability needed in our Rust packages, for IceCat 60
On Fri, Sep 21, 2018 at 23:35:17 -0400, Mark H Weaver wrote: > Thanks to your hard work on our Rust packages, I was able to update our > IceCat package to a pre-release of 60.2.0. I recently pushed it to > master and Hydra is currently busy bootstrapping the chain of Rust > compilers in order to eventually build IceCat. This is wonderful news! I'm really excited to give this a try once Hydra is ready. Thank you! And thank you too, Danny, since your work made this possible. -- Mike Gerwitz signature.asc Description: PGP signature
Re: Firefox 52's end of life, packaging Chromium
On Sat, Sep 01, 2018 at 16:13:53 +0200, Ludovic Courtès wrote: > I have to say that Andreas, Mark, Marius, and others who worked on > IceCat and Chromium packaging are heroes: it’s a huge effort and we can > be grateful for that! I agree---I am very grateful for their work! -- Mike Gerwitz signature.asc Description: PGP signature
Re: Firefox 52's end of life, packaging Chromium
On Thu, Aug 30, 2018 at 07:14:37 +0200, Clément Lassieur wrote: > The problem is a technical problem. We would have with Icecat 60 the > same packaging difficulties we have with Firefox 60. Whether we choose > Icecat or Firefox is unrelated. Right, which is why I was curious if there were recent efforts with vanilla Firefox, since those efforts would directly apply to IceCat. -- Mike Gerwitz signature.asc Description: PGP signature
Re: Firefox 52's end of life, packaging Chromium
On Thu, Aug 30, 2018 at 09:07:39 +, Nils Gillmann wrote: > Mike Gerwitz transcribed 1.8K bytes: >> But as was stated in another thread, once we _do_ have an updated IceCat >> source distribution, we need it packaged for Guix, and that is quite the >> undertaking. Has anyone pursued packaging modern versions of vanilla FF >> in recent months? > > Yes, I have. The outcome was not so much progress because Firefox > starting at a certain version does no longer allow disabling the build > of the rust crates. You then need a way to deal with the "breakage" in > the directory 'thirdparty/rust/' and its subdirectories. > Progress could be achieved with a phase which either records our changes > to the checksum related files or reverts our changes. Thank you for your efforts! -- Mike Gerwitz signature.asc Description: PGP signature
Re: Firefox 52's end of life, packaging Chromium
On Wed, Aug 29, 2018 at 11:03:07 +0200, Clément Lassieur wrote: > Firefox 52 isn't supported anymore upstream[1] and we don't have a > package for Firefox 60. Currently the only alternative is Epiphany but > it's close to unusable (it crashes every 5 minutes, and sometimes > freezes my computer). This is a big problem. Thanks for keeping up with the status. I'll get into contact with the necessary people on behalf of GNU to figure out the current status of IceCat. But as was stated in another thread, once we _do_ have an updated IceCat source distribution, we need it packaged for Guix, and that is quite the undertaking. Has anyone pursued packaging modern versions of vanilla FF in recent months? -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: gnumaint changes
On Thu, Jul 12, 2018 at 17:57:01 +0200, Ludovic Courtès wrote: > Hello, > > Mike Gerwitz skribis: [...] >> Do you have a couple examples of what you think would be beneficial to >> pull form Guix? I'm certainly open to the idea where it makes sense; >> there's no sense in us duplicating effort within GNU unnecessarily. > > I realize that Guix doesn’t have all GNU packages yet so in fact there’s > not so much to pull from at this point. I was suspecting blurbs are > likely to be more up-to-date in Guix, but that’s very subjective, I > don’t know if this is the case. It seems like the blurbs in Guix may be slightly different: in Womb they are provided by the package author for use here: https://www.gnu.org/manual/blurbs.html In Guix they may be augmented with additional information that the Guix package author finds useful, and may deviate from what the GNU package author provided. Is that true? It makes sense to me, though, that Guix and that page would be in sync. But if the intent is to have the blurbs be written by the package authors, syncing them would mean that Guix would forefit the ability to manage its own package descriptions. I'm not sure if that's something Guix would want to do. I'm also unaware of how many GNU package maintainers even remember that the blurbs page even exists. So it's possible that such descriptions could be updated. It'd be worth maintainers@ occasionally asking package maintainers to review our records. >> I'm also working on automating parts of our recordkeeping: in the next >> few weeks, Womb will have up-to-date version information automatically >> pulled from info-gnu release announcements; the FTP server; and a couple >> websites where necessary, though I'll be manually committing it for the >> first few months to verify that it is all working properly. So Guix >> might also be able to depend on rec/gnupackages.rec for checking for new >> releases as well, since unfortunately GNU doesn't mandate the use of the >> FTP server, or even info-gnu (so releases are all over the place). > > The (guix gnu-maintenance) modules are tools to retrieve the latest > version of a GNU package by traversing its ftp.gnu.org (or similar) > directory. That’s something you might find useful. Here’s an example: Thanks---I was going to reference Guix's implementation. But do note that many GNU packages don't make use of GNU's FTP server, so this doesn't work on its own as a comprehensive version check tool for GNU software. But if this hasn't been a practical problem for Guix yet, then there's no need to change that. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: gnumaint changes
On Wed, Jul 11, 2018 at 16:11:37 +0200, Ludovic Courtès wrote: > Hello Mike, > > Mike Gerwitz skribis: [...] >> pkgblurbs.txt has also been replaced by rec/pkgblurbs.rec. > > Commit daf76c7cd54df428abc28d490747c7f83a844df0 changes > gnu-maintenance.scm to use the .rec files. Thanks for the heads-up. Thanks. I was planning to submit a patch this weekend, but you beat me to it. Sorry for the trouble! I'm glad to see that the change was pretty simple. >> If anyone here also knows of any other external systems pulling from >> womb, please lmk. I wasn't aware that anyone outside of maintainers@ >> used that repo, tbh. > > It’s used by ‘guix import gnu’ and ‘guix lint -c gnu-descriptions’ > currently. > > It’d be nice if synopses and descriptions in the Womb could contain > Texinfo markup. > > In fact, perhaps it’d make sense to reverse the roles, i.e., have the > Womb take (some of its) descriptions from Guix? `blub' in pkgblurbs (which is what `official-description' uses) is provided by package authors after they've been dubbed by rms. That is in turn used on gnu.org. Consequently, I think it's best to have such blurbs maintained independently of guix. What sort of Texinfo markup are you looking for, and are we talking about the same field? What field does guix use for the synopsis? Everything in rec/gnupackages.rec is handled by us at maintainers@, so we can do whatever we want there. Do you have a couple examples of what you think would be beneficial to pull form Guix? I'm certainly open to the idea where it makes sense; there's no sense in us duplicating effort within GNU unnecessarily. I'm also working on automating parts of our recordkeeping: in the next few weeks, Womb will have up-to-date version information automatically pulled from info-gnu release announcements; the FTP server; and a couple websites where necessary, though I'll be manually committing it for the first few months to verify that it is all working properly. So Guix might also be able to depend on rec/gnupackages.rec for checking for new releases as well, since unfortunately GNU doesn't mandate the use of the FTP server, or even info-gnu (so releases are all over the place). -- Mike Gerwitz signature.asc Description: PGP signature
Re: shortening the git test suite
On Fri, Jul 06, 2018 at 23:05:04 +0200, Ludovic Courtès wrote: > Instead of ‘git-minimal’, we could have ‘git’ without SVN support, and > have a separate ‘git-svn’ package. We can probably arrange for that > ‘git-svn’ package to only provide the relevant libexec/git-core bits > (git-svn is just a Perl script anyway.) > > Thoughts? I'm a git-svn user, and that sounds fine with me. I agree that's much better to provide a separate package with the SVN tests rather than simply disable SVN tests in a full-featured Git. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: gnumaint changes
On Wed, Jun 27, 2018 at 21:40:19 -0400, Mike Gerwitz wrote: > I'll have to look at what guix/gnu-maintenance.scm does, but: [...] > Rather than get rid of gnupackages.txt completely, I wrote a script last > week to generate it from rec/gnupackages.rec. The formats are largely > the same---it's possible that you can use the recfile directly. > However, if you still need the old format, just run > `make gnupackages.txt`. Ah, I see, it fetches that single file over HTTP. Certainly running `make` (or the underlying gawk script) is undesirable in that situation. Can someone with more knowledge of what this is used for run a couple of tests to see what is broken if you use rec/gnupackages.rec instead? Worst case, I can commit gnupackages.txt until the script can be updated, but I'd prefer to keep generated files out of the repository. pkgblurbs.txt has also been replaced by rec/pkgblurbs.rec. If anyone here also knows of any other external systems pulling from womb, please lmk. I wasn't aware that anyone outside of maintainers@ used that repo, tbh. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: gnumaint changes
On Wed, Jun 27, 2018 at 08:23:45 +, Nils Gillmann wrote: > could someone verify (I have an old checkout) that guix/gnu-maintenance.scm > still works? > gnupackages.txt is dead in gnu.org womb CVS. I'll have to look at what guix/gnu-maintenance.scm does, but: A couple years back, Brandon Invergo started migrating from gnupackages.txt to a new recutils format (rec/gnupackages.rec). This unfortunately required us to maintain two separate files. Rather than get rid of gnupackages.txt completely, I wrote a script last week to generate it from rec/gnupackages.rec. The formats are largely the same---it's possible that you can use the recfile directly. However, if you still need the old format, just run `make gnupackages.txt`. Lmk if that works for you. In the future, if you have problems with gnumaint in womb, please email maintain...@gnu.org; this message just happened to catch my eye. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
On Thu, May 17, 2018 at 13:34:37 +0200, Ludovic Courtès wrote: > I wonder why IceCat is based on an ESR, and what it would take to have > it follow Firefox releases more closely. IWBN if IceCat could be pretty > much like Linux-libre, i.e., a set of scripts that semi-automatically > adjusts the Firefox source (I’m not sure if that is the case currently.) Its maintainer was struggling to keep up with any releases at all, which is why Mark Weaver stepped up backporting security patches for Guix. I'm not sure how much effort is involved with running the script and issuing a new release. > At any rate, people interested in this should probably team up with the > IceCat people (person?) to see how we can together move in the right > direction. Please do contact maintain...@gnu.org if anyone is interested! Rubén Rodríguez is IceCat's maintainer and is an employee at the FSF. I proposed to both rms and John Sullivan at different points that maybe IceCat maintenance can be made part of Rubén's responsibilities at the FSF. The FSF recently announced a paid contact position for LibreJS, so maybe at some point IceCat can see some attention too. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
On Tue, May 15, 2018 at 10:57:39 +0200, Ludovic Courtès wrote: > Hi Pjotr, > > Pjotr Prins <pjotr.publi...@thebird.nl> skribis: [...] >> I think I'll go to FF again if this persists. > > IceCat is essentially the same code as FireFox modulo branding, add-ons, > and a few trivial things. I don’t see how IceCat itself could be > blamed—the add-ons maybe, the way it is packaged in Guix perhaps, but > IceCat?… IceCat is based on an old ESR; FF has undergone many substantial changes (and rewrites of parts of the system) since then; it's much more performant and I've found it to be much more stable over the years. (I use IceCat at home and FF at work.) So when users compare IceCat to "Firefox", they're not likely performing a valid comparison, since they're going to use a modern version of Firefox. I think Rubén is working on an ESR upgrade, so maybe users' experiences will be a bit better soon. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
On Sun, May 06, 2018 at 18:33:56 +0200, Hartmut Goebel wrote: > Am 06.05.2018 um 16:05 schrieb Mike Gerwitz: >> In the case of their addon >> system, they encourage installation of non-free addons, which is against >> the Free Software Distribution Guidelines (FSDG), and is the same reason >> that Debian isn't a recommended free software distribution. >> > My aim is to empower people, not to infantilize them. > > If we disable adding add-on, we appoint ourselves as guardian for > immature users. And this IMHO is contrary to "free" (as in "free speech"). There might be a miscommunication: I'm not suggesting that we disable addons (I use many of them), merely that we do not have the default Firefox addon page, which encourages non-free software. IceCat replaces it with its own page that uses the free software directory, for example. Users are free to use that directory; go to addons.mozilla.org themselves; or install addons however else they choose. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
On Sun, May 06, 2018 at 11:48:28 +0200, Hartmut Goebel wrote: > Am 06.05.2018 um 03:24 schrieb Mike Gerwitz: >> On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote: >>> I have noticed somepeople advocating for packaging Firefox in GNU Guix, >>> and since FF still has freedom issues, I see it as a no-go. >> A simple option for now is to package FF by disabling those features and >> _not_ providing an alternative. For example, IceCat loads a different >> addon page than FF; we could just load no addon page at all, or a static >> one saying that it's something'll we'll get to eventually. > > Not packaging FF or crippling FF is a no-go! Doing so will discourage > users from using GuixSD and Free Software. Packaging Firefox as-is is not an option. In the case of their addon system, they encourage installation of non-free addons, which is against the Free Software Distribution Guidelines (FSDG), and is the same reason that Debian isn't a recommended free software distribution. https://www.gnu.org/distros/free-system-distribution-guidelines.html -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
On Sun, May 06, 2018 at 06:01:59 +, Nils Gillmann wrote: > Mike Gerwitz transcribed 2.2K bytes: >> On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote: >> > I have noticed somepeople advocating for packaging Firefox in GNU Guix, >> > and since FF still has freedom issues, I see it as a no-go. >> >> A simple option for now is to package FF by disabling those features and >> _not_ providing an alternative. For example, IceCat loads a different >> addon page than FF; we could just load no addon page at all, or a static >> one saying that it's something'll we'll get to eventually. > > For the majority of people it will be "weird" to load add-ons not via > the Mozlla Store, but if explained before usage it can work out. Users are free to still use addons.mozilla.org, of course. I do, because I know to check the license of the addon before installing, and the website does not require JS for the functions that I need. I suspect that most Guix users are more technical than average users and would be much less bothered by a kluge for the time being. But to prevent bug reports, something should certainly indicate that it's not failing to load because of a bug. > I thin with regards to Addons of Mozilla based software, we just have > to reimplement what Nix does for the Addons. I'm not familiar with what Nix does; is it similar to what Guix does with e.g. Emacs packages? I would like that. >> I have no suggestions for dealing with the trademark issue, though. > > The branding "aurora" (building without branding) is trademark free. > What remains are mentions of "Firefo" in some places. Oh, excellent. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
On Fri, May 04, 2018 at 16:24:11 +0200, Pjotr Prins wrote: > On Thu, May 03, 2018 at 01:59:24PM -0400, Mike Gerwitz wrote: >> I use IceCat personally and FF Dev Edition at work. Until the recent >> move to WebExtensions, I used the same addons. I use NoScript and Tor >> and have no problems. But I rarely enable JS and never run proprietary >> JS, so my exposure may be different. I do not use LibreJS (because I >> don't usually run JS at all in general and it historically did not play >> well with NoScript; maybe that has changed). > > Disabling all extensions makes Icecat work much better. I'll try it as > a default now. I don't think I made clear with the above: I use many different addons (NoScript, Privacy Badger, HTTPS Everywhere, uBlock Origin, Self-Destructing Cookies, Foxyproxy, Tree Style Tab, and some misc ones); I didn't want to give the impression that extensions are a problem for me. As far as the extensions that come _with_ IceCat, I just don't have use for them or use something else in place of them. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging a free Firefox
On Wed, May 02, 2018 at 23:06:32 -0700, Chris Marusich wrote: > Clément Lassieur <clem...@lassieur.org> writes: > >> I find Icecat very buggy, even if I compare it to a home-made Firefox >> package that inherits Icecat (and thus is very close to Icecat). For >> example I can't even pay with my credit card with icecat-52-guix, >> whereas I can with firefox-home-52-guix. (It looks like a javascript >> issue.) Also, lots of videos don't work, and it's difficult to know >> whether it's because of technical issues or because of DRM. > > This has not been my experience with IceCat. With two exceptions, > IceCat has performed just as well as Firefox for me for everything I > have done, including credit card payments. I sometimes watch YouTube > videos using IceCat, but I don't view many other videos, so I can't > really comment on how well IceCat handles videos. If it requires DRM, > of course, it's not going to work in IceCat, which is a good thing. > > When I use IceCat over TOR, it doesn't always work. When I use IceCat > with extensions (plugins? add-ons? I'm not sure what the right > terminology is here) like NoScript enabled, it doesn't always work. But > when I don't use TOR and I disable those add-ons, everything works just > as well as stock Firefox. If you're still having trouble after > disabling those things, can you describe the specifics of what you're > having trouble with? I use IceCat personally and FF Dev Edition at work. Until the recent move to WebExtensions, I used the same addons. I use NoScript and Tor and have no problems. But I rarely enable JS and never run proprietary JS, so my exposure may be different. I do not use LibreJS (because I don't usually run JS at all in general and it historically did not play well with NoScript; maybe that has changed). > The exceptions I have experienced with IceCat: > > 1) A website failed for me because IceCat enables Referer spoofing by > default (network.http.referer.spoofSource in about:config). I had to > disable that feature to use that website. This was a frustrating problem for me for CloudFlare CAPTCHAs---it would enter an infinte direct loop. Disabling referer spoofing fixed the issue. > 2) It used to be that IceCat would crash frequently for me. However, > once I changed my gfx.canvas.azure.backends and > gfx.content.azure.backends from "cairo" to "skia", this problem stopped > for me. I don't know if this is still an issue , since I haven't ever > switched it back to "cairo". See here for details: > > https://lists.gnu.org/archive/html/help-guix/2016-11/msg8.html It will crash for me if I try e.g. Jitsi Meet; I'll have to see if anything you are describing helps. Anyway: I too would like a modern version of FF packaged for Guix. I know that David Thompson was exploring it at some point but got hung up on some Rust packaging issues that he didn't have the time to explore. I want the modern performance benefits, and I also use the browser for web development. IceCat maintenance also effectively falls on Mark Weaver backporting security patches in Guix; Rubén Rodriguez (IceCat) maintainer has a lot on his plate and IceCat does not get a lot of attention. (If anyone wants to help with IceCat maintenance, he would like the help; contact us at maintain...@gnu.org.) -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Meltdown / Spectre
On Tue, Jan 16, 2018 at 12:10:53 +0100, Ludovic Courtès wrote: > Should GuixSD nevertheless provide a mechanism to support microcode > updates, while not steering users to particular proprietary microcode? > Just like Linux-libre (attempts to) support loading of proprietary > firmware at the user’s choice? Would it make sense at all? Does Linux-Libre specifically support loading proprietary firmware, or does the project phrase it as _any_ firmware, free or not, that the user may provide? My point being: if there only exists proprietary microcode, it's hard to make the argument that a freedom-respecting user will use a microcode update tool for anything other than proprietary software. In that case, does the inclusion of the microcode updater in Guix encourage the use of non-free microcode, even if it doesn't state where to get it? -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Meltdown / Spectre
On Mon, Jan 15, 2018 at 09:07:45 +0100, Pjotr Prins wrote:
> GNU Guix, however, by virtue of being a GNU project is hampered by its
> free software credentials.
"hamper" isn't a good word to use to describe the FSDG:
From The Collaborative International Dictionary of English v.0.48 [gcide]:
Hamper \Ham"per\, n. [See {Hamper} to shackle.]
1. A shackle; a fetter; anything which impedes. --W. Browne.
[1913 Webster]
From The Collaborative International Dictionary of English v.0.48 [gcide]:
Hamper \Ham"per\, v. t. [OE. hamperen, hampren, prob. of the
same origin as E. hamble.]
To put a hamper or fetter on; to shackle; to insnare; to
inveigle; to entangle; hence, to impede in motion or
progress; to embarrass; to encumber. "Hampered nerves."
--Blackmore.
[1913 Webster]
A lion hampered in a net.--L'Estrange.
[1913 Webster]
They hamper and entangle our souls. --Tillotson.
[1913 Webster]
The FSDG is mean to liberate, not hamper; we're all stronger because
of Guix's adherence to it. This is perhaps the only occasion I can
think of---and is admittedly very awkward---where the software running
on a computer is considered fine if we pretend that it doesn't exist as
software, but becomes a problem if we recognize its existence and
attempt to update it. This is a conflict that needs resolution, but I'm
not offering that here---I just wanted to comment on the phrasing.
--
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com
signature.asc
Description: PGP signature
Re: [PATCH 1/1] gnu: Add ccid.
On Tue, Nov 21, 2017 at 02:05:26 +0100, Marius Bakke wrote: > I'd start by copying an existing (simple) service as "boilerplate", and > then write a "system test" that simply (attempts to) start the daemon. > You'll find these under "gnu/tests" and "gnu/services". Thanks for the advice. I'll give this a shot over the next couple of months (hopefully sooner, but we know how that goes) as I try to get myself situated. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: [PATCH 1/1] gnu: Add ccid.
Hey, Marius: I'm resurrecting this thread. :) On Mon, Oct 31, 2016 at 10:09:14 +, Marius Bakke wrote: > Mike Gerwitz <m...@gnu.org> writes: >> On Fri, Oct 28, 2016 at 12:27:29 +0100, Marius Bakke wrote: >>> Packages are not allowed to write to /var, so to run pcscd on Guix you >>> will have to symlink ~/.guix-profile/pcsc/drivers to >>> /var/lib/pcsc/drivers manually, until we have a system service for >>> pcscd. Can you try that? >> >> That does indeed work. Thanks. > > Thanks a lot for testing! :) > >> Part of this for me is being unfamiliar with how everything in Guix >> works, so I'm sure it'll make a lot more sense once I see what service >> you come up with and observe its conventions. > > I haven't started working on this yet, but the idea is to provide a list > of drivers in the service definition (with ccid as default), and then > symlink each of them to the driver directory before starting pcscd. I'm getting GuixSD set up on an X200 now, and this is something that I'm interested in getting resolved. For the time being, I'm using the symlink workaround that you suggested. If you're still interested in doing this---great! Otherwise, I'm tight on time and am already deep in a GuixSD crash-course, so I'd appreciate any sort of mentoring/direction to get this working properly and in a manner consistent with Guix/GuixSD's philosophy. If there are existing service examples that demonstrate the same core concept, I'd be happy to play around with that. But I'd need to know what approach you'd like to take to solving this. Could you provide some more detail? Thanks! -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: On packaging old versions of libraries
On Thu, Aug 24, 2017 at 00:20:34 +0200, Roel Janssen wrote: > Regardless of whether older versions of libraries would be accepted > upstream, you can also keep them in a separate repository or directory > and use the environment variable GUIX_PACKAGE_PATH to include them in Right, I just want my efforts to be useful to someone else as well. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
On packaging old versions of libraries
There is a game my kids love playing named Secret Mayro Chronicles. Unfortunately, it's been unmaintained since 2012, and it was removed from Debian because it is no longer compatible with newer versions of libraries they package.[0] There is a maintained fork of the game, but it's quite different from the original (intentionally). I have the option of compiling it using old libraries (I would have to compile the old libraries' dependencies as well, as needed), upgrade the game by backporting changes from the fork (which I honestly doubt I have the time for right now, but I'll look into it), or run the game within a VM/container running an old Debian version. I'm going to look into what is required to backport, but if I decided to go the first route, I would probably use Guix. Would such a contribution be accepted considering it packages older libraries, which would add some cruft? At the least, I would have to compile CEGUI 0.7, but that might need older versions of libraries itself to compile. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812096 -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: npm (mitigation)
On Mon, Jul 17, 2017 at 11:45:29 +0200, Catonano wrote: > in my idea I would have build a database withh conditions for being non > free forr every npm package. > > So we could have queried the database for questions like: is there any non > free or non buildable package in the dependency tree of, say, the current > Jquery ? Being able to query the graph for non-free dependencies is good, yes. My concern is developing a (reasonably) fool-proof system for detecting those packages that doesn't require manual verification, which would be extremely costly, outside of a reasonable randomly-chosen set. I'm not saying it's impossible; it's just difficult with such wildly varying standards and carelessness with regards to licensing that is prominent in the JS community. But we have to start somewhere, so anything you can come up with would be good. :) > You might remember my post of a few months back about an attempt of mine to > crawl thhe npm registry and storing data found there. I do---I'm sorry if there are details that I missed or should know; I haven't been able to follow this too closely. I can be a bit of a parrot sometimes with certain issues. :x -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: npm (mitigation)
On Fri, Jul 14, 2017 at 13:57:30 +0200, Jelle Licht wrote: > Regardless, the biggest issue that remains is still that npm-land is mired > in cyclical dependencies and a fun-but-not-actually unique dependency > resolving scheme. I still think the largest issue is trying to determine if a given package and its entire [cyclic cluster] subgraph is Free. That's a lot of manual verification to be had (to verify any automated checks). npm's package.json does include a `license' field, but that is metadata with no legal significance, and afaik _defaults_ to "MIT" (implying Expat), even if there's actually no license information in the repository. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Guix libification.
On Sat, Jun 10, 2017 at 12:08:21 +0200, Mathieu Othacehe wrote: > The script is becoming bigger and some parts of Guix would be really > handy : (guix records), (guix workers), (guix utils) ... > > I don't want Guix to become a dependency of my script but copying parts > of Guix in not great either. So I'm wondering if some parts of Guix, > useful to other guile projects could be integrated to a lib, guile-lib > for instance ? 1+ I use (guix records) for a few projects. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Changing guix download page from using HTTP to HTTPS
On Sun, Mar 05, 2017 at 16:32:16 +, ng0 wrote: > As it is, it is inaccessible for tor users. This would fix it. The FTP server you mean? rms has asked the FSF sysadmins to fix this as of a day or two ago, so hopefully that'll work soon. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: Leaving the guix project
On Tue, Feb 21, 2017 at 14:13:45 +0100, David Craven wrote:
> In most you can not. And I don't know of a way to tell if it is
> possible without trying it.
The card will either be soldered or be inserted into a slot much like a
PCI card. It sometimes has its own area on the outside of the case;
otherwise it's easy to find because the antennas that connect to it
usually go to the monitor or other corners of the case.
> What about laptops that don't have usb ports anymore? Are there any
> free USB-C wifi dongles yet?
USB-C -> USB adapter.
> What about laptops that have a single usb port? you can only plugin a
> thumbdrive or use wifi?
Does the kernel linux support multi USB port adapters? I've been
meaning to try.
I'm not saying this is ideal. I have only two USB ports on my C201
Chromebook. I use a Wifi dongle or pair my Replicant phone for Internet
access, leaving me with only one free port, which usually houses my
Nitrokey. If I need more ports, I'll need an adapter. Sometimes such
laptops come with {,Micro}SD card readers (mine does), which is also an
alternative to a flash drive.
Many of us are used to having to make sacrifices for freedom. Hopefully
one day this won't be necessary.
--
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05
Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB
https://mikegerwitz.com
signature.asc
Description: PGP signature
Re: Leaving the guix project
On Mon, Feb 20, 2017 at 14:25:51 +0100, John Darrington wrote: > 3. Undertake extra paid employment in some activity (not necessarily computer > related) > which benefits the community, and spend the mony you earn to purchase harware > on which > GuixSD runs better. To add: certain things (like Wifi) do not require a full system replacement, either: adapters/cards of various sorts are available. I unfortunately haven't owned a laptop where the stock hardware works with free drivers; I have a ThinkPenguin wireless USB dongle that I plug into whatever I need to work with. In some laptops, you can simply remove and replace the built-in wireless card. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: jquery 3.1.1
On Sat, Jan 21, 2017 at 20:12:25 +0100, Catonano wrote: > I could use some help, here, by someone used the the Nodejs intricacies Scoped packages are described here: https://docs.npmjs.com/misc/scope I've never actually used them, but they're installed normally: https://docs.npmjs.com/cli/install What's a specific package you're having trouble with? -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: jquery 3.1.1
On Thu, Jan 19, 2017 at 21:48:44 +0100, Catonano wrote: > Anyway, now I have a COMPLETE graph of the dependencies of jquery 3.1.1 > > It's made of > 47311 vertices and > 324569 edges lol... > Anyway, these broken packages pose a challenge to the mission of porting > Jquery into Guix, in my opinion, My greater concern is verifying licenses: that'd have to be considered in the DAG (...I hope it's a DAG; who knows what those node packages might be doing!) to flag potential problems. The JS community is pretty lax on licensing (in both the permissive sense and the I-don't-care sense); the license might not be correct or might be missing entirely. Or might not match what's in the source files. Verifying that many dependencies is going to be a challenge for an automated system; we'd want humans to look at many of them too to make sure things aren't fishy. :x The problem is that one single dependency that's mischaracterized as free---even if it's one of the single-function packages---can destroy an entire project (e.g. jQuery). For some packages, this task is feasible. > The code is here > https://gitlab.com/humanitiesNerd/Culturia Thanks for all the hard work you've put into this. I admit that I don't have the time to read into it much right now, but I'll certainly be following progress on this list. > One last fun fact: while I was watching the output flowing in my terminal, > I saw a package called > > "broccoli-funnel" Ah, they missed a really good logo opportunity! -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: Encrypted root partition
On Wed, Jan 18, 2017 at 03:38:57 -0800, Chris Marusich wrote: > As a bonus, I realized that one could use this feature to encrypt swap, > also. You can encrypt your swap area by using a swap file in the root > file system. Specifically, if you do something like this... Using an ephemeral key for swap (that is: a temporary key that is randomly generated and never stored) is preferred: when you unmount it, the data won't be recoverable. Mounting a normal swapfile, on the other hand, writes swapped memory to disk, which opens a host of potential security and forensic issues. Of course, so does traditional swap. :) I'm not familiar enough with Guix (yet!) to know how to set it up, but I also haven't done any research. Arch has a good summary: https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: Packaging IceCat extensions with Guix
On Thu, Jan 12, 2017 at 23:26:24 -0200, Adonay Felipe Nogueira wrote: > We are more unhappy because CludFlare makes site visitors (of any site > that uses their service) to use non-free software automatically. Not that this excuses the issue or lessens the need for the liberation of CloudFlare's JS, but it is worth noting that their CAPTCHA works with JS disabled. Certain adblockers and other privacy addons (including FF's built-in) might block the JS-free version from loading; you'll have to play around with that as appropriate. There are rare occasions where the site uses the JS-only "challenge", which does actually require JS. I use archive.org or some other cache to view the site in that case. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: [Patch 0/10] Add Ring
On Wed, Nov 09, 2016 at 12:07:10 -0600, Lukas Gradl wrote: > If anyone would like to work on this patch series, please feel free to > claim it as your own. I hope my work will be of some use. If nobody > picks it up, I will be very happy to come back to it, but that will most > likely not happen within the next two months. With that in mind, as part of the evaluation, the Ring team agreed to create a build system that conforms to GNU standards. They're likely to wrap their CMake system, but hopefully this change will make it easier to package in the future. I don't know the timeline, though. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: [PATCH 1/1] gnu: Add ccid.
Marius: Sorry for the late reply. On Fri, Oct 28, 2016 at 12:27:29 +0100, Marius Bakke wrote: > Packages are not allowed to write to /var, so to run pcscd on Guix you > will have to symlink ~/.guix-profile/pcsc/drivers to > /var/lib/pcsc/drivers manually, until we have a system service for > pcscd. Can you try that? That does indeed work. Thanks. Part of this for me is being unfamiliar with how everything in Guix works, so I'm sure it'll make a lot more sense once I see what service you come up with and observe its conventions. >> Debian has the dependencies structured such that pcscd has ccid as an >> input. > > This would work, but ccid is one of potentially many drivers for pcscd, > so I'm reluctant to "hard code" it. It would not be possible to use > other drivers if usbdropdir is set to the ccid output. Okay, that sounds fine with me if there is a potential to be able to use other drivers; I'm not familiar enough with pcscd to know. Thanks for working on this! -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: [PATCH 1/1] gnu: Add ccid.
On Thu, Oct 27, 2016 at 10:46:11 +0100, Marius Bakke wrote: > + `(#:configure-flags (list (string-append "--enable-usbdropdir=" %output > + "/pcsc/drivers")) When I run pcscd under Guix, I get: hotplug_libudev.c:122:HPReadBundleValues() Cannot open PC/SC drivers directory: /var/lib/pcsc/drivers 0041 hotplug_libudev.c:123:HPReadBundleValues() Disabling USB support for pcscd. I believe that is what `--enable-usbdropdir' is referencing in ccid. pcsc-lite has the same configuration option, but it's currently hardcoded to /var/lib/pcsc/drivers; could you update it to match ccid's and see if that works? Debian has the dependencies structured such that pcscd has ccid as an input. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: [PATCH 0/2] gnu: Add libpcsclite
Marius: Thanks for your mentoring on this. :) On Mon, Oct 24, 2016 at 17:21:18 +0100, Marius Bakke wrote: > I'll continue working on getting ccid integrated and eventually make a > pcscd service for GuixSD. Is there anything you'd like help on? I'd be happy to test whatever you come up with as soon as it's available. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
[PATCH 1/2] gnu: Add pcsc-lite
* gnu/packages/gnupg.scm (pcsc-lite): New variable.
---
gnu/packages/gnupg.scm | 32
1 file changed, 32 insertions(+)
diff --git a/gnu/packages/gnupg.scm b/gnu/packages/gnupg.scm
index 5fcc03a..da48e26 100644
--- a/gnu/packages/gnupg.scm
+++ b/gnu/packages/gnupg.scm
@@ -9,6 +9,7 @@
;;; Copyright © 2016 Christopher Allan Webber <cweb...@dustycloud.org>
;;; Copyright © 2016 Nils Gillmann <n...@libertad.pw>
;;; Copyright © 2016 Christopher Baines <m...@cbaines.net>
+;;; Copyright © 2016 Mike Gerwitz <m...@gnu.org>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -30,8 +31,10 @@
#:use-module (gnu packages)
#:use-module (gnu packages adns)
#:use-module (gnu packages curl)
+ #:use-module (gnu packages linux)
#:use-module (gnu packages openldap)
#:use-module (gnu packages perl)
+ #:use-module (gnu packages pkg-config)
#:use-module (gnu packages pth)
#:use-module (gnu packages python)
#:use-module (gnu packages qt)
@@ -73,6 +76,35 @@ Daemon and possibly more in the future.")
(properties '((ftp-server . "ftp.gnupg.org")
(ftp-directory . "/gcrypt/libgpg-error")
+(define-public pcsc-lite
+ (package
+(name "pcsc-lite")
+(version "1.8.18")
+(source (origin
+ (method url-fetch)
+ (uri (string-append
+"https://alioth.debian.org/frs/download.php/file/4179/;
+"pcsc-lite-" version ".tar.bz2"))
+ (sha256
+ (base32
+"0189s10xsgcmdvc2sixakncwlv47cg6by6m9vdm038gn32q34bdj"
+(build-system gnu-build-system)
+(native-inputs
+ `(("perl" ,perl) ; for pod2man
+ ("pkg-config" ,pkg-config)))
+(propagated-inputs
+ `(("libudev" ,eudev)))
+(home-page "https://pcsclite.alioth.debian.org/pcsclite.html;)
+(synopsis "Middleware to access a smart card using PC/SC")
+(description
+ "pcsc-lite provides an interface to communicate with smartcards and
+readers using the SCard API. pcsc-lite is used to connect to the PC/SC daemon
+from a client application and provide access to the desired reader.")
+(license (list license:bsd-3; pcsc-lite
+ license:expat; src/sd-daemon.[ch]
+ license:isc ; src/strlcat.c src/strlcpy.c
+ license:gpl3+; src/spy/*
+
(define-public libgcrypt
(package
(name "libgcrypt")
--
2.9.3
[PATCH 2/2] gnu: gnupg: patch scdaemon libpcsclite path
* gnu/packages/gnupg.scm (gnupg): Use absolute path of pcsc-lite for
libpcsclite in `scd/scdaemon.c'
---
gnu/packages/gnupg.scm | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/gnupg.scm b/gnu/packages/gnupg.scm
index da48e26..52af7c0 100644
--- a/gnu/packages/gnupg.scm
+++ b/gnu/packages/gnupg.scm
@@ -293,6 +293,7 @@ compatible to GNU Pth.")
("libksba" ,libksba)
("npth" ,npth)
("openldap" ,openldap)
+ ("libpcsclite" ,pcsc-lite)
("readline" ,readline)
("sqlite" ,sqlite)
("zlib" ,zlib)))
@@ -301,9 +302,15 @@ compatible to GNU Pth.")
#:phases
(modify-phases %standard-phases
(add-before 'configure 'patch-config-files
- (lambda _
+ (lambda* (#:key inputs outputs #:allow-other-keys)
(substitute* "tests/openpgp/defs.inc"
(("/bin/pwd") (which "pwd")))
+(substitute* "scd/scdaemon.c"
+ (("\"(libpcsclite\\.so[^\"]*)\"" _ name)
+ (string-append "\""
+ (assoc-ref inputs "libpcsclite")
+ "/lib/" name
+ "\"")))
#t)
(home-page "https://gnupg.org/;)
(synopsis "GNU Privacy Guard")
--
2.9.3
[PATCH 2/2] gnu: gnupg: libpcsclite propagated input
* gnu/packages/gnupg.scm (gnupg): Add libpcsclite as propagated-input
---
gnu/packages/gnupg.scm | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/gnupg.scm b/gnu/packages/gnupg.scm
index c4920b0..562b377 100644
--- a/gnu/packages/gnupg.scm
+++ b/gnu/packages/gnupg.scm
@@ -296,8 +296,14 @@ compatible to GNU Pth.")
("readline" ,readline)
("sqlite" ,sqlite)
("zlib" ,zlib)))
+(propagated-inputs
+ `(("libpcsclite" ,libpcsclite)))
(arguments
-`(#:configure-flags '("--enable-gpg2-is-gpg")
+`(#:configure-flags
+ (list "--enable-gpg2-is-gpg"
+(string-append "LDFLAGS=-Wl,-rpath="
+ (assoc-ref %build-inputs "libpcsclite")
+ "/lib"))
#:phases
(modify-phases %standard-phases
(add-before 'configure 'patch-config-files
--
2.9.3
Re: NPM and trusted binaries
On Thu, Sep 08, 2016 at 21:54:36 +0200, Jan Nieuwenhuizen wrote: > The question I'm trying to answer is: how does `a user' who builds a > package from the repository install the needed dependencies. Sorry, I misinterpreted. `npm install ' will by default install all devDependencies; the `--production' flag suppresses that behavior. Many packages define a command to be run when `npm test` is invoked, which would in turn need the devDependencies to run the test suite. > I very much doubt that users install the essential dependencies all by > building those from the source repository. How would they do that? No, they don't. I'm not sure if it's even possible with how npm works, though I haven't done that sort of research. But that'd be Guix' responsibility---just because npm doesn't offer a way to do that doesn't mean that Guix can't, provided that there is an automated way to track down each of the packages and determine how they are built. Some might use Make, some Grunt, nothing, etc. > My working hypothesis is that it's impossible to do so for any > moderately interesting npm package. And I would very much like someone > to show me (with working code) that instead it is possible. I'm hoping such code is precisely what this project produces. :) > what the benefits are (in terms of software freedom) of spending our > energy by upholding the source/binary metaphor (even if for a majority > of packages there may not be a difference). As I mentioned, I don't see a difference between this situation and packaging other software that has no distinction between source code and "binary" distribution. It's just a hell of a lot more complex and the package manager used to manage these packages (npm) doesn't care about these issues. Corresponding source code must include everything needed to build the software, and must be the preferred form of modifying that software. This assumption cannot be made with the state of the packages in the npm repository. Some of the files might not even be in the source repository (e.g. generated). I have great faith in Guix and its mission; it would be a shame to see that tainted by something like this. Normally someone will look over a package manually before adding it; but mass-adding thousands of packages in an automated manner is even _more_ of an argument for the importance not trusting binary distributions. With all that said, I have no idea how it'll be done. Someone could just add any old file to the published npm package and never commit it to any source repository. I've done that accidentally. I don't know how you'd handle situations like that. I don't know how you'd handle a situation where a build script doesn't even work on a machine other than the author's. I don't know how you confirm that the software produced from a build will actually be the same as the software normally installed when you invoke `npm install `. If a package doesn't build from source, contain all the necessary files, etc, it's not practical to exercise your freedoms, and so including it would be bad. But if one dependency out of thousands has that problem, then what? If one of the dependencies happens to actually contain non-free code, then what? When I evaluate software offered to GNU, I have to consider each and every dependency. This usually isn't a difficult task---many libraries are standard, have already been reviewed by a project like Debian, and there's rarely more than a few dozen of them. I then build it from source. If I have the packages on my system (Trisquel at present), I know that they're free and can be built from source. Otherwise, I must compile the library myself, recursively as needed for all dependencies (which is usually not an issue). If any of those were a problem at any point, then the whole of the project is a problem. If any of those dependencies are non-free, the whole of the project is non-free unless it can be swapped out. If one obscure library requires several dark incantations and a few dead chickens, users can't practically exercise their freedoms, and that would be a problem for the package. Now how the hell is this enforced with thousands of dependencies that have not undergone any review, within a community that really couldn't care less? Even something as simple as the license: package.json has no legal force; it's _metadata_. I feel like this will have to be manually checked no matter how it is done; any automated process would just be a tool to aid in a transition and keeping a package up-to-date. I don't really see any other way. So I think that I share in your concern with how such a thing would possible be done. My point is that if it can't, it shouldn't be at all (where is where we differ). -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: NPM and trusted binaries
On Thu, Sep 08, 2016 at 10:45:57 +0200, Jan Nieuwenhuizen wrote: > If a user builds an npm package from its source repository, I assume > that they install the devDependencies needed for that using npm? Unfortunately that depends on the project. Some projects use devDependencies only for things like linters, test runners, assertion systems, etc; others might need them for building. > The transitive closure of installing all devDependencies for the `q' > package by building them all from their source repositories, means > building > 6000 packages. Many of those packages are shared between others. Given a sufficiently large pool of npm packages, there'll be a great deal of intersections in the graph. I haven't been following this closely enough to speak intelligently about the conversion, though. > I would also like to explore if the source/binary package metaphor is > a valid one for npm. Sure it is. > For the packages that I considered, I used the `diff' command to assert > that the installable npm package includes javascript and C files and are > identical to the ones in the repository. In some cases, this will be true. Possibly in a majority. Think of npm as publishing the results of `make dist` (literally, that's what I do). That could do anything, it could do pretty much nothing. If a Perl/Python/PHP/Ruby/Scheme/ script is in the distribution tarball unmodified from the source, what considerations do we give it when packaging for, say, Debian? But we'd have to know that on a case-by-case basis. If we want a general solution to this problem, we wouldn't want to add a bunch of exceptions. If it's literally publishing the source code repository (which many are), then there is no distinction. But we'd have to know that to be true. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: NPM and trusted binaries
On Tue, Sep 06, 2016 at 18:50:48 +0200, Pjotr Prins wrote: > On Tue, Sep 06, 2016 at 11:48:04AM -0400, Thompson, David wrote: >> This violates a core principle of Guix: reproducible builds. I don't >> support patches that encourage using pre-built binaries. > > In principle I agree. We want to be able to read the code. > > Still, I think Guix would benefit from a somewhat more relaxed stance > in this. If a user is able to build from source, shouldn't Guix be able to? And if neither can, how can we guarantee that the provided binary is even free and actually corresponds to the given source? From a software freedom perspective, the source code _is_ the program. If that is unworkable, then so is the software itself. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: ‘core-updates’ merge is a squashed commit
On Thu, Aug 04, 2016 at 17:06:15 +0200, Andy Wingo wrote: > What's the rationale for requiring non-HEAD commits to be signed when > pushing? For me a signed HEAD implicitly signs all parent comments, in > my mental trust model anyway :) That could be a potentially daunting/impossible task for the person signing a commit. Aside from asserting one's identity, GPG-signed commits also (can) help in the event that the system of one of the Guix hackers with commit access is compromised. Attacking Savannah is one way to compromise the repo, but compromising one of the many Guix hackers' systems is another. If a commit is signed in the hacker's local repo, it cannot be manipulated by an attacker, nor can an attacker sign a new malicious commit. Unless, of course, the GPG key resides on the same box, the attacker can get a hold of it, and can use a keylogger/etc to get the passphrase. Smart cards help here. I also recommend against auto-signing commmits on rebase unless you first verify that each commit within that range has a valid signature beforehand. Not fool-proof, but nothing is. :) -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer https://mikegerwitz.com | GPG Key ID: 0x8EE30EAB signature.asc Description: PGP signature
Re: Unpatched security flaws in GNU IceCat 38
Mark: On Wed, Aug 03, 2016 at 23:06:17 -0400, Mark H Weaver wrote: > I'm sorry to report that GNU IceCat 38 can no longer be safely used, due > to critical security flaws that are believed to allow remote code > execution. I was unable to backport upstream fixes from 45.3 to 38. > > Until IceCat 45.3 is available, I recommend that you use Epiphany. Could you elaborate? I assume you're referencing this: https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox-esr/#firefoxesr45.2 Are you going to be publishing an announcement about this? Sorry if I missed it; gnu.org/s/icecat doesn't mention anything. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer https://mikegerwitz.com | GPG Key ID: 0x8EE30EAB signature.asc Description: PGP signature
