[06:18] <tjaalton> ahasenack_: hey, I see that you got your review already :) that's cool, thanks for working on it, and the test looks fine to me
[06:48] <juliank> RikMills: no
[07:06] <RikMills> juliank: seems to be there. python-apt-1.9.10/apt/package.py: def get_dependencies(self, *types):
[07:06] <RikMills> or you mean the issue is not there?
[07:07] <juliank> RikMills: That's a function that'sd being called, not a method
[07:07] <juliank> It has the same name, but it's a different thing
[07:07] <juliank> softwareproperties/gtk/SoftwarePropertiesGtk.py
[07:07] <RikMills> right
[07:07] <juliank> 100:def get_dependencies(apt_cache, package_name, pattern=None):
[07:09] <RikMills> where is that?
[07:09] <juliank> So, the function needs to move into SoftwareProperties class as a method
[07:09] <juliank> it says right there
[07:09] <juliank> softwareproperties/gtk/SoftwarePropertiesGtk.py line 100
[07:10] <juliank> older checkout, though
[07:10] <juliank> Now it's line 147
[07:10] <RikMills> so was no done in software-properies-qt by the lubuntu porter of the driver page?
[07:11] <RikMills> if so, just surprised only getting bugs now
[07:14] <RikMills> juliank: anyway, thanks. I'll pass that on to the lubuntu guy
[08:10] <seb128> rbalint, hey, bug #1870930 sounds like a regression/new issue since 245.2-1ubuntu2
[08:34] <mantas-baltix> hello all :)
[08:51] <rbalint> seb128, yes, will check it soon
[08:51] <seb128> rbalint, thanks
[08:58] <mantas-baltix> I've updated and fixed lots of snap store translations five days ago, but I don't see new translations in latest snap-store 20200413.ac9047f from latest/beta channel :(
[08:59] <santa_> rbalint: nvm, vorlon already pointed out the solution for virtualbox-guest-utils installation here: https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1872485/comments/2
[08:59] <santa_> https://salsa.debian.org/systemd-team/systemd/-/commit/02e27e24e4f84335f360c085d1e8c3f11bd12349
[09:00] <santa_> ↑ this should work :)
[09:12] <rbalint> santa_, i'm testing the next systemd upload that has the fix at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3801
[10:06] <AsciiWolf> kenvandine, are the classic packages showing in Snap Store for you with latest snapd?
[10:10] <AsciiWolf> I reverted my testing vm snapshot to a beta clean install, fully updated the system (including latest snapd that was previously in proposed), made sure I have latest Snap Store from stable branch and still no luck :/
[10:23] <santa_> rbalint: thank you very much, I tested with that package and it's possible to install virtualbox-guest-utils + shared folders work
[10:25] <rbalint> santa_, thanks for testing!
[13:16] <kenvandine> AsciiWolf: with core from the beta channel it is working for me
[13:16] <kenvandine> AsciiWolf: can you please pastebin /var/lib/snapd/apparmor/profiles/snap.snap-store.ubuntu-software
[13:37] <kanashiro> locutus__: I applied the ruby2.7 delta (riscv related) we carry in Debian and also did a minor update in the symbols file: https://tracker.debian.org/news/1118113/accepted-ruby27-270-5-source-into-unstable/
[13:37] <kanashiro> should we sync this version before the release?
[13:42] <Laney> mdeslaur: stgraber: vorlon: (TB people): wdyt about creating a 20.04.1 milestone on Launchpad?
[13:42] <Laney> I'd like us to be able to target bugs to it, to commit to them after the .0 release
[14:51] <ogra> GRRR ... so the focal installer just trashed my grub on the laptop... when installing from one USB device to another, seems the grub on my nvme disk is now wiped completely and i can only boot from USB stick
[14:52] <ogra> during partitioning the USB disk was picked as target for both, rootfs and grub installation
[14:54] <ogra> (which means i wouldnt expect *anything* to touch the installed grub on the nvme disk)
[14:57] <seb128> ogra, sounds like worth a bug report and maybe a rls-ff-incoming tag
[14:58] <ogra> okay
[14:59] <ogra> against ubiquity i guess ?
[15:01] <Laney> ogra: bug #1847898 ?
[15:06] <ogra> Laney, let me sse (i just filed https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1872736 but will duplicate if needed)
[15:07] <ogra> hmm, not sure thats the same
[15:09] <Laney> it probably is
[15:09] <Laney> or https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379 which is related
[15:11] <ogra> from 2014 ?!?!?!
[15:11] <ogra> WOW
[15:16] <ogra> that could be it though
[15:16] <AsciiWolf> kenvandine, sorry for the late reply, here is the pastebin of snap.snap-store.ubuntu-software apparmor profile: https://pastebin.com/anaNsxEZ
[15:16] <ogra> not really sure if the EFI partition was mounted from NVME or not during install
[15:17] <kenvandine> AsciiWolf: should work
[15:17] <kenvandine> AsciiWolf: /usr/share/metainfo/{,**} r,
[15:17] <kenvandine> /usr/share/appdata/{,**} r,
[15:18] <kenvandine> AsciiWolf: kill the current process and run snap-store --verbose
[15:18] <kenvandine> does the appstream show as disabled?
[15:22] <AsciiWolf> kenvandine, here is the full verbose log: https://pastebin.com/XLHt4epE
[15:22] <AsciiWolf> it seems so: "15:20:06:0469 Gs  disabling appstream as setup failed: No AppStream data found"
[15:23] <AsciiWolf> looks like there is some apparmor issue
[15:26] <AsciiWolf> I will try downloading the latest nightly focal iso and reinstalling the vm using this iso instead of the beta iso
[15:26] <kenvandine> AsciiWolf: i'm trying to reproduce it now
[15:26] <kenvandine> AsciiWolf: my download from friday works
[15:28] <AsciiWolf> most likely something gone wrong when updating the packages to latest versions... bad thing is that I tried it multiple times and it was the same every time so it is possible that this will happen for every user who installed the official focal beta iso, then upgraded the system instead of installing latest nightly/final focal build :/
[15:29] <AsciiWolf> kenvandine, try this official beta iso: http://releases.ubuntu.com/20.04/
[15:29] <kenvandine> AsciiWolf: we'll get it fixed :)
[15:29] <AsciiWolf> this is what I used
[15:44] <kenvandine> AsciiWolf: ok, i've reproduced it
[15:44] <kenvandine> i think it's a mix of my VM had previously had the 3.34 code base installed but now the 3.36 code base is in that channel
[15:45] <kenvandine> and i think the components cache is already there for me
[15:45] <kenvandine> but starting fresh with an empty cache isn't working with the 3.36 codebase
[15:45] <kenvandine> AsciiWolf: i think...
[15:48] <AsciiWolf> I was also reproducing the issue on an older Snap Store build that was 3.34 based
[15:50] <kenvandine> AsciiWolf: i think that was the apparmor thing that is now fixed in snapd
[15:50] <kenvandine> that was affecting both
[15:50] <kenvandine> but racy
[15:51] <kenvandine> i'm doing a new build of the 3.34 branch now to verify
[16:18] <AsciiWolf> hmm, so I have tried the latest daily build iso and have the same issue... but I think I have made one mistake: I have ran Snap Store right after the Ubuntu installation without upgrading the system first...
[16:19] <AsciiWolf> there were updates for snapd and apparmor, I have installed them, rebooted the system, but Snap Store does not show any classic packages, just snaps... just like on the old vm
[16:21] <Eickmeyer> I need help. I have a critical bug 1872555 with Ardour (repo at https://code.launchpad.net/~ubuntustudio-dev/+git/ardour). It uses CDBS for its build system. I can't get the patch I made to apply correctly.
[16:21] <Eickmeyer>  It applies correctly using dh_quilt_patch but CDBS doesn't want to apply it correctly.
[16:21] <Eickmeyer> How can I override CDBS to apply the patch correctly?
[16:24] <cjwatson> Eickmeyer: Is the bug present in current master of that repository?
[16:24] <cjwatson> Eickmeyer: I mean, the patching bug
[16:25] <Eickmeyer> cjwatson: Yes. The plugins build, but will not run with the new libgcc-s1.
[16:25] <cjwatson> Eickmeyer: Not quite what I mean - I mean, how can I reproduce the CDBS problem you're describing?
[16:26] <Eickmeyer> cjwatson: The patch I made is a cherry-pick from the Ardour github repo. I could get it to build with launchpad's autobuild, but building locally with debuild -S isn't working.
[16:26] <Eickmeyer> We were also able to verify the autobuild with the patch worked.
[16:32] <cjwatson> This repository is super-confusing.  Probably needs to be converted to git-buildpackage or git-dpm's patching system.  Let's see if I can work out exactly how it's out of sync
[16:32] <cjwatson> Whoa, what on earth is this .orig
[16:33] <cjwatson> It's a tarbomb!
[16:33] <cjwatson> Scribbled all over the current directory when I unpacked it rather than unpacking into a single directory
[16:34] <Eickmeyer> I'm not surprised. Ardour has been around for over a decade. It's our premiere DAW for Studio.
[16:34] <cjwatson> Eickmeyer: The .orig was apparently built by you though
[16:35] <Eickmeyer> Oh, it had to be a repack, iirc.
[16:35] <cjwatson> And tarbombs have been very thoroughly out of style for well over two decades
[16:36] <Eickmeyer> Had to do the repack because the actual orig contains a binary waf.
[16:36] <cjwatson> Yeah, but you didn't have to do it like that :)
[16:36] <Eickmeyer> Terribly sorry.
[16:36] <Eickmeyer> I'll remember that for next time. :)
[16:36] <cjwatson> The basic problem here is that the git tree, after "quilt pop -a", doesn't agree with the .orig
[16:37] <Eickmeyer> So, something got screwed-up in the tree?
[16:38] <cjwatson> I have no idea how you maintain this tree, but basically
[16:38] <kenvandine> AsciiWolf: i have a reproducer, debugging
[16:38] <Eickmeyer> Ok, I'll give that a whirl.
[16:38] <cjwatson> I see it's imported from Debian, let me see if there's anything suspicious in the delta
[16:38] <cjwatson> Hm, does look like it's maintained with something automatic
[16:39] <cjwatson> Hold off a minute while I dig further
[16:39] <Eickmeyer> Yeah, Debian was too slow to fix it after the gcc/fluidsynth update/Python2 removal.
[16:39] <Eickmeyer> I had to take matters into my own hands.
[16:39] <Eickmeyer> But, holding.
[16:41] <cjwatson> Eickmeyer: So can you explain this repack thing a bit more?  Your orig differs from Debian's but has the same upstream version number, which is very strange
[16:41] <cjwatson> Eickmeyer: And I don't see a binary waf in Debian's orig
[16:42] <Eickmeyer> I don't quite remember. I *can* grab Debian's orig, if you think that will help.
[16:42] <Eickmeyer> I'm pretty sure Debian's is a repack as well. I may have only duplicated the effort.
[16:42] <Eickmeyer> cjwatson: ^
[16:43] <cjwatson> I think it may help, given that that's the baseline that the git repository is relative to.  But I'll investigate a bit more first ...
[16:47] <cjwatson> Eickmeyer: Yeah, the source package builds fine if I move your ardour_5.12.0.orig.tar.gz into a different directory and put Debian's ardour_5.12.0.orig.tar.bz2 there instead.  (The uploader will need to pass the -sa option to debuild -S to force it to include the .orig in the upload.)  Do test-build the actual resulting source package first though, as there were a number of other (hopefully ...
[16:47] <cjwatson> ... inconsequential) differences between the two orig files.
[16:48] <Eickmeyer> cjwatson: Ok, I'll give that a shot. One thing:
[16:48] <Eickmeyer> cjwatson: I'm trying to get the tarball with "pristine-tar checkout ardour_5.12.0.orig.tar.bz2" but it is failing. Am I doing it wrong?
[16:48] <Eickmeyer> That might be why I did the repack in the first place.
[16:49] <cjwatson> Eickmeyer: Yeah, pristine-tar does seem to fail to reconstruct the tarball for a reason I can't see, but you can always fetch it directly from the Debian archive.
[16:49] <Eickmeyer> Ok
[16:49] <cjwatson> Eickmeyer: e.g. in a temporary directory run "pull-debian-source -d ardour"
[16:50] <Eickmeyer> Ok, I'll give that a shot.
[16:51] <cjwatson> With this repository layout, the key is that the orig needs to match the "upstream" branch in git
[16:52] <Eickmeyer> Ok, I'll recommit the "upstream" branch with that tarball.
[16:52] <cjwatson> No, don't!
[16:52] <cjwatson> The upstream branch matches the Debian orig
[16:52] <Eickmeyer> Er... no.
[16:52] <cjwatson> So just use the Debian orig :)
[16:52] <cjwatson> Then the source packaging will match git
[16:52] <Eickmeyer> Ok.
[16:53] <Eickmeyer> Waddya know, it worked.
[16:53] <cjwatson> (It's also slightly more than just committing on top of the upstream branch - for a new upstream release, you'd need to manage it using gbp (a bit like https://wiki.debian.org/Python/GitPackaging#New_upstream_release, only obviously not Python).  But no need for that here AFAICS
[16:53] <Eickmeyer> teward: We were using the wrong tarball.
[16:53] <cjwatson> )
[16:54] <Eickmeyer> You're right, it matched and was happy.
[16:54] <Eickmeyer> Dunno how my .tar.xz got so screwed-up.
[16:54] <Eickmeyer> I'll see if I can pristine-tar commit this thing. Should I?
[16:54] <cjwatson> No
[16:54] <Eickmeyer> Ok.
[16:54] <cjwatson> I would leave the pristine-tar branch alone and just ignore it
[16:54] <Eickmeyer> Ok
[16:55] <cjwatson> Fortunately since the file names are different you can still upload this without having to change the upstream version number
[16:55] <cjwatson> .gz vs. .bz2
[16:55] <cjwatson> Bit of a cheat but it works :)
[16:56] <Eickmeyer> Yep, but I need teward to upload it first since ERR:NoPackagesetYet (Fix coming Monday).
[16:56] <Eickmeyer> Unless you have an extra cycle, cjwatson.
[16:57] <cjwatson> I might do but it would be later this evening
[16:57] <Eickmeyer> You're... what time zone?
[16:57] <teward> that's about how soon I could get to it too so :P
[16:57] <teward> (~4hr+ from now)
[16:58] <cjwatson> Europe/London
[16:58] <cjwatson> Laptop's needed now for my daughter's ballet class though
[16:59] <Eickmeyer> Ok, cool. Just let me know. I'll assign you the bug. :)
[17:36] <kenvandine> AsciiWolf: ok, i've sort of figured it out.  I found the failure, which is a query of the appstream components cache.
[17:36] <kenvandine> and i've tested a workaround that fixes it but has an annoying side effect
[17:37] <kenvandine> AsciiWolf: i'm going to discuss this with robert_ancell when he comes online in a couple of hours to get a proper fix
[17:38] <AsciiWolf> kenvandine, nice, good work!
[17:38] <AsciiWolf> thanks
[18:51] <cjwatson> Eickmeyer,teward: uploaded
[18:51] <Eickmeyer> cjwatson: Thanks! :)
[20:00] <vorlon> ganso: my "maintenance" of nfs-utils is largely hypothetical, sorry
[20:02] <vorlon> Laney, sil2100: do we have a target date for the 20.04.1 milestone?  It's not on https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule
[20:03] <vorlon> Laney: anyway, https://launchpad.net/ubuntu/+milestone/ubuntu-20.04.1
[20:09] <ganso> vorlon: hmm is there someone you know that I could ask and would be able to answer my question about nfs-utils version pinning/update ?
[20:17] <vorlon> ganso: one or more of the other people listed as uploaders of the package ;)