Bug#496930: ITP: dvc -- Emacs front-end to distributed version control systems
Package: wnpp Owner: Daniel Dehennin <[EMAIL PROTECTED]> Severity: wishlist Tags: patch * Package name: dvc Version : 0r20080828 Upstream Author : Stephan Reichoer <[EMAIL PROTECTED]> * URL or Web page : http://download.gna.org/dvc * License : GPL Description : Emacs front-end to distributed version control systems DVC is an attempt to build a common infrastructure for various distributed revision control systems. Actually supported are tla, bazaar, bzr, git, mercurial, darcs and monotone. . DVC main features are: * dvc-status: Intuitive interface for status viewing. * dvc-log: Log viewer. * dvc-diff: View uncommitted changes in your working directory. * dvc-bookmarks: Bookmark manager with partner support. * Integration with ediff, Emacs's graphical diff tool. * dvc-missing: Interface to view missing patches from all your partners with a single command. * Send/receive/apply patches via the Gnus email client. * Run many version control commands from Emacs (such as init and pull). -- Daniel Dehennin Récupérer ma clef GPG: gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1 pgpYD80Jk2F7d.pgp Description: PGP signature
Bug#496930: Status
Antony Gelberg writes: > Hi, Hello, > Any news on this ITP? No, the upstream does not fix the issue and the software is in hard-sleep mode, main developers seems busy but apply some patch sent to them. The DVC team wish to integrate emacs, that day the copyright issue will be resolved and I will be able to make a dvc-snapshot package. For now, it can be closed, should I close it or tag it as wontfix? Thanks to Julien who accepted to be my mentor, and sorry for not being able to integrate this package. Regards. -- Daniel Dehennin Récupérer ma clef GPG: gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1 pgp3vU26cnCsr.pgp Description: PGP signature
Bug#491723: Debian packaging
Hello, Is there any progression on the packaging? I can make some tests and help in packaging, I'm not a Debian developer but package myself with CDBS and now a little about dbconfig-commom. Regards. -- Daniel Dehennin Récupérer ma clef GPG: gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1 pgpNUqc0T7rQY.pgp Description: PGP signature
Bug#496930: Status?
Le 5623 Septembre 1993, Daniel Moerner a envoyé: > Any progress on this ITP? I am currently using dvc debian packages > built from the bzr source that is linked to at > http://download.gna.org/dvc/. It would be nice to get this into Debian > proper. > > I see that it was tagged as pending, but the tag was removed. Hello, This bug is actually "forwared" upstream as the package was rejected for wrong copyright notices: > REJECTed, as you've missed FSF as a copyright holder for quite a few > files. I went throught the whole package and didn't see anything > else wrong, Regards. -- Daniel Dehennin Récupérer ma clef GPG: gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750837: ITP: moarvm -- virtual machine for Rakudo Perl 6 and NQP
Package: wnpp Owner: Daniel Dehennin Severity: wishlist * Package name: moarvm Version : 2014.05 Upstream Author : Jonathan Worthington * URL or Web page : http://moarvm.org * License : Artistic-2.0 Description : virtual machine for Rakudo Perl 6 and NQP Short for “Metamodel On A Runtime”, MoarVM is a virtual machine built especially for Rakudo Perl 6 and the NQP Compiler Toolchain. The goal is to provides nqp and rakudo with this second backend and let the user choose which one she prefers using alternatives. I manage to build the moarvm binary and its libmoar packages in AMD64 and i386 schroots. I manually build the NQP 2014.05 in a schroot using my moarvm deb and the nqp test suite pass: All tests successful. Files=90, Tests=3260, 19 wallclock secs ( 0.46 usr 0.07 sys + 18.08 cusr 1.20 csys = 19.81 CPU) Result: PASS You can find the first draft of packaging on my git repository[1]. Regards. Footnotes: [1] http://git.baby-gnu.net/gitweb/?p=moarvm.git;a=shortlog;h=refs/heads/feature/first-packaging-try -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
Bug#750837: ITP: moarvm -- virtual machine for Rakudo Perl 6 and NQP
Dominique Dumont writes: > On Saturday 07 June 2014 13:08:37 Daniel Dehennin wrote: >> You can find the first draft of packaging on my git repository[1]. > > That's a really god start. > > But "git-buildpackage --git-ignore-branch" ends with lintian errors > and warnings that must be fixed. > > Some of them like "syntax-error-in-dep5-copyright line 11: Duplicate > field copyright" can be fixed with "cme fix dpkg" (provided by > libconfig-model-dpkg-perl), > other will require more work. Thanks, I miss-read the documentation[1]. > /usr/lib/libmoar.so should be a symlink towards a versioned libmoar. > And libmoar.so should be delivered in a -dev package. > See > https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime The versioning of the library is reported upstream[2], I could patch build/setup.pm to add a version but I don't know if packaging should do something like this. > The versioned lib should land in /usr/lib/ to conform with > multiarch. > See https://wiki.debian.org/Multiarch This will require a patch since there is no way to specify the libdir at configuration time. (update: I just submit a request[3] upstream and was accepted on IRC) I just made one to remove the RPATH[4]. Regards. Footnotes: [1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field [2] https://github.com/MoarVM/MoarVM/issues/74 [3] https://github.com/MoarVM/MoarVM/issues/102 [4] http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
Bug#750837: ITP: moarvm -- virtual machine for Rakudo Perl 6 and NQP
Dominique Dumont writes: > On Thursday 12 March 2015 16:57:39 gregor herrmann wrote: >> Any news on moarvm packaging? > > Hmm no. The original plan was to Daniel to do the packaging work and me to > sponsor. I hope this plan still stands. Sorry for my long inactivity. I just rework my packaging[1] against the latest MoarVM 2015.02 : - install libmoar outside of the "standard linker path"[2] - generate the manpage from the pod file - use dpkg-buildflags instead of hardening-wrapper Actually, lintian says: W: moarvm source: empty-short-license-in-dep5-copyright (paragraph at line 50) P: moarvm source: debian-watch-may-check-gpg-signature W: moarvm: hardening-no-relro usr/bin/moar I: moarvm: hardening-no-fortify-functions usr/bin/moar W: moarvm: hardening-no-relro usr/lib/moar/libmoar.so I: moarvm: hardening-no-fortify-functions usr/lib/moar/libmoar.so I: moarvm: extended-description-is-probably-too-short I think I'll need to patch the build system to use the environment variables for *FLAGS for hardening. I wonder if I should have a -dfsg branch to remove the 3rdparty libatomic_ops and libtommath since I build against the Debian ones. Regards. Footnotes: [1] http://git.baby-gnu.net/gitweb/gitweb.cgi?p=pkg-moarvm.git;a=summary [2] https://github.com/MoarVM/MoarVM/issues/74 -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
Bug#750837: ITP: moarvm -- virtual machine for Rakudo Perl 6 and NQP
gregor herrmann writes: >> I just rework my packaging[1] against the latest MoarVM 2015.02 : > > % git clone git://git.baby-gnu.net/pkg-moarvm.git > Cloning into 'pkg-moarvm'... > fatal: remote error: access denied or repository not exported: > /pkg-moarvm.git Sorry, I forgot the git-daemon-export-ok, it's ok now. >> Actually, lintian says: >> W: moarvm source: empty-short-license-in-dep5-copyright (paragraph at >> line 50) > > Should be easy to fix by providing a short license name. > (Can be "other" if there is nothing ready-to-use.) Great, I was wondering what to use in that case. > >> P: moarvm source: debian-watch-may-check-gpg-signature > > Can be ignored. Sure, it's just pedantic >> W: moarvm: hardening-no-relro usr/bin/moar >> I: moarvm: hardening-no-fortify-functions usr/bin/moar >> W: moarvm: hardening-no-relro usr/lib/moar/libmoar.so >> I: moarvm: hardening-no-fortify-functions usr/lib/moar/libmoar.so >> I: moarvm: extended-description-is-probably-too-short > > That's unfortunate and needs investigation. > >> I think I'll need to patch the build system to use the environment >> variables for *FLAGS for hardening. > > Yup, looks like the *FLAGS are ignored. >> I wonder if I should have a -dfsg branch to remove the 3rdparty >> libatomic_ops and libtommath since I build against the Debian ones. > > If they are dfsg-free they can stay in the source package, as long as > they are not used. No need for the additional hassle of repackaging. Ok, I was not sure about source files duplication. > Maybe you could push the git repo to alioth (to the rakudo team > maybe?), then it's easier for others to clone/look/help out. What dou > you think? - No idea how pkg-rakudo works but I assume they are > welcoming since I know the some guys there :) And you're already a > project member. Yes, that's why I rename my repository to pkg-moarvm like pkg-rakudo. Regards. -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87pp8ay1vu@hati.baby-gnu.org
Bug#750837: ITP: moarvm -- virtual machine for Rakudo Perl 6 and NQP
gregor herrmann writes: [...] >> > Yup, looks like the *FLAGS are ignored. > > I looked into this now, see the attached patch series. > (Not perfect but a starting point.) Thanks, I'll look at them just after my brewing meeting ;-) >> > Maybe you could push the git repo to alioth (to the rakudo team >> > maybe?), then it's easier for others to clone/look/help out. What dou >> > you think? - No idea how pkg-rakudo works but I assume they are >> > welcoming since I know the some guys there :) And you're already a >> > project member. >> Yes, that's why I rename my repository to pkg-moarvm like pkg-rakudo. > > Excellent! But it seems I can't create a new repository on alioth, I'll wait for an admin to create the empty “pkg-moarvm.git” bare repository and then I'll push here. Regards. NB: I'm not sure about keeping all the Cc: on all mails. -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
Bug#750837: ITP: moarvm -- virtual machine for Rakudo Perl 6 and NQP
gregor herrmann writes: [...] >> > Yup, looks like the *FLAGS are ignored. > > I looked into this now, see the attached patch series. > (Not perfect but a starting point.) 5 days ago it was half fixed upstream[1], today it's fully fixed[2]. I tested them and I need to disable PIE or I have this issue: #+begin_src gcc -o libmoar.so -O2 -DNDEBUG -g3 -Wl,-rpath,/usr/lib/moar -fPIE -pie -Wl,-z,relro -Wl,-z,now -shared -fPIC src/core/callsite.o src/core/args.o src/core/exceptions.o src/core/interp.o src/core/threadcontext.o src/core/compunit.o src/core/bytecode.o src/core/frame.o src/core/validation.o src/core/bytecodedump.o src/core/threads.o src/core/ops.o src/core/hll.o src/core/loadbytecode.o src/math/num.o src/core/coerce.o src/core/dll.o src/core/ext.o src/core/nativecall.o src/core/continuation.o src/core/intcache.o src/core/fixedsizealloc.o src/gen/config.o src/gc/orchestrate.o src/gc/allocation.o src/gc/worklist.o src/gc/roots.o src/gc/collect.o src/gc/gen2.o src/gc/wb.o src/gc/objectid.o src/gc/finalize.o src/io/io.o src/io/eventloop.o src/io/syncfile.o src/io/syncstream.o src/io/syncpipe.o src/io/syncsocket.o src/io/fileops.o src/io/dirops.o src/io/procops.o src/io/timers.o src/io/filewatchers.o src/io/signals.o src/io/asyncsocket.o src/6model/reprs.o src/6model/reprconv.o src/6model/containers.o src/6model/parametric.o src/6model/reprs/MVMString.o src/6model/reprs/MVMArray.o src/6model/reprs/MVMHash.o src/6model/reprs/MVMCFunction.o src/6model/reprs/KnowHOWREPR.o src/6model/reprs/KnowHOWAttributeREPR.o src/6model/reprs/P6str.o src/6model/reprs/P6opaque.o src/6model/reprs/MVMCode.o src/6model/reprs/MVMOSHandle.o src/6model/reprs/MVMCompUnit.o src/6model/reprs/MVMStaticFrame.o src/6model/reprs/P6int.o src/6model/reprs/P6num.o src/6model/reprs/Uninstantiable.o src/6model/reprs/HashAttrStore.o src/6model/reprs/MVMThread.o src/6model/reprs/MVMIter.o src/6model/reprs/MVMContext.o src/6model/reprs/SCRef.o src/6model/reprs/Lexotic.o src/6model/reprs/MVMCallCapture.o src/6model/reprs/P6bigint.o src/6model/reprs/NFA.o src/6model/reprs/MVMException.o src/6model/reprs/MVMDLLSym.o src/6model/reprs/MVMMultiCache.o src/6model/reprs/MVMContinuation.o src/6model/reprs/NativeCall.o src/6model/reprs/CPointer.o src/6model/reprs/CStr.o src/6model/reprs/CArray.o src/6model/reprs/CStruct.o src/6model/reprs/ReentrantMutex.o src/6model/reprs/ConditionVariable.o src/6model/reprs/Semaphore.o src/6model/reprs/ConcBlockingQueue.o src/6model/reprs/MVMAsyncTask.o src/6model/reprs/MVMNull.o src/6model/reprs/NativeRef.o src/6model/6model.o src/6model/bootstrap.o src/6model/sc.o src/6model/serialization.o src/mast/compiler.o src/mast/driver.o src/spesh/dump.o src/spesh/graph.o src/spesh/codegen.o src/spesh/candidate.o src/spesh/manipulate.o src/spesh/args.o src/spesh/facts.o src/spesh/optimize.o src/spesh/deopt.o src/spesh/log.o src/spesh/threshold.o src/spesh/inline.o src/spesh/osr.o src/jit/graph.o src/jit/compile.o src/jit/log.o src/strings/decode_stream.o src/strings/ascii.o src/strings/utf8.o src/strings/ops.o src/strings/unicode.o src/strings/latin1.o src/strings/utf16.o src/strings/windows1252.o src/math/bigintops.o src/profiler/instrument.o src/profiler/log.o src/profiler/profile.o src/moar.o src/platform/posix/mmap.o src/platform/posix/time.o src/platform/posix/sys.o src/jit/emit_posix_x64.o 3rdparty/tinymt/libtinymt.a 3rdparty/libuv/libuv.a 3rdparty/dyncall/dyncall/libdyncall_s.a 3rdparty/sha1/libsha1.a 3rdparty/dyncall/dynload/libdynload_s.a 3rdparty/linenoise/liblinenoise.a 3rdparty/libtommath/libtommath.a 3rdparty/dyncall/dyncallback/libdyncallback_s.a -ltommath -latomic_ops -lm -lpthread -lrt -ldl /usr/bin/ld.bfd.real: 3rdparty/dyncall/dyncall/libdyncall_s.a(dyncall_callvm.o): relocation R_X86_64_PC32 against symbol `gVT_x64' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld.bfd.real: final link failed: Bad value collect2: error: ld returned 1 exit status Makefile:484: recipe for target 'libmoar.so' failed make[2]: *** [libmoar.so] Error 1 make[2]: Leaving directory '/build/moarvm-QgLiKc/moarvm-2015.02' dh_auto_build: make -j1 NOISY=1 returned exit code 2 debian/rules:37: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory '/build/moarvm-QgLiKc/moarvm-2015.02' debian/rules:26: recipe for target 'binary' failed make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 #+end_src Regards. Footnotes: [1] https://github.com/MoarVM/MoarVM/commit/09393586b6207b5aafd0067fc6f6ee339b7d3ff4 [2] https://github.com/MoarVM/MoarVM/issues/187 -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
Bug#750837: ITP: moarvm -- virtual machine for Rakudo Perl 6 and NQP
gregor herrmann writes:
> Hm, shouldn't $ENV{CPPFLAGS} go into @cflags instead of @ldflags?
Yes[1]
>
>
>> I tested them and I need to disable PIE or I have this issue:
>
>
> - hardening=+all ?
> - or because of @ldflags instead of @cflags?
>
>
> I should have time to take a look tomorrow, unless you beat me to it
I merged[2] their patches with my pull request, and I explicitely disabled
PIE after adding “+all”[3].
Now it builds cleanly in a schroot, I even install the package and “moar
--help” works \o/.
Regards.
Footnotes:
[1] https://github.com/MoarVM/MoarVM/pull/188
[2]
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-rakudo/pkg-moarvm.git;a=commit;h=807610863ff64609a7b1e1b12c84c25b4ff1b1d1
[3]
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-rakudo/pkg-moarvm.git;a=commit;h=571d44c7622b5dbae314dcd4c3e6d9b65b2fc050
--
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF
signature.asc
Description: PGP signature
Bug#750837: ITP: moarvm -- virtual machine for Rakudo Perl 6 and NQP
gregor herrmann writes: > Yay, great! > > Looks like the ITP bug can be tagged pending :) The new 2015.03 is out, this will permit to drop the patch ;-) Regards. -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
Bug#750837: ITP: moarvm -- virtual machine for Rakudo Perl 6 and NQP
Daniel Dehennin writes: > gregor herrmann writes: > >> Yay, great! >> >> Looks like the ITP bug can be tagged pending :) > > The new 2015.03 is out, this will permit to drop the patch ;-) Should I change the version of the single entry in debian/changelog or should I add a new section for this new release. I wonder since there is no .deb package yet. Regards. -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87pp84rjp4@hati.baby-gnu.org
Bug#750837: ITP: moarvm -- virtual machine for Rakudo Perl 6 and NQP
Dominique Dumont writes: > On Tuesday 17 March 2015 00:23:51 Daniel Dehennin wrote: >> Now it builds cleanly in a schroot, I even install the package and “moar >> --help” works \o/. > > I've begun to review the package. A couple of comments: > > * I think /usr/lib/moar/libmoar.so should land in a multiarch path (even > though libtommath.so is not currently multiarch...) The library is not versioned[1], so I thought it should not. > * copyright is missing Upstream-contact Should I set it to some upstream author or the http://moarvm.org/contributing.html URL? > * Expat license is duplicated in debian/copyright (which would have > been avoided if you were using cme ...) I tried “cme fix dpkg-copyright” but it does nothing :-/ I fixed it by hand and add the Vcs-* fields too. Thanks. Footnotes: [1] https://github.com/MoarVM/MoarVM/issues/74 -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
Bug#750837: ITP: moarvm -- virtual machine for Rakudo Perl 6 and NQP
Dominique Dumont writes: > Hello Daniel Hello, > I've used moarvm package as a test case for 'cme update dpkg-copyright'. > > Turns out that some copyright entries from 3rdparty directories were missing. > There were also some minor mistakes in the copyright owners. There's a better > chance of having moarvm go through ftp-masters without missing entries in > copyright file... Great, I was looking for a tool to manage this, it's quite cumbersome to do it by hand. > I've also added a 'fix.scanned.copyright' file in debian to work around some > limitations (or bugs) of licensecheck command. > > Last but not least: your previous work on debian/copyright is not wasted: > some files cannot be scanned and 'cme update' did reuse the data you've > created. > The fix.scanned.copyright file [1] is needed for files where licensecheck > returns > bogus data. > > I've pushed the new debian copyright file [2] to copyright-cme-update branch > on > pkg-moarvm repo. Feel free to pick up what you want from this file or simply > merge it on master. Ok, I merged it. I remove the “author variant” license paragraphes “BSD-2-clause~author” and “BSD-3-clause~Google” and manually fix the remaining “BSD-3-clause~author”. > I also found (manually, cme is not that magic ;-p ) that the license you > flagged as "Other" is a MIT variant. This update is pushed on master. [3] > > Once the copyright is done, I don't see any other issue to upload moarvm. I added the Upstream-Contact pointing to the “contribution” web page since it groups GitHub and IRC informations. Everything pushed. Regards. -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
Bug#496930: ITP: dvc -- Emacs front-end to distributed version control systems
Ben Finney writes: > Upstream development http://bzr.xsteve.at/dvc/> has resumed in > recent months, with what appear to be some improvements and bug fixes > committed to the VCS. > > Are you still interested in collaborating with upstream to get this > package into Debian? Hello, I did not notice it, I switched to magit[1]. I rarely use something else than Git, I really prefer magit over DVC and I'm not interested in it any more. Regards. Footnotes: [1] http://magit.vc -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
