=== ricab_ is now known as ricab
[09:42] <xnox> jibel:  didrocks: uploaded grub2-signed to match the grub2 upload. Note each time one uploads grub2 it creates a side-tarball for signing, which launchpad then signs and publishes in the archive like a custom upload (similarish to e.g. d-i)
[09:43] <xnox> jibel:  didrocks: then one has to upload grub2-signed such that it would fetch those signed blobs, and repackage them into .deb and ship it in the archive, to make grub2 securebootable.
[09:43] <xnox> anyway, uploaded
[09:43]  * xnox hopes to get d-i buildable and migratable.
[09:45] <jibel> xnox, thx
[09:45] <didrocks> xnox: ah, good to know! Thanks! Is it documented anywhere?
[09:46] <didrocks> so that I can add a bookmark for my own self next time :p
[09:49] <cjwatson> Have these ZFS patches been sent upstream?
[09:49] <xnox> didrocks:  no idea. but watch out for things that produce signing tarballs like: linux shim grub2 s390-tools
[09:49] <xnox> all of which have linux-signed shim-signed grub2-signed s390-tools-signed matching packages
[09:50] <xnox> jibel:  didrocks: also cyphermox is in the middle of rebase on top of 2.04 =)
[09:50] <cjwatson> An entire new script in util/grub.d/ is a significant maintenance commitment if it's downstream-specific.
[09:50] <didrocks> cjwatson: there is a card for this, we'll do it once zsys enters the distro
[09:50] <didrocks> and we separated the ubuntu-specific things in following patches (like the "recovery" translations)
[09:50] <didrocks> so that we only have in the first patch what can be upstreamed
[09:51] <didrocks> xnox: got it, thx ;)
[09:51] <cjwatson> I really recommend doing the upstreaming first next time.  From experience.
[09:51] <cjwatson> We can end up in unfortunate situations where we have to maintain interfaces in perpetuity that have been changed in the review process upstream.
[09:51] <didrocks> cjwatson: noted down, we wanted to testproof it a little bit, but that makes sense as well
[09:52] <didrocks> what interfaces? I don't think we added anything in any lib (no new API)
[09:52] <cjwatson> I don't think that multiple 10_linux_* scripts is a good pattern to follow, *at all*.
[09:52] <cjwatson> The interface between the boot loader and the installed system is an interface.
[09:53] <cjwatson> Dataset naming patterns, that sort of thing
[09:53] <didrocks> we initially got it as 15_, but thought 10_ would be better as it override for zfs 10_linux and is really similar, we can rename it + add the conffiles transitions
[09:53] <cjwatson> You misunderstand me.  My objection is not to the 10
[09:54] <cjwatson> We need to work out how to integrate this properly so that we don't have to have multiple scripts for booting Linux.  The existence of 20_linux_xen is bad enough but really shouldn't be perpetuated
[09:55] <cjwatson> Anyway, this isn't a veto since I no longer maintain Ubuntu grub2, but I wouldn't be willing to take this patch in Debian grub2 as it stands, and I'd be surprised if it were upstreamable (but I could be wrong)
[09:56] <cjwatson> IMO to be upstreamable it must be integrated into 10_linux properly
[09:57] <cjwatson> (Also, a minor point: zfs_enhance_support.patch shouldn't patch the autogenerated files Makefile.in and Makefile.util.am)
[09:58] <didrocks> If it could be merged with 10_linux, that would be great, but I really doubt about it or it means 10_linux will need to be really refactored a lot to be properly testable (as we do with 10_linux_zfs) and in functions. The intersection of commonality is quite small, but happy to discuss this upstream
[09:58] <cjwatson> Right, so start with preliminary patches to refactor it?
[09:58] <cjwatson> I imagine that would be a good thing anyway
[09:59] <didrocks> if my manager acks some time to do this, yes
[09:59] <didrocks> (and ack on Makefile.in, will fix this)
[10:00] <cjwatson> Ideally this would be laid out in such a way that the history handling could be shared by e.g. a btrfs implementation
[10:01] <cjwatson> Not saying you actually have to implement that, but if there were obvious slots for doing so, to me that would be a good indicator that the code layout is about right
[10:03] <didrocks> we have intermediate representations in memory of system layout and machines, so it can be generic enough (with in linux_entry() have switch cases for specifity in each file system)
[10:04] <cjwatson> Anyway, don't get me wrong, I'm glad to see work being done here, the particular shape of it just caught me by surprise as somebody who cares about the packaging being long-term sustainable
[10:05] <didrocks> We thought having a separate script will make it more maintainable, but I get you. Anyway, upstreaming is part of the plan and we'll ensure we have most of it upstream. Then, I will need to have official work time on merging with 10_linux as this will mean: more tests to write (we have 396 only on 10_linux_zfs) and I guess a month of refactoring for 10_linux
[10:08] <cjwatson> Sorry, if anyone had asked me earlier I would have said a separate script would make it less maintainable, without a second's hesitation
[10:08] <cjwatson> Some kind of upstream test framework for the grub.d scripts would be fantastic
[10:09] <cjwatson> I know there's been some talk upstream about a project to rewrite the whole grub-mkconfig structure (again), but I don't know how far it's got
[10:16] <didrocks> cjwatson: if I don't include Makefile.in and Makefile.util.am, debian/rules clean (and so debuild -S) is failing due to those files being modified before creating the source package
[10:20] <cjwatson> didrocks: Only if you've first done a build in-tree
[10:20] <cjwatson> In fact I think only if you've run ./autogen.sh in-tree
[10:20] <cjwatson> If you do it via the debian/rules machinery then clean should revert those changes, via dh_autoreconf_clean
[10:21] <cjwatson> It is not standard practice in this package to patch the autogenerated files, so it definitely works in general
[10:21] <didrocks> cjwatson: hum, I have a clean git checkout (without any modifications), I modified debian/patches/zfs_enhance_support.patch to remove those 2 files patches and I run debuild -S
[10:21] <cjwatson> See e.g. restore-mkdevicemap.patch
[10:21] <cjwatson> Did you actually revert the patches too rather than just removing them from the patch file?
[10:22] <cjwatson> Anyway, just telling you what standard practice is
[10:22] <cjwatson> You can look at the other patches for proof
[10:23] <didrocks> cjwatson: no patch is applied, no local modification, I remove Makefile.in and Makefile.util.am from debian/patches/zfs_enhance_support.patch, and then debuild -S, what is wrong in that workflow?
[10:25] <cjwatson> I don't know, sorry, you'll have to work it out yourself.  I use git-dpm in Debian which may not be in use for the Ubuntu packaging
[10:25] <cjwatson> Sounds like your local tree isn't quite clean
[10:26] <didrocks> let me try a fresh checkout, maybe the file which triggers this behavior is in .gitignore
[10:26] <didrocks> but I was told by cyphermox to use the git-dpm branch, but to build the source package with debuild -S
[10:27] <cjwatson> That's what I do in Debian
[10:27] <cjwatson> You don't need a fresh checkout
[10:27] <cjwatson> Look at git ignored files
[10:27] <didrocks> yeah, that's what I will try to purge and not only rely on git st
[10:27] <cjwatson> e.g. git clean -dfx will probably sort it out
[10:27] <cjwatson> Assuming you have nothing uncommitted that you want to keep in that tree :)
[10:27] <didrocks> well, I did my cp first ;)
[10:28] <didrocks> git clean -dfx doesn't do it, let me try to inspect any ignored files directly
[10:29] <cjwatson> So wait, you're using git-dpm but you hacked the .patch file directly?
[10:29] <didrocks> just for testing before committing
[10:29] <cjwatson> That seems unlikely to work well.
[10:29] <cjwatson> The files will still be modified in the working tree.
[10:29] <cjwatson> Use git-dpm properly
[10:30] <didrocks> why, "debuild -S" has no idea of git dpm?
[10:30] <cjwatson> You have a category error
[10:30] <cjwatson> It doesn't work that way
[10:30] <didrocks> and cyphermox told me that for this package, just use debuild -S to build the source package
[10:30] <cjwatson> Which is correct, but not if the working tree has been deliberately made out of sync with debian/patches/ ...
[10:30]  * didrocks is more familiar with gbp
[10:30] <cjwatson> git-dpm is a patches-applied workflow
[10:31] <cjwatson> Things will not go well if you modify .patch files by hand in a way that makes them not be in sync with the working tree
[10:31] <didrocks> ah? so debuild -S knows about git dpm and the applied commits?
[10:31] <cjwatson> No, it doesn't have to
[10:31] <cjwatson> The working tree has patches applied
[10:32] <didrocks> ah, indeed, even in the ubuntu branch, I thought it was only after a checkout-patched command
[10:32] <cjwatson> git-dpm checkout-patched; git rebase -i <whatever the corresponding upstream ref is>; edit the patch in question using git; git rebase --continue; git-dpm update-patches
[10:32] <didrocks> ok, makes sense then, so I'll refresh the patch even for testing
[10:33] <cjwatson> OK, that explains the confusion if you didn't realise it was patches-applied
[10:33] <didrocks> yeah, I was thinking with the gbp model, which is different
[10:33] <didrocks> ok, so let me rebase and test
[10:38] <didrocks> cjwatson: ok, so all good now. I was really at 100 feets of thinking the ubuntu branch would be patch-applied (I thought only patched-ubuntu was, after checkout-patched). No more issue know. let me just stage that in tree. Thanks and sorry for the confusion
[10:41] <juliank> not sure if I want to fix goplay on ppc64el (spurious? uninitialized variable error) or just ask for removal
[10:41] <juliank> like last update in debian was me nmuing it in 2015
[10:46] <cjwatson> didrocks: Cool, thanks
[11:00] <juliank> Qt question:
[11:00] <juliank> No rule to make target 'string', needed by '.ui/ui_debtagssettingswidget.h'.  Stop.
[11:00] <juliank> packagesearch fails to build like that
[11:01] <juliank> Anyone has an idea?
[11:01] <juliank> hmm
[11:02] <juliank> it's written like that in the Makefile
[11:02] <juliank> that qmake generated
[11:03] <juliank> why would qmake make that file depend on set and string, standard C++ headers?
[11:04] <juliank> there are includes for that in the .ui file, but it seems like a bug in qmake to turn   <include location="global" >string</include> into a <file>: string depends
[11:13] <juliank> nvm, I removed the include lines and it worked
=== md_5- is now known as md_5
=== ricab is now known as ricab|lunch
=== ricab|lunch is now known as ricab
=== laptop20 is now known as laptop2
[14:01] <seb128> bdmurray, hey, do you have any idea why bug #1820130 is showing on https://people.canonical.com/~ubuntu-archive/pending-sru.html for disco but not bionic?
[14:01] <ubottu> bug 1820130 in modem-manager-gui (Ubuntu Disco) "[SRU] modem-manager-gui fails to start after modemmanager is upgraded to 1.10.0-1" [Undecided,Fix committed] https://launchpad.net/bugs/1820130
[14:04] <bdmurray> seb128: looking
[14:04] <seb128> bdmurray, thx
[14:06] <bdmurray> seb128: there's nothing obvious I'll run the report locally and see if I can sort it out
[14:07] <seb128> bdmurray, thx
[14:16] <seb128> juliank, bug #1766890 has been assigned to you since august 2018 ... do you still plan to work on it? if not it might be worth wontfixing it or unassigning as appropriate?
[14:16] <ubottu> bug 1766890 in gnome-menus (Ubuntu) "package gnome-menus 3.13.3-6ubuntu3.1 failed to install/upgrade: triggers looping, abandoned" [Critical,Confirmed] https://launchpad.net/bugs/1766890
[14:17] <juliank> seb128: closing as invalid
[14:18] <seb128> juliank, thx
=== jdstrand_ is now known as jdstrand
[15:21] <bdmurray> seb128: I don't know what happened but it self resolved.
[18:54] <mdeslaur> infinity, stgraber, vorlon, kees: TB meeting in 6m
[19:53] <seb128> bdmurray, thx for checking, good that it autoresolved :)
[20:07] <vorlon> mdeslaur: sorry for missing, feeling a bit under the weather today :/