| === ricab_ is now known as ricab | ||
| 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:42 |
|---|---|---|
| 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:43 | |
| jibel | xnox, thx | 09:45 |
| didrocks | xnox: ah, good to know! Thanks! Is it documented anywhere? | 09:45 |
| didrocks | so that I can add a bookmark for my own self next time :p | 09:46 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| cjwatson | IMO to be upstreamable it must be integrated into 10_linux properly | 09:56 |
| cjwatson | (Also, a minor point: zfs_enhance_support.patch shouldn't patch the autogenerated files Makefile.in and Makefile.util.am) | 09:57 |
| 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:58 |
| didrocks | if my manager acks some time to do this, yes | 09:59 |
| didrocks | (and ack on Makefile.in, will fix this) | 09:59 |
| 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:00 |
| 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:01 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:08 |
| 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:09 |
| 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:16 |
| 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:20 |
| 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:21 |
| cjwatson | Anyway, just telling you what standard practice is | 10:22 |
| cjwatson | You can look at the other patches for proof | 10:22 |
| 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:23 |
| 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:25 |
| 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:26 |
| 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:27 |
| didrocks | git clean -dfx doesn't do it, let me try to inspect any ignored files directly | 10:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:38 |
| 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:41 |
| cjwatson | didrocks: Cool, thanks | 10:46 |
| 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:00 |
| juliank | Anyone has an idea? | 11:01 |
| juliank | hmm | 11:01 |
| juliank | it's written like that in the Makefile | 11:02 |
| juliank | that qmake generated | 11:02 |
| juliank | why would qmake make that file depend on set and string, standard C++ headers? | 11:03 |
| 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:04 |
| juliank | nvm, I removed the include lines and it worked | 11:13 |
| === 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 | ||
| 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:01 |
| bdmurray | seb128: looking | 14:04 |
| seb128 | bdmurray, thx | 14:04 |
| bdmurray | seb128: there's nothing obvious I'll run the report locally and see if I can sort it out | 14:06 |
| seb128 | bdmurray, thx | 14:07 |
| 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:16 |
| juliank | seb128: closing as invalid | 14:17 |
| seb128 | juliank, thx | 14:18 |
| === jdstrand_ is now known as jdstrand | ||
| bdmurray | seb128: I don't know what happened but it self resolved. | 15:21 |
| mdeslaur | infinity, stgraber, vorlon, kees: TB meeting in 6m | 18:54 |
| seb128 | bdmurray, thx for checking, good that it autoresolved :) | 19:53 |
| vorlon | mdeslaur: sorry for missing, feeling a bit under the weather today :/ | 20:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!