[02:18] <karstensrage> i keep trying to upload the signed CoC but its error'ing no public key
[02:18] <karstensrage> (7, 9, u'No public key')
[07:58] <dholbach> good morning
[08:21] <Rhonda> karstensrage: And you have your public key in there?  Btw., #launchpad might be more appropriate for that question.
[11:13] <alkisg> Hi, I want to ship a newer version of my package X, but I want the old postrm to be called with "remove" instead of "upgrade". Will "Conflicts: X (<< 10)" do that?
[12:13] <Rhonda> alkisg: According to the graph on https://wiki.debian.org/MaintainerScripts if the old postrm with remove fails, the new postrm is called with failed-upgrade.
[12:14] <Rhonda> Would that help you?
[12:14] <Rhonda> erm, old postrm with upgrade fails*
[14:27] <karstensrage> Rhonda, thanks, i figured it out, the key has subkeys and gpg was using the wrong subkey... some weirdly hidden feature allows you select the subkey only if you put a ! after the id
[14:29] <karstensrage> i wonder if anyone at gpg has heard about the principle of least surprise
[14:37] <Rhonda> "anyone at gpg", you know it's literally a one-man show? :)
[14:38] <ogra_> didnt he hire someone last year ?
[14:38] <ogra_> :)
[14:42] <Rhonda> I just met him two days ago btw.
[14:42] <Rhonda> fosdem is nice sometimes. :)
[14:42] <ogra_> :)
[14:42]  * ogra_ missed it again this year :(
[14:43] <ogra_> can't do both ... SCaLE and FOSDEM ...
[14:44] <Rhonda> You have to learn to scale better, then. :)
[14:44] <ogra_> haha
[14:44] <karstensrage> wow
[14:44] <karstensrage> no Rhonda i did not know that
[14:44] <karstensrage> anyway it buried in the documentation i really should write a blog post about how useless documentation is
[14:44] <karstensrage> its buried
[14:46] <Rhonda> I always stayed away from subkeys so far.  Never was able to wrap my head around understanding them so far.
[14:47] <karstensrage> yeah maybe a good idea
[15:44] <alkisg> Rhonda: thank you, but the old prerm/postrm don't fail, they exist successfully... When I tried "Conflicts: X (<<10)", I got `(old-)prerm upgrade <new-version>`, while I'm looking for `(old-)prerm remove in-favor <new-version>`...
[15:44] <alkisg> *exit
[15:52] <alkisg> "conflictor's-prerm remove in-favour package new-version"
[16:03] <Rhonda> alkisg: Why would you need to make it being called with remove which you can't work around through some snippets in the new preinst?
[16:04] <Rhonda> Order is: old->prerm upgrade, new->preinst upgrade, old->postrm upgrade, new->postinst configure
[16:05] <alkisg> Rhonda: the old package was programmed by someone else and has some hacks, different per their own version, and I don't want to have to include all their hacks' history in my preinst code...
[16:05] <alkisg> Rhonda: I'm reading this: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact
[16:05] <alkisg>  The prerm script may be called in the following ways:
[16:05] <Rhonda> Only for a release (or the releases that are supported to upgrade from)
[16:05] <alkisg> conflictor's-prerm remove in-favour package new-version
[16:06] <Rhonda> Don't read the policy, looking at the graph is so much more sane.  :)
[16:06] <alkisg> ...that's what I'm trying to reproduce by the appropriate conflict/breaks/replaces directives, but I can't
[16:06] <alkisg> The graphs state that they don't cover the "conflicts" case
[16:07] <Rhonda> So, maybe the oldhacks in those scripts are obsolete by now anyway?  Aren't they version bound?
[16:07] <alkisg> And they link to another site, which also has graphs, but explains "conflicts" in a text-only section...
[16:10] <alkisg> I could call their own prerm script with "remove", if conflicts: can't call `prerm remove`, but that sounds hackish on my part... :/
[16:10] <alkisg> I.e. find it at /var/lib/dpkg/info...
[16:23]  * alkisg ends up reading dpkg/src/unpack.c...
[16:23] <alkisg> "conflictor" is the older version, right?
[16:43] <alkisg> I got it working *if* I use a different package name... with conflicts+replaces
[16:43] <alkisg> This then does call `prerm remove in-favour`
[16:57] <alkisg> Changing the package name back to the original changes the behaviour, it passes "update" instead of "remove", so no-go