Bug#754260: RFS: terminology/0.6.0-1 [ITP]
On Wed, 2014-08-06 at 06:47 +0100, Anthony F McInerney wrote: https://phab.enlightenment.org/T1489 Why is that bug locked/private? The two main comments were Could you work on the patch to use the lib if the lib is found. This would require debian to provide a lz4.pc (and give it to upstream). Followed by invalid and closed. The patch already does that I think, hard to tell from the language they use though. I think they would accept a patch that would work for them to be able to keep their embedded copy. The whole point is to have them remove the embedded copy so that doesn't sound like a useful thing to spend time on. So that we don't have to patch, just delete src/bin/lz4, which would be cleaner? The best thing you can do for now is just apply the patch in Debian until upstream are willing to remove the embedded code copy. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
On 6 August 2014 06:56, Paul Wise p...@debian.org wrote: https://phab.enlightenment.org/T1489 Why is that bug locked/private? I do believe you might actually need a phab account to see it. http://i.imgur.com/7NcKL7r.jpg here's a screenshot instead The best thing you can do for now is just apply the patch in Debian until upstream are willing to remove the embedded code copy. On that note, also some further comments from raster (lead enlightenment/efl dev) raster in this case - no raster as other distros dont generally ship lz4 raster and as i said - we are going to wrap etc. raster and move it elsewhere raster also - debian policies are not ours Oh well. Anthony.
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
Hi Pabs, On 5 August 2014 06:02, Paul Wise p...@debian.org wrote: The attached files (completely untested) should do something like that and fix other issues. Yup, the use-lz4.patch was great, i merged your rules/control with mine (that i'd created from your previous mail) and everything appears to be fine. I've pushed the patch (and the others) upstream, hopefully something will be done. Still waiting on what to do with geneet stuff, upstream are working on a solution and hopefully will hear from them soon. (they have the email address for this bug) Thanks very much for your help pabs. I've uploaded the new revision to mentors. Kind Regards Anthony (bofh80)
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
On Wed, Aug 6, 2014 at 2:16 AM, Anthony F McInerney wrote: Yup, the use-lz4.patch was great, i merged your rules/control with mine (that i'd created from your previous mail) and everything appears to be fine. I've pushed the patch (and the others) upstream, hopefully something will be done. If you could get upstream to delete src/bin/lz4 from their VCS and tarballs that would be good too. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6emd1bfctshocnygccngfk2ee902zdqszj0t5v6cvp...@mail.gmail.com
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
If you could get upstream to delete src/bin/lz4 from their VCS and tarballs that would be good too. https://phab.enlightenment.org/T1489 The two main comments were Could you work on the patch to use the lib if the lib is found. This would require debian to provide a lz4.pc (and give it to upstream). Followed by invalid and closed. I think they would accept a patch that would work for them to be able to keep their embedded copy. So that we don't have to patch, just delete src/bin/lz4, which would be cleaner?
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
Hi pabs, On 1 August 2014 05:36, Paul Wise p...@debian.org wrote: Add liblz4-dev to the Build-Depends. In addition you will need to patch src/bin/Makefile.am and src/bin/termptysave.c so that the system version is used. Since you are patching the autotools build system you will need to replace autotools-dev with dh-autoreconf in the Build-Depends and replace autotools-dev with autoreconf in debian/rules. The code references lz4.c while lz4-dev supplies only lz4.h. Is there another way i can pull in the lz4 source package? Or am i just confused? :) grep lz4/lz4.c * -R bin/Makefile.in:lz4/lz4.c lz4/lz4.h \ bin/Makefile.in:lz4/terminology-lz4.o: lz4/lz4.c bin/Makefile.in:@am__fastdepCC_TRUE@$(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(terminology_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT lz4/terminology-lz4.o -MD -MP -MF lz4/$(DEPDIR)/terminology-lz4.Tpo -c -o lz4/terminology-lz4.o `test -f 'lz4/lz4.c' || echo '$(srcdir)/'`lz4/lz4.c bin/Makefile.in:@AMDEP_TRUE@@am__fastdepCC_FALSE@ $(AM_V_CC)source='lz4/lz4.c' object='lz4/terminology-lz4.o' libtool=no @AMDEPBACKSLASH@ bin/Makefile.in:@am__fastdepCC_FALSE@ $(AM_V_CC@am__nodep@)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(terminology_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o lz4/terminology-lz4.o `test -f 'lz4/lz4.c' || echo '$(srcdir)/'`lz4/lz4.c bin/Makefile.in:lz4/terminology-lz4.obj: lz4/lz4.c bin/Makefile.in:@am__fastdepCC_TRUE@$(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(terminology_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT lz4/terminology-lz4.obj -MD -MP -MF lz4/$(DEPDIR)/terminology-lz4.Tpo -c -o lz4/terminology-lz4.obj `if test -f 'lz4/lz4.c'; then $(CYGPATH_W) 'lz4/lz4.c'; else $(CYGPATH_W) '$(srcdir)/lz4/lz4.c'; fi` bin/Makefile.in:@AMDEP_TRUE@@am__fastdepCC_FALSE@ $(AM_V_CC)source='lz4/lz4.c' object='lz4/terminology-lz4.obj' libtool=no @AMDEPBACKSLASH@ bin/Makefile.in:@am__fastdepCC_FALSE@ $(AM_V_CC@am__nodep@)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(terminology_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o lz4/terminology-lz4.obj `if test -f 'lz4/lz4.c'; then $(CYGPATH_W) 'lz4/lz4.c'; else $(CYGPATH_W) '$(srcdir)/lz4/lz4.c'; fi` bin/Makefile.am:lz4/lz4.c lz4/lz4.h \ Thanks Anthony (bofh80)
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
On Tue, Aug 5, 2014 at 12:38 PM, Anthony F McInerney wrote: The code references lz4.c while lz4-dev supplies only lz4.h. Is there another way i can pull in the lz4 source package? Or am i just confused? :) I think you are confused. The package should link against the lz4 shared library rather than embedding a copy of the library. To link against a shared library you do not need the source code at all, just the header and the shared library. The attached files (completely untested) should do something like that and fix other issues. -- bye, pabs https://wiki.debian.org/PaulWise control Description: Binary data rules Description: Binary data --- a/configure.ac +++ b/configure.ac @@ -55,6 +55,8 @@ AC_CHECK_FUNCS(mkstemps) +AC_CHECK_HEADER([lz4.h], [AC_DEFINE([HAVE_LZ4_H], [1], [Define to 1 if you have lz4.h.])], [AC_MSG_ERROR([Please install the lz4 dev library https://code.google.com/p/lz4/])]) + EFL_WITH_BIN([edje], [edje-cc], [edje_cc]) with_max_log_level=EINA_LOG_LEVEL_ERR --- a/src/bin/Makefile.am +++ b/src/bin/Makefile.am @@ -7,7 +7,7 @@ -DPACKAGE_BIN_DIR=\$(bindir)\ -DPACKAGE_LIB_DIR=\$(libdir)\ \ -DPACKAGE_DATA_DIR=\$(pkgdatadir)\ @TERMINOLOGY_CFLAGS@ -terminology_LDADD = @TERMINOLOGY_LIBS@ @ELDBUS_LIBS@ +terminology_LDADD = @TERMINOLOGY_LIBS@ @ELDBUS_LIBS@ -llz4 terminology_SOURCES = \ private.h \ @@ -41,7 +41,6 @@ termptygfx.c termptygfx.h \ termptyext.c termptyext.h \ termptysave.c termptysave.h \ -lz4/lz4.c lz4/lz4.h \ utf8.c utf8.h \ win.c win.h \ utils.c utils.h \ --- a/src/bin/termptysave.c +++ b/src/bin/termptysave.c @@ -2,7 +2,7 @@ #include Elementary.h #include termpty.h #include termptysave.h -#include lz4/lz4.h +#include lz4.h #include sys/mman.h #if defined (__MacOSX__) || (defined (__MACH__) defined (__APPLE__))
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
Hi pabs, Also, src/bin/lz4 looks like an embedded code copy. Please ensure that the package uses the system version of the lz4 library and that src/bin/lz4 is removed in debian/rules build before ./configure is run, so that the code copy is never used. For bonus points, convince upstream to remove this directory from their VCS and tarballs. Please note that lz4 recently had some security issues, so terminology might be affected by them, depending on on how it uses lz4. if i need to remove src/bin/lz4 folder with debian/rules does that imply that i need to use get-orig-source to repack, and also do i then need to use d/copyright to exclude-files? also if the package requires / builds lz4 do i need to modify the makefile that builds it and do i provide the lz4-dev as a build-depends or . . . just the libs a 'depends' i'll look into packaging the geneet package too, assuming that will be needed. Thanks Anthony (bofh80)
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
On Thu, 2014-07-31 at 19:16 +0100, Anthony F McInerney wrote: if i need to remove src/bin/lz4 folder with debian/rules does that imply that i need to use get-orig-source to repack, and also do i then need to use d/copyright to exclude-files? You should not need to repack the orig.tar.gz, just ensure that these files are removed during the build before ./configure is run (override dh_auto_configure). If you really want to remove them from the orig.tar.gz, yes use the uscan support for repacking the orig.tar.gz. also if the package requires / builds lz4 do i need to modify the makefile that builds it and do i provide the lz4-dev as a build-depends or . . . just the libs a 'depends' Add liblz4-dev to the Build-Depends. In addition you will need to patch src/bin/Makefile.am and src/bin/termptysave.c so that the system version is used. Since you are patching the autotools build system you will need to replace autotools-dev with dh-autoreconf in the Build-Depends and replace autotools-dev with autoreconf in debian/rules. i'll look into packaging the geneet package too, assuming that will be needed. Great, thanks. With compat level 9 you do not need /usr/share/dpkg/default.mk in the debian/rules file AFAIK. The pkg-e team could definitely use help, please get involved if you haven't already and have the time to do so. https://wiki.debian.org/PkgE -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
Control: owner -1 ! Hey bofh80, * bofh80 afm...@gmail.com [2014-07-14 16:27:40 +0100]: Thanks for the feedback, I've uploaded 0.6.1 with an extra depends. I've checked in a vm without e17 installed this time to make sure it works first. If you'd be so kind as to check the new version and let me know? http://mentors.debian.net/package/terminology The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/t/terminology/terminology_0.6.1-1.dsc Sorry for the delay in getting back to you, I missed it, came before i subscribed to the mailing list. Terminology has piqued my interest for a while now, and I want to see it in Debian so I'll sponsor you. Here's my review: - debian/README.source is useless. - debian/copyright: - you're not Sebastian Reichel, are you? :) - ltmain.sh is GPL-2 - the copyright for src/bin/lz4 is missing - the copyright years need updating, and I think the authors list is outdated. - the *_eet.* seem to be autogenerated. ftpmasters will probably want them to be built from source, although not having source is fine wrt the license (BSD2). I don't see the source anywhere. - debian/control: - The descriptions need more work: the list of features needs trimming, and/or reformatting. - You might want to Suggest: libelementary-bin and let people know how to switch to OpenGL rendering in a README.Debian. Soft rendering is toasty. - debian/rules: - you should trim the comments/debmake foo and keep it simple. - DPKG_EXPORT_BUILDFLAGS = 1 is the default in debhelper compat level 9 - please have debhelper pass --disable-silent-rules to configure. - I think the exports (from the upstream README) are useful at runtime. - debian/terminology.lintian-overrides: I'm not a big fan of overriding the binary-without-manpage lintian warning, but I won't make you write the manpages either (I like writing manpages, but I understand not everyone does). I'd leave the warning as a reminder that those extra executables need some documentation. - debian/changelog: I'd merge the two entries in a single one, as the first one never entered Debian. - debian/watch: it seems that upstream switched to bz2 tarballs. See https://wiki.debian.org/debian/watch#Common_mistakes for a hint. Furthermore the 0.6.1 version doesn't exist there. You should either update it or provide a get-orig-source target in d/rules to rebuild the tarball you used. Build is ok, lintian seems happy. Things seem to run fine too. Setting aside the sourceless files bit, those issues shouldn't be very hard to fix. Please talk to upstream about the autogenerated files, we really want to ship the source, and ideally, we need the machinery to regenerate them at build time. Cheers, -- Nicolas Dandrimont BOFH excuse #191: Just type 'mv * /dev/null'. signature.asc Description: Digital signature
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
Hi Nicolas The eet file source issues, i ran a 'find' and couldn't see the files your talking about, could you name one or two explicitly for me? When i mentioned them, the terminology devs seemed to think they were config files. (enlightenment has a thing about putting text into 'machine code' for faster parsing) there are tools like edje_cc edje_decc edje_recc etc Everything else has been taken care of and i have uploaded 0.6.1-2 for you to peruse. The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/t/terminology/terminology_0.6.1-2.dsc Thanks again Anthony
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
Heya, * Anthony F McInerney afm...@gmail.com [2014-07-30 23:46:03 +0100]: Hi Nicolas The eet file source issues, i ran a 'find' and couldn't see the files your talking about, could you name one or two explicitly for me? The two files I was talking about are: ./src/bin/app_server_eet.c ./src/bin/app_server_eet.h When i mentioned them, the terminology devs seemed to think they were config files. (enlightenment has a thing about putting text into 'machine code' for faster parsing) there are tools like edje_cc edje_decc edje_recc etc Everything else has been taken care of and i have uploaded 0.6.1-2 for you to peruse. The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/t/terminology/terminology_0.6.1-2.dsc Please keep the revision at -1 until the package is uploaded to Debian. mentors.d.n will be fine with you reuploading the same version over and over again. I'll take another look later today. Cheers, -- Nicolas Dandrimont BOFH excuse #382: Someone was smoking in the computer room and set off the halon systems. signature.asc Description: Digital signature
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
On Thu, Jul 31, 2014 at 1:16 PM, Nicolas Dandrimont wrote: * Anthony F McInerney afm...@gmail.com [2014-07-30 23:46:03 +0100]: The eet file source issues, i ran a 'find' and couldn't see the files your talking about, could you name one or two explicitly for me? The two files I was talking about are: ./src/bin/app_server_eet.c ./src/bin/app_server_eet.h I can't find the source for these files in the upstream git repository either. The source should look something like the two files below. Please ask upstream what happened. It might be that they generated the files and then deleted the source and now tweak the .c files instead of the .geneet files. Or it could be that they rewrote these files from scratch, there are versions without _eet in their name. The best way to find out is to ask upstream. https://git.enlightenment.org/apps/terminology.git/tree/src/bin/ https://git.enlightenment.org/tools/geneet.git/tree/history.geneet https://git.enlightenment.org/tools/geneet.git/tree/phonebook.geneet Also, looks like the tool used to create these files isn't in Debian yet. https://git.enlightenment.org/tools/geneet.git/tree/ Also, src/bin/lz4 looks like an embedded code copy. Please ensure that the package uses the system version of the lz4 library and that src/bin/lz4 is removed in debian/rules build before ./configure is run, so that the code copy is never used. For bonus points, convince upstream to remove this directory from their VCS and tarballs. Please note that lz4 recently had some security issues, so terminology might be affected by them, depending on on how it uses lz4. https://wiki.debian.org/EmbeddedCodeCopies https://security-tracker.debian.org/tracker/source-package/lz4 -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6gxz4vj1swwh3m2i1s7gej_nt9+0w3wn7qrhkog57c...@mail.gmail.com
Re: Bug#754260: RFS: terminology/0.6.0-1 [ITP]
The new version appears to work for me. Thanks very much for testing it again. By the way, do you happen to know if terminology is supposed to replace eterm, or are both going to live together? They are certainly not the same thing, i'll simply put in the lead enlightenment devs response to someone else from the irc channel yesterday: Jul 14 03:36:25 bunjiboys Hi, after a reinstall of my Debian box, I am no longer able to get Eterm working. When i try to start it, it opens the window just fine, but it never opens the shell. I tried settings different commands to run using the -e switch to change what to execute, but it seems like it never gets to that point. After running with both strace and --debug it looks like it is stuck in a loop trying to read a socket (/tmp/.X11-unix/X0). Strace output: https://bunjiboys raster bunjiboys: no idea raster i havent used eterm for over a decade raster also note - thats the socket use to ttalk to x raster so its talking to x all day raster thats how you draw or get input raster i use terminology raster it's actively developed raster and uses modern efl raster eterm does not bunjiboys I was hoping not to have to change terms, been using Eterm for well over a decade now, just so used to it :) raster then get used to it not working raster or fix it yoursefl raster http://git.enlightenment.org/apps/eterm.git/ raster thats the activity on it raster one commit in march raster another janruary last year raster anoither in 2012 raster etc. raster not very active bunjiboys yeah, guess I do need to start shopping around for alternatives cippp for sure you will like terminology raster terminology is a far cry from eterm raster it is pretty different raster on the fancy-side it does a whole host more bunjiboys well, i didnt really use most of the features of Eterm, I disabled all the UI stuff and so on, its probably more an Ive always used it, so Ill keep using it thing bunjiboys Although, having been working on OSX recently, I wouldnt mind something that comes a little closer to iTerm2 raster well then... you'll be needing to do your own debugging raster as such enlightenment has moved on raster we build on efl raster (our libs) raster eterm does not raster it is effectively not part of enlightenment as a project anymore raster it's legacy we don't work on, support etc. raster it doesn't use our library infra raster and doesn't even visually fit in bunjiboys my point was that I'm not against finding something else, just never looked raster sure raster just saying that if you don't move - you're not going to get any help here raster terminology is the e terminal raster it uses efl raster it's modern raster http://www.enlightenment.org/p.php?p=about/terminologyl=en
Re: Bug#754260: RFS: terminology/0.6.0-1 [ITP]
Thanks for the feedback, I've uploaded 0.6.1 with an extra depends. I've checked in a vm without e17 installed this time to make sure it works first. If you'd be so kind as to check the new version and let me know? http://mentors.debian.net/package/terminology The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/t/terminology/terminology_0.6.1-1.dsc Sorry for the delay in getting back to you, I missed it, came before i subscribed to the mailing list. Many Thanks Anthony
Re: Bug#754260: RFS: terminology/0.6.0-1 [ITP]
On Mon, Jul 14, 2014 at 04:27:40PM +0100, bofh80 wrote: Thanks for the feedback, I've uploaded 0.6.1 with an extra depends. I've checked in a vm without e17 installed this time to make sure it works first. If you'd be so kind as to check the new version and let me know? The new version appears to work for me. I have not looked at packaging details, testing merely the functionality itself. By the way, do you happen to know if terminology is supposed to replace eterm, or are both going to live together? -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140714200407.ga11...@angband.pl
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package terminology * Package name: terminology Version : 0.6.0-1 Upstream Author : Carsten Haitzler ras...@rasterman.com * URL : http://git.enlightenment.org/apps/terminology.git/ * License : BSD-2 Section : x11 It builds those binary packages: terminology - Enlightenment efl based terminal emulator terminology-data - Enlightenment efl based terminal emulator data To access further information about this package, please visit the following URL: http://mentors.debian.net/package/terminology Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/terminology/terminology_0.6.0-1.dsc More information about Terminology can be obtained from https://www.enlightenment.org/p.php?p=about/terminology Changes since the last upload: * Initial release (Closes: #718031) Regards, Anthony F McInerney -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140709085720.32673.38479.reportbug@d630
Re: Bug#754260: RFS: terminology/0.6.0-1 [ITP]
On Wed, Jul 09, 2014 at 09:57:20AM +0100, Anthony F McInerney wrote: * Package name: terminology It fails to start, with the following output: CRI20400:elementary elm_win.c:2858 _win_constructor() Software X11 engine creation failed. Trying default. ERR20400:elementary elm_win.c:2994 _win_constructor() Cannot create window. ERR20400:eo lib/eo/eo.c:1217 eo_error_set_internal() Error with obj '0x2369c00' at elm_win.c:2995 ERR20400:eo lib/eo/eo.c:1107 eo_add_internal() in elm_win.c:2718, Object of class 'Elm_Win' - One of the object constructors have failed. ERR20400:eo lib/eo/eo_ptr_indirection.x:275 _eo_obj_pointer_get() obj_id (nil) is not pointing to a valid object. Maybe it has already been freed. ERR20400:efreet_cache lib/efreet/efreet_cache.c:1108 on_send_register() org.enlightenment.DBus.Canceled Canceled by user. -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140709101745.ga26...@angband.pl
