[01:09] 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] sparr: is the config in /boot/config-`uname -r` ? [01:13] if so, copy that config to .config in your kernel tree, then make oldconfig [04:45] sarnold: when make prompts something with (NEW) that means the option didn't exist in the previous config? [04:45] yeah [04:47] ok, after make oldconfig and answering the one new thing? [04:50] build kernel as needed :) [04:52] 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] 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] installing build-essential and then starting the build and fixing errors as they occur will probably get you pretty far [04:55] thanks, picking through dependencies like libssl now [04:55] drives me nuts when the name of a library doesn't match the name of the package (openssl vs libssl) [04:56] 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] I guess I should count myself lucky that I couldn't continue without the right onw [06:03] 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] 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] cpaelzer: qemu-system-arm/amd64 unsatisfiable Depends: libvirglrenderer0 (>= 0.7.0) [11:24] doko: that has a MIR https://bugs.launchpad.net/ubuntu/+source/virglrenderer/+bug/1657409 [11:24] Launchpad bug 1657409 in virglrenderer (Ubuntu) "[MIR] virglrenderer" [Medium,In progress] [11:25] doko: do you have time to do the override? [11:25] I have updated the MIR bug to make clear that the upload triggering it now is intentional [11:34] cpaelzer: done [12:31] cpaelzer: libsys-virt-perl autopkg test failure === Sir_Gallantmon is now known as Son_Goku [13:02] oSoMoN: lo needs https://cgit.freedesktop.org/libreoffice/core/commit/?id=635b38704594851648f359477b53f2224b9e6ee1 for openjdk 11.0.2 [13:08] doko, ack [13:37] thanks doko [13:38] 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] 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? === ricab is now known as ricab|lunch [14:28] oSoMoN: there are some autopkg test failures, but nothing blocking afaics [14:36] rbasak: pacemaker would need a merge, there are some dep-waits in proposed [14:38] doko: how do I find the dep-waits please? [14:39] rbasak: http://qa.ubuntuwire.org/ftbfs/ [14:40] doko: pacemaker doesn't appear there though? [14:40] no, but dlm [14:41] Just dlm? [14:41] We're looking into whether we want to merge pacemaker 2 this cycle, or if it's too close to feature freeze. [14:42] So knowing what's impacted would be helpful. [14:42] mdeslaur, http://debomatic-amd64.debian.net/distribution#unstable/libcaca/0.99.beta19-2/buildlog can you please open a debian bug too? :) [14:43] we might go back in sync :) [14:51] LocutusOfBorg: sure, debian bug 920442 [14:51] Debian bug 920442 in libcaca "libcaca FTBFS in unstable" [Serious,Open] http://bugs.debian.org/920442 [14:51] LocutusOfBorg: thanks === ricab|lunch is now known as ricab [15:58] 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] thanks mdeslaur :) [16:15] doko: thanks for checking. I'll get on to it when I'm back at work on Tuesday. [16:28] The following tests FAILED: [16:28] 372 - mir_umock_unit_tests.EvdevInputPlatform.* (Failed) [16:28] 376 - mir_umock_unit_tests.DeviceHandling/EvdevInputPlatform.* (Failed) [16:29] 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] doko: oh! That's fixed in trunk. [16:31] I guess we've now got the systemd version which exposes that bug. [16:31] so better upload a patch... [16:32] RAOF: could you point me to that patch? [16:32] Yup! The patch should apply without problems. [16:32] Let me get out my laptop... [16:32] and building with -DMIR_USE_PRECOMPILED_HEADERS=OFF for now ... [16:37] doko: https://github.com/MirServer/mir/commit/c845095f291af00d94ea3918e41a59509bd29509 [16:48] RAOF: https://launchpad.net/ubuntu/+source/mir/1.0.0-0ubuntu7 [16:49] Ta. [16:49] Oh! Does this mean the yaml-cpp MIR has been resolved? [16:56] no, not yet. so maybe I re-upload 0.32 this weekend. not sure [17:00] should https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel still be accurate? [17:01] I got to the fakeroot step and ended up with "/usr/bin/fakeroot: 175: /usr/bin/fakeroot: debian/rules: not found" [17:01] possibly because I'm fetching a mainline kernel source instead of from the release git [17:19] rbasak: is the pcre2 thing needed before 19.04 release? I.E. release-critcal for this cycle? [17:21] teward: definitely no, there are many main things that will still be using pcre3 for 19.04 and probably 19.10 too [17:22] jbicha: that's what I thought. [17:22] 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] and I"m not familiar enough with either PCRE to do patches for thsoe changes :P [17:23] it it were that easy to kill pcre3 in main, the pcre2 MIR would have been approved a long time ago [17:31] indeed [17:38] 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] sparr: if you're doing mainline, another outdated guide might help: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild [17:59] but I think it still works.. [18:00] thanks, I'll try it [18:00] also trying to figure out how to apply https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0-rc2/0001-base-packaging.patch [18:03] 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] your wiki page wants me to do git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git which fails :( [18:05] lucid is old, no? [18:05] oh god, is this a full kernel source? that's a 4 hour clone [18:07] this is the fourth full copy of the kernel source I've had to download, three from git :( [18:08] 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] rbasak: ack. [18:08] that's why i inquired as to the criticality of it [18:08] jbicha's note that there's a ton still using pcre3 makes sense :P [18:08] Yeah [18:08] i'm sure not all upstreams want to move off pcre3, too, because of different API and such [18:08] Before the next LTS would be nice but I'm not sure if that'll happen. [18:08] 20.04 you mean [18:08] Yes [18:09] 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] gQuigs: stuck at `cp -a /usr/share/kernel-package ubuntu-package` because I don't have /usr/share/kernel-package [18:18] oh, sorry, I missed that that guide has a couple of extra packages to install [18:26] then actually failing on "cp ubuntu-cosmic/debian/control-scripts/{postinst,postrm,preinst,prerm} ubuntu-package/pkg/image/" [18:26] no such files [18:40] sparr: ahh, sorry, I thought you wanted to just do the make -j ... bzImage modules install step to get your kernel.. [18:41] 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] I am worried about producing a kernel or package (including initrd and grub settings) that do not well match my current kernel [19:02] 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] if you just add more remotes to an existing git clone then it shouldn't be anything like as much to download [19:04] ^^^^ 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] 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] 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] thank you for the idea, though [19:08] sparr: what is it you're trying to build, is this for the i915 glitch? [19:09] yes, for the i915 glitch [19:11] trying to build https://cgit.freedesktop.org/drm-tip/ at commit d0757afd00d71dca98268d09884dc6248743d8ce [19:13] which I *think* I have just started compiling, after accidentally doing a full compile of 5.0-rc3 [19:17] 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] 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] 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] TJ-: more responses in #intel-gfx, hard to keep track of which channel you're asking in [19:28] I can continue or repeat here? [19:28] sparr: hehe sorry, it is a bit difficult to decide which is more appropriate! [19:31] I am tempted to start over [19:31] I've downloaded and copied so many things so many places now that I've lost track [19:31] lost track to the point that I ran an entire successful kernel build... on the wrong directory [19:31] or to just give up [19:32] 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] 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] I currently have 3 kernel sources checked out, drm-tip, ubuntu-cosmic, and mainline v5.0-rc2 [19:40] 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] (oddly, it build rc3, which I don't remember checking out) [19:54] 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] now, back to #intel-gfx... [22:19] ah crap, cannot edit it here [22:22] ?