Bug#906259: ITP: smartparens -- auto insertion, wrapping, and navigation of ()s, delimiters, and tags for Emacs
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves Package name: smartparens Version : 1.11.0 Upstream Author : URL : https://github.com/Fuco1/smartparens License : GPL-3+ Programming Lang: elisp Description : auto insertion, wrapping, and navigation of ()s, delimiters, and tags for Emacs Smartparens is minor mode for Emacs that manages parenthetical pairs and tries to be smart about it. Smartparens combines the functionality of autopair, textmate, wrap-region, electric-pair-mode, paredit into an integrated and extensible interface, with consistent behaviour across multiple languages. It aims to manage parentheses, delimiters, tags, et al in a way that does not cause cognitive dissonance. . Users who have found paredit awkward, or who miss LISP-specific niceties when working in other languages should try Smartparens. Conversely, long-time paredit users may require a period of adaptation, may need to customise various smartparens behaviours, and ultimately might find that this package is insufficiently paredit alike. Also, there are some reports that it is slow and inefficient in some modes (eg: AUCTeX); however, it works particularly well with Cider (Clojure). . Smartparens uses a default profile for most languages, but has specific support for Emacs LISP, Clojure, Elixir, ESS, Haskell, HTML, Javascript, LaTeX, Lua, Markdown, ML, Org, Python, Racket, Ruby, Rust, Scala, and plain text. This package is at the 99% percentile of MELPA downloads, Emacs Prelude installs it, and it is part of Spacemacs (and thus the Spacemacs packaging effort). I am currently in the process of investigating how well I like it. I really like the idea of paredit but continue to find it difficult to use in practise, so Smartparens might become one of my favourite packages. I plan to maintain it as part of the Debian Emacsen team, and I will need a sponsor for the initial upload. Regards, Nicholas signature.asc Description: PGP signature
Processed: block 828154 with 906259
Processing commands for cont...@bugs.debian.org: > block 828154 with 906259 Bug #828154 [wnpp] RFP: spacemacs -- Emacs configuration to get best of Emacs and Vim 828154 was blocked by: 880606 794624 872873 828154 was not blocking any bugs. Added blocking bug(s) of 828154: 906259 > thanks Stopping processing here. Please contact me if you need assistance. -- 828154: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828154 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0
Package: wnpp
Severity: normal
I request assistance with maintaining the julia package.
Specifically I need a ppc64el porter (or anyone who has root access to
a ppc64el box) to help me:
1. Apply patch[1] to Debian's llvm-toolchain-6.0 (= 1:6.0.1-4) and build it.
2. Install the resulting llvm-6.0-dev (= 1:6.0.1-5).
3. dget julia 0.7.0-2 and build Julia for ppc64el.
4. if (!llvm-ftbfs && !julia-ftbfs) {
1. clone #905807 for llvm-6.0 and remove the +moreinfo tag
2. pull the experimental branch from
https://salsa.debian.org/julia-team/julia
and see if the patched llvm-6.0 is also able to build julia 1.0.0
} elif (!llvm-ftbfs && julia-ftbfs) {
1. find out which patch actually fixes julia's build failure
https://github.com/JuliaLang/julia/blob/master/deps/llvm.mk#L482-L509
} else { .. }
I tried to setup a ppc64el chroot with qemu, and immediately find it
impractical for my laptop.
I tried to do it on launchpad (Ubuntu PPA/cosmic), and lauchpad told me
"Sorry, something just went wrong in Launchpad." during registration.
I tried to think of applying for the access to debian's ppc64el porterbox
but it appears to be impossible for a normal user to install the resulting
package and build another package. Although maybe I can do some hacks on
PATH and LD_LIBRARY_PATH but that's dirty.
So I gave up and wrote this RFH. That begin said, Julia's ppc64el port
is indeed supported by upstream, and it is worthwhile to keep Julia for
ppc64el such a powerful architecture.
Thanks in advance.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905807
Appendix
The package description is:
Julia is a high-level, high-performance dynamic programming language for
technical computing, with syntax that is familiar to users of other technical
computing environments. It provides a sophisticated compiler, distributed
parallel execution, numerical accuracy, and an extensive mathematical function
library. The library, mostly written in Julia itself, also integrates mature,
best-of-breed C and Fortran libraries for linear algebra, random number
generation, FFTs, and string processing. Julia programs are organized around
defining functions, and overloading them for different combinations of
argument types (which can also be user-defined).
.
This package provides a complete Julia installation (JIT compiler, standard
library, text-based user interface).
Julia is a high-level, high-performance dynamic programming language for
technical computing, with syntax that is familiar to users of other technical
computing environments. It provides a sophisticated compiler, distributed
parallel execution, numerical accuracy, and an extensive mathematical function
library. The library, mostly written in Julia itself, also integrates mature,
best-of-breed C and Fortran libraries for linear algebra, random number
generation, FFTs, and string processing. Julia programs are organized around
defining functions, and overloading them for different combinations of
argument types (which can also be user-defined).
.
This package provides a complete Julia installation (JIT compiler, standard
library, text-based user interface).
Processed (with 1 error): Re: RFP: sandsifter -- program/applicaiton to audits x86 processors for hidden instructions and hardware bugs
Processing commands for cont...@bugs.debian.org: > retitle 906246 ITP: sandsifter -- program/applicaiton to audits x86 Bug #906246 [wnpp] RFP: sandsifter -- program/applicaiton to audits x86 processors for hidden instructions and hardware bugs Changed Bug title to 'ITP: sandsifter -- program/applicaiton to audits x86' from 'RFP: sandsifter -- program/applicaiton to audits x86 processors for hidden instructions and hardware bugs'. > processors for hidden instructions and hardware bugs Unknown command or malformed arguments to command. > owner 906246 ! Bug #906246 [wnpp] ITP: sandsifter -- program/applicaiton to audits x86 Owner recorded as SZ Lin (林上智) . > thanks Stopping processing here. Please contact me if you need assistance. -- 906246: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906246 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#687118: poc pkg available
Proof of concept packaging available at https://sml.zincube.net/~niol/repositories.git/django-filebrowser-safe/ . Alex
Processed: RFP: gloo/0.5.0 -- Collective communications library for machine learning
Processing commands for cont...@bugs.debian.org: > noowner 889950 Bug #889950 [wnpp] RFP: gloo/0.5.0 -- Collective communications library for machine learning Removed annotation that Bug was owned by Lumin . > stop Stopping processing here. Please contact me if you need assistance. -- 889950: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889950 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#687081: poc pkg available
Proof of concept packaging available at https://sml.zincube.net/~niol/repositories.git/django-grappelli-safe/ . Alex
Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0
On Thu, Aug 16, 2018 at 08:38:04AM +, Mo Zhou wrote: > I tried to do it on launchpad (Ubuntu PPA/cosmic), and lauchpad told me > "Sorry, something just went wrong in Launchpad." during registration. Sorry for the inconvenience. Please get in touch with Launchpad staff (which happens to include me) about this. If you give us the OOPS ID that should have been part of the message you received, then we can fix up whatever's wrong with your account, and then you can use the ppc64el builders in our build farm. The details of this won't be on-topic for debian-devel of course, but you can contact us at feedb...@launchpad.net, or #launchpad on freenode. -- Colin Watson [cjwat...@debian.org]
Bug#906272: ITP: minetest-mod-intllib -- Minetest module for internationalization of modules
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: minetest-mod-intllib Version : 20180811 Upstream Author : Diego Martinez * URL : https://github.com/minetest-mods/intllib * License : Unlicense Programming Lang: lua Description : Minetest module for internationalization of modules This Minetest module provides a framework to internationalize other minetest modules. It doesn't provide translations for other modules, but it makes it possible for them to use their own translations. I plan to maintain it with my other minetest-mod-* packages within the Debian Games Team. Cheers, jpuydt on irc.debian.org
Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0
Mo Zhou writes ("Bug#906265: RFH: julia -- ppc64el port of Julia language and
LLVM-6.0"):
> I tried to think of applying for the access to debian's ppc64el porterbox
> but it appears to be impossible for a normal user to install the resulting
> package and build another package. Although maybe I can do some hacks on
> PATH and LD_LIBRARY_PATH but that's dirty.
This looks quite annoying. The basic pattern here is that the porter
may need to install modified build-deps. This seems like it must come
up all the time. DSA, do you have any suggestions ?
I was going to suggest that if the llvm-toolchain maintainers agree,
perhaps the package with the proposed patch could be uploaded to
experimental. But in my ad-hoc tests I couldn't get dd-schroot-cmd to
even install the package from experimental.
Ian.
Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0
On 08/16/2018 02:45 PM, Ian Jackson wrote:
> Mo Zhou writes ("Bug#906265: RFH: julia -- ppc64el port of Julia language and
> LLVM-6.0"):
>> I tried to think of applying for the access to debian's ppc64el porterbox
>> but it appears to be impossible for a normal user to install the resulting
>> package and build another package. Although maybe I can do some hacks on
>> PATH and LD_LIBRARY_PATH but that's dirty.
>
> This looks quite annoying. The basic pattern here is that the porter
> may need to install modified build-deps. This seems like it must come
> up all the time. DSA, do you have any suggestions ?
>
I believe tricks with env vars are indeed the usual way to play with
something like that. Porter boxes don't lend themselves well to
installing untrusted packages.
Cheers,
Julien
Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0
Julien Cristau writes ("Re: Bug#906265: RFH: julia -- ppc64el port of Julia
language and LLVM-6.0"):
> I believe tricks with env vars are indeed the usual way to play with
> something like that. Porter boxes don't lend themselves well to
> installing untrusted packages.
I wonder if `fakechroot' is any use.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#906280: ITP: ionit -- Render configuration files from Jinja templates
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: ionit Version : 0.1 Upstream Author : Benjamin Drung * URL : https://github.com/bdrung/ionit * License : ISC Programming Lang: Python 3 Description : Render configuration files from Jinja templates ionit is a simple and small configuration templating tool. It collects a context and renders Jinja templates in a given directory. The context can be either static JSON or YAML files or dynamic Python files. Python files can also define functions passed through to the rendering. ionit comes with an early boot one shot service that is executed before the networking service which allows one to generate configurations files for the networking and other services before they are started. In this regard, ionit can act as tiny stepbrother of cloud-init. I developed this tool since we found nothing similar. We will use ionit in our company. I will maintain the package on my own. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0
Hi Mo Zhou,
On Thu, 16 Aug 2018 08:38:04 +, Mo Zhou wrote:
> Package: wnpp
> Severity: normal
>
> I request assistance with maintaining the julia package.
> Specifically I need a ppc64el porter (or anyone who has root access to
> a ppc64el box) to help me:
>
> 1. Apply patch[1] to Debian's llvm-toolchain-6.0 (= 1:6.0.1-4) and build it.
I fetched this https://reviews.llvm.org/D43781
> 2. Install the resulting llvm-6.0-dev (= 1:6.0.1-5).
>
> 3. dget julia 0.7.0-2 and build Julia for ppc64el.
>
> 4. if (!llvm-ftbfs && !julia-ftbfs) {
I got there : both built fine.
I just had to avoid building in a schroot because of this :
---
make[3]: Entering directory '/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0'
Warning: git information unavailable; versioning information limited
cd /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/base && if !
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/bin/julia -O3 -C "native"
--output-o
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys-o.a.tmp
--startup-file=no --warn-overwrite=yes --sysimage
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys.ji
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys.ji;
then echo '*** This error is usually fixed by running `make clean`. If the
error persists, try `make cleanall`. ***'; false; fi
Generating precompile statements...ERROR: LoadError: Failed to open PTY master
Stacktrace:
[1] error(::String) at ./error.jl:33
[2] open_fake_pty at
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/share/julia/test/testhelpers/FakePTYs.jl:14
[inlined]
[3] with_fake_pty(::getfield(Main.anonymous,
Symbol("##3#9")){String,Base.GenericIOBuffer{Array{UInt8,1}},Base.GenericIOBuffer{Array{UInt8,1}},String})
at
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/share/julia/test/testhelpers/FakePTYs.jl:30
[4] (::getfield(Main.anonymous,
Symbol("##2#8")){Float64,Module,String})(::String, ::IOStream) at
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:81
[5] mktemp(::getfield(Main.anonymous, Symbol("##2#8")){Float64,Module,String},
::String) at ./file.jl:576
[6] mktemp at ./file.jl:574 [inlined]
[7] generate_precompile_statements() at
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:78
[8] top-level scope at
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:144
in expression starting at
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:4
---
which is unrelated to the problem you had but to workaround I built in a
fresh ppc64el unstable vm (probably due to bug #817236 and my schroot being too
old
to be created with the fix)
>
> 1. clone #905807 for llvm-6.0 and remove the +moreinfo tag
> 2. pull the experimental branch from
> https://salsa.debian.org/julia-team/julia
> and see if the patched llvm-6.0 is also able to build julia 1.0.0
this one builds fine as well.
For now, I won't have time to re-assign the bug on llvm. I'll check that
tomorrow.
> } elif (!llvm-ftbfs && julia-ftbfs) {
>
> 1. find out which patch actually fixes julia's build failure
> https://github.com/JuliaLang/julia/blob/master/deps/llvm.mk#L482-L509
>
> } else { .. }
>
> I tried to setup a ppc64el chroot with qemu, and immediately find it
> impractical for my laptop.
>
> I tried to do it on launchpad (Ubuntu PPA/cosmic), and lauchpad told me
> "Sorry, something just went wrong in Launchpad." during registration.
>
> I tried to think of applying for the access to debian's ppc64el porterbox
> but it appears to be impossible for a normal user to install the resulting
> package and build another package. Although maybe I can do some hacks on
> PATH and LD_LIBRARY_PATH but that's dirty.
Yes, that's a security related limitation of porter boxes which
sometimes makes them unhelpful sadly.
FYI, you may request a ppc64el vm there :
http://openpower.ic.unicamp.br/minicloud/
> So I gave up and wrote this RFH. That begin said, Julia's ppc64el port
> is indeed supported by upstream, and it is worthwhile to keep Julia for
> ppc64el such a powerful architecture.
>
> Thanks in advance.
Thanks a bunch for this work :)
F.
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905807
>
> Appendix
>
>
> The package description is:
> Julia is a high-level, high-performance dynamic programming language for
> technical computing, with syntax that is familiar to users of other technical
> computing environments. It provides a sophisticated compiler, distributed
> parallel execution, numerical accuracy, and an extensive mathematical
> function
> library. The library, mostly written in Julia itself, also integrates mature,
> best-of-breed C and Fortran libraries for linear algebra, random number
> generation,
Bug#714844: marked as done (RFP: python-osmapis -- Tools for accessing and manipulating OSM data)
Your message dated Thu, 16 Aug 2018 16:20:22 + with message-id and subject line closing RFP: python-osmapis -- Tools for accessing and manipulating OSM data has caused the Debian Bug report #714844, regarding RFP: python-osmapis -- Tools for accessing and manipulating OSM data to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 714844: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714844 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: wishlist * Package name: python-osmapis Version : 0.9.2 Upstream Author : Petr Morávek * URL : https://github.com/xificurk/osmapis * License : LGPL Programming Lang: Python Description : Tools for accessing and manipulating OSM data Osmapis is a set of tools for accessing and manipulating OSM data via OSM API, Overpass API. --- End Message --- --- Begin Message --- RFP 714844 has no visible progress for a long time, so closing.--- End Message ---
Processed: ITP: ruby-aes-key-wrap -- Ruby implementation of AES Key Wrap
Processing control commands: > block 902721 by -1 Bug #902721 [ruby-json-jwt] CVE-2018-1000539 902721 was not blocked by any bugs. 902721 was not blocking any bugs. Added blocking bug(s) of 902721: 906289 -- 902721: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902721 906289: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906289 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#762451: 762451 ITA: solfege -- Ear training software
retitle 762451 ITA: solfege -- Ear training software (duplicate) owner 762451 ! stop Hello, I'm preparing a new package of solfege to fix the lintian error missing-depends-on-sensible-utils, and I volunteer for maintaining this package. Should I do something else in addition to upload the new package to mentors.debian.net? Best Regards, François signature.asc Description: This is a digitally signed message part
Processed: 762451 ITA: solfege -- Ear training software
Processing commands for cont...@bugs.debian.org: > retitle 762451 ITA: solfege -- Ear training software (duplicate) Bug #762451 [wnpp] O: solfege -- Ear training software (duplicate) Bug #762445 [wnpp] O: solfege -- Ear training software (duplicate) Changed Bug title to 'ITA: solfege -- Ear training software (duplicate)' from 'O: solfege -- Ear training software (duplicate)'. Changed Bug title to 'ITA: solfege -- Ear training software (duplicate)' from 'O: solfege -- Ear training software (duplicate)'. > owner 762451 ! Bug #762451 [wnpp] ITA: solfege -- Ear training software (duplicate) Bug #762445 [wnpp] ITA: solfege -- Ear training software (duplicate) Owner recorded as François Mazen . Owner recorded as François Mazen . > stop Stopping processing here. Please contact me if you need assistance. -- 762445: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762445 762451: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762451 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#906309: ITP: tootle -- GTK3 client for Mastodon
Package: wnpp Severity: wishlist Owner: Federico Ceratto * Package name: tootle Version : 0.1.5 Upstream Author : Bleak Grey * URL : https://github.com/bleakgrey/tootle * License : GPLv3 Programming Lang: Vala Description : GTK3 client for Mastodon A simple and lightweight desktop client for Mastodon The packaging will be maintained at https://salsa.debian.org/debian/tootle Co-maintainers are very welcome.
Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0
Hi Frédéric,
Thank you very much for your help!
I've filed the bug for LLVM
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906314
and had it blocking julia's ppc64el build failure.
And have requested for a ppc64el vm. Next time I should be able to
do the ppc64el build by myself :-)
On Thu, Aug 16, 2018 at 05:37:06PM +0200, Frédéric Bonnard wrote:
> Hi Mo Zhou,
>
> On Thu, 16 Aug 2018 08:38:04 +, Mo Zhou wrote:
> > Package: wnpp
> > Severity: normal
> >
> > I request assistance with maintaining the julia package.
> > Specifically I need a ppc64el porter (or anyone who has root access to
> > a ppc64el box) to help me:
> >
> > 1. Apply patch[1] to Debian's llvm-toolchain-6.0 (= 1:6.0.1-4) and build
> > it.
>
> I fetched this https://reviews.llvm.org/D43781
>
> > 2. Install the resulting llvm-6.0-dev (= 1:6.0.1-5).
> >
> > 3. dget julia 0.7.0-2 and build Julia for ppc64el.
> >
> > 4. if (!llvm-ftbfs && !julia-ftbfs) {
>
> I got there : both built fine.
> I just had to avoid building in a schroot because of this :
>
> ---
> make[3]: Entering directory '/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0'
> Warning: git information unavailable; versioning information limited
> cd /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/base && if !
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/bin/julia -O3 -C "native"
> --output-o
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys-o.a.tmp
> --startup-file=no --warn-overwrite=yes --sysimage
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys.ji
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys.ji;
> then echo '*** This error is usually fixed by running `make clean`. If the
> error persists, try `make cleanall`. ***'; false; fi
> Generating precompile statements...ERROR: LoadError: Failed to open PTY master
> Stacktrace:
> [1] error(::String) at ./error.jl:33
> [2] open_fake_pty at
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/share/julia/test/testhelpers/FakePTYs.jl:14
> [inlined]
> [3] with_fake_pty(::getfield(Main.anonymous,
> Symbol("##3#9")){String,Base.GenericIOBuffer{Array{UInt8,1}},Base.GenericIOBuffer{Array{UInt8,1}},String})
> at
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/share/julia/test/testhelpers/FakePTYs.jl:30
> [4] (::getfield(Main.anonymous,
> Symbol("##2#8")){Float64,Module,String})(::String, ::IOStream) at
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:81
> [5] mktemp(::getfield(Main.anonymous,
> Symbol("##2#8")){Float64,Module,String}, ::String) at ./file.jl:576
> [6] mktemp at ./file.jl:574 [inlined]
> [7] generate_precompile_statements() at
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:78
> [8] top-level scope at
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:144
> in expression starting at
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:4
> ---
>
> which is unrelated to the problem you had but to workaround I built in a
> fresh ppc64el unstable vm (probably due to bug #817236 and my schroot being
> too old
> to be created with the fix)
>
> >
> > 1. clone #905807 for llvm-6.0 and remove the +moreinfo tag
> > 2. pull the experimental branch from
> > https://salsa.debian.org/julia-team/julia
> > and see if the patched llvm-6.0 is also able to build julia 1.0.0
>
> this one builds fine as well.
> For now, I won't have time to re-assign the bug on llvm. I'll check that
> tomorrow.
>
> > } elif (!llvm-ftbfs && julia-ftbfs) {
> >
> > 1. find out which patch actually fixes julia's build failure
> >
> > https://github.com/JuliaLang/julia/blob/master/deps/llvm.mk#L482-L509
> >
> > } else { .. }
> >
> > I tried to setup a ppc64el chroot with qemu, and immediately find it
> > impractical for my laptop.
> >
> > I tried to do it on launchpad (Ubuntu PPA/cosmic), and lauchpad told me
> > "Sorry, something just went wrong in Launchpad." during registration.
> >
> > I tried to think of applying for the access to debian's ppc64el porterbox
> > but it appears to be impossible for a normal user to install the resulting
> > package and build another package. Although maybe I can do some hacks on
> > PATH and LD_LIBRARY_PATH but that's dirty.
>
> Yes, that's a security related limitation of porter boxes which
> sometimes makes them unhelpful sadly.
>
> FYI, you may request a ppc64el vm there :
> http://openpower.ic.unicamp.br/minicloud/
>
> > So I gave up and wrote this RFH. That begin said, Julia's ppc64el port
> > is indeed supported by upstream, and it is worthwhile to keep Julia for
> > ppc64el such a powerful architecture.
> >
> > Thanks in advance.
>
> Thanks a bunch for this work :)
>
> F.
>
> >
> > [1] https://bugs.de
Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0
On Thu, Aug 16, 2018 at 01:45:14PM +0100, Ian Jackson wrote:
> Mo Zhou writes ("Bug#906265: RFH: julia -- ppc64el port of Julia language and
> LLVM-6.0"):
> > I tried to think of applying for the access to debian's ppc64el porterbox
> > but it appears to be impossible for a normal user to install the resulting
> > package and build another package. Although maybe I can do some hacks on
> > PATH and LD_LIBRARY_PATH but that's dirty.
>
> This looks quite annoying. The basic pattern here is that the porter
> may need to install modified build-deps. This seems like it must come
> up all the time. DSA, do you have any suggestions ?
Yes, sadly. However if DSA grant us the permission to install a
customized package, we can package e.g. a setuid program to obtain
the root shell within chroot.
BTW the schroot usage page (https://dsa.debian.org/doc/schroot/)
should really mention the tricks about env vars. I've submitted bug here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906313
> I was going to suggest that if the llvm-toolchain maintainers agree,
> perhaps the package with the proposed patch could be uploaded to
> experimental. But in my ad-hoc tests I couldn't get dd-schroot-cmd to
> even install the package from experimental.
Frédéric has just verified the proposed patch and it's working as
expected. Thank you again @Frédéric Bonnard !
> Ian.
