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