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,
On Tue, Nov 27, 2018 at 01:01:12PM +0500, Andrey Rahmatullin wrote:
> On Tue, Nov 27, 2018 at 08:38:56AM +0100, Wouter Verhelst wrote:
> > > > The experimental distribution is a good place for work in
> > > > progress. Maybe the rules for automatic rejects can be relaxed for
> > > > experimental
On Tue, Nov 27, 2018 at 08:38:56AM +0100, Wouter Verhelst wrote:
> > > The experimental distribution is a good place for work in
> > > progress. Maybe the rules for automatic rejects can be relaxed for
> > > experimental so a package can go into the archive (and have e.g. the BTS
> > > used for
On Tue, Nov 27, 2018 at 01:05:14AM +0100, Alf Gaida wrote:
> On Sat 24 Nov 2018 at 04:29PM +0100, Guido Günther wrote:
>
> > The experimental distribution is a good place for work in
> > progress. Maybe the rules for automatic rejects can be relaxed for
> > experimental so a package can go into
On Thu, Nov 22, 2018 at 09:16:59PM +, Holger Levsen wrote:
> On Thu, Nov 22, 2018 at 01:42:42PM +, Ian Jackson wrote:
> > > > Because:
> > > > ...
> > > thanks! nice summary.
> > I replied in my other mail to the things I disagreed with (as is
> > traditional) but it occurred to me I ought
On Sat 24 Nov 2018 at 04:29PM +0100, Guido Günther wrote:
> The experimental distribution is a good place for work in
> progress. Maybe the rules for automatic rejects can be relaxed for
> experimental so a package can go into the archive (and have e.g. the BTS
> used for that version) if the
On Sun, Nov 25, 2018 at 10:25:44AM -0700, Sean Whitton wrote:
> >> If someone does want to come along and fix the package, having it pass
> >> through NEW again is not a good use of ftpteam time.
> > Sounds like NEW is the problem, not other parts?
>
> Not sure what you mean.
I mean it seems
Hello,
On Sun 25 Nov 2018 at 05:41PM +0500, Andrey Rahmatullin wrote:
>> If someone does want to come along and fix the package, having it pass
>> through NEW again is not a good use of ftpteam time.
> Sounds like NEW is the problem, not other parts?
Not sure what you mean. I am saying that we
On Wed, Nov 21, 2018 at 08:37:28PM -0700, Sean Whitton wrote:
> >> Before we get there, we should first start autoremoving packages from
> >> unstable, if we consider rc-buggy in unstable to be unacceptable. We
> >> do have quite a bit of things in unstable, that are neither getting
> >> fixed,
Hello,
On Sat 24 Nov 2018 at 04:29PM +0100, Guido Günther wrote:
> The experimental distribution is a good place for work in
> progress. Maybe the rules for automatic rejects can be relaxed for
> experimental so a package can go into the archive (and have e.g. the BTS
> used for that version) if
Hi,
On Thu, Nov 22, 2018 at 12:52:48PM +, Ian Jackson wrote:
> Holger Levsen writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> > On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote:
> > > Why is any of this a reason for an ftpmaster REJECT ? I still th
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
On Thu, Nov 22, 2018 at 01:42:42PM +, Ian Jackson wrote:
> > > Because:
> > > ...
> > thanks! nice summary.
> I replied in my other mail to the things I disagreed with (as is
> traditional) but it occurred to me I ought to send a positive note
> about this:
>
> Thanks for being easy to
Chris Lamb writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes
REJECTED)"):
> Ian Jackson wrote:
> >[..] Compared to REJECT mails:
> > - Discussions in the BTS are more transparent
> > - Discussions in the BTS are better organised
> &
Ian Jackson wrote:
>[..] Compared to REJECT mails:
>
> - Discussions in the BTS are more transparent
> - Discussions in the BTS are better organised
> - Discussions in the BTS can have wider participation
> - Discussions in the BTS are better archived
> - Discussions
Hello,
On Thu 22 Nov 2018 at 11:20AM GMT, Holger Levsen wrote:
> On Wed, Nov 21, 2018 at 08:37:28PM -0700, Sean Whitton wrote:
>> What harm are the packages doing sitting in unstable? Distributing them
>> does not have much point, but neither does removing them.
>
> the rather few people
Holger Levsen writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes
REJECTED)"):
> On Thu, Nov 22, 2018 at 12:52:48PM +, Ian Jackson wrote:
> > Because:
> > ...
>
> thanks! nice summary.
I replied in my other mail to the things I disagreed with (as
Holger Levsen writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes
REJECTED)"):
> still I think we should only stuff in unstable which is suited for
> testing. So while you have convinced me that it's good to have those
> packages in Debian I now think that experimen
On Thu, Nov 22, 2018 at 12:52:48PM +, Ian Jackson wrote:
> Because:
>
> * Discussions about the RC bugs can be more effectively dealt with
>using our existing discussion mechanisms, including primarily the
>Debian BTS. Compared to REJECT mails:
> - Discussions in the BTS are
Holger Levsen writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote:
> > Why is any of this a reason for an ftpmaster REJECT ? I still think
> > all of this should be handled as bugs (possibly RC bugs) in the BT
On Wed, Nov 21, 2018 at 08:37:28PM -0700, Sean Whitton wrote:
> What harm are the packages doing sitting in unstable? Distributing them
> does not have much point, but neither does removing them.
the rather few people working on (fully and partly) automated QA have to
spend brain and cpu cycles
Sean Whitton:
> Hello,
>
> On Wed 21 Nov 2018 at 06:19PM GMT, Holger Levsen wrote:
>
>> On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote:
>>> Before we get there, we should first start autoremoving packages from
>>> unstable, if we consider rc-buggy in unstable to be
On Wed, Nov 21, 2018 at 03:29:38PM -0500, Jeremy Bicha wrote:
> On Wed, Nov 21, 2018 at 10:57 AM Holger Levsen wrote:
> > (in that sense I would appreciate packages getting automatically tested
> > (and rejected if needed) before they enter *unstable*, and then again,
> > with stricter automatic
Quoting Sean Whitton :
On Wed 21 Nov 2018 at 06:19PM GMT, Holger Levsen wrote:
On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote:
Before we get there, we should first start autoremoving packages from
unstable, if we consider rc-buggy in unstable to be unacceptable. We
do have
Hello,
On Wed 21 Nov 2018 at 06:19PM GMT, Holger Levsen wrote:
> On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote:
>> Before we get there, we should first start autoremoving packages from
>> unstable, if we consider rc-buggy in unstable to be unacceptable. We
>> do have quite
On Wed, Nov 21, 2018 at 10:57 AM Holger Levsen wrote:
> (in that sense I would appreciate packages getting automatically tested
> (and rejected if needed) before they enter *unstable*, and then again,
> with stricter automatic tests before they enter testing.)
This sounds to me like what Ubuntu
On Wed, Nov 21, 2018 at 06:19:49PM +, Holger Levsen wrote:
> On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote:
> > Before we get there, we should first start autoremoving packages from
> > unstable[...]
> I'm all for it.
also with a 3 month delay (instead of the 2 weeks or
On 2018-11-21 18:47 +0100, Matthias Klose wrote:
> On 21.11.18 16:56, Holger Levsen wrote:
> > On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote:
> >> Why is any of this a reason for an ftpmaster REJECT ? I still think
> >> all of this should be handled as bugs (possibly RC bugs) in the
On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote:
> Before we get there, we should first start autoremoving packages from
> unstable, if we consider rc-buggy in unstable to be unacceptable. We
> do have quite a bit of things in unstable, that are neither getting
> fixed, nor
On Wed, 21 Nov 2018 at 15:57, Holger Levsen wrote:
>
> On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote:
> > Why is any of this a reason for an ftpmaster REJECT ? I still think
> > all of this should be handled as bugs (possibly RC bugs) in the BTS
> > in the conventional way, after
On Wed, Nov 21, 2018 at 06:47:52PM +0100, Matthias Klose wrote:
I really like the approach of some ftp-masters to accept a package and then file
rc-issues, if there are some, like adding updated copyright information.
If the copyright info is wrong then it definitely shouldn't be in the
On 21.11.18 16:56, Holger Levsen wrote:
> On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote:
>> Why is any of this a reason for an ftpmaster REJECT ? I still think
>> all of this should be handled as bugs (possibly RC bugs) in the BTS
>> in the conventional way, after ACCEPT.
>
>
El miércoles, 21 de noviembre de 2018 12:56:42 -03 Holger Levsen escribió:
> On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote:
> > Why is any of this a reason for an ftpmaster REJECT ? I still think
> > all of this should be handled as bugs (possibly RC bugs) in the BTS
> > in the
On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote:
> Why is any of this a reason for an ftpmaster REJECT ? I still think
> all of this should be handled as bugs (possibly RC bugs) in the BTS
> in the conventional way, after ACCEPT.
because why accept rc-buggy software in the archive
Emilio Pozuelo Monfort writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> > On 2018/10/25 12:24, Ian Jackson wrote:
> >> Ian Jackson writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> >>> My main concern here is this: AFAICT this package has b
Hi,
On 21/11/2018 14:56, Graham Inggs wrote:
> Hi Bastian
>
> My apologies in advance for doing this, but another month has passed.
> Another ping from me.
>
> On 2018/10/25 12:24, Ian Jackson wrote:
>> Ian Jackson writes ("Re: julia_1.0.0-1_amd64.changes REJE
On Wed, Nov 21, 2018 at 03:56:44PM +0200, Graham Inggs wrote:
> > Ping, ftpmaster ?
Please read https://ftp-master.debian.org/REJECT-FAQ.html
Of cause lintian errors and warnings are reasons to reject packages.
Overriden ones without proper explanation more so.
> From the original REJECTion
Hi Bastian
My apologies in advance for doing this, but another month has passed.
Another ping from me.
On 2018/10/25 12:24, Ian Jackson wrote:
Ian Jackson writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
Lumin writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
Ian Jackson writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> Lumin writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> > 1. Isn't "incomplete backtrace" a sensible reason to keep debug symbols?
> >Policy said "should" but n
Hi Bastian
Sorry, I've just noticed my 'Reply All' email went to ftpmaster@ but
not waldi@, so I assume you missed it.
Please let me (and Lumin) know if you have any further concerns.
Also, there have been two further julia uploads since my last email.
Regards
Graham
On Wed, 26 Sep 2018 at
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
Graham Inggs writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> I thought Lumin had made it clear enough that being able to obtain a
> stacktrace from within Julia is actually a feature [1]. One of Julia's
> tests checks this, and hence autopkgtests fail if debug symbols
Lumin writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> 1. Isn't "incomplete backtrace" a sensible reason to keep debug symbols?
>Policy said "should" but not "must". Please tell me what I can do in
>order to help improve the src:ju
On Wed, Sep 26, 2018 at 12:52:41PM +0200, Graham Inggs wrote:
> I thought Lumin had made it clear enough that being able to obtain a
> stacktrace from within Julia is actually a feature [1]. One of Julia's
> tests checks this, and hence autopkgtests fail if debug symbols are missing
> from
Hi Bastian
I sponsored Lumin's original upload of Julia 1.0.0-1 and worked with him
closely, reviewing the commits leading up to the upload. In the
meantime, Lumin has become a Debian Developer and uploaded the
subsequent versions himself, although still with some input and testing
from me.
Hi Lumin
On Tue, Sep 25, 2018 at 02:40:43PM +, Lumin wrote:
> 1. Isn't "incomplete backtrace" a sensible reason to keep debug symbols?
>Policy said "should" but not "must". Please tell me what I can do in
>order to help improve the src:julia package to satisfy the requirements?
The
Hi Lumin,
On Tue, Sep 25, 2018 at 02:40:43PM +, Lumin wrote:
> > What I'm emphasizing here is, the debug info in those shared objects
> > are intensionally kept to preserve a good user experience and
> > avoid increasing maintainance burden.
> >
> > This is the expected backtrace from the
hi ftp-master,
Sorry for the noise, but I really care about the package src:julia. And
I started to suspect that ftp-master failed to recieve my last feedback
on the rejection. So I'm re-sending the feedback again, and CCing
-devel to make sure the mail won't get lost.
As of 1.0.0-3 (NEW), this
57 matches
Mail list logo
