[03:52] <Eickmeyer[m]> Can we get another set of eyes on https://code.launchpad.net/~ubuntustudio-dev/+git/ardour ? teward and I are kinda stumped as to why debhelper isn't populating packages.
[03:52] <Eickmeyer[m]> Log file here in my PPA: https://launchpad.net/~eeickmeyer/+archive/ubuntu/ppa/+build/18604635
[03:54] <teward> or more specifically
[03:54] <teward> why the built binaries aren't picked up
[03:54] <teward> in the ardor package.
[03:54] <teward> ardour*
[05:02] <infinity> teward: You almost certainly want override_dh_auto_install, not override_dh_install.
[05:03] <infinity> teward: auto_install is the one that attempts to rnu "make install" or equivalent.
[05:03] <teward> Eickmeyer[m]: ^
[05:03] <Eickmeyer[m]> infinity: On it. Thanks.
[05:04] <teward> Eickmeyer[m]: running that in sbuild locally atm
[05:04] <teward> infinity: thanks for the extra set of eyes, this package is a tad janky :P
[05:05] <Eickmeyer[m]> infinity: Interestingly enough, that package came straight from Debian, and the rules file is only slightly modified.
[05:20] <roadmr> is there a way to find how popular a given .deb package is? even a ballpark figure will suffice, if possible.
[05:29] <Eickmeyer[m]> infinity: Per teward, that FTBFS on his system.
[05:29] <teward> trying to get builds up
[05:30] <Eickmeyer[m]> still testing with my PPA.
[05:30] <teward> https://paste.ubuntu.com/p/D3dnpvCY9v/ <-- excerpt of the 36k lines of logs where it fails
[05:30] <teward> i wonder if this indicates an issue with the *package itself*
[07:51] <Laney> vorlon: suspicious that the no-change rebuild for the new libffi broke it
[07:54] <Laney> seems better with everything from focal-proposed
[08:18] <doko> so is the arm64 kernel working again in -proposed?
[08:18] <doko> otoh I'm told that I shouldn't use all-proposed=1, but figure out the triggers ;p
[08:20] <doko> the libffi build didn't break it, no
[09:24] <rbalint> sil2100, i've hinted the wrong version of gvfs, could you please fix it? https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/378016
[09:25] <seb128> rbalint, sil2100 , I think there is a real problem with gvfs tests now, that skip feels wrong
[09:26] <rbalint> seb128, is there a problem with gvfs or just with the tests?
[09:28] <seb128> rbalint, I don't know, I've been pocking a bit earlier but didn't get to the bottom of it yet
[09:28] <seb128> rbalint, webdavs tests are hanging, they were failing earlier because of the libssl changes and the test certificate being too weak, but I got that fixed yrsterday
[09:28] <seb128> now they are to hang
[09:28] <seb128> which feels like might be another certificate/ssl problem
[09:29] <rbalint> seb128, sounds like a badtest, still
[09:32] <seb128> rbalint, well unless the gvfs webdav code has some real issue with recent libssl...
[09:33] <seb128> and that webdav access would hang the same way on a real system than it does in the tests
[09:38] <rbalint> seb128, it is reproducible locally in qemu
[09:38] <rbalint> seb128, could you please find out if it is a test bug or a real issue?
[09:39] <rbalint> seb128, gvfs holds back the libnfs migration and the package set keeps collecting new ones with syncs
[09:40] <seb128> rbalint, trying but I'm in CapeTown and travelling back a bit later
[09:41] <seb128> rbalint, I think it's fine to ignore the tests to unblock libnfs since we already did that and the current focal gvfs is already buggy so it's not like we forcing a regression in
[09:41] <seb128> but then we should fix the issue/tests
[09:43] <rbalint> seb128, sure, later then
[09:43] <rbalint> sil2100, ^
[09:46] <sil2100> seb128: thanks for looking into this
[09:46] <sil2100> rbalint: ACK
[09:46] <sil2100> rbalint: ah, crap, all those version numbers just blurred for me yesterday
[09:51] <rbalint> sil2100, you see, i had the same problem :-)
[10:02] <Laney> doko: works if I add pygobject and gobject-introspection from proposed
[10:07] <doko> Laney: could you do that for the other pygobject related stuff as well?
[10:09] <Laney> will I make broken stuff migrate?
[10:09] <Laney> feel like we should make those two become candidates first
[10:09] <Laney> or
[10:09] <Laney> ?
[10:10] <doko> pygobject triggered tests block libffi
[10:11] <Laney> I guess they'd get blocked by the transition anyway right?
[10:11] <Laney> yeah
[10:11] <Laney> ok
[10:21] <doko> there's still some haskell stuff
[10:21] <doko> ghc encodes libffi into every package whether it needs it or not
[10:25] <waveform> rbasak, what's your preference for the commit updating the changelog? Should I drop the PPA bump commits and revise the entry in a new commit at the end, or rebase the history so the changelog was "always" correct?
[10:30] <rbasak> waveform: I would prefer to be given a branch tip that has everything correct including the changelog ready for upload, but I'm happy to be given a commit hash of a preceding commit instead. Personally I don't bother committing the PPA changelog bumps, leaving those in a dirty worktree instead.
[10:32] <waveform> rbasak, no prob - I'll chop those PPA bumps and stick a commit on the tip that fixes up the changelog for upload
[10:32] <rbasak> Thanks!
[10:50] <waveform> rbasak, done - branch tip at https://code.launchpad.net/~waveform/ubuntu/+source/u-boot/+git/u-boot/+ref/focal-clean-up should be upload-ready
[10:57] <juliank> doko: Ok, let's talk here, it seems that the tests are stuck in /usr/bin/mpirun -np 4 ./ams_driver -solver 5 -tol 1e-4
[10:57] <juliank> Thoug stuck might be the wrong word - there are 4 ams_driver processes, each using 400% CPU
[10:58] <juliank> I rebuilt the tests with -g and gdb'ed in
[10:58] <juliank> and straced
[10:58] <juliank> they did not make any syscalls, but were in exec_blas_async_wait
[10:58] <doko> ginggs: ^^^
[10:59] <doko> juliank, even with the debug build?
[11:00] <juliank> doko: if you mean the -g build I made, then yes
[11:00] <juliank> doko: Without -g, I could not get any backtrace at all
[11:01] <rbasak> waveform: ack, will look at it shortly
[11:06] <doko> juliank, so it also failed with openmpi 3
[11:08] <rbasak> waveform: since 2019.07+dfsg-1ubuntu4 is in focal-proposed and that version is "burned" I believe it should remain in the changelog as its own entry, and your ubuntu5 changelog entry should only mention changes from ubuntu4.
[11:08] <rbasak> Unless someone here disagrees with me?
[11:08] <juliank> doko: it did?
[11:08] <rbasak> Otherwise it's confusing
[11:09] <rbasak> Single source of truth being Launchpad and all that
[11:09] <rbasak> The changelog history should try to match Launchpad's history where possible
[11:10] <rbasak> (and when it makes sense, ie. maybe not for backports etc)
[11:10] <juliank> sil2100: re: your retry of hypre with openblas/0.3.7+ds-1  - that does not work, it still pulled in openblas/0.3.7+ds-7, as the version is more or less ignored
[11:10] <doko> juliank: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/h/hypre/20200101_130655_5e13f@/log.gz  succeeded with 4.0.2
[11:10] <sil2100> juliank: I know
[11:11] <sil2100> juliank: that retry was a fluke
[11:11] <juliank> ok
[11:11]  * juliank retries that stuff with hello, usually
[11:11] <juliank> :D
[11:11] <juliank> doko: yes it succeeded with 4.2, but it also did with openmpi/3.1.3-11build2
[11:12] <rbalint> juliank, i think apt 1.9.7 broke unattended-upgrades autopkgest :-\
[11:12] <juliank> rbalint: hmm
[11:12] <doko> well, yes, it's openblas
[11:12] <rbalint> juliank, or .6
[11:13] <juliank> last it worked with -1
[11:13] <juliank> so you'd expect it to have broken between -1 and -3
[11:13] <juliank> -3 is same as -2
[11:14] <juliank> but all -2 did was build more variants
[11:15] <juliank> We use libopenblas0-pthread on the tests
[11:17] <juliank> doko: Wondering if i should recompile -1 and then retest against that, it _should_ have the same result
[11:19] <juliank> 2019-11-01 13:04:11 UTC is when it started failing
[11:22] <juliank> It seems to be trying to unlock a mutex in a loop
[11:24] <doko> juliank: rebuilding openblas?
[11:24] <juliank> yeah
[11:24] <doko> but that's what ginggs already tried?
[11:24] <juliank> ah?
[11:26] <sil2100> I don't think he did, at least not on the bug he filled in
[11:26] <sil2100> I mean, maybe he did, but not documented it on the bug
[11:29] <sil2100> GunnarHj: hello o/
[11:30] <GunnarHj> Hi sil2100!
[11:30] <sil2100> GunnarHj: sorry to bother you in the morning, but did you see my e-mail regarding translation updates for .4? :)
[11:31] <sil2100> I pushed all the langpacks to bionic-proposed already if anything
[11:31] <waveform> rbasak, okay - second try - amended the changelog commit at the tip of https://code.launchpad.net/~waveform/ubuntu/+source/u-boot/+git/u-boot/+ref/focal-clean-up
[11:31] <sil2100> GunnarHj: would be awesome if you could send out your usual call for testing
[11:31] <sdhd-sascha> hi, does anybody know if i can use `landscape` with 20.04 ? I want to test it with 19.10 but hadn't have luck.
[11:31] <GunnarHj> sil2100: I did. Planning to reply today. (Basically agree.)
[11:32] <sil2100> GunnarHj: excellent, thank you!
[11:33] <GunnarHj> sil2100: Sure, I can send the call, but I would like to include some info in it about the possibility that also non-tested languages might end up in -updates.
[11:34] <rbasak> waveform: OK and that's build tested in your PPA, right, apart from the changelog tweak/
[11:34] <rbasak> ?
[11:34] <waveform> rbasak, yup - built successfully against -proposed in https://launchpad.net/~waveform/+archive/ubuntu/u-boot-focal
[11:34] <sil2100> GunnarHj: thanks, yeah, that makes sense. I would still like to discuss that with other release members that were previously driving point-releases (infinity, vorlon), but it's certainly a possibility
[11:34] <GunnarHj> sil2100: Don't want to risk that those who do test feel cheated.
[11:35] <sil2100> +1
[11:35] <rbasak> waveform: you don't want to mention your shebang changes in debian/changelog? :)
[11:35] <rbasak> waveform: maybe worth mentioning that you added a quilt patch
[11:36] <rbasak> waveform: up to you. I'm happy either way.
[11:37] <waveform> rbasak, heh - no, I think I can live without mentioning the shebang - I suppose I could bung in something for d/p/python2.patch - just a mo
[11:38] <waveform> rbasak, amended the tip
[11:39] <rbasak> ack
[11:40] <ddstreet> Laney I think https://code.launchpad.net/~ddstreet/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/377688 is ready, let me know if you'd like to see anything else for it
[11:41] <juliank> So I downgraded libopenblas basically, and that works, the test runs itertions and finishes
[11:41] <juliank> with focal it does not even reach the (end of ?) the first iteration
[11:41] <juliank> s/focal/proposed/
[11:41] <rbasak> waveform: uploaded. Thanks!
[11:41] <waveform> rbasak, thanks :)
[11:43] <rbasak> bryce, kanashiro: so I'd like to publish git-ubuntu from edge into stable now. Lucas, any news on that possible regression? As it's only performance in the merge subcommand that didn't sound like it'd be too bad, any objection to us releasing to stable anyway?
[11:46] <kanashiro> rbasak, it was just a performance issue, I merged another package after that using the same workflow and it was not that bad, so no objections, go ahead
[11:49] <rbasak> OK thanks!
[12:06] <JackFrost> Could I convince someone to merge popcon from Debian, picking up the speedup and fixing LP 1822672 while they're at it?
[12:12] <juliank> doko, sil2100 So switching from libopenblas0-pthread to libopenblas0-openmp makes that test work
[12:13] <doko> so what do we want to test?
[12:14] <ahasenack> rbasak: +1
[12:15] <ahasenack> rafaeldtinoco: net-snmp migrated, what's this ftbfs with frr and how is it related?
[12:15] <juliank> doko: Well, we at least know the bug is somewhere in the pthread implementaiton of openblas now
[12:18] <doko> juliank: I wouldn't mind the omp implemtation
[12:18] <juliank> doko: Wondering if we could just force openmp for hypre on armhf
[12:19] <juliank> but not sure how
[12:19] <juliank> they are using alternatives
[12:19] <juliank> so we could only Breaks: libopenmp0-pthread
[12:20] <juliank> which seems harsh
[12:20] <juliank> or just modify the test, but then systems normally end up different than that
[12:21] <doko> yes, adding the break for the test for that arch, where would you modify the preferred alternative?
[12:24] <juliank> We could also just ignore the failure given that probably there is nobody using hypre on armhf
[12:25] <juliank> I need to get some lunch now
[12:27] <doko> well, sil2100 didn't want to ignore it
[12:36] <rafaeldtinoco> ahasenack: libsnmp35 rdepend only
[12:36] <ahasenack> k
[12:38] <sil2100> doko: I didn't say I didn't want to ignore it, I just didn't feel like I have enough info to make that call without consulting
[12:38] <sil2100> This is why I asked for a second opinion/investigation
[12:40] <sil2100> juliank: ok, thanks for investigating!
[12:40] <sil2100> juliank: could you document that in the bug?
[12:40] <juliank> yes, but let me finish eating first :)
[13:19] <rbalint> juliank, unattended-upgrades autopkgtest failed only in python3-coverage and it is progressing promisingly with all proposed
[13:23] <juliank> doko, sil2100: updated the bug
[13:23] <juliank> rbalint: ack
[13:25]  * sdhd-sascha great, could upgrade two machines with netplan, bond, bridges, zfs, libvirt, kvm, lxd and nfs server to 20.04 without any problems, today :-) +1
[13:26]  * sdhd-sascha And MAAS is still in the same state as before ;-)
[13:27] <rbalint> juliank, the failure is similar to the one observed when the origin collection change was in, if all-proposed lets the tests finish i'd like to include that change again :-)
[13:30] <seb128> vorlon, what's the proper way to add enchant-2 to the i386 whitelist? gspell/i386 depwait on it as things are transitioning from enchant to enchant-2
[13:39] <waveform> juliank, finished test-build for the SRU in LP: #1847587 - any chance you can have a look at that this afternoon? (the branch ref'd in the issue should be correct now)
[13:58] <juliank> waveform: So I've compared it against focal, and there seem to be a few changes compared to that, could you add a list of changes made in the backport relative to focal in the changelog?
[13:59] <juliank> waveform: Because without it, I can't judge whether its intentional or not
[14:00] <ahasenack> rafaeldtinoco: https://code.launchpad.net/~ahasenack/ubuntu/+source/frr/+git/frr/+merge/378042
[14:00]  * rafaeldtinoco reviews right away
[14:00] <juliank> waveform: Well I can for the boot loader argument, but not db/all.db
[14:01] <juliank> waveform: I'd probably keep all the changelog entries between 3.90... and 3.98, then people have a better insight in what was backported, but that's just me
[14:14] <rbalint> juliank, ok, with all-proposed u-u's most tests pass, except for kernel-patterns which imo is a valid bug in apt
[14:18] <rafaeldtinoco> ahasenack: it will take a small while, i want to test it in s390x
[14:19] <rafaeldtinoco> to make sure it works before upload
[14:19] <ahasenack> np
[14:20] <doko> sil2100: ok, could you comment on juliank's analysis in the issue?
[14:24] <juliank> rbalint: I'm not sure what it's about, but I want to rewrite apt's kernel autoremoval handling
[14:27] <rbalint> juliank, just LP: #1607845
[14:34] <juliank> Hmm why did I not merge this into 1.9....
[14:54] <rafaeldtinoco> ahasenack: +1ed
[14:54] <ahasenack> rafaeldtinoco: thx
[14:54] <rafaeldtinoco> nice job on net-snmp
[14:54] <rafaeldtinoco> now i hope it was the golden key last issue
[14:54] <rafaeldtinoco> lol
[15:14] <waveform> juliank, tweaked changelog and rebased branch at https://code.launchpad.net/~waveform/ubuntu/+source/flash-kernel/+git/flash-kernel/+ref/bionic-clean-up - should hopefully make sense now (the commits that modify db/all.db and the boot options include their relevant changelog entries too)
[15:15] <juliank> waveform: LGTM
[15:17] <juliank> waveform: I guess I should update the changelog date to the current date before uploading, because otherwise it's a bit weird
[15:17] <waveform> juliank, heh - good point
[15:20] <juliank> waveform: uploaded
[15:20] <waveform> juliank, thanks!
[16:03] <tjaalton> coreycb: I don't see cinder 15.0.1 in focal
[16:05] <tjaalton> coreycb: besides, the versioning is wrong, it should be -0ubuntu1~19.10.1 or such, -0ubuntu1 is probably what focal will eventually get?
[16:11] <coreycb> tjaalton: yes you're right, we must have missed the final upload. the version for eoan will be correct once we get focal updated. thanks for looking.
[16:25] <sdhd-sascha> hello,
[16:25] <sdhd-sascha> why does nfs-common depends on rpcbind ?
[16:27] <sdhd-sascha> In my case, i only need a nfs client. So i masked the *.service.
[16:31] <Eickmeyer[m]> Can we get another set of eyes on https://code.launchpad.net/~ubuntustudio-dev/+git/ardour ? teward and I are kinda stumped as to why debhelper isn't populating packages. infinity recommended changing dh_override_install to dh_override_auto_install, but that ended in a complete FTBFS.
[16:32] <Eickmeyer[m]> It uses waf as the build system, so that's part of it, but built binaries aren't being picked-up by debhelper for whatever reason.
[16:32] <Eickmeyer[m]> vorlon: Perhaps you have some insight?
[16:32] <teward> FTBFS logs for ^ that are available at http://people.ubuntu.com/~teward/ardour_5.12.0-3ubuntu1_amd64-2020-01-24T05:12:38Z.build btw
[16:33] <Eickmeyer[m]> This is a key package for Ubuntu Studio and has been for years, if not over the past decade.
[16:34]  * Eickmeyer[m] will be afk for a bit, taking son to school
[16:42] <juliank> Eickmeyer[m]: I can have a quick look
[16:42] <juliank> I guess
[16:42] <juliank> Depends on how long it takes to build
[16:42] <juliank> probably too long, seeing it's a huge load of C++
[16:44] <juliank> Eickmeyer[m]: it certainly is wrong now, as override_dh_install does need to call dh_install
[16:44] <juliank> and yes, override_dh_auto_install would have been the right to do
[16:45] <juliank> Eickmeyer[m]: the build log looks good, it's correctly installing stuff
[16:45] <juliank> or at least some of it
[16:46] <juliank> Now what you can see is that all libraries are installed but dpkg-shlibdeps can't find them
[16:47] <juliank> So I'd guess they had an rpath set that was removed or something, given that the libraries are in usr/lib/lib/ardour5/libardour.so.3.0.0  and not the standard search path
[16:48] <juliank> A simple thing to remember is that you basically want to always call the command your override, except for the auto commands
[16:48] <juliank> I see you set LD_LIBRARY_PATH += :$(DEB_DESTDIR)/usr/lib/ardour5/
[16:48] <juliank> but you don't export it, so nothing can use it
[16:49] <juliank> whether it would work - i don't know
[16:49] <juliank> it feels wrong - how will the dynamic linker find stuff at run-time then anyway?
[16:50] <juliank> Summary: The build log looks very good, it just needs fixing of the library search path or library locations or something lie that
[16:53] <teward> juliank: the key problem here is that WAF is the build system, I think that's botching many of the 'standard' mechanisms at play
[16:53] <juliank> teward: Only the dh_auto ones
[16:53] <teward> right
[16:54] <juliank> It's amazing that something in 2020 still uses waf
[16:54] <Eickmeyer[m]> juliank: Just for reference, the d/rules file is almost completely unmodified from the upstream one in Debian that was building correctly for years.
[16:55] <Eickmeyer[m]> I applied a proposed merge request from a month ago that I modified by adding dh_clean -d.
[16:56] <juliank> I have no idea how the Debian rules files works
[16:56] <Eickmeyer[m]> juliank: https://salsa.debian.org/multimedia-team/ardour/merge_requests/1
[16:56] <juliank> given that it does not call dh_install, files should be ending up in debian/tmp and packages empty
[16:57] <Eickmeyer[m]> That's correct, however, it should be picked-up anyhow since it defaults to looking in debian/tmp.
[16:58] <juliank> But dh_install should not have been running
[16:58] <juliank> it's been overridden, and not run in the override target
[16:58] <Eickmeyer[m]> Right, and prior to infinity 's suggestion, it wasn't.
[16:59] <Eickmeyer[m]> I'm doing a rebuild right now in my PPA to demonstrate the previous behavior (override_dh_install vs override_dh_auto_install).
[16:59] <juliank> hmm
[16:59] <juliank> it was called as dh_install -pardour
[16:59] <juliank> now I'm confused
[17:00] <juliank> (in debian
[17:00] <juliank> )
[17:00] <juliank> I don't know why but it sounds like a debhelper bug that was fixed
[17:00] <Eickmeyer[m]> So, the logs that teward gave you are indicative of what happened when override_dh_auto_install was used.
[17:01] <Eickmeyer[m]> However, when override_dh_install was used, it built the binaries but failed to populate the .deb files with said binaries built in debian/tmp.
[17:01] <Eickmeyer[m]> It returned a false successful build.
[17:02] <juliank> Eickmeyer[m]: Yes, as I'd expect. The log I saw that failed was failing the right way
[17:02] <Eickmeyer[m]> Should I update compat to something newer than 10?
[17:02] <cjwatson> When you say "it defaults to looking in debian/tmp", you're talking about a command that isn't being run
[17:02] <cjwatson> AFAICS
[17:03] <juliank> That's what I wrote, didn't I?
[17:03] <cjwatson> Yes, dh_install defaults to looking in debian/tmp, but that doesn't mean anything if it's being overridden in such a way as to cause it not to be run
[17:03] <cjwatson> Right, I'm just trying to clarify since it's not clear that Eickmeyer[m] has understood this
[17:03] <juliank> that was exactly the problem, and infinity's suggestion was absolutely correct as we can see in the new build failure
[17:03] <juliank> as all files are being installed
[17:04] <Eickmeyer[m]> Yes, I understand this, but this wasn't an issue for YEARS before.
[17:04] <juliank> It probably was a bug in debhelper that got fixed or something
[17:04] <cjwatson> I haven't seen the rules file that was in use for years.  Perhaps there was some slight variation
[17:04] <juliank> cjwatson: It had the same problem, but debhelper _somehow_ run dh_install -pardour
[17:05] <cjwatson> https://git.launchpad.net/~ubuntustudio-dev/+git/ardour/log/debian/rules shows plenty of changes to it so it's not like it's been the same all along
[17:05] <juliank> unless it was never uploaded
[17:05] <cjwatson> So https://git.launchpad.net/~ubuntustudio-dev/+git/ardour/commit/debian/rules?id=c3ac15c24f25a88a0c9c7869b2d96a0634ecda82 definitely looks correct and should be put back
[17:05] <juliank> Right, the last version Debian had was using cdbs
[17:06] <Eickmeyer[m]> cjwatson: That one FTBFS, even though the binary packages built.
[17:06] <cjwatson> Sure, but it's still more correct
[17:06] <juliank> So you can't say that this worked before, as it never worked.
[17:06] <juliank> The conversion to dh was essentially unfinished in the packaging repository
[17:06] <juliank> it was never uploaded anywhere
[17:07] <Eickmeyer[m]> That's categorically false. This application USED to be packaged upstream, but got removed 1-11-2020 by vorlon .
[17:07] <cjwatson> *This generation of the packaging machinery* never worked
[17:07] <juliank> Now, what you need to add is
[17:07] <juliank> override_dh_shlibdeps:
[17:08] <juliank>    dh_shlibdeps -l usr/lib/ardour5
[17:08] <juliank> I believe
[17:08] <cjwatson> The thing that was removed had a completely different rules file (I just checked)
[17:08] <cjwatson> That sounds plausible
[17:08] <cjwatson> (Does it need a leading slash though?  The man page example has one)
[17:09] <juliank> maybe
[17:09] <juliank> and maybe no space after -l
[17:09] <juliank> The rules files currently sets LD_LIBRARY_PATH, but does not export it
[17:09] <cjwatson> So dh_shlibdeps -l/usr/lib/ardour5
[17:09] <Eickmeyer[m]> cjwatson: Check that rules file vs https://salsa.debian.org/multimedia-team/ardour vs the pending merge request there.
[17:09] <juliank> It' possible that did the same in cdbs
[17:09] <juliank> Eickmeyer[m]: That one was never uploaded.
[17:09] <juliank> Eickmeyer[m]: this was the last one: https://salsa.debian.org/multimedia-team/ardour/blob/debian/1%255.12.0-3/debian/rules
[17:10] <juliank> Eickmeyer[m]: The version you see in the current branch of the ardour repo there was a WIP
[17:10] <cjwatson> Right, you seem to have branched off an unreleased thing
[17:10] <cjwatson> And then found that it didn't work
[17:11] <cjwatson> Which may be why it's unreleased :)
[17:11] <Eickmeyer[m]> Then I'm clearly in over my head. Without this application, Ubuntu Studio loses all credibility as an operating system for audio production.
[17:11] <cjwatson> Have you considered instead doing the work based on the 1:55.12.0-3 tag?
[17:11] <cjwatson> Rather than based on unreleased stuff on master?
[17:11] <cjwatson> Sorry, the debian/1:5.12.0-3 tag I mean
[17:12] <Eickmeyer[m]> Here's the problem: waf now needs to build against Python 3, and the application itself needs to build against fluidsynth 2. I have patches in place to make that happen.
[17:12] <cjwatson> It's not usual to pull in extra unreleased stuff from master unless it's required and works
[17:12] <juliank> Eickmeyer[m]: Then apply those patches to 5.12.0-3 instead of the WIP master branch
[17:12] <Eickmeyer[m]> I'll go ahead and bring-in the original cdbs-based rules file and see what happens.
[17:13] <cjwatson> I would make a new working git branch starting from the tag corresponding to the last upload
[17:13] <cjwatson> And reapply whatever patches are necessary to that
[17:13] <juliank> or go back to https://salsa.debian.org/multimedia-team/ardour/commit/c7ab456c9bdd81d57f9bfff60d01fcce2e164210
[17:13] <juliank> which seems to include that?
[17:13] <juliank> that ~ python3 support
[17:13] <cjwatson> Don't try to mutate your current master branch (if you will take my advice)
[17:14] <juliank> +1
[17:17] <Eickmeyer[m]> Ok, recloning then.
[17:21] <cjwatson> Why recloning?
[17:21] <cjwatson> git checkout -b focal debian/1:5.12.0-3
[17:21] <cjwatson> or some such, assuming that you have a remote corresponding to the Debian repository
[17:25] <Eickmeyer[m]> It errored, but looks like I was trying to get the wrong tag.
[17:26] <cjwatson> debian/1:5.12.0-3 should be the tag name according to the URL juliank posted above
[17:26] <cjwatson> I haven't actually cloned it to check because rubbish internet connection
[17:27] <Eickmeyer[m]> Actually, it's coming back as debian/1%5.12.0-3
[17:29] <cjwatson> Oh right of course
[17:29] <cjwatson> Sorry, should have actually decoded properly :)
[17:29] <cjwatson> I always tab-complete tag names ...
[19:30] <sdhd-sascha> hi, have here a machine, which want to upgrade from 18.04 to 20.04 ... which has trouble with package resolution...
[19:44] <Eickmeyer[m]> !support | sdhd-sascha
[19:46] <sdhd-sascha> ubottu: oh, ok - what kind of `devel` is here ? i'm from `db`, `backend`, `desktop` and a little bit `web`
[19:47] <sdhd-sascha> Eickmeyer[m]: no, problem -- thank you -- don't need support ;-)
[19:47] <sdhd-sascha> /me just more security, like everywhere ;-)
[19:50] <Eickmeyer[m]> sdhd-sascha: The point is that this is the wrong channel to address your question.
[19:51] <Eickmeyer[m]> sdhd-sascha: And technically you want #ubuntu+1
[19:52] <sdhd-sascha> Eickmeyer[m]: i'm sorry - it's okay. (Just happened some day ago, that i got some push, to do a update. here)
[19:52] <sdhd-sascha> But, no problem. I can figure it out. The #ubuntu is ,mostly, too much talk for me ...
[20:51] <SamWhited> Hi, I was hoping to get a performance fix backported to libseccomp 2.4.x in Ubuntu. Debian has done so here and the patch from 2.5 (which applies cleanly to 2.4) can be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913
[20:51] <SamWhited> Would the correct procedure be to file a bug, or since the maintainers appear to overlap between Debian and Ubuntu for this package, should I just leave it and trust they'll apply the patch in both places? Thanks!
[23:19] <bryce> SamWhited: For backported fixes to stable series, a bug report is generally always involved, so filing one would be a correct procedure, yes, even if the maintainers are involved in both places
[23:19] <bryce> aw rats he left already
[23:43] <Eickmeyer[m]> cjwatson, juliank: Thanks to you both, I now have it working. teward will be sponsoring the upload shortly, and Ubuntu Studio will not being missing its primary DAW in 20.04.
[23:45] <teward> that said, it will need AA intervention because it was removed
[23:46] <teward> and it'll be stuck in NEW otherwise.