[08:11] what is needed to make ubuntu-dev-tools (reverse-depends) work with hirsute? [08:16] doko: I think tumbleweed has to do some updates on ubuntuwire at least? [08:17] Hi, groovy's rsync misbehaves (https://github.com/WayneD/rsync/issues/109), but if I build the groovy package locally in focal with dkpg-buildpackage, rsync then works fine! [08:17] Any clues on how to troubleshoot rsync runtime issues when they're caused by the build environment? [08:23] I just tested, focal's rsync, when built on groovy, misbehaves as well. Something in the build environment upgrade, from focal to groovy, breaks rsync. [08:24] I've no idea where to file such a bug report, "build environment breaks rsync" is too generic, and rsync upstream closed the issue that I filed there with "not an rsync issue" [08:50] kanashiro: could you have a look at ruby in hirsute? e.g. installation of b-d's for libprelude are broken (ruby-rubygems) [08:59] mwhudson: looks like the autosyncs made golang 1.15 the default. do you want to go with this, or delay that until 1.16? [11:04] alkisg: if rsync is broken on Groovy, I'd file a bug against rsync in Ubuntu with steps to reproduce [11:04] It can always be moved later [11:05] Sounds like something to do with a glibc difference to me [11:41] cpaelzer: looks like we started a postgres transition with the syncs [11:45] Thank you rbasak, doing so [12:02] I have no capacity to do PG-13 now and from my last check (not too long ago) way too many deps aren't ready yet [12:03] doko: did you mean PG-13 or just 12.4-3 ? [12:04] if it is PG-13 we ahve to remove things from hirsute as of now and revisit ~january [12:04] 13 [12:04] last time the depending projects needed ~1year to pick up PG-12 as needed [12:04] the component mismatches [12:04] see the ... [12:04] Debian allows multiple postgres versions which is why they can slow-roll [12:04] we don't and would like to have one, but one working [12:04] therefore PG-12.x it is (for now) [12:05] then please fix postgresql-common [12:05] I'm happy if PG-13 turns out to be way less transition pain than what PG-12 was [12:08] I'll need to talk to Myon [12:08] gladly I'm totally overloaded right now :-/ [12:08] thanks for the ping thou @doko [12:13] I'll either tune back 13->12 in postgresql-common OR try to find time to get things moving [13:41] seb128, thanks for sane-backends fix, can you please also forward the patch to the Debian bug? I think Debian maintainer is doing a different fix... not sure which one is better (or if they are both needed) [13:42] LocutusOfBorg, the patch is more a workaround, I didn't want to start creating the lock from code and then have to do with group membership etc [13:42] it can probably be overwritten with a fix from upstream or Debian when they have one [13:44] seb128, https://jff.email/cgit/sane-backends.git/commit/?id=736573a8db4bd098da28a4831ce4c601f880aacd [13:44] this is the fix mentioned on the Debian bug [13:45] looks "sane" enough to me (sorry for the pun) [13:45] LocutusOfBorg, that's not going to work, /var/lock is not a persistent dir [13:45] (that was mentioned on the Debian bug) [13:45] the file is going to not be there anymore after a restart [13:46] ack thanks [14:04] I'm going to start Qt 5.14 → 5.15 transition in a few hours. If something is entangled with it and I should wait, please let me know. [14:22] mitya57: we currently have a broken ruby, e.g. no gems can be built [14:25] doko: I hope that won't be a problem for Qt [14:39] mitya57, what about doing it in bileto? [14:39] the queue is really huge, not sure if entangling will help in making it faster, specially for autopkgtests [14:40] I would like also to do haskell and ocaml and nodejs, but I prefer to wait some more days [14:40] or is it already ready to land? [14:41] in that case, meh :D === cpaelzer__ is now known as cpaelzer [15:00] LocutusOfBorg: I have started the work in Bileto (4316), but I want to publish it today because otherwise Qt will be autosynced from Debian (and it will be worse because it needs bootstrapping). [15:01] oh... [15:01] so better publish :) [16:13] Missing build dependencies: fonts-urw-base35 (< 20170801.1.0~) [16:15] tkamppeter: ^^^ ghostscript needs an update, everything b-d on ghostscript can't be built [16:16] doko, OK, I think Debian has done this already, so I will take over what Debian did, or better merge their GS. [16:17] ta === Pici` is now known as Pici === ijohnson is now known as ijohnson|lunch [17:58] I managed to pinpoint the issue better: AC_CHECK_FUNC(lchmod) says "checking for lchmod... yes" in Ubuntu 20.10, while it said "no" in 20.04. [17:58] But from what I understand, lchmod isn't supported in Linux (and it's failing when /proc isn't mounted), so that would be a bug in coreutils? [18:07] https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1902109 [18:07] Launchpad bug 1902109 in rsync (Ubuntu) "rsync uses lchmod and fails in Ubuntu >= 20.10" [Undecided,New] === _hc[m] is now known as _hc [18:56] doko: speaking about ruby, maybe it's better to remove ruby-defaults 1:2.7+2 from groovy-proposed until rubygems is built? [18:57] That version doesn't seem to have major changes apart from the change that broke it. So 1:2.7+1 should work fine. [18:59] kanashiro: ^^^ [19:06] Btw it's also broken in Debian, see Debian #972490 [19:06] Debian bug 972490 in src:rubygems "rubygems_3.2.0~rc.1-2_all-buildd.changes REJECTED" [Serious,Open] http://bugs.debian.org/972490 [19:35] tkamppeter, I can do ghostscript if you want [19:42] syncing/merging [19:55] tkamppeter, looks like the sync built just fine on ppc64el [19:55] so no more delta [19:56] what is your opinion? [20:14] doko: I was waiting for a name for Hirsuite, to do distro-info updates. But it seems we've got it now === ijohnson|lunch is now known as ijohnson [21:10] [y5kvpn7km] (unsupported message type)