Re: the upcoming Great Python2 Purge™
Leo Famulari writes: > On Wed, Dec 26, 2018 at 11:38:12AM +0200, Efraim Flashner wrote: >> We're now about a year out from the official EOL for python2 (Jan 1, >> 2020). So far we've been not adding python2 variants of packages that >> are new unless they're actually needed for something. Do we want to >> start removing python2 packages when updating other packages if they are >> leaf packages? > > This was previously discussed here: > > https://lists.gnu.org/archive/html/guix-devel/2018-06/msg00237.html > > That discussion didn't go very far. As you mentioned, the consensus > seemed to be that we 1) relax the policy of always providing both Python > 2 and 3 packages and 2) we'll act when we need to. > > My opinion is that we should remove Python 2 packages after the upstream > EOL announcement if they are causing trouble somehow. > > But I don't think we need to remove them en masse. We offer many other > packages that are basically abandoned upstream, so I think it will be > okay to keep the Python 2 packages as long as there are no bugs or if > they are maintained somehow. I think we could also just move them to a different Guix channel entirely as a sort of legacy-support option. I am almost positive somebody among us would be willing to maintain them. Could be better than everybody wanting to maintain their own channel for it. Also, on a side note, how would this work for the python importers? Would we stop offering python2 substitutes on the build servers? There are some other questions here that I think aren't getting addressed. Brett Gilio
Re: add DEPRECATION grace period: the upcoming Great Python2 Purge™
Hello everyone! Leo Famulari writes: > On Wed, Dec 26, 2018 at 02:33:55PM +0100, Pjotr Prins wrote: >> A lot of software outside Guix still depends on Python2, for better or >> worse. I don't believe EOL means they are going to drop security >> updates. Leaf packages may well be in use today. > > I do think it means that the current Python team at python.org will stop > issuing security updates for Python 2. [0] > > Previously, Guido van Rossum said "The way I see the situation for 2.7 > is that EOL is January 1st, 2020, and there will be no updates, not even > source-only security patches, after that date. Support (from the core > devs, the PSF, and python.org) stops completely on that date." [1] > > Well, Guido is no longer involved with Python, so maybe the situation > has changed. In any case, I think we can expect third parties like Red > Hat to keep maintaining Python 2 for some years, and we can use their > work. > I suggest everyone to read these two LWN articles[0][1]. IMO, we should start deprecating all python 2 packages which are already available in python 3 and are not dependencies of python-2-only packages(*). Also, we should not create python 2 definition for new python packages anymore. Of course, we can make an exception if there's a demand for it. This way, we can start warning everybody that python 2 is going EOL and support is going to be dropped gradually. Right now, 'guix refresh -l python2' shows there're 1692 packages depending on python 2. For security updates, as Guido has mentioned python devs will no longer provide security updates after 1/1/2020, which others seemed to agree. You can read the whole thread here[2]. However, centos and debian will still be supporting python 2 past that date. Centos will support python 2 until 2024 and I suspect Debian will have to support it for even longer since their next stable release (Debian 10 on 2020) will include python 2. Cheers, Alex (*): Should we make a new construct that does it? Also, I think we should mention it in the guix blog, so others can learn about the deprecation. [0]: https://lwn.net/Articles/756628/ [1]: https://lwn.net/Articles/750833/ [2]: https://www.mail-archive.com/python-dev@python.org/msg100031.html >> Is there a way we mark packages as DEPRECATED? I think we should not >> just remove packages without a grace period. Deprecate for, say, 3 >> months or even 6 months is the way to do this. A deprecation tag >> should include a time stamp that gives the (planned) removal time. > > Not exactly, although there is a 'deprecated-package' procedure that > accepts a replacement package to supersede the deprecated package. It > doesn't do what you suggest. > > [0] Already, the status of Python 2 is 'bugfix'. If it reaches "end > of life", the bugfixing activity will presumably cease, although they do > describe another 'security' status that seems lesser than 'bugfix': > https://devguide.python.org/#status-of-python-branches > > [1] > https://mail.python.org/pipermail/python-dev/2018-March/152348.html signature.asc Description: PGP signature
Re: Better names for Guix versions from git?
I like dates in "rolling release" version strings because they immediately tell you how old/new the version is, but I can certainly live with that format too. Definitely better than what we have. - Taylan On Wed, Dec 26, 2018 at 3:02 PM Marius Bakke wrote: > > swedebugia writes: > > > On 2018-12-25 20:49, Taylan Kammer wrote: > >> Currently, after running 'guix pull', the Guix version will be reported > >> by 'guix --version' as something like: > >> > >> 522d1b87bc88dd459ade51b1ee0545937da8d3b5 > >> > >> I think it would be really nice if instead it were something like: > >> > >> 2018-12-25-522d1b > >> > >> where the date is the commit's date (year, month, day) in UTC+0. > >> > >> That's shorter, more descriptive, and just as unique. (The chances of > >> there being two commits in the same day with the same first 6 positions > >> in the hash should be negligient.) > >> > >> The package name is currently something like: > >> > >> guix-522d1b87b > >> > >> That could become: > >> > >> guix-2018-12-25-522d1b > >> > >> which is a bit longer but more descriptive. > >> > >> I looked into guix/self.scm a bit but couldn't easily tell how difficult > >> it would be to implement these changes. > >> > >> Thoughts? Worth it? > > > > I think it is worth it, in fact I was on my way to suggest the same. > > I like the "git describe" format: > > $ git describe > v0.16.0-414-ge99d036828 > > It does not mention a date, but it can be copy-pasted into "git" and > shows how many commits there were between each generation.
Missing fonts issue with GNU Icecat
Hi guix, I have a profile with icecat, fontconfig and basic fonts, but the browser seems not to find any font. It displays only numbers-in-squares placeholders. ``` $ icecat (/gnu/store/x9c8vysvvivx4bc1xa4gz7sl37y3i2k6-icecat-60.3.0-gnu1/lib/icecat/.icecat-real:3240): Pango-WARNING **: 10:16:13.107: failed to create cairo scaled font, expect ugly output. the offending font is 'DejaVu Sans 9.9990234375' (/gnu/store/x9c8vysvvivx4bc1xa4gz7sl37y3i2k6-icecat-60.3.0-gnu1/lib/icecat/.icecat-real:3240): Pango-WARNING **: 10:16:13.107: font_face status is: file not found (/gnu/store/x9c8vysvvivx4bc1xa4gz7sl37y3i2k6-icecat-60.3.0-gnu1/lib/icecat/.icecat-real:3240): Pango-WARNING **: 10:16:13.108: scaled_font status is: file not found (/gnu/store/x9c8vysvvivx4bc1xa4gz7sl37y3i2k6-icecat-60.3.0-gnu1/lib/icecat/.icecat-real:3240): Pango-WARNING **: 10:16:13.108: shaping failure, expect ugly output. shape-engine='PangoFcShapeEngine', font='DejaVu Sans 9.9990234375', text='●' (/gnu/store/x9c8vysvvivx4bc1xa4gz7sl37y3i2k6-icecat-60.3.0-gnu1/lib/icecat/.icecat-real:3240): Pango-WARNING **: 10:16:13.113: failed to create cairo scaled font, expect ugly output. the offending font is 'DejaVu Sans 9.9990234375' (/gnu/store/x9c8vysvvivx4bc1xa4gz7sl37y3i2k6-icecat-60.3.0-gnu1/lib/icecat/.icecat-real:3240): Pango-WARNING **: 10:16:13.114: font_face status is: file not found (/gnu/store/x9c8vysvvivx4bc1xa4gz7sl37y3i2k6-icecat-60.3.0-gnu1/lib/icecat/.icecat-real:3240): Pango-WARNING **: 10:16:13.114: scaled_font status is: file not found (/gnu/store/x9c8vysvvivx4bc1xa4gz7sl37y3i2k6-icecat-60.3.0-gnu1/lib/icecat/.icecat-real:3240): Gtk-WARNING **: 10:16:14.576: Could not load a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg. This may indicate that pixbuf loaders or the mime database could not be found. ``` Utilities from fontconfig (in the same profile) seem to work fine: ``` $ fc-match 'DejaVu Sans 9.9990234375' DejaVuSans.ttf: "DejaVu Sans" "Book" $ fc-list | grep DejaVuSans.ttf ~/.guix-profile/share/fonts/truetype/DejaVuSans.ttf ``` Any idea? How can I test if the issue is with pango or icecat or somewhere else? The "host" distro is Alpine. Best, --- Daniel Gerber
Re: Missing fonts issue with GNU Icecat
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"
```
(Besides, the web site gives other mailing lists (not in the info
manual)... maybe help-guix is better suited for this kind of
issues.)
Re: Trustworthiness of build farms (was Re: CDN performance)
Hi Jeremiah, jerem...@pdp10.guru writes: >> To truly solve that problem, we need bug-free compilers. > Impossible for all but the simplest of languages as the complexity of > implementing a compiler/assembler/interpreter is ln(c)+a but the > complexity of implementing a bug-free compiler/assembler/interpreter > is (e^(c))! - a. Where a is the complexity cost of supporting it's > host architecture. Where are you getting those complexity expressions from? Can you cite references to back them up? If not, can you explain how you arrived at them? What is 'c'? >> In practice, this requires provably correct compilers. > Which in practice turn out *NOT* to be bug free nor complete in regards > to the standard specification. If you're referring to the bugs found in CompCert, the ones I know about were actually bugs in the unverified parts of the toolchain. In the past, its frontend was unverified, and several bugs were found there. Even today, it produces assembly code, and depends on an unverified assembler and linker. Bugs can also exist in the specifications themselves, of course. However, in the areas covered by the proofs, the results are quite dramatic. For example, in the paper "Finding and Understanding Bugs in C Compilers" by Xuejun Yang, Yang Chen, Eric Eide, and John Regehr, https://web.stanford.edu/class/cs343/resources/finding-bugs-compilers.pdf the authors state on page 6: The striking thing about our CompCert results is that the middle- end bugs we found in all other compilers are absent. As of early 2011, the under-development version of CompCert is the only compiler we have tested for which Csmith cannot find wrong-code errors. This is not for lack of trying: we have devoted about six CPU-years to the task. The apparent unbreakability of CompCert supports a strong argument that developing compiler optimizations within a proof framework, where safety checks are explicit and machine-checked, has tangible benefits for compiler users > Now, don't get me wrong; provably correct > compilers are a correct step in the right direction but the real > solution is to first generate simplified languages that don't have > undefined behavior and human model first behavior. I'm not sure what "and human model first behavior" means, but if you mean that the semantics of languages should strive to match what a human would naturally expect, avoiding surprising or unintuitive behavior, I certainly agree. I consider Standard ML, and some subsets of Scheme and Lisp, to be such languages. >> Does that make sense? > Absolutely, certainly something possible to do; but extremely human > effort intensive and I don't see anyone willing to throw 2+ years of > human effort at the problem outside of non-free Businesses like > CompCert. If I understand correctly, what you don't expect to happen has already been done. CakeML is free software, and formally proven correct all the way down to the machine code. Moreover, it implements a language with an exceptionally clear semantics and no undefined behavior. Anyway, you've made it fairly clear that you're not interested in this line of work, and that's fine. I appreciate the work you're doing nonetheless. Regards, Mark
