#linuxcnc-devel Logs

Nov 08 2021

12:08 AM pere: seb_kuzminsky: think I see the problem, it is caused by my use debuild, the use of d/configure and the clean target. looking at a fix.
12:30 AM pere: seb_kuzminsky: fix in place in my test-dh-install branch, <URL: https://github.com/LinuxCNC/linuxcnc/commit/8dbaa65e5891238165d27ba300ff05c91c4f54dc >.
12:31 AM pere: smoe must have build in a different way, where clean was done before d/configure. I on the other hand build by running d/configure, then 'clean' and finally 'all'. :)
06:12 AM pere: Is there something wrong with <URL: https://github.com/LinuxCNC/linuxcnc/pull/1358 >, or are just the right people busy?
09:09 AM -!- #linuxcnc-devel mode set to +v by ChanServ
10:04 AM seb_kuzminsky: pere: good find! since linuxcnc doesn't have a full set of packaging files in debian/ in the "git clean" state, it might be a bit unusual and delicate in its 'd/rules clean' target - we have to leave behind the files d/configure made
10:05 AM pere: which is part of the reason I want more of d/configure operations to move into d/rules, so it can handle clean more gracefully. :)
10:07 AM seb_kuzminsky: yeah, i can sure see the value of that
10:07 AM pere: I must admit, I do not really see the point of d/configure when d/rules also is a turing complete program.
10:08 AM pere: anyway, did you find any other problems with the dh_install pull request?
10:08 AM seb_kuzminsky: for a long time in the past, our d/configure tweaked the debian directory significantly for building either rtai or rt-preempt packages, which had different package names (
10:08 AM seb_kuzminsky: "linuxcnc" vs "linuxcnc-uspace")
10:09 AM seb_kuzminsky: we'd rewrite d/rules, d/control, d/*.files, and possibly other things i'm forgettings about
10:10 AM seb_kuzminsky: you've come into our project at a sort of simple time, when we have just one "d/configure target", uspace aka rt-preempt, so some of the infrastructure you see are relics from a more complicated past
10:11 AM seb_kuzminsky: i merged 1358, thanks!
10:12 AM seb_kuzminsky: i'll take a look at the other packages in the test-dh-install branch today
10:14 AM pere: :)
11:26 AM seb_kuzminsky: hrm, debian unstable has asciidoc 10.0.1, and our docs don't build :-(
11:33 AM pere: bug in asciidoc?
11:34 AM pere: I build on bullseye myself, have not tested on unstable.
11:34 AM seb_kuzminsky: looks like 10.0.1 doesn't like our docs/src/docbook.conf
11:35 AM seb_kuzminsky: i usually build on bullseye too (and the buildbot builds on buster), but sometimes i test on other distros (in pbuilder)
11:37 AM pere: sound to me like something to fix after the first upload to debian
11:39 AM seb_kuzminsky: uploads build on unstable, don't they? Ah, you mean we should upload to get a spot in the ftp-masters queue, then upload again with the fix before they get to it?
11:42 AM seb_kuzminsky: now i think our docbook.conf is fine, and it's a change in behavior in asciidoc's a2x's "--asciidoc-opts" argument
11:43 AM seb_kuzminsky: it used to accept multiple acsiidoc options, now it accepts one and you invoke it multiple times
11:43 AM pere: exactly.
11:43 AM seb_kuzminsky: old: "--asciidoc-opts="-f this -f that"
11:43 AM pere: I want to get the spot in the queue as soon as possible.
11:43 AM seb_kuzminsky: new: --asciidoc-opts="-f this" --asciidoc-opts="-f that"
11:44 AM seb_kuzminsky: i appreciate that... i'll stop getting sidetracked and try to pay attention to that dh-install pr instead :-)
11:56 AM pere: my po4a effort is just idle work while I wait for the debian fixes to get ready. :)
12:39 PM pere: seb_kuzminsky: I'm trying to match up the english and spanish translation, but without spanish language skills, it is really impossible. :(
12:41 PM pere: is the spanish translator around?
12:45 PM seb_kuzminsky: no, it's been a while since we heard from them
12:46 PM seb_kuzminsky: your d/rules fix looks good! i asked smoe to cherry-pick that commit into the PR, then i'll merge it
12:52 PM pere: smoe is offline this week, so that is a bad idea.
12:53 PM pere: seb_kuzminsky: he asked me to do the upload in his absense.
12:53 PM smoe: Just this weekend :) And just popped back in when github jumped to life.
12:53 PM pere: aha!
12:53 PM pere: then I yield to smoe . :)
12:54 PM smoe: This web client does not allow me to reread your discussion.
12:54 PM pere: I use hexchat myself.
12:54 PM smoe: I feel that the undoing of the deletion is wrong since these files should not exist.
12:54 PM seb_kuzminsky: smoe!
12:55 PM smoe: There was a change of mine to configure that took linuxcnc.install.in and substed that to $(MAIN_PACKAGE_NAME).install
12:55 PM smoe: Is that not probably preferable?
12:55 PM smoe: possibly
12:56 PM smoe: I happily update the branch with whatever you prefer, though.
12:56 PM smoe: Just to make sure I am understood.
12:56 PM seb_kuzminsky: there are no subst variables in linuxcnc.install.in, so i don't think we need to subst it
12:57 PM seb_kuzminsky: i guess it behaves as a rename from the "generic" name to the specific MAIN_PACKAGE_NAME
12:57 PM seb_kuzminsky: but imo doing that with subst rather than mv obscures things a bit
12:57 PM seb_kuzminsky: but that's not really the issue that pere is fixing here
12:57 PM smoe: We can also use cp. I agree.
12:58 PM smoe: Well, if we use cp then we have the install files matching the package name as it needs to be.
12:58 PM pere: well, d/rules clean can not undo what d/configure did, as it kills the d/configure; debuild workflow, as well as kill any 'debuild; debuild' rebuild.
12:58 PM seb_kuzminsky: linuxcnc is unorthodox in that our debian/ directory is not static, it's a build artifact constructed by our debian/configure script
12:59 PM smoe: And if we leave the deletion as I put it then we can adapt the package name and have everything cleaned up afterwards.
01:00 PM smoe: I am not here to defend the deletion for _too long_ . You both think that you have understood what I was after, right? I then happily adapt that branch.
01:00 PM smoe: with Petter's patch.
01:00 PM seb_kuzminsky: if d/rules deletes files generated by d/configure, then we can't run "d/rules clean", because what's left won't be the intended d/* files
01:01 PM seb_kuzminsky: so that breaks building with pbuilder and debuild
01:01 PM seb_kuzminsky: does that make sense? or am i missing something here?
01:02 PM seb_kuzminsky: i think of our d/configure a bit like the recipe you put in d/README.source, but written in bash instead of english :-)
01:02 PM smoe: Where is that facepalm symbol again?
01:02 PM smoe: I got it. Sorry.
01:03 PM seb_kuzminsky: ☺✋
01:03 PM smoe: ;)
01:12 PM pere: seb_kuzminsky: without access to someone who understand the language, I am unable to migrate the existing translations to PO files. I've tried, but am I not able to reformat the translations I do not understand to match the structure of the original text.
01:13 PM seb_kuzminsky: that reminds me, i was supposed to email emc-developers to ask for feedback on this po4a change, i'll do that now and ask for translators at the same time
01:21 PM pere: yeah. :)
01:31 PM seb_kuzminsky: pere: are you on the emc-developers mailing list?
01:35 PM pere: seb_kuzminsky: nope
01:36 PM pere: in fact, the linuxcnc.org web site refuse access from tor, so I have not been able to access it at all.
01:59 PM smoe: I just forwarded the email to @pere
02:05 PM seb_kuzminsky: thanks!
02:07 PM seb_kuzminsky: merged! thanks for all your perseverance on this PR
02:08 PM -!- #linuxcnc-devel mode set to +v by ChanServ
02:08 PM pere: yay!
02:20 PM smoe: Happy!
02:26 PM pere: smoe: perhaps seb_kuzminsky should be an uploader when uploading to Debian?
02:26 PM smoe: He is.
02:27 PM smoe: https://github.com/LinuxCNC/linuxcnc/blob/9251bd89d5ca9b99179e75071c0dfcf0d85e165a/debian/control.top.in#L5
02:27 PM pere: great.
02:27 PM pere: I suggest building the upload on bullseye, until the asciidoc issue is fixed.
02:30 PM smoe: seb_kuzminsky - how close are you to a new git tag?
02:32 PM smoe: I would otherwise create one with the date and git hash as part of the version.
02:41 PM pere: smoe: do you expect to do more uploads while we wait for the ftpmasters to process it?
02:53 PM rene-dev: smoe pere thanks for all the work on the debian stuff!
02:54 PM rene-dev: Im working on a new build system based on cmake, that should simplify a lot of things. But it’s not ready yet.
02:55 PM pere: rene-dev: instead of autoconf?
03:01 PM seb_kuzminsky: i think i have the asciidoc issue mostly fixed locally
03:07 PM rene-dev: Yes. There are just too many problems with autoconf. The first one is, linuxcnc doesn’t even use autoconf properly
03:09 PM pere: why do you think linuxcnc will use cmake properly, when it can not use autoconf properly?
03:09 PM rene-dev: Try to configure with a prefix, it won’t work.
03:10 PM pere: rene-dev: I believe you. just seem like what you describe is a problem solved by training, not new tech. :) will training be given with the new tech?
03:14 PM rene-dev: Cmake is much easier to understand and learn. It’s actually readable. And it’s possible to load the whole project into an ide, and debug stuff.
03:15 PM rene-dev: You are right, sone problems are autotool related in general, some are that linuxcnc uses it badly
03:17 PM rene-dev: https://github.com/machinekit/machinekit/issues/336
03:17 PM rene-dev: This is machinekit, but the same problems apply to linuxcnc. And that was 7 years ago.
05:06 PM jepler[m]: You should have seen the previous system! at least you got an early-2000s style nonrecursive make as your build system (the build of kernel modules aside). Depending how ready the project overall is to give up the kernel-module model (lxrt is a better idea for rtai anyway, in this day and age), the biggest 'make is required' problem is thereby solved. That said, I recognize that the rest of the world moves on and nobody really wants to maintain
05:06 PM jepler[m]: Makefiles; plus the once "beautiful" (to me) design has banished over a decade of, well, use and extension. I'm open to new systems!
05:08 PM jepler[m]: just rationalizing what is there would help too (why are some scripts generated from .in and some by make? ditto some library-ish files? why are the rules for syntaxchecking a python script [to pick one example] repeated instead of centralized, etc. Great opportunities for improvement.
05:14 PM * Tom_L thinks jepler[m] is gettin all nastalgic
06:24 PM seb_kuzminsky: i have no strong opinion on the buildsystem. i admit i have no love for autotools - it's served us well for a long time, and it's always done everything i've wanted it to, but i never really felt fully comfortable with it. that's more a personal failing than a problem with autotools, probably
06:27 PM seb_kuzminsky: i've used cmake a bunch over the years, it's ... fine. we have some meson build stuff in the repo now, i've heard good things about that but never used it myself
07:28 PM smoe: My local build from master does not show any lintian error and so I uploaded it to Debian. A confirmatory email should arrive within the next few minutes. If I did not do some weird mistake then the package will then be queued in in the "new queue" on https://ftp-master.debian.org/new.html somewhen later tonight.
07:28 PM seb_kuzminsky: wooooo!
07:28 PM seb_kuzminsky: thank you smoe!!!
07:30 PM smoe: Yip. Also happy. But thanks go to you guys. Petter and me just helped here and there.
07:30 PM * seb_kuzminsky compulsively clicks reload on ftp-master
07:31 PM smoe: I'll forward the email. And then this needs unbearable extra time until that page is updated.
07:34 PM smoe: Right. The list is the maintainer, so everyone gets the emails. A first confirmation arrived that tells that the package was detected and apparently everything was consistent wrt signatures and file checksums.
09:56 PM linuxcnc-build: build #1521 of 1660.rip-buster-python3 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1660.rip-buster-python3/builds/1521 blamelist: Rene Hopf <renehopf@mac.com>
09:56 PM pere: very glad to see the upload in place. :)
10:09 PM linuxcnc-build: build #1380 of 4041.deb-buster-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4041.deb-buster-rtpreempt-amd64/builds/1380 blamelist: Phillip Carter <phillcarter54@gmail.com>
10:24 PM linuxcnc-build: build #1924 of 1640.rip-buster-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1640.rip-buster-rtpreempt-amd64/builds/1924 blamelist: Rene Hopf <renehopf@mac.com>
10:28 PM linuxcnc-build: build #1272 of 4042.deb-buster-rtpreempt-rpi4 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4042.deb-buster-rtpreempt-rpi4/builds/1272 blamelist: Phillip Carter <phillcarter54@gmail.com>
10:52 PM linuxcnc-build: build #1682 of 1650.rip-buster-rtpreempt-rpi4 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1650.rip-buster-rtpreempt-rpi4/builds/1682 blamelist: Rene Hopf <renehopf@mac.com>
10:52 PM linuxcnc-build: build #8322 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/8322 blamelist: Rene Hopf <renehopf@mac.com>
11:12 PM linuxcnc-build: build #1925 of 1640.rip-buster-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1640.rip-buster-rtpreempt-amd64/builds/1925 blamelist: Phillip Carter <phillcarter54@gmail.com>
11:12 PM linuxcnc-build: build #1522 of 1660.rip-buster-python3 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1660.rip-buster-python3/builds/1522 blamelist: Phillip Carter <phillcarter54@gmail.com>
11:18 PM linuxcnc-build: build #1683 of 1650.rip-buster-rtpreempt-rpi4 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1650.rip-buster-rtpreempt-rpi4/builds/1683 blamelist: Phillip Carter <phillcarter54@gmail.com>
11:18 PM linuxcnc-build: build #8323 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/8323 blamelist: Phillip Carter <phillcarter54@gmail.com>
11:45 PM pere: I notice there is some handling in docs/src/Submakefile to maintain manual pages as asciidoc. why are some manual pages in roff format, and others as adoc?
11:48 PM pere: why not run the following command and maintain them all as adoc? for m in docs/man/man?/* ; do echo pandoc -t asciidoc $m -o $(echo $m |sed s%docs/man%docs/src/man%).adoc; done