Difference between search-paths and native-search-path
Hi, what is the difference between search-paths and native-search-path? The manual describes search-paths at [1], but native-search-paths are only named at [2] without any description. [1] https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html#index-search-paths-1 [2] https://www.gnu.org/software/guix/manual/html_node/package-Reference.html -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Re: QT install and search paths
Am 24.08.2017 um 13:59 schrieb 宋文武: > Currently, it doesn't follow a normal package layout, We should change > it to (like it in Debian and ArchLinux): I'd support this. What do you think about using "…/qt5" instead of just "…/qt", like Fedora does. IMHO this is not a bad idea. > Which need adjust the configure flags, search-patchs and the > qt_config.prf of our qtbase package (and maybe some kde ones, I don't > know). Can you take care of this? I can take care of kde-frameworks.scm. Maybe we can work on a different branch until we finished all packages. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
QT install and search paths
Hi,
I'm currently working on the build of KDE's plasma-desktop. When
strac-ing the tets, I dicoverd that plaugins are searched in
/gnu/store/…-qtbase-5.9.1/plugins/…
while most of the KDE program use
/gnu/store/…-plasma-workspace-5.10.4/lib/plugins/… (mind the
additional `lib`)
which is not searched. Wondering why, I found this in qt.scm (qtbase):
(search-path-specification
(variable "QT_PLUGIN_PATH")
(files '("plugins")))
This means that `lib/plugins` is *not* included in QT_PLUGIN_PATH and
thus not searched. (Which I assume is the reason for many test-failures.)
Also in qt.scm (qtbase) there is:
(substitute* qt_config.prf
…
(("\\$\\$\\[QT_INSTALL_PLUGINS\\]")
"$$replace(dir, mkspecs/modules, plugins)")
I assume this should make the plugins to be in stalled in …/plugins, but
KDE framework is installing into …/lib/plugins.
So I assume this is wrong or there are other places which need to be
adpoted to the changed directory layout.
What do you think?
All of the written above is true for the `qml` directory.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
0xBF773B65.asc
Description: application/pgp-keys
Re: How to add KDE desktop service?
Hi Danny, thanks a lot for this information. This should help me to get started. Completing will take quite some time, since … > > Hmmm not sure what exactly "components" means. Are those dbus services? … this is what I don't know. KDE plasma seems to be huge and I need to figure out what exactly is needed. I peek at other distributions implementations to find out what is needed and currently not even all packages are available in guix. (I worked on quite some of them, bit this is yet unfinished.) If the packages are available, I can try to get the desktop started. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
How to add KDE desktop service?
Hi, I thing it's time to (at least try to) add a KDE desktop service to guix. All major components should be available and if not this will show us what is missing. Now I wonder, how to do this. Taking gnome-desktop-service as a template, I can spot only "gnome-settings-daemon" as being different to xfce-desktop-service. So where do I tell the service which display-manager to use, or which components to install and start. Any hints? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
running icecat in container – inputs missing? (was: xcalc looks "incomplete" - dependencies missing?)
Hallo, since xcalc does not work well when running in a container (and in a stand-alone environment), I tried icecat, since this is what pjotr's great notes about containers [1] are using as an example. Now, the result is: icecat does not run in a container, too (it does run in an environment, though) I assume icecat or gtk is missing some inputs, which even may need to be propagated. Any hints? ./pre-inst-env guix environment --container --network --share=/tmp/.X11-unix --fallback --ad-hoc icecat export DISPLAY=:0.0 icecat failed with: ExceptionHandler::GenerateDump cloned child 46 ExceptionHandler::SendContinueSignalToChild sent continue signal to child ExceptionHandler::WaitForContinueSignal waiting for continue signal... (crashreporter:47): Gtk-WARNING **: Could not load a pixbuf from /org/gtk/libgtk/icons/16x16/status/image-missing.png. This may indicate that pixbuf loaders or the mime database could not be found. ** Gtk:ERROR:gtkiconhelper.c:493:ensure_surface_for_gicon: assertion failed: (destination) I tried adding shared-mime-info with no result. [1] https://github.com/pjotrp/guix-notes/blob/master/CONTAINERS.org -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/das-fass-ist-voll-grunde-linux-201asystemd2018-zu-meiden Kolumne: http://www.cissp-gefluester.de/2010-08-scheingefechte-um-rim
xcalc looks "incomplete" - dependencies missing?
Hello, thanks to pjotr's great notes about containers [1], I now know how to run a X-application in a guix container :-) Thanks pjotr! I tried this with xcalc and got a "incomplete" window, see screenshot (yes, is this tiny thing is the complete window). Now I'm wondering what the reason for this is. It looks like xcalc is missing some dependencies? Addendum: I found out that xcalc is behaving the same when running in a normal environment. Also please note that I'm running guix on top of some host OS. To reproduce: ./pre-inst-env guix environment --ad-hoc xcalc -- xcalc [1] https://github.com/pjotrp/guix-notes/blob/master/CONTAINERS.org -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Seeking PHP "Hello World" project (or other simple example)
Am 21.06.2017 um 01:41 schrieb Adonay Felipe Nogueira: > Perhaps you can make such contribution directly to the official PHP > project? :) Some PHP-guy should do. I give PHP a berth as wide as ever possible. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
… which cannot be found in RUNPATH
Hi guix! I have a package installing a lib as …/lib/plasma/libDiscoverCommon.so and a second lib as …/lib/other/lib.so. Building and linking works fine, but phase `validate-runpath' fails with: "…/other/lib.so depends on 'libDiscoverCommon.so', which cannot be found in RUNPATH". I checked the RUNPATH shown in this error-message and it includes the correct output of this package. But the RUNPATH only includes "…/lib", not "…/lib/plasma" – I don't know if this matters. It is one of the KDE packages, using the cmake-build-system, which did not show this kind of errors (for me). libDiscoverCommon.so was installed to the correct output of this package. I tried setting linker flags, as I've seen in other packages, but this did not help. How to solve this? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Unexpected behaviour of guix environment --container
Hi, I try debugging some package test-cases. The test-suite runs (but fails) when using "guix build". Now I want to get an environment matching the build container (including the already build package). For this I run e.g. ./pre-inst-env guix environment -C kdelibs4support@5.34.0 --ad-hoc strace within this container I run something like source ./environment-variables PATH=$GUIX_ENVIRONMENT/bin:$PATH ctest -R kstandarddirstest and am getting this error: /tmp/guix-build-kdelibs4support-5.34.0.drv-0/build/autotests/kstandarddirstest: error while loading shared libraries: libQt5Test.so.5: cannot open shared object file: No such file or directory What's going on here? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Building gpgme with Qt support?
Am 05.06.2017 um 15:21 schrieb Danny Milosavljevic: > a possible way would be: Thanks for pointing me to this road. Gladly it's been even simpler (see my patch [1]): - Run configure - Symlink two .la files - cd lang/qt - make So there was no need to add (and maintain) a configure.ac file. [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=27260 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Building gpgme with Qt support?
Am 04.06.2017 um 20:35 schrieb Leo Famulari: > Could we make a new package qt-gpgme that inherits from gpgme and provides a > QT-enabled gpgme?? How can this be done without duplicating the libraries? With an simple inherited package, all libraries will be compiled again and the Qt-bindings will point to the libraries within the "qt-gpgme" package. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Building gpgme with Qt support?
Hi, since version 1.7 gpgme [1] includes both the C++ bindings (former package: gpgmepp) and the Qt-Framework API (former package qgpgme, not in guix). Our gpgme package is currently build *without* support for Qt: checking for GPGME_QT... checking for GPGME_QTTEST... ./configure: line 18672: : command not found configure: WARNING: *** *** Qt5 (Qt5Core) not found Qt Binding will be disabled. *** The major draw-back of adding these bindings is that this would install qtcore (and all it's dependencies) for any application using gpgme. How can we avoid this? [1] https://mail.kde.org/pipermail/release-team/2016-September/009732.html [2] https://lists.gnupg.org/pipermail/gnupg-devel/2016-September/031647.html -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Re: Error when including openexr
Am 01.06.2017 um 13:06 schrieb Andreas Enge: > this looks a lot like a problem I had with the hugin package > (currently as a patch in the debbug tracker). I ended up doing > the following: > > +;; The header files of ilmbase (propagated by openexr) are not found > +;; when included by the header files of openexr, and an explicit > +;; flag needs to be set. > +(string-append "-DCMAKE_CXX_FLAGS=-I" > + (assoc-ref %build-inputs "ilmbase") > + "/include/OpenEXR") Thanks for this snippet. This did the trick! -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Error when including openexr
Am 01.06.2017 um 00:22 schrieb Danny Milosavljevic: > Is that gcc? Which version? It's an up to date guix system, nothing special. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Error when including openexr
Hi guix! I try building a package using openexr. Building fails with /gnu/store/…-openexr-2.2.0/include/OpenEXR/ImfInt64.h:44:24: fatal error: ImathInt64.h: No such file or directory but file …-openexr-2.2.0/include/OpenEXR/ImathInt64.h exists. I discovered that OpenEXR/ImfInt64.h contains #include "ImathInt64.h" #include "ImfNamespace.h" Maybe this should be "OpenEXR/ImathInt64.h" (same for the other)? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Re: Building AbiWord without libwmf and removing libwmf from Guix
Am 27.05.2017 um 23:13 schrieb Ricardo Wurmus: > I think it would be better to remove libwmf. +1 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Trouble with DHCP and GuixSD in a VM
Am 26.05.2017 um 09:03 schrieb Jan Nieuwenhuizen: >> I am able to ping both from my host machine. > Don't try to use ping (ICMP) to test the network. Use someting tcp/udp, > wget/ssh for example. This is only partly correct. ping *may* not be a sufficient network test, since many systems block ping-requests. But if he is able to ping both hosts from the host machine, ping is sufficient network test for within the guest, too. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
We need a different downloader for KDE
Hi,
can anybody more skilled than me please implement some HTTP(s) updater,
so we can "refresh" directly from downloads.kde.org. Please apologize,
if there already is one, I did not spot one.
Yesterday KDE released an security update, which was available at
downloads.kde.org at 05:38 GMT. When I tried updating the packages
("guix refresh") at about 18:30 GMT, the packages have not been found.
Reasons for this is: "guix refresh --type=kde" uses
ftp://mirror.mit.edu, which obviously is lagging. This may cost us
important time in case of an emergency update. Unfortunately KDE's main
site (downloads.kd.org) is only accessible via https, not via FTP.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Re: store reference detection (was Re: JARs and reference scanning)
Am 12.05.2017 um 23:51 schrieb Mark H Weaver: > What's the motivation for this proposal, if not to allow the scanner to > see references that would otherwise be obfuscated? The motivation is to have references at all. See <http://lists.gnu.org/archive/html/guix-devel/2017-04/msg00639.html> for an example of a package having propagated inputs which are not recognized as references by the gc. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Unprivileged /gnu/store with PRoot
Am 12.05.2017 um 17:53 schrieb Ludovic Courtès: > Pretty cool no? :-) Indeed. :-) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: store reference detection (was Re: JARs and reference scanning)
Am 12.05.2017 um 20:22 schrieb Mark H Weaver: > Might the compressed portions contain store references that > will fail to be grafted? Class files per se do not contain references to any JAR file AFAIK. For all other files (resources, etc.) its the same as for other programming languages -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: store reference detection (was Re: JARs and reference scanning)
Am 12.05.2017 um 19:39 schrieb Mark H Weaver: > It would not interfere, but it could have the effect of *hiding* > security problems due to a failure to graft properly. > [...] > If we create a redundant set of references in another file, then > problems like this could go undetected for a long time. Reading you comments (and words like "hidden"), I assume you are referring to some compressed or otherwise unreadable data. Please don't confuse this: We are *not* talking about compressed files, but about plain text (or stored uncomressed within e.g. a zip-file). -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Planning for the next release
Am 12.05.2017 um 07:45 schrieb Ricardo Wurmus: > > With UEFI (almost) ready, Guile 2.2 in the house, and “make release”, > > should we aim for next week (like Wed. 17th)? Can we focus on polishing > > the remaining bits and testing? > > > > If the schedule turns out to be too tight, we could move to the week > > after. KDE has a severe security error regarding KAuth and dbus [1]. I suggest updating he frameworks to 5.34, which is scheduled for tomorrow [2]. Alternatively we could try to integrate the patches mentioned at [1]. [1] https://www.kde.org/info/security/advisory-20170510-1.txt [2] https://www.kde-neon.de/kde-release-termine/?event_id1=27 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: store reference detection
Am 12.05.2017 um 10:19 schrieb Chris Marusich: > I'm not convinced we need these things (a list of > dependencies in ".guix-dependencies" or embedded classpaths in JAR > files), I'm convinced that we need such a beast, since references are not kept at all for quite some kind of packages. See <http://lists.gnu.org/archive/html/guix-devel/2017-04/msg00639.html> for an example with *not* working references. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | signature.asc Description: OpenPGP digital signature
Re: store reference detection (was Re: JARs and reference scanning)
Am 11.05.2017 um 10:41 schrieb Chris Marusich: > Based on this test, it looks like we can embed absolute paths in > uncompressed JAR files. Only the MANIFEST within the JAR file needs to be uncompressed, the remaining files can be compressed. JARs are zip files, which include data compressed individually, thus the above could be achieved. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Equivalent to lib32readline6-dev
Am 08.05.2017 um 18:15 schrieb Kei Kebreau: > Hartmut Goebel <h.goe...@crazy-compilers.com> writes: > >> Hi, >> >> for building LinageOS, the Debina/Ubuntu package lib32readline6-dev is >> required – which is the 32-bit version. How can I get this in guix? > My first guess would be using > > `guix build --system=i686-linux readline@6.2' > > to get a look at what you're working with. Ah, seems my question was not precise enough: How can I install the 32-bit *and* the 64-bit development files at once. So I can tell gcc/clang "now build for 32-bit". -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: potluck status
Hi, Am 28.04.2017 um 14:05 schrieb Andy Wingo: > 5.15 Invoking ‘guix potluck’ Please think about an other name for this command. "potlouk" may be common to native speakers but I never heard this word. Thanks. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: store reference detection (was Re: JARs and reference scanning)
Am 27.04.2017 um 15:46 schrieb Ludovic Courtès: > ‘propagated-inputs’ is one way to manually specify run-time references. > It works at the package level and not at the store level—that is, the > store item’s references are unaffected by what ‘propagated-inputs’ > contains. It’s usually enough for our purposes though. I'm not sure if 'propagated-inputs' are enough. For example "python-passlib" as propagated-input python-py-bcrypt, but the later does not show up as reference, requisite nor referrer: $ ./pre-inst-env guix build --fallback python-passlib […] /gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1 $ ./pre-inst-env guix gc -R /gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1 /gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1 $ ./pre-inst-env guix gc --references /gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1 /gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1 $ ./pre-inst-env guix gc --referrers /gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1 /gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
JARs and reference scanning (was: Need help from Java-developers)
Am 24.04.2017 um 00:57 schrieb Chris Marusich: > Chris Marusich <cmmarus...@gmail.com> writes: > >> Speaking of JAR files, shouldn't we try to avoid them entirely? My >> understanding is that they are compressed files, which means the Guix >> daemon won't be able to scan them for references. I don't know if it's >> easy to use Maven to build a project without putting the build output >> into a JAR file, though. > For the record, I looked into this a little more. I was mistaken: JAR > files are not necessarily compressed. In fact, it seems [1][2] that it > should always be possible to make un-compressed JARs. So, perhaps the > Guix daemon will not have trouble scanning JARs for references, after > all. (Whether or not any references will actually be retained in the > JARs produced by Maven is another question; I don't know the answer.) I have to admit that I do not know at all how the reference scanning and dependency-tracking in the store works. Regarding the jar-files ny understanding is: - JAR-files are Zip-files with additional data (as Ricardo already stated) - Zip-files can be used to store data without compressions (I assume this is what you are refering to). - My experience is that the contents of the JAR file can also be *unpacked* into the file-system, so not archives would be needed. Some Java guy might know better. I'm not sure it this is desired at all, though. - My understanding is that Java normally does not have any reference from one package (or jar-file) to another one. There is no such thing like "rpath" but is more like Python or Perl where the garbage collector AFAIK can not track references either. - According to [3, 2] the MANIFEST.INF file *may* specify a Class-Path containing the relative paths to other Jar-files. If this would help we *could* add references here, but the entry-length is limited to 65353 bytes, so we might hit this limit with the long paths of the store. - Fedora forbids to use this Class-Path entry in MANIFEST files [1]. - If it helps the garbage collector, we could add some ".dependencies" file alongside each Java package. But we don't do this for Python or Perl, either. [1] https://fedoraproject.org/wiki/Packaging:Java#No_class-path_in_MANIFEST.MF [2] https://en.wikipedia.org/wiki/JAR_(file_format)#Dependencies [3] http://docs.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#JAR%20Manifest -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Suggest A debian-style menu system for guix
Am 24.04.2017 um 14:48 schrieb Feng Shu: > All I want to say is that: we *must* add menu info in "package define" > if users of this package *real need* a menu instead of waiting upstream > to write a .desktop. Well, if there is no desktop file, wouldn't it be sufficient to add one? -- ▶︎Digitalcourage e.V., Hartmut Goebel, Marktstr. 18, D-33602 Bielefeld Tel: +49-521-1639 1639 | Fax: 0521-61172 | m...@digitalcourage.de https://digitalcourage.de | http://bigbrotherawards.de | -- Für Bürgerrechte, Datenschutz und eine lebenswerte digitale Welt - Online spenden: https://digitalcourage.de/spende/ Vorratsdatenspeicherung? Nicht schon wieder! Unterstützen Sie unsere Verfassungsbeschwerde: https://digitalcourage.de/weg-mit-vds
Trust and reproducible build (was: Help needed from Java developer to finish maven)
Am 24.04.2017 um 03:20 schrieb Hilco Wijbenga:
> First, if it's about trust ("am I really running a stock,
> unmanipulated Maven") then there are the checksums and signatures on
> the download page which exist for exactly that purpose.
While signatures are very useful in many cases, in this case they are
not. A signature on a JAR file only proofs that the JAR file was build
by some person or organization. It does not proof that the content of
the JAR file is exactly what was produced when compiling the source.
> If you feel
> you cannot rely on those then why trust the SCM that holds the Maven
> code?
The source can be reviews, the JAR-file content not. (One could
disassemble and reverse engineer it, but for this you need to trust
another tool: the disassembler. And then you still have to review the code.)
> Second, as an end user this makes it even harder to trust the end
> result. I now have to trust both the Maven devs *and* the Guix devs
> who worked on the packages.
Now this is where reproducible build steps in: You don't need to trust
the guix developers. Package descriptions are quite easy to review for
code manipulations (even ugly and long ones like the one for java and
the one for maven). So you can get the maven source-code from some
different source, easily verify the one you have is unchanged and build
it. And you will get the same checksums as anybody else building maven
via guix (on the same platform an guix version). Yes, you still have to
trust the guix developers to use a valif version of the C-compiler (and
a few other tools), but this is *much* less to trust compared a other
operation system distributions (Redhat, Fedora, Debian, Windows, OS X,
Solaris), where you have no chance to verify the code.
> (By the way, I run Gentoo GNU/Linux so I am very familiar with
> building from source. For me (and Gentoo) it's more about control and
> performance than anything else, though.)
Soi your aim is different than Guix's aim :-)
> But, still, building such a JAR from source (once Maven is
> available) takes little effort and so is worth it.
You are absolutely right. But "once Maven is available" is the key to
all of this.
> :-) Well, no, of course not. Maven isn't at the pre alpha state
> anymore. So in the spirit of "eat your own dogfood", Maven builds with
> Maven.
Umm, well,, It would help a lot if there would be some "minimal
maven" which could be used for bootstrapping. But even a "minimal Maven"
need tons of other packages
> Right, that makes perfect sense except for the part where you jump
> through hoops and make unexpected changes to Maven just to be able to
> build it in a highly unorthodox way. ;-) :-)
Be ensured that I have no plan at all to change maven. in any way. I'm
not going to make changes to Maven. I simply try bootstrapping it from
source. If there would be some "official" way, I would use it. What I'm
doing is simply adption the build.xml in guix. (Hmm, thinking on this,
maybe I can trip down my description to manipulate the build.xml. But I
don't think this is of much use since I most probably could only reuse
two simple tasks.)
Please keep in mind that Maven is not a compiler. its just a build tool.
So its easy to compare the build results from the guix package
description with whatever Maven builds when it is bootstrapping itself.
And I'm confident that as soon as I make maven to bootstrap itself from
source, it will be correct.
> According to msg00536 you patched Maven to use different JARs and
> versions. Obviously, that creates a problem so don't do that. Stick
> with the JARs/versions that Maven was built with and all will be well.
Please try to reproduce what I've done. The error message I posted is in
now way related to any version change, since when using the tar-ball I
could change the version and still bootstrap maven.As opposed to the
guix description, where maven fails to run quite early.
> But you would be much better off if you dropped this whole approach as
> I mentioned above. Even if you somehow made it work, it would be
> unreliable.
It would be much better if you'd help finding the cause of the error
message instead of spending time arguing about the way :-) No offence
meant, but adding precompiled JARS from maven central is not an option.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Guile bindings of GnuTLS are missing (was: Help needed from Java developer to finish maven)
Am 24.04.2017 um 14:41 schrieb Catonano: > I tried to build your branch just out of curiosity and the configure > of Guix fails because > > configure: error: The Guile bindings of GnuTLS are missing; please > install them. > > I'm running this inside a > > guix environment guix > > so I assume all the deps should be available Yes, this is one of the issues bugging me to quite often. Within the environment you'll also need to run: export SSL_CERT_DIR="$GUIX_ENVIRONMENT/etc/ssl/certs" export SSL_CERT_FILE="$GUIX_ENVIRONMENT/etc/ssl/certs/ca-certificates.crt" export GIT_SSL_CAINFO="$SSL_CERT_FILE" (This is why I wrote myself a script for setting up a guix environment.) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Help needed from Java developer to finish maven
Hi Hilco, for what I want to achieve, you need to understand Guix's philosophy: One of the major points is to have as few components as possible pre-build be external entities. Because only then Guix can ensure that the component is build from exactly the known source and not manipulated. And this means, that neither adding JARs from Maven Central to the store nor putting the maven tar-ball into the store are admissible options for Guix. I know other distributions do, like NixOS, but Guix will not. Sadly maven does not support building from source. Even the maven "source" includes a jar-file (maven-ant-task), which's job is to download JAR files from maven central. So I have a take a lot of effort building all (minimum) requirements, manually recreating e.g. meta-data files which maven creates, and that like. Most of these packages rely on maven for buiilding - which is not yet available. My actual gaol is to have some Java applications I need in Guix – but the Guix way :-) And this requires to be able to build JARs which are build using maven, and for this I need to be able to bootstrap maven from source. Am 23.04.2017 um 20:43 schrieb Hilco Wijbenga: I had a look at > maven-with-guix-versions.patch and I notice that you are changing > various version numbers and replacing some JARs with other JARs. Why > would you do that? Why do you expect the end result to work well? Or > at all? How would anyone be able to trust this patched Maven? I assume you are referring so the patch I posted month ago, which is is outdated now. For the current status, please have a look at the branch "WIP-maven" at https://gitlab.com/htgoebel/guix.git. My question refer to this status. This branch also uses some different versions, but the tar-ball maven builds and runs fine when using these versions. See https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00536.html for details on how I came to this conclusion. > I hope this is of use to you. If you have more questions, ask away. If you have an idea what could cause the error I posted, please give fixing it a try. You can find the Guix description at the branch "WIP-maven" at https://gitlab.com/htgoebel/guix.git. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
XPATH queries and manipulation in guile?
Hi, as far as I see it might be necessary to manipulate maven pom.xml files in many cases. Fedora provides macros like "pom_xpath_inject" or "%pom_remove_dep" for this [1, 2, 3]. Where can I find XPATH support for guile and some examples? Alternatively we could use Fedora's python-scripts [3] to do the job – ultimately showing that Python is superior to Java, since every Java package needs Python to build :-) Yes, I've seen SXPath [4], but IMHO this usign this would *not* be a good choice: It would require packages to learn yet another path language, while when using XPath, the packagers could simply copy expressions from some fedora .spec-file. Additionally I find the documentation of SXpath hard to understand - for be frank: I did not get it at all. [1] https://fedora-java.github.io/howto/snapshot/index.html#mvn_macros [2] https://pagure.io/javapackages/blob/master/f/macros.d/macros.fjava [3] https://pagure.io/javapackages/blob/master/f/java-utils [4] https://www.gnu.org/software/guile/manual/html_node/SXPath.html -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Seeking PHP "Hello World" project (or other simple example)
Hi, quite some time ago I [1] posted a patch for implementing a simple PHP "Hello World" program, to be used for testing setups. Ludo argued about using some example from somewhere else, instead of using a home-made package. (I created this package because I did not find some external project for such a simple example.) Does anybody know some "Hello Wolrd" like PHP example project? It should print some simple html page (preferable without leaking system inforamation). [1] https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00330.html -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Help needed from Java developer to finish maven
Hi Björn, I'm looking forward to your findings! > 1. Is this already the output of "mvn -X" and/or "mvn -e"? Yes, this is the output of mvn -X (basically, in fact I'm running "java … org.apache.maven.cli.MavenCli -X"). > 3. Do you have a WIP branch and instructions on how to reproduce this? You can find the branch "WIP-maven" at https://gitlab.com/htgoebel/guix.git. To reproduce simply run git clone https://gitlab.com/htgoebel/guix.git cd guix git checkout WIP-maven ./pre-inst-env guix build maven-for-bootstrap > 2. Some posts suggest that this could be caused because of wrong > version of dependencies? I.e. API and thus number of parameters changed: Inspired by you suggestion, I tested whether the versions I defined in guix would build when bootstrapping with "maven-ant-task". *maven bootstraps with this versions* (see below). In the repo you can find the file "30-compare-jars.ods", which shows the versions in different test-scenarios: Col 1: Versions and dependencies as listed in maven's DEPENDENCIES file. Col 2: Versions in the CLASSPATH when running maven-ant-task. Files not listed in Col 1 are marked yellow. Col 4: Versions in CLASSPATH used in guix WIP-maven. Version differing from Col 2 are marked blue. Col 3: Versions for running maven-ant-task, adopted to the versions in WIP-maven. Notably the versions used in guix are the same versions as used in Col 3 and Col 3 passes. You may want to double-check this. To reproduce this, run: git clone https://gitlab.com/htgoebel/guix.git cd guix git checkout WIP-maven X="$PWD" cd /tmp tar xzf /gnu/store/ydp9px7*-apache-maven-3.3.9-src.tar.gz patch < "$X/maven-with-guix-versions.patch" cd apache-maven-3.3.9 M2_HOME=/tmp/maven-test-build ant all -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Help needed from Java developer to finish maven
Hi, I'm seeking for help from some skilled Java developer. I nearly finished bootstrapping maven: I made it to start up, but now fails with this error message: org.apache.maven.InternalErrorException: Internal error: com.google.inject.ProvisionException: Unable to provision, see the following errors: 1) null returned by binding at org.eclipse.sisu.wire.LocatorWiring but parameter 1 of org.eclipse.aether.transport.wagon.WagonTransporterFactory.() is not @Nullable while locating org.eclipse.aether.transport.wagon.WagonConfigurator for parameter 1 at org.eclipse.aether.transport.wagon.WagonTransporterFactory.(Unknown Source) while locating org.eclipse.aether.transport.wagon.WagonTransporterFactory while locating java.lang.Object annotated with * I assume this means some meta-date file is missing in one of the jars (like plexus/components.xml or sisu/javax.inject.Named), but I was not able to find any missing file or data. may. Any tipps? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Funding Guix development esp. maven?
Hi, Ludo suggested me to ask on the mailing-list: I'm seeking for some funding for working on Guix. Project-based this could be bringing maven into guix. Working on Guix is a lot of fun, but I'm a freelancer, so I need to make my living somehow. Currently I'm spending too much time on guix which is missing on the income side. Unfortunately I have no contacts into the software-development scene, since my business is quite different: I'm a Consultant it Information Security Management (ISO 270001 and that like). If I'd have software-development customers, of course I'd ask them for funding. If somebody has ideas how to fund working on Guix, please drop me a note off-list. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Idea: 'ethical hosting' [formerly mailman service (free for FOSS projects)]
Am 18.04.2017 um 19:59 schrieb Pjotr Prins: > there is actually a business case for something like ethical hosting. I also see some demand for ethical hosting, esp. for collaboration services like mailman, chat, file-share, a simple web-site, etc. I get questions about this quite often. But most times the people are neither capable to setup and maintain a server at all – or they don't want to spend the money. E.g. at 1blu.de you can get a vServer with Plesk admin interface for 8 € per month. This includes KVM virtualization (or virtuozzo if you prefer), a web-mailer, mailinglists via plesk (mailman in the background) and a domain. So I don't see a business case here :-( -- +++hartmut | Hartmut Goebel| | | hart...@goebel-consult.de | www.goebel-consult.de |
Re: Progress and todos for Jave maven
Am 16.04.2017 um 17:38 schrieb Björn Höfling: > You posted half a year ago a series of patches that are not yet > integrated into Guix: > > https://lists.gnu.org/archive/html/guix-devel/2016-09/threads.html#00774 > > Are they still worth integrating, or are they obsolete with your new > approach? I'm asking because Ricardo wanted to work on them two weeks > ago: These patches are most probably outdated and will be overhauled. My current strategy is to build "bootstrap" versions for each of these packages and then build the "real" ones using the "maven-build-system". This effects at least the plexus packages, but most probably also the other ones to get "poms" for these, too. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: libxml2: Wrong separator in XML_CATALOG_FILES?
Am 13.04.2017 um 16:44 schrieb Ludovic Courtès: > Specifically, catalog.c in libxml2 has this: > > /* the XML_CATALOG_FILES envvar is allowed to contain a > space-separated list of entries. */ Thanks for digging into this. I'm still wondering about this non-standard implementation, though. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Guix command line flag consistency
Am 14.04.2017 um 22:57 schrieb Mike Swierczek: > I'd much prefer if both the short and long command line arguments > accepted their argument in any arrangement. I also stumbled over "--show=foo" failing. I suggest guix should follow the GNU command lien parsing conventions. Maybe this could be extended with the possibility to unambiguous shorten long options. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 05/20] gnu: Add python-sphinx-1.3.3
Am 15.04.2017 um 19:28 schrieb Hartmut Goebel: > Am 14.04.2017 um 12:13 schrieb Muriithi Frederick Muriuki: >> (define-public python2-sphinx-rtd-theme-0.1.9 >>(package-with-python2 python-sphinx-rtd-theme-0.1.9)) >> + >> +(define-public python-sphinx-1.3.3 >> + ;; python-httpretty has a hard requirement for >> + ;; sphinx == 1.3.3 > Please test if it works with an up-to-date version of sphinx, too. There > are very few reasons for requiring strict version of a tool like sphinx > or sphinx-rtd-them. And we should avoid adding versions over versions of > packages. https://github.com/gabrielfalcao/HTTPretty/blob/0.8.14/requirements.txt says: # HTTPretty doesn't have any requirements per se so far. yay! So I assume you take the version definitions in "development.txt" as "hard requirement" - but this file only defines *one* valid set of dependencies. So please review *all* the packages you say "python-httpretty has a hard requirement" and try to get rid of them. It may be even better to patch or "substitute" httpretty to make it work with our set of versions instead of piling of version of packages used only for this one. Thanks. -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/verschlusselte-mailingslisten Kolumne: http://www.cissp-gefluester.de/2011-08-horrorszenario-bring-your-own-device
Re: [PATCH 06/20] gnu: Add python-coverage-4.0.3
Am 14.04.2017 um 12:13 schrieb Muriithi Frederick Muriuki: > + ;; httpretty has a hard requirement for coverage==4.0.3 Same here. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 05/20] gnu: Add python-sphinx-1.3.3
Am 14.04.2017 um 12:13 schrieb Muriithi Frederick Muriuki: > (define-public python2-sphinx-rtd-theme-0.1.9 >(package-with-python2 python-sphinx-rtd-theme-0.1.9)) > + > +(define-public python-sphinx-1.3.3 > + ;; python-httpretty has a hard requirement for > + ;; sphinx == 1.3.3 Please test if it works with an up-to-date version of sphinx, too. There are very few reasons for requiring strict version of a tool like sphinx or sphinx-rtd-them. And we should avoid adding versions over versions of packages. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 01/20] gnu: Add python-radon
Am 14.04.2017 um 12:13 schrieb Muriithi Frederick Muriuki:
> + ("python-flake8-polyfill"
> +,python-flake8-polyfill)
I assume this should be a native-input, shouldn't it.
Also please write this in a single line.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Need help from Java-developers
Hi, as bootstrapping maven progresses (see my other post), the need for help from Java-developers arises. To finish all the work to be done after maven bootstrapping, some experienced Java developers are needed. The following questions need to be answered. * Designing the maven-build-system as follows: o How to maven commands map to our build phases? Should they map, should there be new ones? o Is there a need to clean up the pom-files prior to building, e.g. remove version numbers? o How to make the maven-build-system to never ever include other jar? Perhaps we need to post-process the generated jars. o How to handle pom-files (see below) * Which naming conventions should be used for packages? Maven has the notion of "group-id" and "atrtifact". Should this be kept? OTOH, there are very common packages like "commons-io" aka "apache-commons-io". * Where should the repo-files be kept in Guix? Debian seems to bot them into a dir-structure which I assume is leaned on some file-structure in the maven central repository. See <https://wiki.debian.org/Java/MavenRepoSpec> <https://wiki.debian.org/Java/MavenRepoHelper> and <https://packages.debian.org/jessie/maven-repo-helper> * Where to keep the pom-files? Are there other files we need (I've seen "effective pom", and "maven-fragments" in other distros)? Can or should we strip these files, like Debian seems to to with the maven-repo-helper? If so: What do we need? can this be done in guix, is there a maven-plugin, or …? * Help finding official sources, homepages, etc. for all packages. For many packages the data in the pom is outdated, since e.b. codehaus.org and code.google.com are gone. Please comment! -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Re: Some suggestion about "Contributing" documents.
Am 11.04.2017 um 07:28 schrieb Feng Shu: > "Contributing" document is hard to be understood i think. > In my opinion, "Contributing" part of document should split > two sub parts: > > 1. I am a guix core developer > > 2. I Just want to add a new apps's "define-public" Good idea. I'd even put the "add a new apps" part first since this is what more people will do more often. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Getting rid of "source file .. newer than compiled" messages
Hi Ricardo, Am 02.01.2017 um 16:08 schrieb Ricardo Wurmus: > If you want to keep a stable branch of Guix around you can use “git > worktree”. Then you can have a worktree on master and another worktree > where your WIP branches are being edited. Editing or switching branches > in one worktree won’t affect the other worktree. I'm using this git worktree feature now since one or two weeks and this is really great. I have several worktrees for different "projects" (like updating KDE Frameworks). Side-note: You tip also made me use worktrees for when generating a github-pages-based website using sphinx: The _build/html directory is the worktree holding the "gh-pages" branch. Works like a charm :-) Details: https://github.com/pyinstaller/pyinstaller.github.io -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Shouldn't docbook-xml/xsl set XML_CATALOG_FILES?
Hi, within a few day I stumbled twice over this: When using docbook-xml or docbook-xsl in a package description, one needs to set XML_CATALOG_FILES to make xslproc (and others) find the catalogs. Shouldn't XML_CATALOG_FILES be defined as native-search-paths? IMHO users expect (at least I do :-) the .xml and .xsl files to be available aber installation of these packages without further action required. BTW: For docbook-xsl the directory-name includes version, while for docbook-xml it does not. Which one should be used? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Curious link error: symbols not found
Am 23.03.2017 um 15:45 schrieb Thomas Danckaert: > Perhaps the monolithic Qt (which is at 5.6x) as well as the modular Qt > are in your profile? Bingo! Thanks, exactly this was the problem. Thanks a lot for the quick answer. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Curious link error: symbols not found
Hi, just today I tried to compile "ktouch", a KDE and QT application. This failed with *link* errors (see below), which I find very curious. Let's look at the first error message: To my understanding.the package "kcmutils" should reference to *exactly* the version of Qt (or what ever), it was build for. So how can it be that some symbol is not found? I tried force-re-building qtbase and the effected packed (as listed below), but this did not solve the issue. /gnu/store/…-kcmutils-5.28.0/lib/libKF5KCMUtils.so.5.28.0: undefined reference to `qt_version_tag@Qt_5.7' /gnu/store/…-kxmlgui-5.28.0/lib/libKF5XmlGui.so.5.28.0: undefined reference to `QIODevice::isTransactionStarted() const@Qt_5' /gnu/store/…-kcmutils-5.28.0/lib/libKF5KCMUtils.so.5.28.0: undefined reference to `QIcon::fromTheme(QString const&)@Qt_5' /gnu/store/…-kpackage-5.28.1/lib/libKF5Package.so.5.28.0: undefined reference to `qt_QMetaEnum_flagDebugOperator(QDebug&, unsigned long, int)@Qt_5' /gnu/store/…-kwindowsystem-5.28.0/lib/libKF5WindowSystem.so.5.28.0: undefined reference to `QJsonValue::toString() const@Qt_5' /gnu/store/…-kxmlgui-5.28.0/lib/libKF5XmlGui.so.5.28.0: undefined reference to `QListWidget::setSelectionModel(QItemSelectionModel*)@Qt_5' /gnu/store/…-kxmlgui-5.28.0/lib/libKF5XmlGui.so.5.28.0: undefined reference to `QString::resize(int, QChar)@Qt_5' -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
License Question for language packs
Hi, I'm about to package the 55 localization packages for KDE. The licence for these files seems to be very complicated, as it may depend on the copyright of the translated application. Debian's Copyright file [1] says: License: The licence for translations is the same as that of the application or library from which they come. The lowest common denominator is GNU GPL 2 only. Many apps are under GNU GPL 2 or later and libraries under GNU LGPL 2 or later. See the relevant application or library for details. The language packs include translations for different applications, so stating each of them might become a) cumbersome and b) of less use. Which license should I declare in the package? [1] http://metadata.ftp-master.debian.org/changelogs/main/k/kde-l10n/unstable_copyright -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Mass-packaging of 300 KDE application prepared - Help required
Hello all, as promised earlier, I prepared a repository inclusing patches for more than 300 KDE packages. I will not have time to work on them, though. Others will need to implement the packages based on this preperations. The repo contains prepared guix package descriptions for more than 300 KDE packages. The idea is to take a lot of stupid work from the shoulders of those who want to add a KDE package and automatically prepare as much as possible. Prepared are - name, version, url, hash - synopsis (two variants) - description (two variants) - license (needs to be verified) - inputs and native-inputs - store-path of the archive The synopsis and descriptions are taken from Debian and Mageia, chosen by what was easy to access for me. The license is taken from Debian but needs to be rechecked. Maybe OpenSuSE is a good place to look since they seem to have a strong focus on this. The inputs and native-inputs are taken from the `CMakeList.txt` file, which I processed and mapped many known requirements to guix's package names. For your convenience unprocessed content of the `CMakeList.txt` file has been put into the description, so you hopefully find all necessary information there. The repository can be found at <https://gitlab.com/htgoebel/guix-kde-package>, detailed description on how to work with it is available ins the README there. If you have any enhancement requests, please let me know. (I refained from sending the patches to some mailinglist since it is more then 880KB data and more than 300 patches). -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: gnu-patches back log
Am 06.03.2017 um 17:14 schrieb Ludovic Courtès: > add Reviewed-by tags Can git add this automatically? Otherwise it would mean additional manual work. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 1/2] doc: Symlink daemon start-up files.
Am 05.03.2017 um 21:55 schrieb Leo Famulari: > I've attached two patches. The first updates the instructions in the > manual, and the second builds the service files with the '/var/guix...' > path. LGTM -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: gnu-patches back log
Am 28.02.2017 um 07:25 schrieb Pjotr Prins: > Would it be an idea to send out weekly E-mails with patches that had > no attention to a select list of reviewers? Or maybe to the ML as a > whole? Basically it would read: This might be a good idea. Please mind adding links to that mail so one can easily access the patches and the "reports". This would make occasional reviewers live much easier. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Leaving the guix project
Hi David, > I also believe that the gnu project has moved away from those core > values and focuses instead on petitioning websites and hardware > manufacturers to release work they have invested a lot of money in > developing, often in very pushy and uncivil ways. Even if they > succeed, I do not really care about this expensive, rushed to market > and badly engineered code. I believe that the free software community > can do much better on it's own. Like others I don't understand how these concerns relate to Guix. I'm sad you decided to leave the Guix project – which is about to become reality – due to some "visionary" point which I consider to not related to Guix. It's a bit like not helping people to get drinking water since they have the vision to make their own Coke. Anyway, it's your decision. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: server and client in one package -> security issue
Am 13.02.2017 um 15:13 schrieb Ludovic Courtès: > Now, back to the “only install the required software”, I wouldn’t go as > far as you do. I generally agree with the rule, but I’m skeptical as to > what this buys you from a security perspective: users can always install > whatever they want by hand anyway, and do you have an idea as to how > much code they install via their browser? Looks like we are talking about different systems. I'm talking about hardened systems, esp. servers, where users are not allowed to install additional software – not even browser add-on. Yes, even on these systems a skilled person can install any software he/she wants. But it is much effort and requires more skills – depending on a lot of parameters – to bring an exploit to the system as if the exploit is already there since some software including the exploit is already installed. Is stress the example with the door of your flat again: For a skilled person opening a locked door is easy even if there is a pun tumbler lock [1]. But would you use just a ward key instead, which can be opened by nearly anybody – and even lay the skeleton key [2] beside the door? And this what hardening is about: reducing the attack surface and removing as many tools as a possible. Is a GNU/Linux distribution separates components sorrowly, its easier to harden the system, which makes the distribution more attractive compared to other distributions. [1] https://en.wikipedia.org/wiki/Pin_tumbler_lock [2] https://en.wikipedia.org/wiki/Skeleton_key -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: server and client in one package -> security issue
Am 14.02.2017 um 10:16 schrieb Danny Milosavljevic: > I don't think Guix should do that, though. I think guix should provide the tools for doing so. Guix has the big advantage of providing trustworthy packages, but kicks itself out of the race if hardening is so much complicated. > IMO locking down everything for users is basically the antithesis of the FSF. The "user" is the company, the employees work on behalf of the company. So the software freedom has to be available toe the company not to the individual employee. As a company I'm expecting the user to *not* install software on their computers (not talking about developers here). Otherwise its like allowing workers to bring their own hammer to the building site or their own machines into the factory building. If the hammer is inappropriate and is deforming all nails, or the machine is producing scrap, the company the the one bear the consequences. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Add murmur.
Am 12.02.2017 um 18:54 schrieb David Craven: > If an attacker already has the privileges required to start the software > I don't think it's possible to gain any more privileges unless that software > has the setuid bit set. You are right. I implicitly made some assumptions like setuid bit set. Nevertheless each additional piece of software already available eases the attack since less work and less skills are required. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [GNU-linux-libre] Free firmware - A redefinition of the term and a new metric for it's measurement.
Am 13.02.2017 um 20:24 schrieb David Craven: > You can always choose not to apply the vendors update. Is the vendor always trustworthy? Think about vulnerabilities in e.g. router firmware from companies like Cisco and Juniper, which were undiscovered for a long time – and one can reasonably argue that these have been back-doors. Also Intel Chips include a lot of magic called "Intel Management Engine" (IME) or "Active Management Technology" [1]. [1] https://en.wikipedia.org/wiki/Intel_Active_Management_Technology -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: server and client in one package -> security issue
Am 12.02.2017 um 13:53 schrieb David Craven: > By development files I assume you mean header files? I don't see how those can > pose a security problem. Can you elaborate? Yes, I meant header files, but also pkgconfig files and all this stuff (including documentation). Having this (and compilers, etc.) available on the target machine makes it *much* easier for an intruder to compile attack tools for malware on the target. If these are missing, the intruder needs to collect a lot of information first to be able to build tools for the target. Of course this is not a silver bullet, but it one piece of protection. Like a lock on the door: It may take the burglar only 2 Minutes to open it, but less skilled ones may be discouraged. Or these 2 Minutes may give you some advantage. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 5/6] gnu: Add python-typing
Am 09.02.2017 um 18:04 schrieb Frederick Muriithi: > It is a backport for python versions older than 3.5 This should be stated in the description then. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 3/6] gnu: Add python-ddt
Am 07.02.2017 um 19:00 schrieb Muriithi Frederick Muriuki:
> +(inputs
> + `(("python-six" ,python-six)
> + ("python-pyyaml" ,python-pyyaml)))
These need to be either native or propagated inputs.Please read the
Packaging guide i the manual. Thanks.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH] gnu: Update youtube-dl to 2017.02.01.
Am 04.02.2017 um 12:55 schrieb José Miguel Sánchez García: > > Appliead as d1606983195a95963ea6cc0ca8c963b5df1e0b61 Thanks. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH] gnu: Add python-rst2ansi
Am 04.02.2017 um 13:02 schrieb Frederick Muriithi:
> + (uri (string-append
> +
> "https://pypi.python.org/packages/3c/19/b29bc04524e7d1dbde13272fbb67e45a8eb2;
> + "4bb6d112cf10c46162b350d7/rst2ansi-"
> + version
> + ".tar.gz"))
Please use pypi-url here.
> +(native-inputs
> + `(("python-docutils" ,python-docutils)))
This must to be a propagated input. Please read the "Python apckages"
section in the manual about this.
> +(synopsis
> + "Python rst converter to ansi-decorated console output")
I suggest writing "reStructuredText" in the synopsis already.
What about: "Convert reStructuredText to ansi-decorated console output"?
> + "Python module dedicated to rendering RST (reStructuredText) documents
> to
> + ansi-escaped strings suitable for display in a terminal")
"Python module for rendering …
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
substitute/regex (was [PATCH 2/2] gnu: Add python-lzo.)
Am 03.02.2017 um 17:36 schrieb ng0: > I see. Okay, do you know which guix or guile module I do have to > rtf to understand once and for all how the (substitute*) behaves? > I'm doing this for too long to continue to run into problems with > this. > > Just the (substitute*)? Or is there some complimentary literature > I should consider (something in guile, grep, sed, …)? I can't remember, But it's two different things: 1) How to properly write strings in guile. For this I assume [1] is a good guide (I did not read it yet). For regexp it comes down that you need to escapw any backslash you need in the regex with another backslash for passing guilse parser. 2) How to use substitute* properly. I'm not an expert on this, but substitute* is defined in guix/build/utils.scm (grep is your friend :-) Here I found a nice, but rarely used feature: Matching groups may be assigned to variables like this: (substitute* file ((\"foo([a-z]+)bar(.*)$\" all letters end) (string-append \"baz\" letter end))) Here ALL is bound to the complete match, LETTERS is bound to the first sub-expression, and END is bound to the last one. [1] https://www.gnu.org/software/guile/manual/html_node/Backslash-Escapes.html -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 2/2] gnu: Add python-lzo.
Am 03.02.2017 um 14:13 schrieb ng0: > ERROR: In procedure scm_lreadr: gnu/packages/compression.scm:387:44: illegal > character in escape sequence: #\) IC, yes, this needs to be written as \\) (two backslashes) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 1/2] gnu: Add python-lz4.
Am 02.02.2017 um 16:16 schrieb contact@cryptolab.net: > * gnu/packages/compression.scm (python-lz4): New variable. LGTM -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Re: [PATCH 2/2] gnu: Add python-lzo.
Am 02.02.2017 um 16:16 schrieb contact@cryptolab.net:
> +(string-append "include_dirs.append(\""
> + (assoc-ref %build-inputs "lzo")
> "/include/lzo" "\")
You could use single quotes for teh python string to make it more readable:
string-append "include_dirs.append('" + (assoc-ref %build-inputs "lzo")
"/include/lzo" "')
> +"
Also this line-break is confusing. I suggest either using "\n" or to
change the substitute into something like:
+ (substitute* "setup.py"
+ (("include_dirs.append\(.*\)") ;; match up to the trailing
parent only, not the new-line
+(string-append "include_dirs.append('"
+ (assoc-ref %build-inputs "lzo") "/include/lzo"
+ "')" ;; put these last few characters
on the next line
Otherwise LGTM.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
0xBF773B65.asc
Description: application/pgp-keys
Python packaging rules again (was: postorius, v2)
Hi, I'm reposting this with a different subject, since this question is not only related to postorius: What do others think about the central question: Should django be a "normal" input or a "native" one? What does this depend on? What are the rules for? > I'm unsure about the correct handling of django in django-XXX. Can we > find rules for this to make future packager's life easier? > > Should django be a "normal" input or a "native" one? What does this > depend on? > > > Clear is: django-XXX should not "propagate" django: > > * django is a framework, django-XXX is an extension for this framework. > * If some application is using django-XXX, I'd expect it to have > django specified as "input", too, since primary it is a django > application. Maybe even djangoXXX is an optional component > > > Just for the records: > > * django-XXX should propagate other django extension it requires. > o If some application is using django-XXX, if should not care > about other django extensions django-XXX requires. This is the > same like as it does not have to care about other python > packages django-XXX requires. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: postorius, v2
Hi,
I just found that I did not verify the inputs carefully enough. Sorry.
Here are my comments:
* python-defusedxml: okay
* python-openid: okay
* python-django-allauth:
o openid, request-oauthlib requests ought to be propagated inputs
o mock is native, okay, but only required for the python2 variant
o Why is django a native input? See below for discussion
* python-django-gravatar2, may be okay, see below for discussion.
* python-django-mailman3
o All "inputs" except django need to be propagated inputs.
o Regarding django: see below
* * postorius: okay (this is an application, so no propagated inputs
are required)
And as we just learned about the licenses: python-django-mailman3 should
be gpl3+
I'm unsure about the correct handling of django in django-XXX. Can we
find rules for this to make future packager's life easier?
Should django be a "normal" input or a "native" one? What does this
depend on?
Clear is: django-XXX should not "propagate" django:
* django is a framework, django-XXX is an extension for this framework.
* If some application is using django-XXX, I'd expect it to have
django specified as "input", too, since primary it is a django
application. Maybe even djangoXXX is an optional component
Just for the records:
* django-XXX should propagate other django extension it requires.
o If some application is using django-XXX, if should not care
about other django extensions django-XXX requires. This is the
same like as it does not have to care about other python
packages django-XXX requires.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
0xBF773B65.asc
Description: application/pgp-keys
Re: [PATCH 3/7] gnu: Add python2-ruamel.ordereddict
Am 02.02.2017 um 05:53 schrieb Maxim Cournoyer: > Maybe the comment should say "No ordereddict python3 build available" ? This should be something like "No Python 3 implementation of this package available.", otherwise it would be very confusing. "Collections.OrderedDict" is part of the Python standard library since 2.7 and 3.1. Further there is a package "ordereddict". -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 6/7] gnu: Add python-ruamel.yaml.
Am 02.02.2017 um 05:42 schrieb Maxim Cournoyer: > I've looked at this patch series and it looks good so far The inputs need to be adjusted to become either native or propagated. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: postorius, v2
Am 30.01.2017 um 12:22 schrieb contact@cryptolab.net: > Changes: > > Applied what has been previously pointed out by Harmut. > Changed copyright headers. > > LGTM -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 6/6] gnu: Add postorius.
Hi, Am 30.01.2017 um 10:10 schrieb ng0: > >>> + (file-name (string-append name "-" version ".tar.gz")) >> I'd keep the original name, but this may be a matter of taste. > The original file name has some "+something2.tar.gz" in it, I want > to be consistent with what we provide. > Or what do you mean? I suggest keeping te original filename. But I don't know the exacpt conventions at Guix for this. > Thanks, I will apply this. They should fix their pypi source (if I got > it from there). ACK. >>> +(synopsis "Web user interface for GNU Mailman") >> Mention "Mailman 3"? > We only "have" version 3, why should I mention a version then? I > can do it... Did Mailman prior to version 3 have different > frontends than version 3? Mailman 3 is a completely new product. AFAIK most part are re-developed from scratch. OTOH at http://list.org/ they are just mentioning "Mailman" and "versions are 2.1.23 … and 3.0.3 …". An at mailman-bundler [1] they write "This is GNU Mailman" and "This package installs GNU Mailman". So probably we should stay with what you did: just call ist "Mailman". [1] https://pypi.python.org/pypi/mailman-bundler/3.0.0 > >> Please move it down to the description - I overlooked it first. > I assume you mean the "Web user interface for GNU Mailman 3". > In case I haven't mentioned it there, I will do so, okay. I meant the "synopsis" entry which I expect to be beside the description and not separate. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 2/2] doc: Discuss encrypted swap space.
Am 30.01.2017 um 05:40 schrieb Chris Marusich: > +Note that if you have encrypted the root partition and created a swap > +file in its file system as described above, then the encryption also > +protects the swap file, just like any other file in that file system. Please also mention the impact on Suspend to Disk. Thanks. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 6/6] gnu: Add postorius.
Am 30.01.2017 um 00:26 schrieb contact@cryptolab.net: > + (file-name (string-append name "-" version ".tar.gz")) I'd keep the original name, but this may be a matter of taste. > +(home-page "https://launchpad.net/postorius;) This has changed: "Postorius is no longer hosted on Launchpad. Please head over to Gitlab at https://gitlab.com/mailman/postorius <https://gitlab.com/mailman/postorius> for all bugs, code, and merge requests for Postorius." (I only checked since I dislike tu user experience at launchpad.) > +(synopsis "Web user interface for GNU Mailman") Mention "Mailman 3"? Please move it down to the description - I overlooked it first. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH] import: pypi: Don't add setuptools to propagated-inputs.
Am 21.01.2017 um 06:31 schrieb Carlo Zancanaro: > The pypi importer currently adds python-setuptools to the propagated > inputs. According to the manual we don't need to do this any more, so > here's a patch that updates the importer to match. > Well spotted :-) Pushed as 2f977d92d3ae517788d3dee98f63680ca149aa1a -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH python-tests] gnu: python-2.7: Enable UCS-4 Unicode encoding.
Hi Danny, thanks for the explanation. I wondered about this since I stepped over it the first time (but did not bother investigating it.) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Re: Systemd error on symlink
Am 20.01.2017 um 14:07 schrieb Leo Famulari: > Did somebody send a patch yet? I thought, you did?! -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH] gnu: whois: Move mkpasswd to its own output.
Am 20.01.2017 um 11:41 schrieb ng0: > I'm still in favor for making it separate guix packages. +1 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Systemd error on symlink
Am 20.01.2017 um 11:22 schrieb Pjotr Prins: > will throw an error. The solution is not to symlink but to copy the service > file. There is already a patch pending to change the manual, see http://lists.gnu.org/archive/html/guix-devel/2017-01/msg01199.html -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: python2-traceback2, python2-linecache2
Am 19.01.2017 um 16:01 schrieb Marius Bakke: > Me neither :-) but it's obviously something we need to tackle > eventually. Copied in Hartmut, maybe he's got some insight? Sorry. I posted my answer in a follow up to another mail of this thread. For the records: I'm afraid we need to package the modules for the next time. I filed some bug reports there. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 2/8] gnu: Add python-reno.
Am 17.01.2017 um 23:25 schrieb Danny Milosavljevic:
> +("python-pbr" ,python-pbr)
AFAIK this is a "library that injects some useful and sensible default
behaviors into your setuptools run." So I assume this should be a native
import. If it is indeed needed as run-time, I suggest adding a short
comment for what, otherwise others may stumble on this, too.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 8/8] gnu: python-dulwich: Fix tests.
Am 17.01.2017 um 23:25 schrieb Danny Milosavljevic:
> + ;(substitute* "dulwich/hooks.py"
> + ; (("f[.]write[(]args[[]0[]][)]")
> "f.write(args[0].encode('utf-8'))"))
This is an interesting but quite unusual way to escape the special
characters. I suggest using the more common type with back-slash, esp.
since "[[]" and "[]]" are very hard to get.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 01/16] gnu: Add python-argparse.
Am 17.01.2017 um 15:11 schrieb Ricardo Wurmus: > * gnu/packages/python.scm (python-argparse, python2-argparse): New As of Python >= 2.7 and >= 3.2, the argparse module is maintained within the Python standard library. Why do we need a this package? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Re: pre-push signature hook error reporting [was Re: [PATCH v6] gnu: python-sphinx: Update to 1.4.8.]
Am 17.01.2017 um 12:34 schrieb Danny Milosavljevic: > For minimal improvement (I don't even think it's measureable), try `git > rev-list HEAD` (backquotes) - it prevents having to spawn a subshell. Huh? I doubt this. The bash manual, section "Command Substitution" does not distinguish between these both, as far as I understand it. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Re: Installing guix packages without root permissions (in HPC environments)
Am 17.01.2017 um 10:15 schrieb Pjotr Prins: > But, I thought the easy way is to patch a path with something the has > the exact same size(!). This has the advantage that it will always > work. Trying this second strategy I wrote a new tool which replaces > the old path with a new one that takes the prefix and truncates the > rest of the path so a prefix /usr/local/bin/hello overwrites Pretty cool idea! -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Re: Help: a pypi source changed from targz into wheel
Am 16.01.2017 um 23:27 schrieb ng0: > Do I simply > download the wheel file and calculate the hash on that one, and > fit the name appropriately into the pypi? AFAIK we treat wheels as a binary files. You need to ask the project to release source archives, I'm afraid, -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Re: [PATCH 1/2] doc: Symlink daemon start-up files.
Am 15.01.2017 um 19:23 schrieb Leo Famulari: > Debian Jessie (their current stable release) doesn't support symlinked > systemd service files yet [0], If it does not work, we should of course revert this change. So you where right already at Nov 18 :-) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Anomalies in Python search-path
Am 15.01.2017 um 23:10 schrieb Ludovic Courtès: >> > My last reporting that pip was working correctly in non-environment was >> > wrong because I had failed to logout/login after installing the python >> > package; after doing so, the behavior is the same as in an environment: >> > the user site location (~/.local/...) comes after site-packages rather >> > than before, as would normally be the case. Apparently this is due to >> > setting a site-packages location with the environment variable >> > PYTHONPATH, which has precedence over the user site location. > ~/.guix-profile/etc/profile prepends things to the search paths, but > it’s up to the user whether to source it before or after other > definitions have been provided (in .bash_profile or similar). Maxim is talking about how python is processing the paths. The "normal" order is: - $PYTHONPATH (which normaly does not include site-packages) - Python Standard library (not including site-packages) - user's site-packages (~/.local/lib/python3.4/site-packages) - global site-packages (/usr/lib/python3.4/site-packages) The user's site-packages take precedence over the global ones. In Guix we currently use PYTHONPATH to add global site-packages. Since PYTHONPATH parts are put in front of the search list, they take precedence over the user's site-packages. And this behaviour is wrong. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Anomalies in Python search-path
Am 15.01.2017 um 20:23 schrieb Maxim Cournoyer: > 1. Remove the current "python-2.7-site-prefixes" patch. I'm afraid, we'll still need this patch. Since "native-inputs" will not be available at build time otherwise. But you way give it a try. > 2. Apply a new patch to site.py to add "$HOME/.guix-profile" > as well as "$GUIX_ENVIRONMENT". I already tried this and unfortunately the test-case "test_site" failed: The user-site-packages directory was not in sys.path. I had not time for investigating this. BTW: I'd not use a patch, but simply "substitute" it in a phase. But that's a matter of taste. > 3. Remove the 'native-search-paths' field. I assume we can remove this. But I do not really understand what "native-search-paths" *really* does. Ludo? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH] gnu: Add emacs-ag
Am 15.01.2017 um 17:13 schrieb ng0: >> Am 15.01.2017 um 12:25 schrieb Christopher Baines: >>> the silver searcher >> Please explain shortly what this is in the description. >> > Why? In my opinion this is already explained when you do As a service for those who do not know what "the solver searcher" is. Adding "code searching tool" to the description should not be much of a problem. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH] gnu: Add emacs-ag
Am 15.01.2017 um 12:25 schrieb Christopher Baines: > the silver searcher Please explain shortly what this is in the description. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH 2/2] gnu: Add openvpn service.
Am 12.01.2017 um 18:57 schrieb Julien Lepiller: > * gnu/services/vpn.scm: New file. > * gnu/local.mk (GNU_SYSTEM_MODULES): Add it. > * doc/guix.texi (VPN Services): N Great! Thanks. What about adding a system example with a openvpn configuration defining one or two peers, an dummy "up" script? This would help understanding the configuration and ease addition for novice users. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Anomalies in Python search-path (was: [PATCH] Update python-pip to 9.0.1)
Am 06.01.2017 um 19:41 schrieb Maxim Cournoyer:
> One thing which I discovered while testing pip on Guix was that
> depending on how you use Python on Guix the PYTHONPATH differs:
I analysed this problem and found set we have another serious problem
here. But good news: There is an easy solution for both problems.
Result of the analysis (as explained below): We must not extend
PYTHONPATH for adding the profile's site-packages directory.
Proposed solution: The standard library module "site" already contains a
place where we can hook in:
# Prefixes for site-packages; add additional prefixes like /usr/local
here
PREFIXES = [sys.prefix, sys.exec_prefix]
So we simply prepend $GUIX_ENVIRONMENT to this list:
PREFIXES = [os.path.expandvar(GUIX_ENVIRONMENT), sys.prefix,
sys.exec_prefix]
Prepending to speed up searches, since within an environment almost all
site-packages will end in GUIX_ENVIRONMENT. There is no need to check if
$GUIX_ENVIRONMENT is set, since if it is not, it will be left unchanged
and the non-existing path will be skipped out automatically
This would solve both the problem Maxim described and the problem
described below, since the Guix site-packages behave exactly like any
other global site-packages directory.
When following this proposal, we *may* even remove some "wrapping" stuff
in the python-build-system. But this has to be investigated first.
Analysis (proof see below):
The python interpreter was two command line options, which are rarely
used, though:
-E ignores environment variables, esp. PYTHONPATH
-S Disable the import of the module site and the site-dependent
manipulations of sys.path.
This means:
a) When passing -E, the Guix environment's site-packages are ignored
(together with PYTHONPATH), while they should not.
b) When passing -S, the Guix environment's site-packages should be
ignored, but is not (since it is specified in $PYTHONPATH, which is not
ignored)
Conclusion: We should must not use PYTHONPATH to specify the Guix's
environment's site-package directory.
Analysis details:
(guix)$ which python3
/gnu/store/zcnb…-profile/bin/python3
Without any options:
-> /home/USER/.local/lib/python3.5/site-packages and
/gnu/store/zcnb…-profile/lib/python3.5/site-packages
should be in sys.path
(base)$ python3 -c 'import sys ; print("\n".join(sys.path))'
/usr/lib64/python34.zip
/usr/lib64/python3.4
/usr/lib64/python3.4/plat-linux
/usr/lib64/python3.4/lib-dynload
/home/USER/.local/lib/python3.4/site-packages
/usr/lib64/python3.4/site-packages
/usr/lib/python3.4/site-packages
(guix)$ python3 -c 'import sys ; print("\n".join(sys.path))'
/gnu/store/zcnb…-profile/lib/python3.5/site-packages
/gnu/store/alk9…-python-3.5.2/lib/python35.zip
/gnu/store/alk9…-python-3.5.2/lib/python3.5
/gnu/store/alk9…-python-3.5.2/lib/python3.5/plat-linux
/gnu/store/alk9…-python-3.5.2/lib/python3.5/lib-dynload
/home/USER/.local/lib/python3.5/site-packages
/gnu/store/alk9…-python-3.5.2/lib/python3.5/site-packages
-E Ignore environment variables like PYTHONPATH and PYTHONHOME
that modify the behavior of the interpreter.
-> /home/USER/.local/lib/python3.5/site-packages and
/gnu/store/zcnb…-profile/lib/python3.5/site-packages
should be in sys.path
(base)$ python3 -E -c 'import sys ; print("\n".join(sys.path))'
/usr/lib64/python34.zip
/usr/lib64/python3.4
/usr/lib64/python3.4/plat-linux
/usr/lib64/python3.4/lib-dynload
/home/USER/.local/lib/python3.4/site-packages
/usr/lib64/python3.4/site-packages
/usr/lib/python3.4/site-packages
(guix)$ python3 -E -c 'import sys ; print("\n".join(sys.path))'
/gnu/store/alk9…-python-3.5.2/lib/python35.zip
/gnu/store/alk9…-python-3.5.2/lib/python3.5
/gnu/store/alk9…-python-3.5.2/lib/python3.5/plat-linux
/gnu/store/alk9…-python-3.5.2/lib/python3.5/lib-dynload
/home/USER/.local/lib/python3.5/site-packages
/gnu/store/alk9…-python-3.5.2/lib/python3.5/site-packages
-S = Disable the import of the module site and the site-dependent
manipulations of sys.path that it entails.
-> /home/USER/.local/lib/python3.5/site-packages and
/gnu/store/zcnb…-profile/lib/python3.5/site-packages
sould *not* be in sys.path
(base)$ python3 -S -c 'import sys ; print("\n".join(sys.path))'
/usr/lib64/python34.zip
/usr/lib64/python3.4/
/usr/lib64/python3.4/plat-linux
/usr/lib64/python3.4/lib-dynload
(guix)$ python3 -S -c 'import sys ; print("\n".join(sys.path))'
/gnu/store/zcnb…-profile/lib/python3.5/site-packages
/gnu/store/alk9…-python-3.5.2/lib/python35.zip
/gnu/store/alk9…-python-3.5.2/lib/python3.5/
/gnu/store/alk9…-python-3.5.2/lib/python3.5/plat-linux
/gnu/store/alk9…-python-3.5.2/lib/python3.5/lib-dynload
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH] gnu: Add tipp10 touch typing tutor.
Am 05.01.2017 um 11:56 schrieb Ludovic Courtès: > Please remove “for Windows, Mac OS and Linux.” > > OK with this change! Pushed with these changes b84257c0ffaa26b635f6a617d28da4b7edf26442 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
