Hi,
On Thu, Dec 20, 2018 at 09:01:06PM +0100, Bastian Blank wrote:
> > One of Julia's tests checks this, and hence autopkgtests fail if debug
> > symbols are missing from sys.so, which is compiled from .jl scripts, not
> > C/CXX source.
>
> This could be also interpreted as "this test is
Hi,
On Thu, Dec 20, 2018 at 09:29:15PM +0100, Ansgar Burchardt wrote:
> Hi,
>
> Mo Zhou writes:
> > Another fortnight has passed. Any update?
>
> Sorry for taking so long; I wanted to put this on our meeting agenda,
> but currently don't find much time...
>
> Anyway, the package is now marked
Hi,
Mo Zhou writes:
> Another fortnight has passed. Any update?
Sorry for taking so long; I wanted to put this on our meeting agenda,
but currently don't find much time...
Anyway, the package is now marked to be accepted.
There were some misunderstandings on our side why debug symbols weren't
Hi Graham
On Fri, Nov 23, 2018 at 04:42:53PM +0200, Graham Inggs wrote:
> On 2018/11/21 16:11, Bastian Blank wrote:
> > I have not seen a real explanation why it needs to be this and exactly
> > this way. This setup was explained as either
> > - a workaround for a bug,
> > - a way to get
Mo Zhou writes ("Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED"):
> We (Julia maintainers) reached an agreement to revert the name of NEW
> binary package "libjulia1" back to "libjulia0.7", and upload the ugly
> package to unstable after a week
On Thu, Dec 20, 2018 at 01:49:29PM +, Mo Zhou wrote:
> I'm declaring this in advance, so if anyone see something dirty happend
> on the Julia binary packages, please don't report any bug against that
> dirty solution.
I'm afraid it doesn't matter for a broken package if the brokenness is
Hi,
We (Julia maintainers) reached an agreement to revert the name of NEW
binary package "libjulia1" back to "libjulia0.7", and upload the ugly
package to unstable after a week or ten days, in order to bypass the NEW
queue process. Resulting lintian Errors will be simply ignored.
I'm declaring
Hi,
Another fortnight has passed. Any update?
I've just uploaded Julia 1.0.3 to the NEW queue. This time the ordinary
shared object libjulia.so.1 is also stripped. Julia's sysimage sys.so
should be regarded as a special case and will never be stripped.
On Fri, Nov 30, 2018 at 02:55:55PM +,
Hi Bastian,
I've uploaded julia_1.0.2-1 to unstable (NEW) yesterday. There are
already six uploads being piled up in NEW. These uploads already have
been tested by Ubuntu devel extensively, and are suitable for the
Buster release.
I totally understand that for traditional C/C++ shared object,
Graham Inggs writes ("Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes
REJECTED"):
> On 2018/11/21 16:11, Bastian Blank wrote:
> > I have not seen a real explanation why it needs to be this and exactly
> > this way. This setup was explained as either
> > - a wo
Hi Bastian
On 2018/11/21 16:11, Bastian Blank wrote:
I have not seen a real explanation why it needs to be this and exactly
this way. This setup was explained as either
- a workaround for a bug,
- a way to get stacktraces from users or
- a way to make autopkgtest run.
Stripping sys.so breaks
Hi Andrey
On 26/09/2018 13:13, Andrey Rahmatullin wrote:
It's not clear why the debug symbols are necessary to be in the binary and
not detached as with most other binaries in the archive.
I believe the debug symbols can be detached, but we would still need to
depend on them, so I don't
12 matches
Mail list logo
