Hi, @Ondřej
I'm closing this bug you forgot to close in -beta3's changelog: 861871 luajit 2.1.0 beta3 available Thank you very much for response and the upload! If the luajit built for arm64 doesn't segfault on start, this bug can also be closed: 818616 luajit: laujit segfaults on arm64 @Gianfranco Caffe was alrealy in a good shape and it does not depend on luajit :-) Recall the Torch7 stack you sponsored, where all the source packages are named lua-torch-*. The Torch7 stack needs luajit 2.1.0~beta* so they are living with luajit in experimental. The whole Torch7 stack will be migrated to unstable as long as luajit 2.1.0~beta* landed onto unstable. There is only one core CUDA module which remains to be packaged. On 8 May 2017 at 13:11, Gianfranco Costamagna <locutusofb...@debian.org> wrote: > Hello > >>We are in freeze and you are NMUing package in experimental after less >>than 14 days? > > > the RC bug is open since one year and two months, not exactly 14 days. > one year ago has received a fix, and 5 months ago has been raised to RC. > > I wouldn't say exactly "14 days old bug" :) > >>Also luajit 2.1.0~beta3 was released on 1. May, so I have just packaged >>that, and picked the cosmetic changes by Lumin. > > > this is awesome! I deleted my upload from deferred queue >>I didn't pick the debhelper related changes - first they do nothing for >>luajit, and second this will just make the backporting much harder. >>Please don't bump DH compat levels just for the sake of the "higher >>number". > > > I don't get this, > "stable-bpo 10.2.5~bpo8+1" stable has debhelper 10 since some months, IIRC, > and backporting to wheezy-sloppy is impossible by policy > (since the change to debhelper 10 won't be part of stretch, the maximum > backport > suite you can reach will be stretch-backports and jessie-backports-sloppy, so > the version requirement will be satisfied). > > (unless I didn't parse correctly your sentence) > > wrt debhelper 10, the --quilt switch should be useless, and the parallel > builds > might save some build time (even if it is already quick enough) > >>Also the binNMUability was done wrong. The common package was actually >>just incorrectly marked as arch:any, and all it took was to put >>Architecture: all in the right place. In fact, this was already fixed in >>git... > > > indeed, I somewhat wondered something had changed and that change was > necessary, > > Re-reading this commit [1] makes more sense now :) > > [1] > https://anonscm.debian.org/cgit/pkg-lua/luajit.git/commit/debian/control?id=1cd32bce634cbe92788d1a144d5648cc94ed86b4 > >>Also please don't put various changes into one big huge patch, but use >>git to split changes into individual patches, so we can work with that. > > > I think changes are split in various files in the BTS tracker, but I have to > check > again. > > Anyhow, thanks a lot for fixing this issue, this is really appreciated, > Lumin is working hard to bring caffe and its dependencies into a suitable > shape in Debian, and luajit has been a blocker for quite some time :) > (not your fault, caffe needs the experimental version, the unstable one is > too old, > so having RC bugs in experimental only is quite annoying for him). > > > thanks a lot once again, > > Gianfranco -- Best, Lumin
