bug#22883: Trustable "guix pull"
Hey, guys. Chris mentioned this thread to me. I'm happy to see the discussion! Chris: unfortunately, my `mml-secure-openpgp-encrypt-to-self` flag somehow got unset when I sent you my reply, so I can't read my own message. But I'll rewrite some of it here. On Mon, Apr 25, 2016 at 20:13:59 -0400, Leo Famulari wrote: >> Note that we’ll be signing patches we push on behalf of contributors who >> do not have commit access (reviewer’s responsibility). >> >> Also, rebasing, amending, and cherry-picking code signed by someone else >> would lose the original signature, which isn’t great and should be >> avoided, if possible. > > I think it's common to make minor edits when committing on behalf of > others. For example, the committer might clean up a commit message or > standardize indentation. > > How should we handle this? You don't. One of the core purposes of digital signatures is to ensure integrity of the signed data: if I submit a patch, I don't want someone else modifying it and saying it was my own, or saying it was modified without supplying a diff; that'd be a misrepresentation; a horror story almost. ;) The question is for what purpose you're signing commits. Chris mentioned trust, but that can come in a few different forms. Signatures ensure: - Authentication: whether the commit came from a trusted source; - Integrity: assurance that the commit has not been modified; and - Non-repudiation of origin: the signer cannot deny signing it. If you only care about authentication, then it doesn't matter if the signature is retained---it only matters that the person who eventually signs off on the commit is trusted. In that case, just sign it. If it's integrity, then make another commit that changes the original. I recommend this regardless, for the reason I stated above; just branch, apply their commits, your change, and merge. For non-repudiation assurances, you'll need to keep the original signature as well. This might be useful, say, in the case of issues with copyright assignments---maybe an employer holds copyright on the code and the employee claims he/she isn't the person that actually submitted it. All of this subject to the usual crypo-caveats (no compromised private key, yadda yadda). Now, what is being signed isn't actually the code---it's the contents of the commit object, which includes a SHA-1 hash of the tree, parent commit(s), author, committer, timestamp, and commit message: --8<---cut here---start->8--- $ git cat-file -p 7062845 tree 7d21b900c0773d7fdc898aecff11053a910ac18d parent 2b56dc019a049b2f68ce078b243fc313fbaeacf3 author Ludovic Courtès 1461943404 +0200 committer Ludovic Courtès 1461945944 +0200 gpgsig -BEGIN PGP SIGNATURE- Version: GnuPG v2 [...] -END PGP SIGNATURE- nls: Add Simplified Chinese translation. [...] --8<---cut here---end--->8--- My point with this[*] is that the GPG signature you receive isn't meaningful in the case of a rebase---if it signed blobs or a diff, maybe it would be. But since rebasing will eventually cause the GPG-signed commit to be GC'd (unless there's a ref to it), you can't modify the commit and just reference the old diff with the original signature. More details in a discussion with Whonix here: https://web.archive.org/web/20150619232904/https://www.whonix.org/forum/index.php?topic=538.msg4278#msg4278 So if you do want to clean up or squash GPG-signed changes from contributors, or do other rebasing, then I'd either push back and tell them to do it, or maybe have them send GPG-signed _patches_ to a public mailing list where it can be permanently archived; then everyone can see the original. [*] SHA-1 was never intended to be used as a security measure in Git---nor should it be; SHA-1 is effectively broken with the demonstration of a freestart collision last year (where the attacker controls the IV; but it's only a matter of time). So if a collision can be found for any of those signed SHA-1 hashes---or any hashes they reference---_that actually makes sense to Git and humans_, then your signature will still be perfectly valid. But distribution archives are also GPG-signed, so Git will never be the only place of reference. I need to update my article, but I'm essentially saying that it's really hard to have strong cryptographic assurances with Git even with signed commits---that attack surface is simply too large, as I mentioned in the Whonix discussion. Realistically, it's extremely unlikely that something will ever happen, but until Git switches to a secure hash algorithm (...har har), don't expect full integrity. If you're using signatures for authorization primarily, then you don't really need to worry. -- Mike Gerwitz Free Software Hacker | GNU Maintainer & Volunteer https://mikegerwitz.com FSF Member #5804 | GPG Key ID: 0x8EE30EAB signature.asc Description: PGP signature
bug#22883: Authenticating a Git checkout
Ludo: On Fri, Jun 03, 2016 at 18:12:47 +0200, Ludovic Courtès wrote: > First, ‘git pull’ doesn’t do it for you, you have to pass ‘--verify’ and > there’s no way to set it globally. That's unfortunate. Does your checkout scenario include a fresh clone? If so, a pull flag wouldn't help there. Leo mentioned a patch; I don't think that'd be too difficult (looking at other config options in builtin/pull.c), and would be a great idea. It appears to pass it off to merge.c; that might be a useful area to verify signatures as well (pull being a fetch && merge/rebase), in a general sense. > Second, even if it did, it would be a shallow check: as Mike notes in > <https://mikegerwitz.com/papers/git-horror-story> with the ‘signchk’ > script, you actually have to traverse the whole commit history and > authenticate them one by one. But that’s OK, it runs in presumably less > than a minute on a repo the size of Guix’s, and we could also stop at > signed tags to avoid redundant checks. Practically speaking, that's probably fine, though note that a signed tag is just a signed hash of the commit it points to (with some metadata), so you're trusting the integrity of SHA-1 and nothing more. With that said, the tag points to what will hopefully be a signed commit, so if you verify the signature of the tag _and_ that commit, that'd be even better. Git's use of SHA-1 makes cryptographic assurances difficult/awkward. An occasional traversal of the entire DAG by, say, a CI script would provide some pretty good confidence. I wouldn't say it's necessary for every pull. > Third, as I wrote before¹, relying on the OpenPGP web of trust to > determine whether a commit is “valid” is inappropriate: what we want to > know is whether a commit was made by an authorized person, not whether > it was made by someone who happens to have an OpenPGP key directly or > indirectly certified. If you want to keep with the convenience of the web of trust, then you can have a keyring trusting only the appropriate Guix hackers. Otherwise, I agree. > Fourth, there’s inversion of control: ‘git log’ & co. call out to ‘gpg’, > so if we want to do something different than just ‘gpg --verify’, we > have to put some other ‘gpg’ script in $PATH. Blech. What types of things are you considering? Or are you just considering the possibility? I agree that it is awkward. At the same time, making it configurable (in the git sense) can potentially be very dangerous, because a malicious script (e.g. configure) could just modify it to a noop (e.g. `true`) and circumvent signature checks. > Fifth, even if we did that, we’d be stuck parsing the possibly l10n’d > output of ‘gpg’. Pretty fragile. In the log output? You could use --pretty and %G*. Otherwise, yes parsing GPG's output seems dangerous; surely there's a better way (like Leo mentioned). > Well no, it turns out that libgit2³ has no support for signed commits > (the ‘signature’ abstraction there has nothing to do with OpenPGP > signatures.) !? D: That's more concerning from a community mindset standpoint than anything. > Seventh, even if it did, what would we do with the raw ASCII-armored > OpenPGP signature? GPG and GPGME are wy too high-level, so we’d > need to implement OpenPGP (in Guile, maybe based on the OpenPGP library > in Bigloo?)?! What about gpgme/libgcrypt?[*] > I stumbled upon git-lockup⁴, which uses something other than OpenPGP to > sign objects in Git. However, signatures are not stored in commits but > rather in “git notes”, which, IIUC, are mutable objects detached from > the rest of the object store, so not great. It seems a bit over-complicated. Without reading much into it, it doesn't strike me as much different than a detached signature, but the problem is that the signature (as you implied) can just be deleted. Git's commit/tag signatures are embedded in the actual object. git-lockup also seems to hash "(branch,commitid) pairs", which signs considerably less data than Git's signature would (unless it actually signs the full object, not a string referencing it). I'll have to read over your first reference (your message) and its references; now I'm curious. [*]: I was actually considering writing an FFI for libgcrypt (if it doesn't exist already), but it made me uncomfortable without studying whether Guile can make assurances that pointer-referenced data in "secure" memory will never be copied anywhere else. I was going to bring it up in the near future on the guile mailing list after I did some research myself; no need to derail the discussion here. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer https://mikegerwitz.com FSF Member #5804 | GPG Key ID: 0x8EE30EAB signature.asc Description: PGP signature
bug#22883: Authenticating a Git checkout
On Sat, Jun 04, 2016 at 13:17:53 +0200, Ludovic Courtès wrote: > We have incomplete libgcrypt bindings: > > http://git.savannah.gnu.org/cgit/guix.git/tree/guix/pk-crypto.scm > > This is used for the authentication of substitutes: > > https://www.gnu.org/software/guix/manual/html_node/Substitutes.html Oh, excellent; I'm not sure if I would have come across that. I should poke around Guix a bit more and see all the goodies that everyone has created. Thanks. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer https://mikegerwitz.com FSF Member #5804 | GPG Key ID: 0x8EE30EAB signature.asc Description: PGP signature
bug#22883: Trustable "guix pull"
On Sat, Jun 04, 2016 at 18:19:31 +0200, Werner Koch wrote: > There are no issues with l10n because _all_ scripts SHOULD use gpg with > the options --status-fd and --with-colons. That output creates a well > defined API and we try very hard never to break it. > [...] > I have never looked into git to check whether git correctly calls gpg > to verify signatures. That should eventually be done. A quick glance (latest master, gpg-interface.c:208 verify_signed_buffer): It invokes `gpg --status-fd=1 --verify FILE -`, where FILE is a signature written to a temporary file for the sake of invoking GPG. It checks for a non-zero exit code and GOODSIG: ret |= !strstr(pbuf->buf, "\n[GNUPG:] GOODSIG "); -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer https://mikegerwitz.com FSF Member #5804 | GPG Key ID: 0x8EE30EAB signature.asc Description: PGP signature
bug#22883: Authenticating a Git checkout
On Sun, Jun 05, 2016 at 15:39:04 -0500, Christopher Allan Webber wrote:
> One theoretical optimization: if I verify the DAG, could I store
> somewhere that I've verified from commit cabba6e and upward already, so
> the next time I verify it only has to verify the new commits?
tbh, I haven't given this the amount of thought/research that I feel it
needs. Unfortunately, you got me thinking, so here's another long
message.
In essence, this is equivalent to Ludo's suggestion of stopping at
the last tag (if you envision, say, tagging the last processed commit)
_provided that_ you also verify the commit that the tag is pointing to.
My short answer is: practically speaking, it's probably fine, because
you're more than likely trying to defend against an attacker that gains
access to the repo, not a second-preimage attack.
* *
*
Long answer (braindump):
When I consider the potential threats, I consider that the integrity of
each blob, tree, commit, etc are fairly well assured by their hashes,
but depend entirely on the security of SHA-1, whose future is
increasingly grim. SHA-1 does just fine for uniquely identifying
objects---and if it didn't, hashes offending preimages would just be
blacklisted. But it was never intended for security.
The problem is pretty bad: signed commits will ensure the integrity of
the commit itself (the object---as in `git cat-file -p COMMIT`); the
problem is that you don't just have to find a preimage for the hashes
signed in that commit: the tree hash is what really dictates the
content, and that tree hash in turn identifies other trees and blobs:
$ git cat-file -p 'HEAD^{tree}'
...
100644 blob 9b9481deea8cee4cc61971a752d02c04d5f0654econfigure.ac
04 tree f2b4528e1f66f3bbc4742dc4a11bd1283cd475b9doc
...
That blob contains the actual file contents.
So in a large project like Guix, you have so many opportunities! You
can try to find preimages for any of the trees or blobs _without having
to worry about any signatures_; neither trees nor blobs are signed.
With that said, if I recall correctly (and after a very brief glance at
fetch-pack.c), a successful preimage attack would only affect users who
haven't already fetched the legitimate object---otherwise Git wouldn't
bother fetching it. I'm not sure if I find comfort in this or not: it's
been used by some to dismiss the problem of collisions, but (assuming
git is silent about it---and why wouldn't it be, as it wouldn't know
better) that's worse, since maintainers and common contributors wouldn't
notice anything wrong at all. But someone who clones fresh and compiles
would be screwed.
So signing commits almost certainly protects you against someone who
gains access to the repository on a common origin or a
maintainer/contributor's PC, provided that nobody's private key is
compromised.
But there doesn't seem to be any way to secure a git repository against
a second-preimage attack.
So given that, it doesn't really matter if you re-verify all the commits
or not: an attacker doesn't need to even bother with the commit
object. I guess one option is to keep a local copy of the repository,
clone a fresh copy, and occasionally diff _every_ object (commit, tag,
tree, blob) for differences.
So if Git wants to take this issue seriously, changes have to be
made. In the meantime, in addition to commit verification, you can
always keep around a local copy of the repository, always clone a copy,
and ensure that builds between the two are reproducible.
signature.asc
Description: PGP signature
bug#22883: [sr #109104] Add Git 'update' hook for Guix repositories
Follow-up Comment #4, sr #109104 (project administration):
Unfortunately, this hook can be easily defeated. Here's some example output
from the current tip of master:
$ git cat-file -p HEAD
tree c65e675351fe76b2630df24eddcb2449774eb344
parent e87c7ec2de815f05d7a84e2792e2da700bb26a38
author Leo Famulari 1470169005 -0400
committer Leo Famulari 1470538536 -0400
gpgsig -BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAABCAAGBQJXpqMoAAoJECZG+jC6yn8Ihn8P+wfUhS5HOL7181KC8ZRdTFC5
5XjavRq/08LJzO2mxer1r5oVcWYuZAvnPKZltO1vdIp0ncvU40c4nmaNpQiB/w6B
8slSkqBsoCVE7GEKHoAWju7Rwwlqw4fUSgDWw5JpJ/3S2PhRj+tvy8o/wCeBEwTL
c90yivRmpKZcdcRgSPHqhHhMJ7lIJxbvHKlb30SPz9vdQTj13EUeeyyJQc/7lu7D
kUiUu9MOjC3o8dPE8E7otMnD51xfj8SNvs5h7cZAMByS0Qk06RwK+O5POkBlXUMV
lVxgPJsC7LfqJJ/VGLb5uOIoXMUCGV3mzdDXA+Pe+xvTTGOT+8rNsPl7kwxAGYqC
vPVrY1dC6CzRX8/7etvb99UHf2nx0NbYRAvetZzh9j6WBbMqGBgHMndRh6i6Y7Fl
BioG+J22sXCQjf3ydRvjd8cznlfvBCTqo9zSqeoG7Ha/qSh1pX16KAUxLi1YGzK6
I79iqOEvpoxwS/9Ym+GB+4rLTimqhtDKN7v3XaQudJ8t6hMlGi+pqjiLhNI8q2c9
dd3RthLu+Zom4duwnGo0BJEVC+CDLYGcdiwCKOpLaI9KtQbCv6useALPBk5RKPHr
pE1Y7nTmBw7Rxl2GuaNOH9x5cHOuULfWW+HLm3JSwTjD4cpAxnFDP7qYINSo7XGR
HGWK/43B5syf6FhZws8N
=h+H0
-END PGP SIGNATURE-
gnu: Add python-pythondialog.
* gnu/packages/python.scm (python-pythondialog): New variable.
(python2-pythondialog): Inherit from PYTHON-PYTHONDIALOG.
Co-authored-by: Vincent Legoll
The hook currently greps for `^gpgsig '. It will indeed find a GPG signature
if it exists, but to circumvent it, an attacker need only put `gpgsig' in the
commit message at column 0---the commit messages aren't indented in the
output.
You can replace the entire loop in the hook with this:
git log --pretty='%GK %h %s' "$rev_old^..$rev_new" \
| awk '/^ / {
e=1
print "error: missing signature:" $0 > "/dev/stderr"
}
END { exit e }'
If the commit is not signed, then `%GK` (GPG key id) will yield an empty
string.
Here's some example output (run with HEAD~15..):
error: missing signature: 7ccb874 gnu: zsh: Move to shells.scm.
error: missing signature: 7977d76 Update NEWS.
___
Reply to this item at:
___
Message sent via/by Savannah
http://savannah.gnu.org/
bug#25254: [minor] 'About' page says GuixSD is a "GNU/Linux distribution"
On Fri, Dec 23, 2016 at 18:35:26 +0100, David Craven wrote: > Besides on most systems there is a lot more software than just what is > provided by GNU or Linux. If we want to be precise we can call it a > mostly POSIX distribution. It's a common misunderstanding that "GNU" refers to only to GNU programs. GNU is a complete operating system, which contains a lot of non-GNU software. GNU didn't develop its own replacements if other free replacements were available. This article does well to explain: https://www.gnu.org/gnu/thegnuproject.html Developing a whole system is a very large project. To bring it into reach, I decided to adapt and use existing pieces of free software wherever that was possible. For example, I decided at the very beginning to use TeX as the principal text formatter; a few years later, I decided to use the X Window System rather than writing another window system for GNU. Because of these decisions, and others like them, the GNU system is not the same as the collection of all GNU software. The GNU system includes programs that are not GNU software, programs that were developed by other people and projects for their own purposes, but which we can use because they are free software. -- 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
bug#27437: Source downloader accepts X.509 certificate for incorrect domain
On Thu, Jun 22, 2017 at 21:12:27 +0200, Ludovic Courtès wrote: > I think only GNU and kernel.org provide signatures, which represents 6% > of our packages. Of the 30% that do not have an updater, surely some > have digital signatures, but we’re probably still below 10%. The > situation is bad in general… What about signed tags/commits? -- 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
bug#28578: xorg not starting on x200 due to recent commit
On Fri, Dec 22, 2017 at 16:19:48 -0600, Christopher Lemmer Webber wrote: >> I run an x200 as well. In case it is useful, here is the output of >> lspci cut down to video-relevant stuff. >> >> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory >> Controller Hub (rev 07) >> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset >> Integrated Graphics Controller (rev 07) >> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset >> Integrated Graphics Controller (rev 07) > > It seems that others aren't having troubles with this on their x200 > machines, but well, I still am (though mine is a refurbished x200, and > there are some differences between different x200 machines anyway, so > maybe that accounts for the difference). Unfortunately being unable to > upgrade my x200 system profile is fairly serious. (Does anyone mind > pasting their equivalent lspci output who's saying "it works for me" on > an x200? I wonder if we can find the soruce of the difference.) 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) I'm running Libreboot. -- 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
bug#28578: xorg not starting on x200 due to recent commit
On Sun, Dec 24, 2017 at 11:59:11 -0600, Christopher Lemmer Webber wrote: > It looks the same. Maybe the Libreboot version is responsible... I'm > not sure. I just received mine recently from Libiquity and I haven't had a chance to play around with any of the flashing tools, so I don't know my version atm. If you know the steps to run a suitable comparison, I'd be happy to do so. If you don't have it figured out by March I'll be at LP2018 if you want to do a more hands-on comparison. -- 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
bug#29881: guix system reconfigure fails if config.scm contains LUKS mapped-devices
On Fri, Dec 29, 2017 at 14:41:21 +0100, Ludovic Courtès wrote: > Diego Nicola Barbato skribis: > >> When running `guix system reconfigure /etc/config.scm' as root I get the >> following error: >> >> guix system: error: failed to load '/etc/config.scm': >> /etc/config.scm:24:9: /etc/config.scm:24:9: In procedure allocate-struct: >> Wrong type argument in position 2: 3 > > I’m afraid you’ll have to “rm -rf ~/.cache/guile/ccache” (Guile’s > auto-compilation cache) to work around > e2721a05e7d778bdf845b7cb7a42fd9f76095b69. > > Can you confirm? I just ran into this, and clearing ~/.cache/guile/ccache did indeed fix it. 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
bug#30611: texlive substitute download failure
Hello, everyone! I'm trying to install texlive, but unfortunately I get an error downloading: --8<---cut here---start->8--- substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0% substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0% substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0% The following package will be installed: texlive 2017/gnu/store/5izbiydbqac7gi9rmzhbmcmafd23v98p-texlive-2017 substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0% The following derivations will be built: /gnu/store/zqdg1zj69qhjbjycr1m1dp2kirc2y8xk-profile.drv /gnu/store/rdnvlc58z4zqhx1r99826svvxr32va22-gtk-icon-themes.drv /gnu/store/i79cszz0dnxlldghbwdqlh3hfby5wjwa-xdg-mime-database.drv /gnu/store/cln6b40jv0icq3rk8cdr42mf36fdniw2-gtk-im-modules.drv /gnu/store/ca73bzg2yjkjaaw492q488ipq9c4kpbm-xdg-desktop-database.drv /gnu/store/1z31ybkxx5z1blq7a63sbndjr7ihrdl8-texlive-texmf-2017.drv /gnu/store/627yjn42y7g14a6ivz29cm5zrm513za6-texlive-texmf-2017.drv /gnu/store/ijvcyhwz84vsqbaxqp1ingw7jhlm9ffp-texlive-bin-20170524.drv /gnu/store/7wnmjj549wv0mzqg0hm0j4zbyylw1irx-info-dir.drv /gnu/store/18fwm5q4gjy7yhcf93f22v4q1x3xsql6-fonts-dir.drv /gnu/store/13r34dp7s1ydi6nkw6za4yq8337gwqj8-ca-certificate-bundle.drv /gnu/store/7y7vi15mrhw8in3729lb7jj5p537a2lw-manual-database.drv /gnu/store/bs76zas470iybm5wi53wxf1xl40v57sq-texlive-2017.drv 2,435.6 MB will be downloaded: /gnu/store/yg617p7x9flwqq582bb0vxhcqpv45pll-texlive-bin-20170524 /gnu/store/x9ymgh619a763gxyxa3rikpzrqjmlq9f-ruby-2.4.3 /gnu/store/j4jygazrm6nkhxbnl54dmrlz2749zs2y-lua-5.3.4 /gnu/store/5rnvmy02yazy8iwaa91kijbbqp8qmflz-texlive-20170524-texmf.tar.xz /gnu/store/6cs06m3sxz4ygxfaskq664kjw3j25c7w-texlive-2017 /gnu/store/94v9vc748rfrbb20sdpypbg351p6rcgi-potrace-1.15 /gnu/store/d7fnhr9imr4aqbfm6yc114bnvpsrw56a-zziplib-0.13.68 /gnu/store/l234wcs9fpnvc1lcj5hz66bai0h035si-teckit-2.5.7 Downloading https://mirror.hydra.gnu.org/guix/nar/5rnvmy02yazy8iwaa91kijbbqp8qmflz-texlive-20170524-texmf.tar.xz... texlive-20170524-texmf.tar.xz 2.23GiB 948KiB/s 00:05 [ ] 0.2% guix substitute: error: TLS error in procedure 'read_from_session_record_port': Resource temporarily unavailable, try again. killing process 2102 guix package: error: build failed: some substitutes for the outputs of derivation `/gnu/store/j3m0a6rwrz9jmass4zlndpn5y0x8g5n4-texlive-20170524-texmf.tar.xz.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source --8<---cut here---end--->8--- I upgraded Guix last night (0181df537ffb4e4273b2ca005738fdb7bd3d73f5) and tried again, but same problem tonight. I can build from source, but that's something I had hoped to avoid. Any ideas? -- 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
bug#31365: libvirt/virt-manager: Embeds full path to qemu-system in saved .xml files
On Fri, May 04, 2018 at 17:01:03 -0700, Vagrant Cascadian wrote: > When i create a new libvirt instance with virt-manager, it embeds the > full path to the qemu binary used at the time. For the machine named > "networkboot": > > # grep qemu-system /etc/libvirt/qemu/networkboot.xml > > /gnu/store/0rzb7rjri2kb258j58asndw2pnp0xv9p-qemu-2.11.1/bin/qemu-system-x86_64: > > If I later run "guix gc" and it happens to remove this particular qemu > version, the system no longer runs, of course: > > # virsh start networkboot > error: Failed to start domain networkboot > error: Cannot check QEMU binary > > /gnu/store/0rzb7rjri2kb258j58asndw2pnp0xv9p-qemu-2.11.1/bin/qemu-system-x86_64: > No such file or directory Thanks for looking into this; I hit this problem last night but hadn't had the time to research. I encountered this issue the same way (after a `guix gc'). > It also means each virtual machine may be running on an older version of > qemu, for better or worse. Yes, I was concerned by that as well. :X VMs would not benefit from security fixes, which is to me is the more important issue here. -- 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
bug#31366: Missing icons in virt-manager user-interface
On Wed, Aug 29, 2018 at 18:24:37 -0400, Leo Famulari wrote: > On Wed, Aug 29, 2018 at 02:05:45PM -0700, Vagrant Cascadian wrote: >> Apparently, merely installing adwaita-icon-theme and hicolor-icon-theme >> into the user's profile also works... not sure if this means it should >> be added to propagated-inputs or users are just expected to install >> relevent icon-theme packages themselves... ? > > Yeah, so far it's preferred that users install the icons themselves. I > *thought* this was in the manual but it's not :) > > One advantage of asking users to install the icon themes is that it > makes it easier to update the icon themes without having to rebuild many > packages. That explains why I had this issue in the past and it has since resolved itself. I'm sorry if this type of thing has been discussed before (I don't read every message on the Guix lists), but what about some way of indicating recommended packages as part of the package definition (a sort of soft dependency). Guix could then output to the user after installation that certain package(s) ought to be installed for things to work optimally. Guix could then be helpful to the user without expecting the user to have read all relevant sections of the manual (I have only read portions so far). `guix package` maybe could also have a flag to automatically install recommended packages into the user's profile. There are strong design considerations here; this is an oversimplification of the problem. -- Mike Gerwitz signature.asc Description: PGP signature
bug#31366: Missing icons in virt-manager user-interface
On Fri, Aug 31, 2018 at 15:11:49 +0200, Ricardo Wurmus wrote: > Much like we pin search path recommendations to certain “root” packages > we could do something similar for recommended packages. “glibc”, for > example, could recommend “glibc-locales”; having a package installed > that links with glibc (i.e. all of them) would result in a > recommendation to also install the “glibc-locales” package. For “gtk+” > the recommendation could be to also install one of the icon themes. > Installing any package depending on “gtk+” would then lead to a > recommendation to install one of these packages. That seems like desirable behavior to me. > Unfortunately, some of these recommendations will only be correct when > using Guix on top of a foreign distribution, because we handle common > scenarios on the Guix-based GNU system directly. I can't comment on that, but in this virt-manager case, I did experience the issue on GuixSD. -- Mike Gerwitz signature.asc Description: PGP signature
bug#32820: Some CSS not displaying in latest Icecat
On Mon, Sep 24, 2018 at 23:21:08 -0400, Mark H Weaver wrote: [...] > Christopher Lemmer Webber writes: > >> Overall very excited about the new Icecat being available! >> >> However, css is not displaying on some sites, and I'm not sure why. >> Disable all extensions and try the following examples: >> >> https://addons.mozilla.org/en-US/firefox/ >> https://github.com/ >> >> Both will show up unstyled. I was about to report the same, for exactly those sites (just upgraded Icecat about an hour ago). > Indeed, I see the same problem. My first guess is that it's related to > the fact that we aren't (yet) using Servo, Mozilla's new CSS engine. > Servo requires LLVM/Clang to build, so I disabled it for now, to > simplify the task of getting IceCat 60 working. > > I'll work on enabling Servo in our IceCat package, and see if that fixes > the problem. Thanks! I tried to do more digging to figure out what may be going on, but it's late and I haven't had any luck. The error still happens in safe mode, and it's unrelated to CSP (the CSS does actually load, and is even visible in the Style Editor, but isn't rendered). Icecat isn't providing any errors anywhere, and I didn't find anything useful in strace output. So hopefully enabling Servo fixes it! I'm curious to know why these pages work but not others. -- 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
bug#32833: IceCat 60 showing sites as "insecure" despite using HTTPS
I don't know if this is a problem specific to Guix or upstream; I can give IceCat a try in a Debian VM tomorrow. But I want to make others aware of the problem in the meantime: Even if sites are using HTTPS, IceCat is still saying "This connection is insecure" if you click on the "i" icon in the URL bar. This seems to be a problem with every HTTPS site I visit. On the "Security" tab of the "Page Info" dialog, under "Technical Details", no certificate information is listed; it simply says "Connection Not Encrypted". That's clearly not true, otherwise the page would fail to load. I've tried with sites that use HSTS and don't even support plaintext connections (e.g. my own)---the pages load just fine. I haven't played around with sites with expired certificates or anything yet. But if IceCat is not reporting security status correctly, then users may be at risk, so be careful in the meantime! -- 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
bug#32835: Icecat is missing fonts (on foreign distro)
On Tue, Sep 25, 2018 at 09:04:51 +0200, Björn Höfling wrote: > When Icecat is up, it looks "normal" and can be used normally [the > more images a site uses, the better the user experience is :-)], just > that ALL letters are just boxes with numbers in them (i.e. what you > usually see only partially when some wired UTF-sign is not installed). I run IceCat within a container, and I noticed that upgrading to 60 caused for me the issue that you are describing. But if I run IceCat normally (as installed to my profile), fonts are fine. -- 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
bug#32833: IceCat 60 showing sites as "insecure" despite using HTTPS
On Tue, Sep 25, 2018 at 20:16:16 -0400, Mark H Weaver wrote: > Mark H Weaver writes: >> To begin, I'm currently building IceCat using the bundled NSPR and NSS, >> to see if that helps. > > Using the bundled NSPR and NSS works around the problem for me. I just > pushed this change in commit 6d328879378fac9524000521f596fb5c68ed on > 'master'. See also the related, immediately preceding commits > 257e3247910610fe24ae1b86f38e85552d53e48c and > 94e96f7f68c3b9053fdb5dee5b0ab614163aaa08. Great! > I'm keeping this bug report open, since it would be good to find a > better fix which avoids using the bundled libraries. I wish I knew enough to suggest a better solution. It's a little late now, but I just tested the IceCat binary on a Debian machine and HTTPS works as expected. Thanks again for your work on this. Maybe I'll let IceCat build overnight so I can give it a try tomorrow (still on my X200). -- Mike Gerwitz signature.asc Description: PGP signature
bug#32820: Some CSS not displaying in latest Icecat
On Tue, Sep 25, 2018 at 20:22:12 -0400, Mark H Weaver wrote: > I just pushed some changes to our IceCat package which I didn't expect > to affect this issue, namely: > > * 6d3288793..: Mark H Weaver 2018-09-25 gnu: icecat: Rebundle NSPR and NSS > [security fix]. > * 94e96f7f6..: Mark H Weaver 2018-09-24 gnu: icecat: Unbundle libevent, > libogg, and libvorbis. > * 257e32479..: Mark H Weaver 2018-09-23 gnu: icecat: Unbundle graphite2 and > harfbuzz. > > However, as of commit 6d328879378fac9524000521f596fb5c68ed on the > master branch, I can no longer reproduce this problem. The two pages > above are both properly styled for me now. > > When you get a chance, can you try the new version and report back? I also verified that those pages render correctly using IceCat's alpha binary on a Debian system. I'll build overnight and let you know tomorrow if the CSS issues are resolved for me. Thanks for the quick response on this! -- Mike Gerwitz signature.asc Description: PGP signature
bug#32833: IceCat 60 showing sites as "insecure" despite using HTTPS
On Tue, Sep 25, 2018 at 20:30:57 -0400, Mike Gerwitz wrote: > Thanks again for your work on this. Maybe I'll let IceCat build > overnight so I can give it a try tomorrow (still on my X200). LGTM. -- Mike Gerwitz signature.asc Description: PGP signature
bug#32820: Some CSS not displaying in latest Icecat
>> When you get a chance, can you try the new version and report back? > > I also verified that those pages render correctly using IceCat's alpha > binary on a Debian system. I'll build overnight and let you know > tomorrow if the CSS issues are resolved for me. LGTM! -- Mike Gerwitz signature.asc Description: PGP signature
bug#32820: Some CSS not displaying in latest Icecat
On Mon, Sep 24, 2018 at 23:05:17 +0200, Ricardo Wurmus wrote: > Open the developer console and switch to the Style Editor tab. On > github.com you’ll see a bunch of CSS files with a note under each saying > “0 rules”. To the right you see the CSS sources. Now add a space > character (or make some other edit in the source pane): all of a sudden > the CSS file can be parsed! > > When you do this to each file, Icecat is going to render the page just > fine. That's an interesting find! Fortunately, since Mark's changes, I haven't experienced any further issues. But it's bizarre indeed. > I also note that Icecat tells me that the page is not encrypted, despite > visiting the https site without errors. Something’s not quite right > here. Mark fixed this in 32833 (<87a7o5cdv3@netris.org>). -- Mike Gerwitz signature.asc Description: PGP signature
bug#43610: IceCat segfault
On Sat, Sep 26, 2020 at 14:05:53 -0400, Mark H Weaver wrote: > I'm particularly sensitive to the memory requirements at build time, > because I choose not to trust the build farm and therefore to build my > entire Guix system with GNOME from source code on a relatively old > Thinkpad X200 with only 4 GB of RAM. I've been doing this for many > years, and I'd like to enable other Guix users to do so if they wish. As someone with the same system as you, I have appreciated this for as long as I've used Guix. Thank you. > My impression is that IceCat debug outputs would primarily useful to > people who are actively developing IceCat, in which case it makes more > sense to build it manually to allow incremental rebuilds after modifying > the source code. I agree---I think it's best not to burden all users (that choose to or have to build) in this case. -- Mike Gerwitz
bug#34176: X200 kernel panic on S3 resume (linux-libre > 4.18.9)
Hello, Guix: I've been sitting on this one for a little while since I didn't have time to try debugging it. Sometime after 2018-09-25 (linux-libre 4.18.9), my X200 locks up after resuming from S3 (suspend to memory). The system is unresponsive, but Alt+Sysreq+B is recognized and reboots the system. Unfortunately, I don't know when this happened---my next upgrade on this box was 2018-12-01, kernel version 4.19.5. I produced a minimal system configuration where I stripped out all but base services (attached below) and the problem still occurs. After wasting a bunch of time on that, I finally added the `no_console_suspend' boot param and, sure enough, I get a kernel panic. It does not write the log to disk, so I'm reproducing it here in part manually: --8<---cut here---start->8--- ACPI: Waking up from system sleep state S3 ACPI: EC: Interrupt unblocked ACPI: EC: event unblocked usb usb3: root hub lost power or was reset general protection fault: [#1] SMP PTI CPU: 1 PID: 441 Comm: kworker/u4:23 Tainted: 6 4.28-3gnu #1 Hardware name: LENOVO 7459VLP/7459VLP, BIOS CBET4000 3774c98 09/07/2016 Workqueue: events_unbound async_run_entry_fn RIP: 0010:uhci_scan_schedule.part.38+0xa3/0xad0 Code: [...machine code...] [...register values...] Call trace: [I'm omitting address offsets] ? __dev_printk uhci_hub_status_data usb_hcd_poll_rh_status uhci_pci_resume resume_common hcd_pci_resume pci_pm_resume [...ata stuff, successful...] uhci_hcd :00:1d.0: host controller process error, something bad happened! uhci_hcd :00:1d.0: host controller halted, very bad! uhci_hcd :00:1d.0: HC died; cleaning up --8<---cut here---end--->8--- I found this: https://01.org/linuxgraphics/gfx-docs/drm/driver-api/usb/persist.html But it states for `persist': For hubs the feature is automatically and permanently enabled and the power/persist file doesn’t even exist, so you only have to worry about setting it for devices where it really matters. (Which is indeed true for my hub :00:1d.0, which is usb6, according to dmesg.) If someone with more experience with these types of issues offer me some advice on my next steps (including the best place to report upstream either for linux-libre or linux, if that's more appropriate), I'd appreciate 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
bug#34176: X200 kernel panic on S3 resume (linux-libre > 4.18.9)
Well, I'm not getting those hours of my life back. On Wed, Jan 23, 2019 at 00:58:57 -0500, Mike Gerwitz wrote: > usb usb3: root hub lost power or was reset [...] > uhci_hcd :00:1d.0: host controller process error, something bad happened! > uhci_hcd :00:1d.0: host controller halted, very bad! > uhci_hcd :00:1d.0: HC died; cleaning up [...] > (Which is indeed true for my hub :00:1d.0, which is usb6, according > to dmesg.) Right after sending this message, I recalled that I used powertop to do "auto tuning". Sure enough, one of the lines was this: Good Autosuspend for USB device UHCI Host Controller [usb6] By disabling it, it runs this command: echo on > /sys/bus/usb/devices/usb6/power/control And it resolves my suspend issues on 4.20.3-gnu. What sucks even more is that I had disabled those settings on the USB controllers over a year ago (because it was putting my USB keyboard to sleep, dropping the first keypress); don't know how it got re-enabled, but the user is probably to blame. Sorry for the noise, everyone. I hope that my suffering provides some value to others. This bug can be closed. -- 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
bug#34176: X200 kernel panic on S3 resume (linux-libre > 4.18.9)
On Wed, Jan 23, 2019 at 01:08:39 -0500, Mike Gerwitz wrote: > Right after sending this message, I recalled that I used powertop to do > "auto tuning". Sure enough, one of the lines was this: > >Good Autosuspend for USB device UHCI Host Controller [usb6] > > By disabling it, it runs this command: > > echo on > /sys/bus/usb/devices/usb6/power/control > > And it resolves my suspend issues on 4.20.3-gnu. [...] > This bug can be closed. Sorry, I take that back. I could have sworn it did resolve the issue, but that does not seem to be the case. This seems unrelated to powertop; `auto' seems to be the default setting of /sys/bus/usb/devices/*/power/control, which is reset on reboot. In any case, setting it to `on' does not solve my suspend issue. It's not a hardware issue, because earlier kernel versions work just fine. I tried debugging this further, but even on a minimal Guix system, I cannot seem to work around the problem. Any advice, anyone? -- Mike Gerwitz signature.asc Description: PGP signature
bug#34176: X200 kernel panic on S3 resume (linux-libre > 4.18.9)
reopen 34176 thanks On Sun, Jan 27, 2019 at 10:34:11 -0500, Mike Gerwitz wrote: > Sorry, I take that back. I could have sworn it did resolve the issue, > but that does not seem to be the case. > > This seems unrelated to powertop; `auto' seems to be the default setting > of /sys/bus/usb/devices/*/power/control, which is reset on reboot. In > any case, setting it to `on' does not solve my suspend issue. Okay, the value of `control' makes no difference. I just accidentally closed my laptop on 4.20.3-gnu and it resumed. I'm _not_ on a minimal system---I have all my usual services running. I have to go to work shortly, so I'll play around with it a little more later tonight and see if e.g. plugging in my Nitrokey (actually using the USB hub) had an effect. With that said, I use my Nitrokey every day (but I did _not_ use it most of the times I was trying to debug this issue) and I thought I've had suspend issues with it before. I guess we'll see. -- Mike Gerwitz signature.asc Description: PGP signature
bug#34176: X200 kernel panic on S3 resume (linux-libre > 4.18.9)
On Tue, Jan 29, 2019 at 07:14:15 -0500, Mike Gerwitz wrote: > reopen 34176 > thanks I guess I don't have permission to do this, since nothing happened. Can someone do this for me? Alternatively, if this seems outside the scope of something we'd want to track in Guix, just leave it closed. > On Sun, Jan 27, 2019 at 10:34:11 -0500, Mike Gerwitz wrote: > I have to go to work shortly, so I'll play around with it a little more > later tonight and see if e.g. plugging in my Nitrokey (actually using > the USB hub) had an effect. With that said, I use my Nitrokey every day > (but I did _not_ use it most of the times I was trying to debug this > issue) and I thought I've had suspend issues with it before. I guess > we'll see. I was not able to figure it out with the time I had available to spend on this the past couple of nights. It's once again locking up when resuming, and I cannot get it to resume correctly. -- Mike Gerwitz signature.asc Description: PGP signature
bug#34176: X200 kernel panic on S3 resume (linux-libre > 4.18.9)
On Thu, Jan 31, 2019 at 02:02:34 -0500, Mark H Weaver wrote: > reopen 34176 > thanks > > Hi Mike, > > Mike Gerwitz writes: > >> On Tue, Jan 29, 2019 at 07:14:15 -0500, Mike Gerwitz wrote: >>> reopen 34176 >>> thanks >> >> I guess I don't have permission to do this, since nothing happened. Can >> someone do this for me? > > No permission is needed, but it must be sent to the correct address. It > must be sent to . I add that address to the > BCC header when including such commands. Ah, that explains it. I saw cont...@debbugs.gnu.org in the debbugs documentation, but looking at past commands on this list (e.g. from you), I didn't see it CC'd, so I thought maybe it wasn't necessary. >> Alternatively, if this seems outside the scope of something we'd want to >> track in Guix, just leave it closed. > > I'm glad to have it in our tracker. Thanks. Hopefully it won't persist for too long. > FWIW, unless someone has a better idea, my recommendation would be to do > a binary search on the kernel versions, to find which version introduced > the problem. That's what I was going to do originally, except I hadn't had the time to research the best way of doing this in Guix. I did see a kernel system configuration option, but I thought that looked more like specifying Linux or Hurd (the default value is `LINUX-LIBRE'), not the specific kernel version. What's the proper way to go about doing this on GuixSD? Sorry if that's clearly documented and I just missed it. > If 4.18.20 works and 4.19 fails, then it will probably be necessary to > do a "git bisect" on the upstream kernel git repository between those > two versions, to find the commit that introduced the problem. If it > comes to this, let me know and I'll help you find a way to do this > efficiently. This is another situation where my unfamiliarity with Guix is the difficult part. I'm comfortable compiling Linux, but I'd need to figure out how to actually boot to it. -- Mike Gerwitz signature.asc Description: PGP signature
bug#34176: X200 kernel panic on S3 resume (linux-libre > 4.18.9)
On Wed, Jan 23, 2019 at 00:58:57 -0500, Mike Gerwitz wrote: > usb usb3: root hub lost power or was reset > general protection fault: [#1] SMP PTI > CPU: 1 PID: 441 Comm: kworker/u4:23 Tainted: 6 4.28-3gnu #1 > Hardware name: LENOVO 7459VLP/7459VLP, BIOS CBET4000 3774c98 09/07/2016 > Workqueue: events_unbound async_run_entry_fn > RIP: 0010:uhci_scan_schedule.part.38+0xa3/0xad0 > Code: [...machine code...] > [...register values...] > Call trace: [I'm omitting address offsets] > ? __dev_printk > uhci_hub_status_data > usb_hcd_poll_rh_status > uhci_pci_resume > resume_common > hcd_pci_resume > pci_pm_resume > [...ata stuff, successful...] > uhci_hcd :00:1d.0: host controller process error, something bad happened! > uhci_hcd :00:1d.0: host controller halted, very bad! > uhci_hcd :00:1d.0: HC died; cleaning up In 5.x this doesn't appear to be a problem anymore---the first message still happens, but it no longer causes a panic. I don't know precisely when it was fixed, since it's been a little while since I've upgraded. I haven't had the chance [yet] to look at the linux sources to see any technical details. I'm going to give it a week or so, and if the problem has indeed been resolved, I'll close this. -- Mike Gerwitz signature.asc Description: PGP signature
bug#34176: X200 kernel panic on S3 resume (linux-libre > 4.18.9)
close 34176 thanks This is no longer a problem on my X200 with Libreboot. On Sun, May 12, 2019 at 10:16:12 -0400, Mike Gerwitz wrote: > In 5.x this doesn't appear to be a problem anymore---the first message > still happens, but it no longer causes a panic. I don't know precisely > when it was fixed, since it's been a little while since I've > upgraded. I haven't had the chance [yet] to look at the linux sources > to see any technical details. > > I'm going to give it a week or so, and if the problem has indeed been > resolved, I'll close this. -- 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
bug#36687: guix gc: error: executing SQLite statement: database disk image is malformed
Sorry I hadn't seen this bug report; it was opened after I researched this issue a couple months ago and I didn't bother checking since. Here's the thread I posted to help-guix: <87lfwbuj27....@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
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
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
