Recent changes & dhmk

Tue Jan 2 14:47:04 UTC 2018

¡Hola Pino!

El 2017-12-29 a las 12:41 +0100, Pino Toscano escribió:
> I would like to know why you are switching all the packages away from 
> dhmk to "pure debhelper".  Sadly, the commit messages do not explain it 
> at all (and they are even hidden from changelog, "Gbp-Dch: Ignore"), 
> and I do not see any discussion here about this.

Because dhmk hasn't been maintained in quite a while (it supports things up to 
compat 7, afaicr), it doesn't support bin and indep targets, it raises the 
entry bar for contributions, and it's a build system that nobody else is 
using.

The discussion about this was initiated as part of the BUILD_QCH=ON 
change:
2017-08-01 09:13:46     maxy    Mmh, should we enable the QCH generation in frameworks? (https://frinring.wordpress.com/2017/06/19/adding-api-dox-qch-files-generation-to-kde-frameworks-builds/)
2017-08-01 09:28:38     maxy    The major downside is that dhmk doesn't support indep builds and this increases the build time considerably.
2017-08-01 09:34:55     maxy    I'm considering replacing dhmk back dh for buster, btw.
2017-08-01 09:49:34     Riddell oh I see, dhmk more hassle than it's worth?
2017-08-01 09:53:05     maxy    dhmk works fine, except for things that are missing (indep support, and maintainers), dh has been adopted by the great majority of projects and it using would reduces the barrier.
2017-08-01 09:54:19     maxy    So, instead of spending time adding the missing features to dhmk, I would prefer to spend it improving the kde/kf5 debhelper addons , and use those instead
2017-08-01 10:12:01     Riddell yeah makes sense
2017-08-01 18:57:45     themill maxy: istr one of the motivations of dhmk was 
to reduce compilation time when hacking on a package by not 'clean'ing so 
much. I can't say I ever really understood why that was needed (as opposed to just dpkg-buildpackage -nc or d/rules build) but never really looked at it.
2017-08-01 18:58:01     themill maxy: +1 for not having a special snowflake buildsystem though
2017-08-02 09:08:14     lisandro        themill, maxy: MoDaX will surely know better, but considering KDE stuff has been splitted so much and that dh has improved in quite a lot of things, maybe it's not a bad idea after all
2017-08-02 09:09:19     svuorela        themill: dh couldn't rebuild stuff. I don't know if it has learnt it yet.
2017-08-02 09:09:43     lisandro        oh
2017-08-02 09:09:59      *      lisandro was always "out of sync" with that part of the team's tools
2017-08-02 09:10:49     svuorela        if a part had succeded once and recorded in the .log file, it wouldn't be attempted again.
2017-08-02 09:11:04     svuorela        I know nthykier was considering changing it, but I don't know if he has.
2017-08-02 09:20:13     themill svuorela: I don't understand
ur CI
2017-08-02 09:23:24     svuorela        themill: what you don't understand ?
2017-08-02 09:23:33     themill the problem
2017-08-02 09:24:20     svuorela        themill: at least back in the days, the dh build system when executing e.g. the 'build' step, it wouldn't actually go to execute '
make' if it had succeeded 'make' in the past.
2017-08-02 09:24:46     svuorela        it kept its own state files
2017-08-02 09:25:02     themill debhelper.log or some other file?
2017-08-02 09:25:29     svuorela        yeah
2017-08-02 09:25:56     themill deleting lines out of them worked, I though
2017-08-02 09:26:08     themill but as you say, debhelper.log is no longer in any case
2017-08-02 09:26:36     svuorela        maybe. but deleting lines out of them is just too much hassle
2017-08-02 09:26:39     svuorela        to get right
2017-08-02 09:26:45     svuorela        and to remember to get in all of them
2017-08-02 09:26:51     themill compared to making a new sequencer?
2017-08-02 09:27:00     svuorela        debian/rules build *needs* to ensure make is run.
2017-08-02 09:27:24     svuorela        if it hadn't been for the new sequencer, we would have stayed on cdbs
2017-08-02 09:28:22     svuorela        doing a new sequencer was a one time job
2017-08-02 09:29:02     themill sort of.... up to the point of maintaining it forever
2017-08-02 09:29:18     themill Not my idea of fun, that's for sure. Glad other people enjoy that
2017-08-02 09:29:50     themill I'd trust my awk to delete the second half of the log file over my make to get that to work
2017-08-02 09:31:01     svuorela        with the much smaller packages, it might not be that much of a problem any longer, but in the past where it was a 4h job to build
the packages, just running clean for the fun of it was not something that would keep anyone around
2017-08-02 09:32:55     themill yeah
2017-08-02 09:33:39     themill I've not checked recently whether the kde build tools play nicely with ccache yet. Always annoyed me that they didn't
2017-08-02 09:36:45     svuorela        I've had less of an issue with ccache, because most of my stuff has been for build ; change ; build changes.
2017-08-02 09:37:02     svuorela        and that's not where ccache comes in handy. it is when you do build ; clean ; build
2017-08-02 09:37:39     lisandro        svuorela | with the much smaller packages, it might not be that much of a problem any longer, ← I suspect the same
2017-08-02 09:37:51     lisandro        but again, just suspicions
2017-08-02 09:37:58     lisandro        or however it is wrote :-P
2017-08-02 09:39:32     themill moc (or was it rcc) used to guarantee cache misses every time
2017-08-02 09:39:53     svuorela        themill: I think my repreducible fixes for those tools have gotten that.
2017-08-02 09:40:11     svuorela        (my and others fixes=
2017-08-02 09:40:13     themill yeah, I wondered if that might be a nice side-effect of the r-b work
2017-08-02 09:40:33     svuorela        some of them embedded timestams (in a comment)
2017-08-02 09:40:39     themill yes
2017-08-02 13:25:24     lisandro        maxy, themill, svuorela: nthykier | lisandro: Ack, I do recognise that from context.  Compat 10 fixes part of the problem and you
can "opt-in" to even "better" support.  But the default is stuck until we can compile packages without needing (fake)root for the binary target (i.e. we canjust call "d/r
ules binary" and not "d/rules build" + "fakeroot d/rules binary")
2017-08-02 13:30:14     lisandro        hope that makes sense
2017-08-02 13:50:39     lisandro        and also: nthykier | lisandro: --without build-stamp is what you are looking for

In the next uploads I was planning to switch to compat 11, and --without build-stamp.

About the debian/changelog I considered this change only relevant to us, and 
not to the users.

> So far, switching only causes regressions, like overlinking (since dhmk 
> takes care of adding as-needed).

Thanks for checking this, I guess we can add a compulsory:

export DEB_LDFLAGS_MAINT_APPEND := -Wl,--as-needed

Happy hacking,
-- 
"If you can't write it down in English, you can't code it." -- Peter Halpern
 Saludos /\/\ /\ >< `/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20180102/21cb1ce9/attachment.sig>