[01:09] <sparr> I need to build a kernel from https://cgit.freedesktop.org/drm-tip/tree/ with all the same options and modules that my current kernel has (https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0-rc2/). Is there a guide on how to do that?
[01:11] <sarnold> sparr: is the config in /boot/config-`uname -r` ?
[01:13] <sarnold> if so, copy that config to .config in your kernel tree, then make oldconfig
[04:45] <sparr> sarnold: when make prompts something with (NEW) that means the option didn't exist in the previous config?
[04:45] <sarnold> yeah
[04:47] <sparr> ok, after make oldconfig and answering the one new thing?
[04:50] <sarnold> build kernel as needed :)
[04:52] <sparr> how can I find the build dependencies for my kernel(s) when none of my installed kernel packages have source packages for doing apt-get build-dep on?
[04:53] <sarnold> the Documentation/Changes file lists the *programs* you need; that might not translate easily to *packages* to install, but it should be pretty close
[04:53] <sarnold> installing build-essential and then starting the build and fixing errors as they occur will probably get you pretty far
[04:55] <sparr> thanks, picking through dependencies like libssl now
[04:55] <sparr> drives me nuts when the name of a library doesn't match the name of the package (openssl vs libssl)
[04:56] <sarnold> heh, the number of times people have installed just an openssl pckage update and missed the libssl package -- which actually fixes the security bug..
[04:57] <sparr> I guess I should count myself lucky that I couldn't continue without the right onw
[06:03] <sparr> sarnold: if I started with source not from an ubuntu package so I don't have a debian/rules directory for fakeroot, what's the actual build step?
[06:04] <sparr> the guide I'm using wants me to do "fakeroot debian/rules binary-headers binary-generic binary-perarch" but debian/rules doesn't exist
[10:11] <doko> cpaelzer: qemu-system-arm/amd64 unsatisfiable Depends: libvirglrenderer0 (>= 0.7.0)
[11:24] <cpaelzer> doko: that has a MIR https://bugs.launchpad.net/ubuntu/+source/virglrenderer/+bug/1657409
[11:25] <cpaelzer> doko: do you have time to do the override?
[11:25] <cpaelzer> I have updated the MIR bug to make clear that the upload triggering it now is intentional
[11:34] <doko> cpaelzer: done
[12:31] <doko> cpaelzer: libsys-virt-perl autopkg test failure
[13:02] <doko> oSoMoN: lo needs https://cgit.freedesktop.org/libreoffice/core/commit/?id=635b38704594851648f359477b53f2224b9e6ee1  for openjdk 11.0.2
[13:08] <oSoMoN> doko, ack
[13:37] <cpaelzer> thanks doko
[13:38] <cpaelzer> I'll look into test errors as usual, but it most likely will be monday until I get more time to really work on it
[14:05] <oSoMoN> doko, LO 6.2.0 is due out next week, so I'll apply the patch there, I won't rebuild 6.1.4, unless really needed?
[14:28] <doko> oSoMoN: there are some autopkg test failures, but nothing blocking afaics
[14:36] <doko> rbasak: pacemaker would need a merge, there are some dep-waits in proposed
[14:38] <rbasak> doko: how do I find the dep-waits please?
[14:39] <doko> rbasak: http://qa.ubuntuwire.org/ftbfs/
[14:40] <rbasak> doko: pacemaker doesn't appear there though?
[14:40] <doko> no, but dlm
[14:41] <rbasak> Just dlm?
[14:41] <rbasak> We're looking into whether we want to merge pacemaker 2 this cycle, or if it's too close to feature freeze.
[14:42] <rbasak> So knowing what's impacted would be helpful.
[14:42] <LocutusOfBorg> mdeslaur, http://debomatic-amd64.debian.net/distribution#unstable/libcaca/0.99.beta19-2/buildlog can you please open a debian bug too? :)
[14:43] <LocutusOfBorg> we might go back in sync :)
[14:51] <mdeslaur> LocutusOfBorg: sure, debian bug 920442
[14:51] <mdeslaur> LocutusOfBorg: thanks
[15:58] <doko> RAOF, xnox: mir is now back again to happily ftbfs in the tests ... trying if the version in the release pocket still works ...
[16:06] <LocutusOfBorg> thanks mdeslaur :)
[16:15] <RAOF> doko: thanks for checking. I'll get on to it when I'm back at work on Tuesday.
[16:28] <doko> The following tests FAILED:
[16:28] <doko> 	372 - mir_umock_unit_tests.EvdevInputPlatform.* (Failed)
[16:28] <doko> 	376 - mir_umock_unit_tests.DeviceHandling/EvdevInputPlatform.* (Failed)
[16:29] <doko> RAOF: ^^^ I'll upload with ignoring the test results, so we have something in the archive which allows me to continue with the migration stuff. btw, these fail in 0.32.1 as well
[16:30] <RAOF> doko: oh! That's fixed in trunk.
[16:31] <RAOF> I guess we've now got the systemd version which exposes that bug.
[16:31] <LocutusOfBorg> so better upload a patch...
[16:32] <doko> RAOF: could you point me to that patch?
[16:32] <RAOF> Yup! The patch should apply without problems.
[16:32] <RAOF> Let me get out my laptop...
[16:32] <doko> and building with -DMIR_USE_PRECOMPILED_HEADERS=OFF for now ...
[16:37] <RAOF> doko: https://github.com/MirServer/mir/commit/c845095f291af00d94ea3918e41a59509bd29509
[16:48] <doko> RAOF: https://launchpad.net/ubuntu/+source/mir/1.0.0-0ubuntu7
[16:49] <RAOF> Ta.
[16:49] <RAOF> Oh! Does this mean the yaml-cpp MIR has been resolved?
[16:56] <doko> no, not yet. so maybe I re-upload 0.32 this weekend. not sure
[17:00] <sparr> should https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel still be accurate?
[17:01] <sparr> I got to the fakeroot step and ended up with "/usr/bin/fakeroot: 175: /usr/bin/fakeroot: debian/rules: not found"
[17:01] <sparr> possibly because I'm fetching a mainline kernel source instead of from the release git
[17:19] <teward> rbasak: is the pcre2 thing needed before 19.04 release?  I.E. release-critcal for this cycle?
[17:21] <jbicha> teward: definitely no, there are many main things that will still be using pcre3 for 19.04 and probably 19.10 too
[17:22] <teward> jbicha: that's what I thought.
[17:22] <teward> just checking to make sure before I ask -release to demote nginx* back to Universe because currently upstream doesn't support pcre2 and doesn't seem to want to redo all the PCRE API stuff since it changes
[17:22] <teward> and I"m not familiar enough with either PCRE to do patches for thsoe changes :P
[17:23] <jbicha> it it were that easy to kill pcre3 in main, the pcre2 MIR would have been approved a long time ago
[17:31] <teward> indeed
[17:38] <sparr> https://help.ubuntu.com/community/Kernel/Compile points to https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel which also seems to be outdated. Is there a newer guide?
[17:58] <gQuigs> sparr: if you're doing mainline, another outdated guide might help: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
[17:59] <gQuigs> but I think it still works..
[18:00] <sparr> thanks, I'll try it
[18:00] <sparr> also trying to figure out how to apply https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0-rc2/0001-base-packaging.patch
[18:03] <gQuigs> if it changes the packaging I wouldn't do it for Git build to work.. . if it's a normal patch just git apply...
[18:04] <sparr> your wiki page wants me to do git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git which fails :(
[18:05] <sparr> lucid is old, no?
[18:05] <sparr> oh god, is this a full kernel source? that's a 4 hour clone
[18:07] <sparr> this is the fourth full copy of the kernel source I've had to download, three from git :(
[18:08] <rbasak> teward: no need to demote nginx yet. I was only talking before about some eventual future time when we're ready to demote pcre3. Only at that future time will we need to care about nginx not having support.
[18:08] <teward> rbasak: ack.
[18:08] <teward> that's why i inquired as to the criticality of it
[18:08] <teward> jbicha's note that there's a ton still using pcre3 makes sense :P
[18:08] <rbasak> Yeah
[18:08] <teward> i'm sure not all upstreams want to move off pcre3, too, because of different API and such
[18:08] <rbasak> Before the next LTS would be nice but I'm not sure if that'll happen.
[18:08] <teward> 20.04 you mean
[18:08] <rbasak> Yes
[18:09] <teward> by that point I can probably persuade NGINX to move on it, because the OSes they're still 'supporting' that don't have PCRE2 die in 2020 :P
[18:17] <sparr> gQuigs: stuck at `cp -a /usr/share/kernel-package ubuntu-package` because I don't have /usr/share/kernel-package
[18:18] <sparr> oh, sorry, I missed that that guide has a couple of extra packages to install
[18:26] <sparr> then actually failing on "cp ubuntu-cosmic/debian/control-scripts/{postinst,postrm,preinst,prerm} ubuntu-package/pkg/image/"
[18:26] <sparr> no such files
[18:40] <sarnold> sparr: ahh, sorry, I thought you wanted to just do the make -j ... bzImage modules install step to get your kernel..
[18:41] <sarnold> sparr: I haven't built my own kernel in ages but last time I did the kernel-package package's make-kpkg command was pretty useful. It's probably a lot faster than *properly* building a .deb package
[19:01] <sparr> I am worried about producing a kernel or package (including initrd and grub settings) that do not well match my current kernel
[19:02] <sparr> I am super annoyed at what seems to have become common practice, to distribute whole copies of the kernel source for small changes to one module :/
[19:03] <cjwatson> if you just add more remotes to an existing git clone then it shouldn't be anything like as much to download
[19:04] <TJ-> ^^^^ this - I have a mainline based repo with about 30 remotes, for the linux-next linux-stable and all ubuntu-XXXX releases etc.
[19:05] <sparr> that would require me to have a much more broad and deep knowledge of the package building process, because I wouldn't be able to follow any guides
[19:06] <sparr> not that the guides are super helpful, since even the most recent official-ish ones seem to be 3-5 years out of date
[19:06] <sparr> thank you for the idea, though
[19:08] <TJ-> sparr: what is it you're trying to build, is this for the i915 glitch?
[19:09] <sparr> yes, for the i915 glitch
[19:11] <sparr> trying to build https://cgit.freedesktop.org/drm-tip/ at commit d0757afd00d71dca98268d09884dc6248743d8ce
[19:13] <sparr> which I *think* I have just started compiling, after accidentally doing a full compile of 5.0-rc3
[19:17] <sparr> drm-tip on  d0757af $ CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-custom --overlay-dir=../ubuntu-package kernel_image kernel_headers
[19:19] <sparr> except that it's not visibly doing much and pstree reports "conf" has been running for a while now. fakeroot───make-kpkg───sh───make───sh───make───make───make───conf
[19:26] <TJ-> sparr: I generally use the kernel's own package-build targets (e.g. bindeb-pkg) - and I disable generating the debug-symbol packages to save time/space for non-gdb testing (in scripts/package/mkdebian, removing then code for $packagename-dbg  )
[19:28] <sparr> TJ-: more responses in #intel-gfx, hard to keep track of which channel you're asking in
[19:28] <sparr> I can continue or repeat here?
[19:28] <TJ-> sparr: hehe sorry, it is a bit difficult to decide which is more appropriate!
[19:31] <sparr> I am tempted to start over
[19:31] <sparr> I've downloaded and copied so many things so many places now that I've lost track
[19:31] <sparr> lost track to the point that I ran an entire successful kernel build... on the wrong directory
[19:31] <sparr> or to just give up
[19:32] <sparr> I only have to deal with this laptop for another few weeks, then I can switch to nvidia graphics and not look back
[19:32] <sparr> if someone thinks it's worth walking me through the process to get a good bug report to improve the intel drivers, I'm game, but it has passed the point where it's worth my time to keep trying alone for just my own benefit.
[19:36] <sparr> I currently have 3 kernel sources checked out, drm-tip, ubuntu-cosmic, and mainline v5.0-rc2
[19:40] <sparr> I actually managed to get v5.0-rc2 to build with some tweaks and skipped steps from these instructions: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
[19:43] <sparr> (oddly, it build rc3, which I don't remember checking out)
[19:54] <sparr> ok, after doing some magical incantations with the moon in a slightly different phase than before, I seem to have drm-tip building
[19:57] <sparr> now, back to #intel-gfx...
[22:19] <hggdh> ah crap, cannot edit it here
[22:22] <sladen> ?