[00:00] <RAOF> By my understanding that could only happen if you shipped an identical library in two different packages?
[00:01] <RAOF> (Because the debugging symbols get put in a path dependent on their BuildID, and the BuildID is unique-per-build)
[00:02] <Eickmeyer> RAOF: I looked, and I don't see any matching files in the packages, let alone libraries.
[00:02] <RAOF> Eickmeyer: *are* you shipping the same `.so` in multiple packages (presumably in multiple filesystem locations)?
[00:02] <Eickmeyer> RAOF: I don't believe so. I can double-check, but I couldn't find anything common between those three packages.
[00:02] <RAOF> Yeah, those debugging symbols are generated in the debhelper machinery.
[00:05] <RAOF> Hm. From a cursory look at the Makefile, it seems that the R3D library is getting installed in two different places.
[00:05] <RAOF> That's what'd be causing this.
[00:06] <Eickmeyer> Then Upstream goofed. I'll have to let them know.
[00:06] <RAOF> They might need it in multiple places. You could fix this by making both packages depend on a 3rd package and symlinking the relevant library in the right place?
[00:07] <Eickmeyer> I could probably do that.
[09:03] <seb128> cjwatson, hey, what do you think about changing the maintainer on https://launchpad.net/ubiquity to maybe ubuntu-core-dev?  (which is what is done for update-manager/update-notifier/software-properties)
[09:04] <cjwatson> seb128: Sure, done
[09:04] <seb128> cjwatson, thanks!
[09:14] <juliank> zsync -i focal-desktop-amd64.iso http://cdimage.ubuntu.com/ubuntustudio/releases/focal/beta/ubuntustudio-20.04-beta-dvd-amd64.iso.zsync
[09:14] <juliank> let's see what that does!
[09:15] <juliank> :D
[09:15]  * juliank wonders how much he can reuse from the ubuntu image for studio
[09:18] <juliank> heh it's still reading the seed file :/
[09:34] <Saviq> didrocks: hey, FWIW my `bpool` did not have a cachefile set:
[09:34] <Saviq> $  zpool get cachefile bpool
[09:34] <Saviq> NAME   PROPERTY   VALUE      SOURCE
[09:34] <Saviq> bpool  cachefile  -          default
[09:34] <Saviq> not sure if that's meaningful or not - will try rebooting in a sec
[09:34] <didrocks> Saviq: yeah, some had depending on when they installed it and if the generator set it. At least, it’s not set, which is the point
[09:35] <didrocks> Saviq: keep me posted!
[09:35] <Saviq> and the rest of your instructions were basically what I had to do to get my system in order (provided I didn't forget… at which point I had to do it from a live USB)…
[09:36] <Saviq> didrocks: is there a way to abort the grub upgrade if it didn't generate any sane entries?
[09:39] <didrocks> Saviq: I don’t know, each script is independent, so having "empty" results is valid (no ZFS for the zfs script, nothing in 10_linux if zfs entries, only os-prober entries…. Maybe a patch to grub-mkconfig directly to check that you at least have one entry will be a fix
[09:53] <juliank> reuse was 21.2%
[09:53] <juliank> better than nothing
[09:53] <juliank> (re how much can I reuse my ubuntu iso when fetching studio iso=
[09:55] <juliank> AFAICT, gnome-system-monitor produces completely wrong network bandwidth
[09:55] <juliank> it like shows 15.6 Mbit/s, whereas iftop shows 8-9.5 Mbit/s
[09:56] <juliank> it also says I
[09:56] <juliank> 'm sending at 300-500 kbit/s
[09:56] <juliank> when it's really just 140-200
[09:56] <juliank> it's ... odd
[09:57] <Saviq> I filed a bug… somewhere… about g-s-m bandwidth…
[09:57] <Saviq> didrocks: that didn't help, neither did adding "Before=boot-{efi-grub}.mount" to zfs-import-{scan,cache}.service…
[09:57] <juliank> Saviq: ah good
[10:02] <didrocks> Saviq: please don’t change the order for generator units, we shouldnt’ use zfs-import-*
[10:02] <didrocks> Saviq: so, do you have other .mount units in /run/systemd/generator/ ?
[10:03] <Saviq> didrocks: yeah that was just me messing about, lemme remove
[10:05] <Saviq> didrocks: https://paste.ubuntu.com/p/2XXKpBkn25/
[10:05] <didrocks> ack, so you are missing boot.mount
[10:05] <didrocks> my bet is that /etc/zfs/zfs-list.cache/bpool is empty
[10:06] <didrocks> (but not /etc/zfs/zfs-list.cache/rpool)
[10:08] <Saviq> didrocks: correct, no `bpool` there
[10:08] <Saviq> something of a chicken'n'egg by now I suppose?
[10:08] <didrocks> exactly!
[10:08] <didrocks> you can either reset to the initial state
[10:09] <didrocks> or just patch it as if nothing happened :p
[10:09] <didrocks> I would suggest reverting to the initial state by creating the same cache metadata as a fresh install
[10:09] <Saviq> didrocks: tell me how :)
[10:10] <didrocks> (you need zfsutils-linux 0.8.3-1ubuntu11)
[10:10] <Saviq> got it
[10:10] <didrocks> echo "" > /etc/zfs/zfs-list.cache/bpool
[10:10] <didrocks> echo "" > /etc/zfs/zfs-list.cache/rpool
[10:10] <didrocks> to create those 2 empty files
[10:10] <didrocks> ensure you have bpool and rpool in the bpool cache
[10:11] <didrocks> grep bpool /etc/zfs/zpool.cache
[10:11] <didrocks> grep rpool /etc/zfs/zpool.cache
[10:11] <Saviq> matching
[10:11] <didrocks> (and ensure you fixed /boot/grub /boot/efi as in the bug)
[10:12] <didrocks> like /boot is empty
[10:12] <didrocks> so umount them, rm…
[10:12] <didrocks> then reimport bpool which should now mount
[10:12] <didrocks> then sudo mount -a for /boot/grub and /boot/efi
[10:12] <didrocks> update-grub
[10:13] <didrocks> and you should be reset to the same state than people who just installed the beta
[10:13] <didrocks> (with your data ofc)
[10:15] <Saviq> didrocks: /etc/zfs/zfs-list.cache/bpool now has contents - but rpool does not, that will happen on next boot, will it?
[10:15] <didrocks> Saviq: yeah, the improt populated it, but you can empty it again, the boot will populate them
[10:15] <didrocks> import*
[10:16] <Saviq> ack, will report back
[10:16] <didrocks> thx!
[11:06] <Saviq> didrocks: yes, that finally helped \o/
[11:12] <didrocks> Saviq: nice! Thanks for hanging on here :) So yeah, this confirms that new installs shouldn’t be impacted (from beta). The issue of the generator failing unnoticed because systemd doesn’t stop the boot is annoying. We’ll upstream to ZFS how we made the generator more robust + dropping to emergency if something bad happens to prevent then having your bpool messed by systemd
[11:29] <Saviq> didrocks: ack, thanks :)
[12:31] <juliank> OK, so ubuntustudio beta does not seem to launch in my kvm
[12:32] <juliank> simple kvm with secure boot, -vga virtio, and -display gtk,gl=on
[12:39] <Laney> Wimpress had some problems with GL & XFCE flavours
[12:40] <juliank> Laney: aha
[12:40] <juliank> Laney: turning that off helped, yes
[12:41] <Laney> bug report would be useful I guess, not sure if one got filed
[12:51] <juliank> Eickmeyer: testing now
[13:32] <juliank> Eickmeyer: analysis posted
[13:32] <juliank> xnox: you might want to review my analysis in https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1851346, just in case I missed something
[13:33] <juliank> xnox: The plugin was marking a ton of stuff for removal, and that stuff was depended upon by other critical stuff like plymouth themes
[13:33] <juliank> xnox: Also you might just want a good scare
[13:33] <juliank> The plugin assumed that any Recommends or Suggests of a metapackage could safely be removed, which is not the case
[13:34] <juliank> Hence the solution is to remove the plugin, or make it only offer selected known-good removals
[13:34] <juliank> I don't care which solution ubuntustudio takes
[13:34] <xnox> Wimpress:  ^^^^
[13:35] <xnox> my vote is to drop the plugin, unless people can come up with curated list of things they want to allow to drop
[13:35] <xnox> ie. something akin of ubuntu-desktop-minimal install type
[13:35] <juliank> example: ubuntustudio-desktop-core recommends fonts-ubuntu, hence fonts-ubuntu was offered for removal
[13:36]  * xnox hm, actually Wimpress is not ubuntustudio lead, who was it?
[13:36] <juliank> xnox: Eickmeyer
[13:36] <ivoks> rafaeldtinoco around?
[13:36] <xnox> Eickmeyer:  ^^^^
[13:36] <rafaeldtinoco> ivoks: yep
[13:36] <juliank> xnox: who I pinged first :)
[13:37] <juliank> but i
[13:37] <ivoks> rafaeldtinoco hey, why don't we just transfer existing LP group to you?
[13:37] <juliank> 'm sure W impress is interested in all our flavors
[13:37] <juliank> :D
[13:37] <juliank> in them succeeding
[13:37] <AsciiWolf> kenvandine, hi, is the fixed version (with fixes to make regular ubuntu packages available, not only snaps) of Snap Store available in Ubuntu 20.04?
[13:37] <ivoks> rafaeldtinoco you have debian maintainer in there, etc
[13:37] <rafaeldtinoco> ivoks: not sure, but we already had the ubuntu-server, i added a "ha" after it, and then discover there was an ubuntu-ha
[13:37] <xnox> Eickmeyer:  juliank: reading the metapackage, it seems to me that ubuntustudio-*-core packages shouldn't be offered for removal
[13:37] <rafaeldtinoco> ivoks: vivec ?
[13:38] <ivoks> rafaeldtinoco maybe old debian maintainer :) i haven't look into these packages in a while
[13:38] <juliank> xnox: None of the metapackages should be, really, only their Recommends/Suggests
[13:38] <juliank> xnox: But then still problems
[13:38] <ivoks> rafaeldtinoco loschwitz
[13:38] <rafaeldtinoco> ah great
[13:38] <juliank> ubuntustudio-desktop recommends fonts-ubuntu too
[13:38] <rafaeldtinoco> can u put me in there then ?
[13:38] <rafaeldtinoco> Ill transfer things later this week
[13:38] <juliank> as does ubuntustudio-fonts
[13:38] <juliank> same for other packages and dependencies
[13:38] <xnox> urgh
[13:39] <juliank> well, s/same/similar/
[13:39] <juliank> :)
[13:39] <juliank> You could build a list of removable recommends/suggests at live build time, I guess
[13:40] <juliank> like try to remove each optional package, check that it does not remove metapackages
[13:40] <juliank> if it does -> don't add it
[13:40] <ivoks> rafaeldtinoco can you check if that's you ;)
[13:40] <juliank> if metapackages remain installer -> add it
[13:40] <juliank> store the list _somewhere_
[13:40] <ivoks> it is
[13:40] <ivoks> making you an admin
[13:40] <juliank> but that requires livecdrootfs work
[13:40] <juliank> so... meh
[13:41] <rafaeldtinoco> ivoks: yep!
[13:41] <AsciiWolf> kenvandine, it does not seem to be on my system, the last stable Snap Store is 20191114 for some reason... I have tried installing the latest edge version, core system snaps were no longer uninstallable, but regular Ubuntu packages were still missing... also, it broke the ubuntu-software integration/branding on my system, the Ubuntu Software icon disappeared
[13:41] <rafaeldtinoco> ivoks: do u mind if I refresh things ?
[13:41] <rafaeldtinoco> ivoks: deleting old ppa, keeping a staging one
[13:41] <rafaeldtinoco> etc etc
[13:41] <ivoks> rafaeldtinoco by all means
[13:41] <ivoks> things are quite old there
[13:41] <rafaeldtinoco> nice
[13:41] <rafaeldtinoco> i'll point wiki to the server guide im creating also
[13:41] <rafaeldtinoco> tku
[13:42] <ivoks> rafaeldtinoco there's also https://launchpad.net/~ubuntu-ha-maintainers
[13:42] <rafaeldtinoco> ivoks: hum.. E_TOOMANYGRPS ?
[13:42] <ivoks> rafaeldtinoco i'll let you organize this any way you want
[13:42] <ivoks> :)
[13:43] <rafaeldtinoco> cool
[13:46] <kanashiro> locutus_, to fix ruby stuff in proposed (reported by edos-distcheck) we still need to sync 3 packages: ruby-rchardet, ruby-redis and ruby-mini-magick
[13:46] <kanashiro> I filed bugs for them
[13:46] <kanashiro> #1871110 , #1871118 and #1871120
[13:47] <kanashiro> there is another package missing (ruby-enumerable-statistics) but it is still in the Debian NEW queue
[13:50] <kenvandine> AsciiWolf: latest/stable/ubuntu-20.04 is the branch you want
[13:51] <kenvandine> AsciiWolf: there is still an issue with regular apt packages, which will be fixed in the next snapd
[13:51] <kenvandine> once all that's in place it'll get promoted to stable
[13:51] <kenvandine> AsciiWolf: but for now the stable branch is snap only and not the latest code
[13:58] <AsciiWolf> kenvandine, ah, ok :-) thanks for your work, I appreciate it!
[13:58] <kenvandine> AsciiWolf: np
[14:25] <LocutusOfBorg> kanashiro, ruby-redis loooks saaaaaad https://launchpadlibrarian.net/473255574/buildlog_ubuntu-focal-amd64.ruby-redis_4.1.2-4_BUILDING.txt.gz
[14:26] <LocutusOfBorg> retrying the build
[14:28] <kanashiro> LocutusOfBorg, ok, if it still fails I can take a look
[14:40] <LocutusOfBorg> it worked on the second try
[14:41] <kanashiro> great :)
[15:04] <rbasak> !dmb-ping
[15:50] <rafaeldtinoco> rbasak: not sure it worked
[15:50] <rafaeldtinoco> i got the ping by a highlight to my name only
[15:51] <rbasak> rafaeldtinoco: that's all it does :)
[15:51] <rafaeldtinoco> rbasak: but from ddstreet
[15:52] <rafaeldtinoco> !dmb-ping test
[15:52] <rbasak> rafaeldtinoco: that's probably just your IRC client's parsing
[15:52] <rafaeldtinoco> you mean a web irc client is not good ? :P
[15:53] <rbasak> rafaeldtinoco: maybe we should move all the Ubuntu IRC channels to Signal? :-P
[15:54]  * rafaeldtinoco adding as a next dmb meeting item to discuss with your name on it
[15:54] <rafaeldtinoco> "suggested by"
[16:17] <seb128> cjwatson, hey, sorry for the direct ping but you seem to have dealt with most of those in the past ... do you have a tool/script to update the booloader.pot in gfxboot-theme-ubuntu?
[16:18] <seb128> cjwatson, or is that done by manually calling po/bin/add_text for every string?
[16:19] <blackboxsw> rbasak: bryce and other git gurus.... we have a development git ubuntu/<series> branch used for daily packaging recipe builds. Our packaging recipe build merges tip master of our project into the <series> branch and rebuilds to make sure our tip doesn't break <series>.
[16:20] <blackboxsw> the complication comes during feature freeze, when we only cherry-pick changes into ubuntu/<series> and perform a release. After that event, we immediately revert the cherry-picks in ubuntu/<series> so daily recipes continue to build when merging tip
[16:20] <cjwatson> seb128: I believe I always used my NOT AT ALL HACKY rosetta-merge (https://paste.ubuntu.com/p/gVyGkdfxrp/) + rosetta-merge-all (https://paste.ubuntu.com/p/MXjg4W3NQH/)
[16:20] <cjwatson> and went over the VCS diff very carefully afterwards.  I can't remember exactly which combination of rosetta-merge-all options I used for gfxboot-theme-ubuntu though
[16:21] <blackboxsw> rbasak:/bryce in this last feature freeze period we have released multiple times from ubuntu/devel with multiple sets of cherry picks which push on during each pkg release event, and pop off immediately afterward to ensure daily package builds succeed.
[16:21] <blackboxsw> rbasak: / bryce it makes for a very dirty set of commit logs (and debian/changelog)
[16:21] <cjwatson> You might have to experiment a bit.  Definitely at least "--apply --prefix bootloader-" but I can't remember whether I used --keep-old
[16:22] <seb128> cjwatson, ok, thanks for the pointers,, I will play with that
[16:22] <cjwatson> I was always sort of hoping somebody would write something that wasn't a giant hack :)
[16:22] <bryce> blackboxsw, are you able to discard the dirty commits when you resync?  Does any of the 'chaff' end up in the released package, or is it contained just to ci?
[16:22] <seb128> haha
[16:23] <blackboxsw> rbasak: bryce. I'm looking at trying to avoid carrying very noisy sets of cherry-pick/push/pop commits on the series branch by leveraging git reset  HEAD~<cherry-pick-count> when we are trying to reapply cherry-picks during 2nd release.
[16:23] <blackboxsw> bryce: rbasak yes I can discard the commits with something like the following....
[16:24] <rbasak> blackboxsw: I suggest that you've got two things going on there: 1) you want to ensure that master is always backportable to stable releases, and 2) you want to maintain stable branches with cherry-picks during feature freeze
[16:24] <rbasak> blackboxsw: could you disentangle the two? With two PPAs - one dedicated for the first purpose only.
[16:24] <blackboxsw> rbasak: bryce this PR adds the --pop-all logic/flow https://github.com/CanonicalLtd/uss-tableflip/pull/45/files#diff-dc87560a3829792f8c7376e1cbffa698R103-R116
[16:25] <blackboxsw> rbasak: yeah it does seem a bit like things are complicated because we are trying to do two things in one place
[16:25] <blackboxsw> my question ultimately was going to be is there an easy way in a git commit range to "reset" certain commits in that range, but leave other interleaved/unrelated/non-cherry-pick commits
[16:26] <bryce> blackboxsw, two separate systems makes sense to me too.  We do that with inkscape - a 'pure' master daily build, and a 'stable-daily' build that tracks the alpha/beta/pre-* stuff prior to the release.  The latter branch is quiescent most of the time but active leading up to release time
[16:26] <rbasak> blackboxsw: there's "git revert -n"
[16:26] <rbasak> You can use that to build up a set of reverts into a single commit
[16:27] <blackboxsw> iiiinteresting.
[16:27] <blackboxsw> ok that may be a stop gap too. and I'll talk to the team about potential separation of tasks... ppas
[16:29] <seb128> cjwatson, you used those scripts to import the translations, not the template right?
[16:29] <cjwatson> Yeah, I don't quite remember about the template I'm afraid
[16:30] <seb128> no worry
[16:30] <cjwatson> It may well have involved some ad-hoc script around add_text
[16:30] <cjwatson> Sounds vaguely familiar
[16:30] <seb128> I think I figured things enough to do it the hacky way
[16:30] <seb128> I will do those add_text calls in a small script, looping with the strings and the flavor names
[16:30] <seb128> cjwatson, thanks
[16:32] <cjwatson> Yeah, I bet that's basically what I did.  Have fun
[16:32] <seb128> thanks!
[17:15] <jdstrand> rbalint: hi! looking at https://bugs.launchpad.net/snapd/+bug/1871148/comments/10
[17:15] <jdstrand> rbalint:: so, zfs-on-root does different pools for /var such that local-fs.target is satisfied but /var/lib/snapd/apparmor/profiles does not exist at the time the service starts
[17:16] <jdstrand> rbalint: so we were thinking of adding to apparmor.service: RequiresMountsFor=/var/lib/snapd/apparmor/profiles
[17:16] <jdstrand> rbalint: do you feel that would be reasonable?
[17:18] <zyga> FYI https://github.com/openzfs/zfs/blob/5a42ef04fd390dc96fbbf31bc9f3d05695998211/etc/systemd/system/zfs-mount.service.in#L8
[17:18] <zyga> Perhaps this is buggy somehow
[17:21] <jdstrand> zyga: oh, nice fine. what is /lib/systemd/system/*zfs*service ? are they using that service file or are the hand-grown?
[17:21] <jdstrand> hand-made*
[17:21] <jdstrand> or home-grown, but not hand-grown :)
[17:34] <jdstrand> jibel: hey, I see you assigned that ^ to yourself. how are you planning on fixing it?
[17:34] <rbasak> bryce: next MP up when you're ready please: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/381765
[17:35] <rbasak> I expect this will take you some time to review, and there may be some back-and-forthing
[17:50] <bryce> rbasak, ok noted
[18:57] <jibel> jdstrand, hi, I just saw the bug when I EOD'd following all the pings on #snappy, I'll have a look tomorrow morning if anything can be done to reorder the zfs unit.
[19:08] <jdstrand> jibel: ok. fyi, I will be adjusting RequiresMountsFor in apparmor
[19:13] <xevious> I've been working with mlombard at Red Hat to resolve some LIO lockups in the kernel. The first patch set was merged to the upstream kernel recently. Our affected systems are all running Ubuntu 16.04 - what process should I follow to propose backporting those patches to fix the lockup?
[19:14] <xevious> Here's the main fix commit: https://github.com/torvalds/linux/commit/57c46e9f33da530a2485fa01aa27b6d18c28c796#diff-b7557d7ed3ba34645f6e9d510f281d3a
[19:15] <juliank> xevious: https://wiki.ubuntu.com/Kernel/FAQ/DevHowToPatch
[19:15] <xevious> Thanks
[22:18] <bdmurray> marcustomlinson: is somebody like L_aney going to upload update-manager soon for the POTFILES fix, or should I do that? I ask as I have another upload of update-manager to do.
[22:48] <jwallden> Hey guys. I'm trying to set up a custom iso and are using preseeding for the install. I have a really strange behavior from Ubiquity now. When using file= to point to the preseed-file everything works as expeted. But when I use preseed/url= it downloads the file just fine but then then Ubiquity completely ignores everything
[22:50] <jwallden> Furthermore I had to use preseed/url to get it to boot at all. Using just url made grub not find the bootdisk. So the documentation is wrong I think