bug#23311: TLS handshake error
Sometimes, TLS handshakes fail in strange ways (the following happens after a dozen of iterations; I’ve enabled GnuTLS debugging in (guix build download) here): --8<---cut here---start->8--- $ while ./pre-inst-env guix download https://mirror.hydra.gnu.org/index.html ; do : ; done [...] Starting download of /tmp/guix-file.4axVhT >From https://mirror.hydra.gnu.org/index.html... gnutls: [2565|3] ASSERT: gnutls_constate.c:588 gnutls: [2565|5] REC[0x1d98bd0]: Allocating epoch #1 gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_GCM_SHA384 (C0.2C) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_128_GCM_SHA256 (C0.86) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_256_GCM_SHA384 (C0.87) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA1 (C0.09) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA256 (C0.23) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA1 (C0.0A) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA384 (C0.24) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_128_CBC_SHA256 (C0.72) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_256_CBC_SHA384 (C0.73) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_CCM (C0.AC) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_CCM (C0.AD) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_3DES_EDE_CBC_SHA1 (C0.08) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_256_GCM_SHA384 (C0.30) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.8A) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.8B) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_128_CBC_SHA1 (C0.13) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_128_CBC_SHA256 (C0.27) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_256_CBC_SHA1 (C0.14) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_256_CBC_SHA384 (C0.28) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_128_CBC_SHA256 (C0.76) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_256_CBC_SHA384 (C0.77) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_AES_128_GCM_SHA256 (00.9C) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_AES_256_GCM_SHA384 (00.9D) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_GCM_SHA256 (C0.7A) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_GCM_SHA384 (C0.7B) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_AES_128_CBC_SHA1 (00.2F) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_AES_128_CBC_SHA256 (00.3C) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_AES_256_CBC_SHA1 (00.35) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_AES_256_CBC_SHA256 (00.3D) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_CBC_SHA1 (00.41) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_CBC_SHA256 (00.BA) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_CBC_SHA1 (00.84) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_CBC_SHA256 (00.C0) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_AES_128_CCM (C0.9C) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_AES_256_CCM (C0.9D) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_RSA_3DES_EDE_CBC_SHA1 (00.0A) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_GCM_SHA256 (00.9E) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_256_GCM_SHA384 (00.9F) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.7C) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.7D) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_CBC_SHA1 (00.33) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_CBC_SHA256 (00.67) gnutls: [2565|4] HSK[0x1d98bd0]: Keeping ciphersuite: GNUTLS_DHE_RSA
bug#23304: import pypi: Option o keep the downloaded file
Am 18.04.2016 um 14:15 schrieb Ben Woodcroft: > Are you suggesting something apart from what 'build --source' does e.g. Some kind of :-) 1) From a usability point of view, this should be part of "guix import" since this is what the user does and where she is looking for help. 2) "guix build --source" returns a derivation, whereas "guix import" ought to return the original, unchanged source. (One could argue that on "import", the derivation is the unchanged source depending on nothing) 3) Of course one could use the output of "guix import", pass it to "guix build --source" and get the original source. But a) this would download the source twice b) would intermix phases: the package definition is in early draft, but "build" should return the source. This does not match. 4) In any case, "guix import" should display the name of the downloaded archive. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change
Alex Kost writes:
> myglc2 (2016-02-08 21:29 +0300) wrote:
>
>> Alex Kost writes:
>>
>>> myglc2 (2016-02-07 21:04 +0300) wrote:
>>>
From guix INFO:
6.2 Invoking ‘guix edit’
[...]
launches the program specified in the ‘VISUAL’ or in the ‘EDITOR’
environment variable to edit the recipe of GCC 4.8.4 and that of Vim."
TYPO:
"edit" (last line above) should be replaced with "view", "inspect", or
"examine".
>>>
>>> Just to mention - I like "edit" name :-)
>
> I changed my mind, I don't like it anymore :-(
Good to hear.
RENAME:
Calling these functions 'guix edit' and 'M-x guix-edit' implies that the
user will be able to modify the recipe, but this is not actually the
case. The functions should be given a more informative and accurate
name, such as: 'guix view', 'guix inspect', or 'guix examine'.
>>>
>>> Along with the package recipes that come with Guix, a user can also have
>>> his/her own packages (specified using GUIX_PACKAGE_PATH env var), and
>>> "guix edit my-super-package" opens a user's file with this package. It
>>> is highly likely that this file is editable, so "guix edit" is a perfect
>>> name in this case I think. IMO it's a user responsibility to understand
>>> what files can be edited and what cannot.
>>
>> Sorry this is so long, but I think this is a useability issue that is
>> worth discussing more.
>>
>> I understand your point-of-view, but I think it is much more
>> packager-centric than you should plan on your ultimate user base being.
>>
>> If we think about the mix of guix users when it is more widely
>> successful, as I strongly believe it will be, a majority (80-90%) will
>> be "simply" managing and configuring their computer and/or user
>> account. They will NOT make packages.
>>
>> If this is the case, the majority of people clicking on "guix edit" will
>> not understand "what files can be edited and what cannot." The very idea
>> that a recipe on their computer can make something they need will be a
>> radical leap. For these people, taking the fist look at a guix recipe
>> will be a step deeper into guix.
>>
>> Such a user's first interaction might run along the lines of mine ...
>>
>> - Hmm, I want to see an actual recipe.
>>
>> - Oh wow, it says I can edit a recipe right here!
>>
>> - Hmm, maybe I shouldn't because I don't want to break something.
>>
>> - But they wouldn't call it "guix edit" if it wasn't OK to change stuff,
>> right?
>>
>> - OK, I'll give it a shot. I'll look at something I am familiar with ...
>>
>> - 'guix edit screen'
>>
>> - WOW look at that. Finds the recipe, opens an editor, COOL!
> [...]
>
> Now I agree with this. There was another person¹ who was confused by
> "edit" name, and I think there will be more. OTOH if it will be renamed
> to anything else, I'm afraid some people will still think they can just
> modify the package definition in place. But "guix edit" is…, well, not
> the best name we can have.
>
> Moreover, I think there are inconsistencies in guix commands. For
> example, we have "guix system build" to build a system, but "guix build"
> to build a package. IMO "guix package build" would be a better choice.
>
> In general, I think it would be good to move package commands inside
> "guix package" (which is probably a different direction to Andy's
> suggestion²), e.g, to make "guix package lint", "guix package size",
> etc.
For overall Guix usability, the overloading of a single guix command for
everything is not so good. When you eventually create a man page, it
will be intimidating for someone just trying to do per-user package
management, which the majority of, and least sophisticated users, will
be trying to do.
On the other hand there are several "classes" of commands and this is
reflected by the guix CLI being described in several logically different
parts of the doc, but not, as you point out, by being differentiated in
the CLI.
A possibly better approach would be to explicitly split the guix
command-verse into command classes to better match the structure of the
doc. For example, per-user ('guix ...'), global-system ('guix-sys ...'),
and developer ('guix-dev ...'), or something similar.
Since the most frequently used commands will be per-user package
management, I think you should replace 'guix package' with 'guix' and
promote the non-package commands to be hyphenated (ALA, guix-daemon).
This would, in turn, give rise to emacs functions something like:
OLDNEW
---
user:
guix-edit guix-view-definition
guix-installed-packagesguix-installed-packages
guix-installed-user-packages NA
admin:
guix-installed-system-packages guix-sys-installed-packages
developer:
guix-hydra-build-list-latest-builds guix-dev-hydra-build-list-latest-builds
guix-edit guix-dev-ed
bug#23217: xboing bugs
On Mon, Apr 18, 2016 at 04:45:11PM +0200, Ludovic Court??s wrote: > John Darrington skribis: > > > You have to run it with the -usedefcmap option. Then it works > > just fine. > > Can we improve on this or should we close the bug? > I see that debian has some quite extensive patches to Xboing, which seems to fix this issue and many others. Should we purloin them? J'
bug#20765: Compressed eggs (Python)
Hi,
I support the proposal for switching to pip.
Switching to pip should be save, since this is the proposed standard way
for installing - and thus it should be save in the long run, too.
I suggest calling pip with this options (valid as of pip 8.1.1)
--no-depsDon't install package dependencies.
--no-binary :all:Do not use binary packages.
--no-indexIgnore package index
--disable-pip-version-check
Since in the internet one can find issues with
--single-version-externally-managed I verified that pip will even work
for packages using distutils instead of setuptools. I did a test and
inspecting the software.
Here is what I did: I used a simply Python package which imports
distutils instead of setuptools. Installing the via pip in verbose-mode
shows this line (you do not need to look at the details):
Running command /tmp/myvenv/bin/python2.7 -u -c "import setuptools,
tokenize;__file__='/tmp/pip-Biwi3y-build/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__,
'exec'))" install --record /tmp/pip-KcE_9O-record/install-record.txt
--single-version-externally-managed --compile --install-headers
/tmp/myvenv/include/site/python2.7/sample
This basically runs the setup.py “wrapped” into setuptools [1]. The
source code of setuptools reviled that it is monkey-pathing distutils
(esp. distutils.dist.Distribution) to objects from setuptools. So the
more elaborate stuff of setuptools is used even if the setup.py only
import distutils.
Additionally I checked what --single-version-externally-managed does
(since the documentation [2] is not that clear): it simply makes
`install` use the "original" distutils install command, which was/is not
able to create zipped eggs. So here we are on the save side, too.
Tested with pip 8.1.1 and setuptools 20.3, but this same code is in pip
6.0 and setuptools 18.0 already (which are older than what is in guix
0.10.0)
[1] Technically this line is executing a command which import setuptools
and then executes setup.py the it the same scope/context.
[2]
https://pythonhosted.org/setuptools/setuptools.html#install-run-easy-install-or-old-style-installation.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
bug#23165: Test suite failures building 0.10.0 on CentOS7
retitle 23165 Tests fail when 'HOME' is unset close 23165 thanks l...@gnu.org (Ludovic Courtès) skribis: > "Cook, Malcolm" skribis: [...] >> In guix/cve.scm: >> 76: 2 [call-with-cve-port # 518400 ...] >> In guix/http-client.scm: >> 300: 1 [http-fetch/cached # # 518400 ...] >> In unknown file: >>?: 0 [string-append #f "/http/" >> "Fjb931UJRoTPOjHq6hc1oawK9bCopdhOoX9grKLx71Q="] >> >> ERROR: In procedure string-append: >> ERROR: In procedure string-append: Wrong type (expecting string): #f' > > This is a harmless failure: it indicates that neither the HOME nor the > XDG_CACHE_HOME environment variables are defined in the build > environment. Commit dd1d09f7e4c522d2185eda9c806ea525e10172be should avoid this situation. Ludo’.
bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change
It seems to me that this bug has no clear purpose, or too broad a purpose, or something. Could you retitle it, or close it, or fix it, whichever is appropriate? :-) Ludo’.
bug#23217: xboing bugs
John Darrington skribis: > You have to run it with the -usedefcmap option. Then it works > just fine. Can we improve on this or should we close the bug? Ludo’.
bug#23307: VLC does not build deterministically
l...@gnu.org (Ludovic Courtès) skribis: > Commit 4ef2721b52c4929aac15db4f8b39702cd37955a1 fixed an obvious > timestamp-related reproducibility issue in VLC 2.2.1, but there remains > a problem with the ‘lib/vlc/plugins/plugins.dat’ whose contents differ > across rebuilds by a few 32-bit values (see attached diffoscope output.) > > The ‘plugins.dat’ file is generated by this rule in bin/Makefile.am: > > ../modules/plugins.dat: vlc-cache-gen$(EXEEXT) > $(AM_V_at)rm -f ../modules/plugins.dat > $(AM_V_GEN)if test "$(build)" = "$(host)"; then \ > ./vlc-cache-gen$(EXEEXT) ../modules ; \ > else \ > echo "Cross-compilation: cache generation skipped!" ; \ > fi Turned out to be simple: http://git.savannah.gnu.org/cgit/guix.git/commit/?id=cd76fbde6f70a6c0087f9330c266d51e334a0679 Ludo’.
bug#23307: VLC does not build deterministically
Commit 4ef2721b52c4929aac15db4f8b39702cd37955a1 fixed an obvious timestamp-related reproducibility issue in VLC 2.2.1, but there remains a problem with the ‘lib/vlc/plugins/plugins.dat’ whose contents differ across rebuilds by a few 32-bit values (see attached diffoscope output.) The ‘plugins.dat’ file is generated by this rule in bin/Makefile.am: --8<---cut here---start->8--- ../modules/plugins.dat: vlc-cache-gen$(EXEEXT) $(AM_V_at)rm -f ../modules/plugins.dat $(AM_V_GEN)if test "$(build)" = "$(host)"; then \ ./vlc-cache-gen$(EXEEXT) ../modules ; \ else \ echo "Cross-compilation: cache generation skipped!" ; \ fi --8<---cut here---end--->8--- Ludo’. t.html.gz Description: diffoscope output
bug#23256: vlc not building after update to ffmpeg 3.0
l...@gnu.org (Ludovic Courtès) skribis: > Efraim Flashner skribis: > >> I seems we have a number of programs that don't currently build with >> ffmpeg-3.0, so including 2.8.6 and using that version for the programs >> that need it is probably a good idea. > > Indeed. Could you add 2.8.6 alongside 3.0 for now, and have vlc and > other packages that broke depend on 2.8.6? Done in b4dff935500abc5aceb3fc0e13fb7cabb5f756c0. Ludo'.
bug#23306: 'guix environment --container' silently rejects invalid --expose parameters
Passing a nonexistent file as --expose leads ‘guix environment’ to silently fail: --8<---cut here---start->8--- $ guix environment --ad-hoc guile --expose=does-not-exist --container guix environment: warning: ambiguous package specification `guile' guix environment: warning: choosing guile-2.0.11 from gnu/packages/guile.scm:125:2 $ echo $? 1 --8<---cut here---end--->8--- It would be nice to print an error message. Ludo’.
bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change
myglc2 (2016-02-08 21:29 +0300) wrote: > Alex Kost writes: > >> myglc2 (2016-02-07 21:04 +0300) wrote: >> >>> From guix INFO: >>> >>> 6.2 Invoking ‘guix edit’ >>> [...] >>> launches the program specified in the ‘VISUAL’ or in the ‘EDITOR’ >>> environment variable to edit the recipe of GCC 4.8.4 and that of Vim." >>> >>> TYPO: >>> >>> "edit" (last line above) should be replaced with "view", "inspect", or >>> "examine". >> >> Just to mention - I like "edit" name :-) I changed my mind, I don't like it anymore :-( >>> RENAME: >>> >>> Calling these functions 'guix edit' and 'M-x guix-edit' implies that the >>> user will be able to modify the recipe, but this is not actually the >>> case. The functions should be given a more informative and accurate >>> name, such as: 'guix view', 'guix inspect', or 'guix examine'. >> >> Along with the package recipes that come with Guix, a user can also have >> his/her own packages (specified using GUIX_PACKAGE_PATH env var), and >> "guix edit my-super-package" opens a user's file with this package. It >> is highly likely that this file is editable, so "guix edit" is a perfect >> name in this case I think. IMO it's a user responsibility to understand >> what files can be edited and what cannot. > > Sorry this is so long, but I think this is a useability issue that is > worth discussing more. > > I understand your point-of-view, but I think it is much more > packager-centric than you should plan on your ultimate user base being. > > If we think about the mix of guix users when it is more widely > successful, as I strongly believe it will be, a majority (80-90%) will > be "simply" managing and configuring their computer and/or user > account. They will NOT make packages. > > If this is the case, the majority of people clicking on "guix edit" will > not understand "what files can be edited and what cannot." The very idea > that a recipe on their computer can make something they need will be a > radical leap. For these people, taking the fist look at a guix recipe > will be a step deeper into guix. > > Such a user's first interaction might run along the lines of mine ... > > - Hmm, I want to see an actual recipe. > > - Oh wow, it says I can edit a recipe right here! > > - Hmm, maybe I shouldn't because I don't want to break something. > > - But they wouldn't call it "guix edit" if it wasn't OK to change stuff, > right? > > - OK, I'll give it a shot. I'll look at something I am familiar with ... > > - 'guix edit screen' > > - WOW look at that. Finds the recipe, opens an editor, COOL! [...] Now I agree with this. There was another person¹ who was confused by "edit" name, and I think there will be more. OTOH if it will be renamed to anything else, I'm afraid some people will still think they can just modify the package definition in place. But "guix edit" is…, well, not the best name we can have. Moreover, I think there are inconsistencies in guix commands. For example, we have "guix system build" to build a system, but "guix build" to build a package. IMO "guix package build" would be a better choice. In general, I think it would be good to move package commands inside "guix package" (which is probably a different direction to Andy's suggestion²), e.g, to make "guix package lint", "guix package size", etc. So, returning to "guix edit". I think any of: "view", "recipe", "definition" are better. I would prefer "guix package definition", not just "guix definition", as in future there may appear a way to "edit" other things. For example, I've sent a patchset³ to go to license definitions in Emacs. So analogously we could have "guix license definition" (along with "guix license list" and similar). I realize that making subcommands for "guix package" and removing "guix graph", "guix lint" and other is radical, but I think it is the right way to organize package commands. ¹ https://gnunet.org/bot/log/guix/2016-03-07#T948796 ² http://lists.gnu.org/archive/html/guix-devel/2015-08/msg00044.html ³ http://lists.gnu.org/archive/html/guix-devel/2016-04/msg00721.html -- Alex
