¡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 /\/\ /\ >< `/

Attachment: signature.asc
Description: PGP signature

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Reply via email to