/srv/irclogs.ubuntu.com/2020/01/24/#ubuntu-devel.txt

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/1860463503:52
tewardor more specifically03:54
tewardwhy the built binaries aren't picked up03:54
tewardin the ardor package.03:54
tewardardour*03:54
infinityteward: You almost certainly want override_dh_auto_install, not override_dh_install.05:02
infinityteward: auto_install is the one that attempts to rnu "make install" or equivalent.05:03
tewardEickmeyer[m]: ^05:03
Eickmeyer[m]infinity: On it. Thanks.05:03
tewardEickmeyer[m]: running that in sbuild locally atm05:04
tewardinfinity: thanks for the extra set of eyes, this package is a tad janky :P05:04
Eickmeyer[m]infinity: Interestingly enough, that package came straight from Debian, and the rules file is only slightly modified.05:05
roadmris there a way to find how popular a given .deb package is? even a ballpark figure will suffice, if possible.05:20
Eickmeyer[m]infinity: Per teward, that FTBFS on his system.05:29
tewardtrying to get builds up05:29
Eickmeyer[m]still testing with my PPA.05:30
tewardhttps://paste.ubuntu.com/p/D3dnpvCY9v/ <-- excerpt of the 36k lines of logs where it fails05:30
tewardi wonder if this indicates an issue with the *package itself*05:30
=== cpaelzer__ is now known as cpaelzer
Laneyvorlon: suspicious that the no-change rebuild for the new libffi broke it07:51
Laneyseems better with everything from focal-proposed07:54
dokoso is the arm64 kernel working again in -proposed?08:18
dokootoh I'm told that I shouldn't use all-proposed=1, but figure out the triggers ;p08:18
dokothe libffi build didn't break it, no08:20
rbalintsil2100, i've hinted the wrong version of gvfs, could you please fix it? https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/37801609:24
seb128rbalint, sil2100 , I think there is a real problem with gvfs tests now, that skip feels wrong09:25
rbalintseb128, is there a problem with gvfs or just with the tests?09:26
seb128rbalint, I don't know, I've been pocking a bit earlier but didn't get to the bottom of it yet09:28
seb128rbalint, 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 yrsterday09:28
seb128now they are to hang09:28
seb128which feels like might be another certificate/ssl problem09:28
rbalintseb128, sounds like a badtest, still09:29
seb128rbalint, well unless the gvfs webdav code has some real issue with recent libssl...09:32
seb128and that webdav access would hang the same way on a real system than it does in the tests09:33
rbalintseb128, it is reproducible locally in qemu09:38
rbalintseb128, could you please find out if it is a test bug or a real issue?09:38
rbalintseb128, gvfs holds back the libnfs migration and the package set keeps collecting new ones with syncs09:39
seb128rbalint, trying but I'm in CapeTown and travelling back a bit later09:40
seb128rbalint, 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 in09:41
seb128but then we should fix the issue/tests09:41
rbalintseb128, sure, later then09:43
rbalintsil2100, ^09:43
sil2100seb128: thanks for looking into this09:46
sil2100rbalint: ACK09:46
sil2100rbalint: ah, crap, all those version numbers just blurred for me yesterday09:46
rbalintsil2100, you see, i had the same problem :-)09:51
Laneydoko: works if I add pygobject and gobject-introspection from proposed10:02
dokoLaney: could you do that for the other pygobject related stuff as well?10:07
Laneywill I make broken stuff migrate?10:09
Laneyfeel like we should make those two become candidates first10:09
Laneyor10:09
Laney?10:09
dokopygobject triggered tests block libffi10:10
LaneyI guess they'd get blocked by the transition anyway right?10:11
Laneyyeah10:11
Laneyok10:11
dokothere's still some haskell stuff10:21
dokoghc encodes libffi into every package whether it needs it or not10:21
waveformrbasak, 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:25
rbasakwaveform: 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:30
waveformrbasak, no prob - I'll chop those PPA bumps and stick a commit on the tip that fixes up the changelog for upload10:32
rbasakThanks!10:32
waveformrbasak, done - branch tip at https://code.launchpad.net/~waveform/ubuntu/+source/u-boot/+git/u-boot/+ref/focal-clean-up should be upload-ready10:50
juliankdoko: Ok, let's talk here, it seems that the tests are stuck in /usr/bin/mpirun -np 4 ./ams_driver -solver 5 -tol 1e-410:57
juliankThoug stuck might be the wrong word - there are 4 ams_driver processes, each using 400% CPU10:57
juliankI rebuilt the tests with -g and gdb'ed in10:58
juliankand straced10:58
juliankthey did not make any syscalls, but were in exec_blas_async_wait10:58
dokoginggs: ^^^10:58
dokojuliank, even with the debug build?10:59
juliankdoko: if you mean the -g build I made, then yes11:00
juliankdoko: Without -g, I could not get any backtrace at all11:00
rbasakwaveform: ack, will look at it shortly11:01
dokojuliank, so it also failed with openmpi 311:06
rbasakwaveform: 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
rbasakUnless someone here disagrees with me?11:08
juliankdoko: it did?11:08
rbasakOtherwise it's confusing11:08
rbasakSingle source of truth being Launchpad and all that11:09
rbasakThe changelog history should try to match Launchpad's history where possible11:09
rbasak(and when it makes sense, ie. maybe not for backports etc)11:10
julianksil2100: 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 ignored11:10
dokojuliank: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/h/hypre/20200101_130655_5e13f@/log.gz  succeeded with 4.0.211:10
sil2100juliank: I know11:10
sil2100juliank: that retry was a fluke11:11
juliankok11:11
* juliank retries that stuff with hello, usually11:11
juliank:D11:11
juliankdoko: yes it succeeded with 4.2, but it also did with openmpi/3.1.3-11build211:11
rbalintjuliank, i think apt 1.9.7 broke unattended-upgrades autopkgest :-\11:12
juliankrbalint: hmm11:12
dokowell, yes, it's openblas11:12
rbalintjuliank, or .611:12
julianklast it worked with -111:13
juliankso you'd expect it to have broken between -1 and -311:13
juliank-3 is same as -211:13
juliankbut all -2 did was build more variants11:14
juliankWe use libopenblas0-pthread on the tests11:15
juliankdoko: Wondering if i should recompile -1 and then retest against that, it _should_ have the same result11:17
juliank2019-11-01 13:04:11 UTC is when it started failing11:19
juliankIt seems to be trying to unlock a mutex in a loop11:22
dokojuliank: rebuilding openblas?11:24
juliankyeah11:24
dokobut that's what ginggs already tried?11:24
juliankah?11:24
sil2100I don't think he did, at least not on the bug he filled in11:26
sil2100I mean, maybe he did, but not documented it on the bug11:26
sil2100GunnarHj: hello o/11:29
GunnarHjHi sil2100!11:30
sil2100GunnarHj: sorry to bother you in the morning, but did you see my e-mail regarding translation updates for .4? :)11:30
sil2100I pushed all the langpacks to bionic-proposed already if anything11:31
waveformrbasak, 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-up11:31
sil2100GunnarHj: would be awesome if you could send out your usual call for testing11:31
sdhd-saschahi, 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
GunnarHjsil2100: I did. Planning to reply today. (Basically agree.)11:31
sil2100GunnarHj: excellent, thank you!11:32
GunnarHjsil2100: 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:33
rbasakwaveform: OK and that's build tested in your PPA, right, apart from the changelog tweak/11:34
rbasak?11:34
waveformrbasak, yup - built successfully against -proposed in https://launchpad.net/~waveform/+archive/ubuntu/u-boot-focal11:34
sil2100GunnarHj: 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 possibility11:34
GunnarHjsil2100: Don't want to risk that those who do test feel cheated.11:34
sil2100+111:35
rbasakwaveform: you don't want to mention your shebang changes in debian/changelog? :)11:35
rbasakwaveform: maybe worth mentioning that you added a quilt patch11:35
rbasakwaveform: up to you. I'm happy either way.11:36
waveformrbasak, 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 mo11:37
waveformrbasak, amended the tip11:38
rbasakack11:39
ddstreetLaney 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 it11:40
juliankSo I downgraded libopenblas basically, and that works, the test runs itertions and finishes11:41
juliankwith focal it does not even reach the (end of ?) the first iteration11:41
julianks/focal/proposed/11:41
rbasakwaveform: uploaded. Thanks!11:41
waveformrbasak, thanks :)11:41
rbasakbryce, 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:43
kanashirorbasak, 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 ahead11:46
rbasakOK thanks!11:49
JackFrostCould I convince someone to merge popcon from Debian, picking up the speedup and fixing LP 1822672 while they're at it?12:06
ubottuLaunchpad bug 1822672 in popularity-contest (Ubuntu) "popularity-contest is broken due to a bad merge with debian" [Medium,Confirmed] https://launchpad.net/bugs/182267212:06
juliankdoko, sil2100 So switching from libopenblas0-pthread to libopenblas0-openmp makes that test work12:12
dokoso what do we want to test?12:13
ahasenackrbasak: +112:14
ahasenackrafaeldtinoco: net-snmp migrated, what's this ftbfs with frr and how is it related?12:15
juliankdoko: Well, we at least know the bug is somewhere in the pthread implementaiton of openblas now12:15
dokojuliank: I wouldn't mind the omp implemtation12:18
juliankdoko: Wondering if we could just force openmp for hypre on armhf12:18
juliankbut not sure how12:19
juliankthey are using alternatives12:19
juliankso we could only Breaks: libopenmp0-pthread12:19
juliankwhich seems harsh12:20
juliankor just modify the test, but then systems normally end up different than that12:20
dokoyes, adding the break for the test for that arch, where would you modify the preferred alternative?12:21
juliankWe could also just ignore the failure given that probably there is nobody using hypre on armhf12:24
juliankI need to get some lunch now12:25
dokowell, sil2100 didn't want to ignore it12:27
rafaeldtinocoahasenack: libsnmp35 rdepend only12:36
ahasenackk12:36
sil2100doko: 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 consulting12:38
sil2100This is why I asked for a second opinion/investigation12:38
sil2100juliank: ok, thanks for investigating!12:40
sil2100juliank: could you document that in the bug?12:40
juliankyes, but let me finish eating first :)12:40
=== ricab is now known as ricab|lunch
rbalintjuliank, unattended-upgrades autopkgtest failed only in python3-coverage and it is progressing promisingly with all proposed13:19
juliankdoko, sil2100: updated the bug13:23
juliankrbalint: ack13:23
* 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 :-) +113:25
* sdhd-sascha And MAAS is still in the same state as before ;-)13:26
rbalintjuliank, 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:27
seb128vorlon, 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-213:30
waveformjuliank, 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:39
ubottuLaunchpad bug 1847587 in flash-kernel (Ubuntu Bionic) "[SRU] Add entries for Pi 4" [Undecided,Fix committed] https://launchpad.net/bugs/184758713:39
juliankwaveform: 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:58
juliankwaveform: Because without it, I can't judge whether its intentional or not13:59
ahasenackrafaeldtinoco: https://code.launchpad.net/~ahasenack/ubuntu/+source/frr/+git/frr/+merge/37804214:00
* rafaeldtinoco reviews right away14:00
juliankwaveform: Well I can for the boot loader argument, but not db/all.db14:00
juliankwaveform: 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 me14:01
rbalintjuliank, ok, with all-proposed u-u's most tests pass, except for kernel-patterns which imo is a valid bug in apt14:14
=== ricab|lunch is now known as ricab
rafaeldtinocoahasenack: it will take a small while, i want to test it in s390x14:18
rafaeldtinocoto make sure it works before upload14:19
ahasenacknp14:19
dokosil2100: ok, could you comment on juliank's analysis in the issue?14:20
juliankrbalint: I'm not sure what it's about, but I want to rewrite apt's kernel autoremoval handling14:24
rbalintjuliank, just LP: #160784514:27
ubottuLaunchpad bug 1607845 in apt (Ubuntu) "List of versioned kernels is not right for Ubuntu" [Low,In progress] https://launchpad.net/bugs/160784514:27
juliankHmm why did I not merge this into 1.9....14:34
rafaeldtinocoahasenack: +1ed14:54
ahasenackrafaeldtinoco: thx14:54
rafaeldtinoconice job on net-snmp14:54
rafaeldtinoconow i hope it was the golden key last issue14:54
rafaeldtinocolol14:54
waveformjuliank, 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:14
juliankwaveform: LGTM15:15
juliankwaveform: I guess I should update the changelog date to the current date before uploading, because otherwise it's a bit weird15:17
waveformjuliank, heh - good point15:17
juliankwaveform: uploaded15:20
waveformjuliank, thanks!15:20
tjaaltoncoreycb: I don't see cinder 15.0.1 in focal16:03
tjaaltoncoreycb: besides, the versioning is wrong, it should be -0ubuntu1~19.10.1 or such, -0ubuntu1 is probably what focal will eventually get?16:05
coreycbtjaalton: 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:11
sdhd-saschahello,16:25
sdhd-saschawhy does nfs-common depends on rpcbind ?16:25
sdhd-saschaIn my case, i only need a nfs client. So i masked the *.service.16:27
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:31
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
tewardFTBFS logs for ^ that are available at http://people.ubuntu.com/~teward/ardour_5.12.0-3ubuntu1_amd64-2020-01-24T05:12:38Z.build btw16:32
Eickmeyer[m]This is a key package for Ubuntu Studio and has been for years, if not over the past decade.16:33
* Eickmeyer[m] will be afk for a bit, taking son to school16:34
juliankEickmeyer[m]: I can have a quick look16:42
juliankI guess16:42
juliankDepends on how long it takes to build16:42
juliankprobably too long, seeing it's a huge load of C++16:42
juliankEickmeyer[m]: it certainly is wrong now, as override_dh_install does need to call dh_install16:44
juliankand yes, override_dh_auto_install would have been the right to do16:44
juliankEickmeyer[m]: the build log looks good, it's correctly installing stuff16:45
juliankor at least some of it16:45
juliankNow what you can see is that all libraries are installed but dpkg-shlibdeps can't find them16:46
juliankSo 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 path16:47
juliankA simple thing to remember is that you basically want to always call the command your override, except for the auto commands16:48
juliankI see you set LD_LIBRARY_PATH += :$(DEB_DESTDIR)/usr/lib/ardour5/16:48
juliankbut you don't export it, so nothing can use it16:48
juliankwhether it would work - i don't know16:49
juliankit feels wrong - how will the dynamic linker find stuff at run-time then anyway?16:49
juliankSummary: The build log looks very good, it just needs fixing of the library search path or library locations or something lie that16:50
tewardjuliank: the key problem here is that WAF is the build system, I think that's botching many of the 'standard' mechanisms at play16:53
juliankteward: Only the dh_auto ones16:53
tewardright16:53
juliankIt's amazing that something in 2020 still uses waf16: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:54
Eickmeyer[m]I applied a proposed merge request from a month ago that I modified by adding dh_clean -d.16:55
juliankI have no idea how the Debian rules files works16:56
Eickmeyer[m]juliank: https://salsa.debian.org/multimedia-team/ardour/merge_requests/116:56
juliankgiven that it does not call dh_install, files should be ending up in debian/tmp and packages empty16:56
Eickmeyer[m]That's correct, however, it should be picked-up anyhow since it defaults to looking in debian/tmp.16:57
juliankBut dh_install should not have been running16:58
juliankit's been overridden, and not run in the override target16:58
Eickmeyer[m]Right, and prior to infinity 's suggestion, it wasn't.16:58
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
juliankhmm16:59
juliankit was called as dh_install -pardour16:59
julianknow I'm confused16:59
juliank(in debian17:00
juliank)17:00
juliankI don't know why but it sounds like a debhelper bug that was fixed17:00
Eickmeyer[m]So, the logs that teward gave you are indicative of what happened when override_dh_auto_install was used.17:00
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:01
juliankEickmeyer[m]: Yes, as I'd expect. The log I saw that failed was failing the right way17:02
Eickmeyer[m]Should I update compat to something newer than 10?17:02
cjwatsonWhen you say "it defaults to looking in debian/tmp", you're talking about a command that isn't being run17:02
cjwatsonAFAICS17:02
juliankThat's what I wrote, didn't I?17:03
cjwatsonYes, 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 run17:03
cjwatsonRight, I'm just trying to clarify since it's not clear that Eickmeyer[m] has understood this17:03
juliankthat was exactly the problem, and infinity's suggestion was absolutely correct as we can see in the new build failure17:03
juliankas all files are being installed17:03
Eickmeyer[m]Yes, I understand this, but this wasn't an issue for YEARS before.17:04
juliankIt probably was a bug in debhelper that got fixed or something17:04
cjwatsonI haven't seen the rules file that was in use for years.  Perhaps there was some slight variation17:04
juliankcjwatson: It had the same problem, but debhelper _somehow_ run dh_install -pardour17:04
cjwatsonhttps://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 along17:05
juliankunless it was never uploaded17:05
cjwatsonSo https://git.launchpad.net/~ubuntustudio-dev/+git/ardour/commit/debian/rules?id=c3ac15c24f25a88a0c9c7869b2d96a0634ecda82 definitely looks correct and should be put back17:05
juliankRight, the last version Debian had was using cdbs17:05
Eickmeyer[m]cjwatson: That one FTBFS, even though the binary packages built.17:06
cjwatsonSure, but it's still more correct17:06
juliankSo you can't say that this worked before, as it never worked.17:06
juliankThe conversion to dh was essentially unfinished in the packaging repository17:06
juliankit was never uploaded anywhere17:06
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 worked17:07
juliankNow, what you need to add is17:07
juliankoverride_dh_shlibdeps:17:07
juliank   dh_shlibdeps -l usr/lib/ardour517:08
juliankI believe17:08
cjwatsonThe thing that was removed had a completely different rules file (I just checked)17:08
cjwatsonThat sounds plausible17:08
cjwatson(Does it need a leading slash though?  The man page example has one)17:08
juliankmaybe17:09
juliankand maybe no space after -l17:09
juliankThe rules files currently sets LD_LIBRARY_PATH, but does not export it17:09
cjwatsonSo dh_shlibdeps -l/usr/lib/ardour517:09
Eickmeyer[m]cjwatson: Check that rules file vs https://salsa.debian.org/multimedia-team/ardour vs the pending merge request there.17:09
juliankIt' possible that did the same in cdbs17:09
juliankEickmeyer[m]: That one was never uploaded.17:09
juliankEickmeyer[m]: this was the last one: https://salsa.debian.org/multimedia-team/ardour/blob/debian/1%255.12.0-3/debian/rules17:09
juliankEickmeyer[m]: The version you see in the current branch of the ardour repo there was a WIP17:10
cjwatsonRight, you seem to have branched off an unreleased thing17:10
cjwatsonAnd then found that it didn't work17:10
cjwatsonWhich 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
cjwatsonHave you considered instead doing the work based on the 1:55.12.0-3 tag?17:11
cjwatsonRather than based on unreleased stuff on master?17:11
cjwatsonSorry, the debian/1:5.12.0-3 tag I mean17:11
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
cjwatsonIt's not usual to pull in extra unreleased stuff from master unless it's required and works17:12
juliankEickmeyer[m]: Then apply those patches to 5.12.0-3 instead of the WIP master branch17:12
Eickmeyer[m]I'll go ahead and bring-in the original cdbs-based rules file and see what happens.17:12
cjwatsonI would make a new working git branch starting from the tag corresponding to the last upload17:13
cjwatsonAnd reapply whatever patches are necessary to that17:13
juliankor go back to https://salsa.debian.org/multimedia-team/ardour/commit/c7ab456c9bdd81d57f9bfff60d01fcce2e16421017:13
juliankwhich seems to include that?17:13
juliankthat ~ python3 support17:13
cjwatsonDon't try to mutate your current master branch (if you will take my advice)17:13
juliank+117:14
Eickmeyer[m]Ok, recloning then.17:17
cjwatsonWhy recloning?17:21
cjwatsongit checkout -b focal debian/1:5.12.0-317:21
cjwatsonor some such, assuming that you have a remote corresponding to the Debian repository17:21
Eickmeyer[m]It errored, but looks like I was trying to get the wrong tag.17:25
cjwatsondebian/1:5.12.0-3 should be the tag name according to the URL juliank posted above17:26
cjwatsonI haven't actually cloned it to check because rubbish internet connection17:26
Eickmeyer[m]Actually, it's coming back as debian/1%5.12.0-317:27
cjwatsonOh right of course17:29
cjwatsonSorry, should have actually decoded properly :)17:29
cjwatsonI always tab-complete tag names ...17:29
sdhd-saschahi, have here a machine, which want to upgrade from 18.04 to 20.04 ... which has trouble with package resolution...19:30
Eickmeyer[m]!support | sdhd-sascha19:44
ubottusdhd-sascha: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.19:44
sdhd-saschaubottu: oh, ok - what kind of `devel` is here ? i'm from `db`, `backend`, `desktop` and a little bit `web`19:46
sdhd-saschaEickmeyer[m]: no, problem -- thank you -- don't need support ;-)19:47
sdhd-sascha/me just more security, like everywhere ;-)19:47
Eickmeyer[m]sdhd-sascha: The point is that this is the wrong channel to address your question.19:50
Eickmeyer[m]sdhd-sascha: And technically you want #ubuntu+119:51
sdhd-saschaEickmeyer[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-saschaBut, no problem. I can figure it out. The #ubuntu is ,mostly, too much talk for me ...19:52
SamWhitedHi, 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=94391320:51
ubottuDebian bug 943913 in libseccomp2 "libseccomp2: seccomp_rule_add is very slow" [Normal,Open]20:51
SamWhitedWould 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!20:51
bryceSamWhited: 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 places23:19
bryceaw rats he left already23:19
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:43
tewardthat said, it will need AA intervention because it was removed23:45
tewardand it'll be stuck in NEW otherwise.23:46

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!