Back
[07:47:28] <skunkworks> zlog
[09:10:56] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jethornton closed issue #63: Blank Error Message 02
https://github.com/LinuxCNC/linuxcnc/issues/63
[09:12:59] <cradek> seb_kuzminsky: trying to build
https://github.com/SebKuzminsky/f-engrave on wheezy, I see that it build-depends dh-python which wants to pull in python3, but it appears that f-engrave is a python2 program. is this a normal thing you expect?
[10:30:15] <seb_kuzminsky> cradek: i was not expecting that
[10:30:23] <seb_kuzminsky> i only tried it on jessie
[10:30:50] <seb_kuzminsky> i'll see about fixing it for wheezy (it's easy to switch out the distro, just point pbuilder at another debootstrap tarball)
[10:31:10] <cradek> well I have no reason to believe it wouldn't build and work
[10:31:29] <cradek> I'm only asking about the distastefulness of requiring python3 to build a non-python3 program
[10:31:42] <cradek> I didn't actually (install dh-python and) try it
[10:31:53] <seb_kuzminsky> aha
[10:32:18] <seb_kuzminsky> yeha, dh-python attempts to be everything to everyone, which is not unreasonable, but a bit superfluous in this case probably
[10:34:20] <seb_kuzminsky> the only wonkiness i found with f-engrave is that you can't point it at /usr/share/fonts/truetype and access all fonts
[10:34:31] <seb_kuzminsky> because it doesn't recurse, it only looks in the directory you tell it
[10:35:28] <seb_kuzminsky> ... so if someone was looking for a python project, that'd probably be an easy one to get into
[10:41:35] <seb_kuzminsky> cradek: i think maybe dh-python.deb is *just* for python3 and python2 doesnt need it
[10:54:30] <seb_kuzminsky> cradek: i just pushed a fix so it doesn't depend on dh-python (or python3) any more, thanks!
[10:54:44] <cradek> awesome
[10:55:43] <cradek> hm I also need the upstream tarball...
[10:56:41] <cradek> dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../f-engrave_1.58.orig.tar.{bz2,gz,lzma,xz}
[10:59:05] <cradek> avoiding that, I get: /usr/bin/install: cannot create regular file `/usr/local/bin/ttf2cxf_stream': Permission denied
[11:01:25] <cradek> argh, it doesn't recognize .zip as the upstream source
[11:03:18] <cradek> aha
[11:03:50] <cradek> once I repackage the upstream as orig.tar.gz, quilt works, and it fixes everything
[11:05:52] <seb_kuzminsky> great
[11:06:20] <seb_kuzminsky> i put the repackaged orig tarball here, in case anyone wants it:
http://highlab.com/~seb/linuxcnc/f-engrave_1.58.orig.tar.bz2
[11:07:30] <seb_kuzminsky> i wonder if i should make it into a native package
[11:07:45] <seb_kuzminsky> instead of quilt-style, which requires an orig tarball
[11:09:51] <cradek> http://timeguy.com/cradek-files/emc/fengrave-package-vcarve-r.png
[11:10:05] <cradek> package builds and runs on wheezy
[11:13:35] <cradek> the gcode even loads and runs
[11:14:27] <cradek> so awesome
[11:14:46] <cradek> also, the AXIS preview feature where you can select a line and then rotate around it is awesome
[11:15:54] <seb_kuzminsky> very cool :-)
[11:16:15] <cradek> our users are going to love this
[11:17:08] <cradek> have you talked to the author?
[11:18:26] <cradek> >From that information
[11:18:39] <seb_kuzminsky> i mailed the author yesterday but haven't heard back yet
[11:18:47] <cradek> interesting - the emc-users mails somehow get ^From_ mangled still
[11:19:12] <cradek> it's always a surprise whenever you think the past is over
[11:20:04] <seb_kuzminsky> the f-engrave website has a couple of ttf and cxf fonts on it, i wonder if they're redistributable
[11:20:19] <seb_kuzminsky> if so we should probably include them in the deb
[11:20:30] <seb_kuzminsky> (if they're not in some other fonts package in debian already)
[11:20:46] <skunkworks> huh - I didn't know axis rotated around the selected segment...
[11:20:55] <cradek> it's so nice
[11:21:06] <cradek> if only every program had navigation as good as AXIS's
[11:22:30] <seb_kuzminsky> i pushed some commits to the f-engrave github to make it into a native package, so no .orig tarball is needed
[11:22:30] <cradek> hmm,
http://timeguy.com/cradek-files/emc/about-axis.png
[11:22:41] <seb_kuzminsky> haha
[11:22:55] <cradek> ooh lemme try rebuilding
[11:23:27] <seb_kuzminsky> it now build-depends on tofrodos, since the f-engrave python file has dos line-endings
[11:24:08] <cradek> haha your 200-fromdos patch was ridiculous
[11:24:15] <seb_kuzminsky> it's interesting that the f-engrave author mentions awallin__ 's openvoronoi project
[11:24:31] <seb_kuzminsky> hrm yeah i was hoping no one would notice
[11:25:12] <cradek> but you didn't actually fromdos it in git?
[11:26:26] <cradek> yay, that builds much more easily now
[11:27:16] <seb_kuzminsky> nah, i do it at build-time now
[11:27:30] <seb_kuzminsky> makes it easier to rebase the debian packaging onto the next upstream release
[11:27:43] <seb_kuzminsky> it's in the top-level Makefile
[11:27:45] <cradek> good point
[11:28:03] <seb_kuzminsky> the old quilt way (and a similar commit in git) would have been a pain
[11:28:55] <cradek> and you remembered to build-dep tofrodos
[11:29:00] <cradek> wizard
[11:29:10] <seb_kuzminsky> i have this build system that was originally for making rtai kernels, but that grew into making debs of a bunch of useful packages (mesaflash, ttt, etc), it'll be easy to drop this f-engrave git repo into that system
[11:29:27] <seb_kuzminsky> https://github.com/SebKuzminsky/linux-rtai-build
[11:29:50] <seb_kuzminsky> then we can add those debs to the archive at wlo
[11:36:23] <seb_kuzminsky> cradek: i'm not a good wizard, but i have a good hunchback ;-)
[13:17:09] <seb_kuzminsky> f-engrave 1.58 for jessie, wheezy, and precise are on wlo now
[13:17:25] <seb_kuzminsky> let me know if you find any problems
[13:28:39] <cradek> I'm very sad to tell you that I think this package is undistributable because it contains both gpl-2-only and gpl-3+ code
[13:28:55] <cradek> they make different binaries, but does packaging them together "combine" them?
[13:29:32] * cradek goes to read faqs
[13:37:24] <cradek> > There is usually no need for different types of files to have different licenses ... if two are incompatible, we cannot distribute the package at all.
[13:37:31] <cradek> this is all I can find on UpstreamGuide
[13:44:59] <mozmck> It would seem that the FSF has done their cause a bit of harm by making gpl-3 incompatible with gpl-2
[13:45:22] <cradek> it's sad but I'm very sure it was unavoidable
[13:45:53] <cradek> I wonder if the author would relicense f-engrave-158.py to be 2+ instead of 3+
[13:46:16] <mozmck> I don't know. It is certain that a lot of projects cannot change for similar reasons to linuxcnc.
[13:46:44] <cradek> I think this is one author who wrote one file
[13:47:02] <cradek> very different from our unknown number of authors over 20 years
[13:47:26] <mozmck> yes, that's what I'm referring to. I believe the linux kernel is that way as well
[13:47:33] <cradek> if not, we can absolutely make two packages, one that depends on the other - this is not a fatal problem
[13:47:58] <cradek> yep, linux kernel is the same way and even (slightly) older
[13:48:34] <cradek> linus explicitly rejects the idea of trusting an infinite number of unknown future licenses
[13:48:50] <cradek> which is really quite understandable if you ask me
[13:49:04] <mozmck> yes
[14:28:31] <cradek> seb_kuzminsky: either way, debian/copyright is not filled out properly
[14:33:14] <seb_kuzminsky> yeah, yeah, nag nag
[14:33:32] <cradek> I'm still digging and can't decide if it's allowed the
[14:33:35] <cradek> -the
[14:33:46] <seb_kuzminsky> there's probably quite a bit of dh-make boilerplate in the packaging texts
[14:35:03] <seb_kuzminsky> i'll ask "scorch" about switching to GPLv2+
[14:35:23] <cradek> I think that would be best/easiest
[14:42:24] <seb_kuzminsky> ok, done, thanks for paying attention to that stuff
[14:42:46] <cradek> which thing did you do?
[14:45:51] <seb_kuzminsky> oh, i mailed scorch (the f-engrave author) about relicensing
[14:46:18] <seb_kuzminsky> yay, it's lunchtime
[15:35:50] <seb_kuzminsky> wow, scorch has some other cool cam-ish programs
[15:35:57] <seb_kuzminsky> http://www.scorchworks.com/Dmap2gcode/dmap2gcode.html
[15:42:41] <cradek> > The core functions of dmap2gcode come from image-to-gcode
[15:43:14] <cradek> I love how he's built on top of our little proofs-of-concept
[15:45:03] <seb_kuzminsky> yeah, that's good stuff
[15:59:28] <seb_kuzminsky> oh no, hard drive failure in my backup server!
[16:00:06] <seb_kuzminsky> good thing i have raid6
[16:00:13] * seb_kuzminsky clicks on the drive in newegg
[16:00:31] <cradek> slap in a new one and zpool replace...
[16:00:47] <seb_kuzminsky> i live in a linux ghetto, no zfs for me
[16:01:07] <cradek> ugh, so sorry
[16:01:33] <cradek> so you like print out the old drive and then OCR it or something?
[16:02:32] <seb_kuzminsky> mdadm add the new drive, mdadm rm the old drive, get a milkshake while the raid rebuilds
[16:02:54] <seb_kuzminsky> the array stays up and keeps receiving new backup snapshots while the new drive is integrated
[16:02:59] <seb_kuzminsky> nbd
[16:03:09] <seb_kuzminsky> err, that means no big deal, not network block device
[16:03:32] <cradek> sweet
[16:03:44] <seb_kuzminsky> it's not zfs, but it's not barbaric ;-)
[17:47:01] <seb_kuzminsky> cradek: scorch (the f-engrave author) says the gpl3+ license of f-engrave was inherited from the engrave-11 program on our wiki, which was the starting point for f-engrave
[17:47:10] <seb_kuzminsky> http://wiki.linuxcnc.org/uploads/engrave-11.py
[17:48:31] <seb_kuzminsky> he(?) has also integrated source code from other projects, all compatible (he claims) with gpl3+
[17:48:43] <seb_kuzminsky> and so he's declined the request to relicense it
[17:48:45] <seb_kuzminsky> shrug
[17:53:28] <andypugh> His code, his choice,
[18:01:05] <mozmck> Is it? If it is derived from gpl3+ licensed code, he doesn't really have a choice does he?
[18:03:48] <seb_kuzminsky> i think you're right, mozmck
[18:04:10] <seb_kuzminsky> he created a derived work from engrave-11.py, which is licensed gpl3+, so the derived work must match that
[18:04:40] <andypugh> Who wrote engrave-11.py?
[18:05:03] <seb_kuzminsky> at the top it says:
[18:05:03] <seb_kuzminsky> Copyright (C) <2008> <Lawrence Glaister> <ve7it at shaw dot ca>
[18:05:03] <seb_kuzminsky> based on work by John Thornton -- GUI framwork from arcbuddy.py
[18:05:04] <seb_kuzminsky> Ben Lipkowitz (fenn)-- cxf2cnc.py v0.5 font parsing code
[18:05:34] <JT-Shop> hey I'm famous
[18:05:42] <andypugh> fenn and JT are still available, butnot sure about Lawrence
[18:05:44] <seb_kuzminsky> your code lives on
[18:18:23] <JT-Shop> I wonder if my Golang program to convert dxf to G code would be useful to create an engraving software
[18:24:52] <andypugh> Potentially, but doe LinuxCNC need yet another language dependency?
[18:25:52] <cradek> that doesn't matter as long as the packages are separate (like f-engrave is separate from linuxcnc)
[18:27:27] <andypugh> I think we need more APL in the project :-)
[18:29:11] <seb_kuzminsky> andypugh: if we can compile it with tools in debian that's fine by me :-)
[18:29:23] <seb_kuzminsky> and if you maintain it, because my brain doesnt have room for another language in it
[18:29:34] <mozmck> heh!
[18:31:19] <seb_kuzminsky> see y'all later, time for a family bbq
[18:33:47] <JT-Shop> go bbq and don't get burned
[18:34:02] <JT-Shop> one thing for sure Goland is very fast
[18:34:13] <mozmck> compared to python?
[18:34:47] <JT-Shop> yea, that's the only thing I can compare it to lol
[18:35:01] <mozmck> python is pretty slow
[18:38:19] <JT-Shop> maybe I should return to C
[18:38:34] <andypugh> C is good for fast
[18:39:49] <JT-Shop> http://www.computing.co.uk/ctg/news/2076322/-winner-google-language-tests
[19:14:02] <jepler> we wouldn't want to put GPL3+ software in linuxcnc.git, or link to / include it when building, but it's just fine to put GPL3+ software in linuxcnc.org's deb repository and to invoke it by a defined interface (standard output) to work as a filter in axis and other compatible UIs
[19:15:55] <jepler> er I see now in scrollback that there is 2-only code in there. boo
[19:16:29] <jepler> which part is 2-only?
[20:54:15] <seb_kuzminsky> jepler: f-engrave forked a GPL2 program named ttf2cxf
[20:54:42] <seb_kuzminsky> the gpl2 ttf2cxf code is included with the gpl3+ f-engrave source
[21:51:24] <cradek> jepler: the f-engrave package has a binary built from a 2-only source file and installed in /usr/bin, and also a separate 3+ python file installed into /usr/bin
[21:51:42] <cradek> they are packaged together but aren't a combined program
[21:52:21] <cradek> this has nothing to do with linuxcnc.git or combining with linuxcnc
[21:52:56] <seb_kuzminsky> yeah, the plan would be to build f-engrave's source into a separate deb, and publish that deb on wlo
[21:52:56] <cradek> jepler: [background] seb is packaging f-engrave, which is a cool program formerly with no useful packaging
[21:53:31] <seb_kuzminsky> and i jumped the gun and did it, damn the lawyers, full speed ahead! and now you can apt-get it from wlo
[21:53:50] <seb_kuzminsky> but maybe i have to take it off or split it up or something if i broke some law
[21:54:34] <seb_kuzminsky> oh, and Scorch, the author, declined my request to relicense the python program from GPL3+ to GPL2+, so it's on us to deal with somehow
[21:54:55] <cradek> hmm ok
[21:55:15] <cradek> worst case is you make two packages
[21:55:45] <seb_kuzminsky> yeah, and point the lawyers at Scorch's zip file if they come a-knockin
[21:56:08] <cradek> yes if there's a problem it'd be on him/her
[22:07:05] <jepler> ok thanks for the clarification.
[22:37:20] <skunksleep> pcw_home:
http://bbs.homeshopmachinist.net/threads/70499-Home-shop-CNC-lathe?p=1052622#post1052622
