Can't have a modified package for both the main and backports
So I was trying to get a newer emacs (27)[1], which should be in the backports. The problem is that the emacs in main (26) is also modified because of debian's allergy to gfdl.
[1] !728 (closed)
This seems like a general issue, where if you want to have a newer version of a package for backports, you have to give up on main and default that to the upstream because there can be only one helper per package.
What would be a good way to relax this awkward limitation?
Attached is some relevant IRC log.
<dragestil> interesting... from the console it looks like it is mainly
attempting to build dictionaries-common, a package helper I added
to satisfy emacs-27's dep requirement, but there's no work with
emacs [23:22]
<dragestil> the failure is a bit cryptic to me - it totally looks different
from running sbuild. I'll take a look tomorrow [23:25]
[Thu Apr 21 2022]
<Ark74> dragestil: you need to add all dependencies independently [01:06]
<Ark74> also the last change (commit) needs to be on the helper
<Ark74> so the builder pick up the change [01:07]
<Ark74> finally backported versions on existing packages need to be on the
backport repository [01:09]
<dragestil> Ark74: OK I'll break the MR into two commits then. What do you
mean by "need to be on the backport repository"? [08:57]
<dragestil> like exact what needs to be done to address this point? [08:59]
<dragestil> what commands does jenkins run? is it in the builder repo? [09:11]
<Ark74> dragestil: take for example kdenline:
https://gitlab.trisquel.org/trisquel/package-helpers/-/blob/nabia/helpers/make-kdenlive
[09:41]
<Ark74> packages should not get replaced for new versions randomly, a good
idea is to add the new versions as part of the backports repository
[09:43]
<Ark74> adding the BACKPORTS=true option on the helpers will allow to complete
that. [09:44]
<dragestil> Oh I did add BACKPORT=true to make-emacs, I'll append the 'S'
[09:46]
<Ark74> or at least I think that is most likely that you MR will be accepted
[09:47]
<Ark74> *that way
<Ark74> jenkins runs the sources build, and also the binaries
<dragestil> ok, I guess I'll find out after splitting the commit
<Ark74> the source are build by running the helper, bash make-$package-name
<Ark74> then the binaries are build on a shcroot jail
<Ark74> *schroot jail [09:49]
<dragestil> ok, that's what I think I did locally. so does jenkins "publish"
correspond to the binary building?
<Ark74> you can create such schroot environments with
https://gitlab.trisquel.org/trisquel/trisquel-builder
<Ark74> and finally it will publish on a testing repository [09:50]
<dragestil> ok, so what does it mean when jenkins dsc succeeds and publish
fails? [09:51]
<Ark74> builds.trisquel.org/ it will look something like this: deb
http://builds.trisquel.org/repos-testing/nabia/ nabia main
<Ark74> dsc is source
<Ark74> Project binary is "binairies" [09:52]
<Ark74> and publish is the repo
<Ark74> seems like there is an issue with reprepro
<Ark74> will report with Ruben on the firday meeting, or sooner if possible
[09:53]
<dragestil> I see
<dragestil> thanks
<Ark74> np
<dragestil> When I do BACKPORTS=true, does that mean the package will only be
available in nabia-backports? [09:55]
<Ark74> yep
<dragestil> ok, but then what happens to the nabia-main emacs? If my change
is merged, does emacs-26 still get build according to the version
1 make-emacs and published in nabia-main? [09:57]
<Ark74> backported packages (new versions) should go there a a rule of thumb
<Ark74> ohh!, emacs, right [09:58]
<Ark74> nope, our current system only allows 1 helper per package
<Ark74> meaning that will overwrite the main one [09:59]
<dragestil> ok, but otoh BACKPORTS=true means the new emacs helper will only
affect the nabia-backports, so main will default to upstream,
without any change?
<Ark74> yeah, in a sense yes [10:00]
<Ark74> the current one, allows to install emacs docs [10:01]
<Ark74> I think I did that
<Ark74> one
<dragestil> right. in general this sounds like a problem. it means we can't
have a helper that modifies both main and backports
<dragestil> or we can't have a package that differs from upstream in main, and
want a newer version in backports [10:02]
<Ark74> yeah, once you know all moving parts you realize it wold need an
overhaul [10:03]
<Ark74> a pending task
<dragestil> ok, I guess we are stuck with emacs26 for now
<dragestil> is the overhaul basically updating the config script in
package-helpers? [10:04]
<trisquel-jenkins> Project gitlab-merge-request build
fix_linux-hwe-5.13_10.0/Update linux-libre tools/Ark74:
SUCCESS in 5.2 sec:
https://jenkins.trisquel.org/job/gitlab-merge-request/863/
<dragestil> assuming it is to fix this specific problem [10:05]
<dragestil> Is there a document mentioning this problem or the overhaul in
general?
<Ark74> well, more repository overhaul
<Ark74> I guess you might want to join the dev meeting on friday
<dragestil> I wish I could, but I'm based in Australia [10:06]
<Ark74> ohh
<dragestil> the meeting happens when I'm asleep
<Ark74> well, we are already into aramo (t11) [10:07]
<dragestil> and? [10:08]
<Ark74> it has enough challenges so far, but it wouldn't hurt to review that
<dragestil> I don't quite understand, you mean the overhaul or T11? [10:09]
<Ark74> t11
<dragestil> ok, so maybe not enough resources to handle the repo overhaul
[10:10]
<Ark74> please open a issue on the helpers repository and I'll bring that up
on the meeting
<dragestil> ok will do and let you know [10:11]
<Ark74> dragestil: kind of yeah
<Ark74> dragestil: thanks [10:12]
<dragestil> Ark74: my pleasure