| 5 Feb 2021 |
 dxld | and you'd have to look at the currently installed stuff to get the transitive deps anyways | 21:03:48 |
 emorrp1 | maybe worth writing up the problem description and posting to the -backports list for discussion, with a separate reply for the maybe solutions - it's not really a generic apt problem, it really is specific to backports under a certain use case | 21:04:34 |
| dxld | oh I didn't know there's a list just for backports | 21:05:01 |
| emorrp1 | https://lists.debian.org/debian-backports/ | 21:06:07 |
| dxld | got it, thanks | 21:07:14 |
| emorrp1 | there's not usually much discussion about how to manage backports itself, mostly just package-specific issues | 21:07:44 |
| dxld | I was going to send this to d-devel, not sure that wouldn't explode badly though :) | 21:08:31 |
| emorrp1 | I tried to imagine the feature being used in maybe testing/unstable hybrids and didn't think it fit, but sure you might get more ... discussion ... on the main -devel | 21:10:10 |
| emorrp1 | * I tried to imagine the feature being used in maybe testing/unstable hybrids and didn't think it fit, but sure you might get more ... discussion ... on the main list | 21:10:26 |
| dxld | I think I'll try backports first, can always repost on d-d | 21:11:33 |
| dxld | testing/unstable hybrids might be another use-case to keep in mind | 21:12:56 |
| dxld | in the case where a target-release is defined I think you'd run into the same prio problem just with 990/500 instead of 990/100 as with backports | 21:13:28 |
|  grove joined the room. | 23:38:42 |
| 7 Feb 2021 |
|  jwest23 left the room. | 01:02:22 |
| emorrp1 | dxld: timely example that might be wider known than synapse debhelper 13.3.1~bpo10+1 needs to add dwz from backports | 07:40:18 |
| dxld | emorrp1: I dunno if that is a good example since you wouldn't necessarily need to have that updated by u-a | 11:56:19 |
|  Mark joined the room. | 16:25:14 |
|  faust left the room. | 19:16:50 |
| dxld | emorrp1: I just finished building a standalone reproducer for this problem if in case you want to play with it: https://salsa.debian.org/dxld-guest/backport-deps-repro/-/blob/master/repro.sh | 19:29:42 |
| dxld | * emorrp1: I just finished building a standalone reproducer for this problem in case you want to play with it: https://salsa.debian.org/dxld-guest/backport-deps-repro/-/blob/master/repro.sh | 19:30:12 |
| emorrp1 | dxld: I'm starting to wonder if it's a known issue, apparently for sbuild to work with backports you need to add --build-dep-resolver=aptitude, so from your repro can you run apt upgrade and it fails, but aptitude upgrade succeeds? | 19:51:48 |
| dxld | did you try with aptitude? | 19:52:19 |
| emorrp1 | no (certainly not with your repro.sh), but I might be able to on my laptop which is probably still on the old version | 19:53:15 |
| dxld | hmm, just doing s/apt-get/aptitude/ then presents me with a couple of prompts and if I do it right it then asks if I want the new version from backports | 19:53:44 |
| dxld | is there another option that the sbuild resolver adds to automate this or something? | 19:54:02 |
| emorrp1 | almost certainly using DEBIAN_FRONTEND=noninteractive which would select the default for those prompts | 19:56:51 |
| dxld | not sure DEB_FE has anything to do with those prompts, adding it certainly doesn't make em go away :) | 19:58:42 |
| dxld | looking at AptitudeResolver.pm the only relevant thing it's doing is passing -y and a bunch of -o ProblemResolver options | 20:03:27 |
| dxld | copying that over just makes aptitude remove the dummy package though, yeah thanks aptitude :P | 20:03:50 |
| dxld | * copying that over just makes aptitude remove the stub package though, yeah thanks aptitude :P | 20:03:56 |
