| xnox | apw, could you for shits and giggles try a build of zfs=true everywhere? e.g. all the 32bit platforms too. | 00:09 |
|---|---|---|
| xnox | looking the disk-layout code, the structure on disk is arch intendant as far as i can see. | 00:10 |
| xnox | independant | 00:10 |
| apw | xnox, its meant to be very kva agressive and not recommended for use on 32bit, iirc the discussion | 00:10 |
| apw | xnox, which is why we didn't enable it there | 00:10 |
| xnox | apw, and we are a nanny state? =) | 00:11 |
| rlaager | I'm looking to bisect a kernel bug. I've narrowed it down to two mainline kernel packages, but now I need to build my own packages with intermediate commits. I have a checkout of the mainline sources with patches applied per: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.5-rc7-wily/README | 03:49 |
| rlaager | How do I actually build this thing? The usual `debuild -uc -us` I would use fails because there is no debian/changelog. There's both a debian/ and debian.master directory after applying the patches. | 03:49 |
| === shuduo-afk is now known as shuduo | ||
| apw | rlaager, you need to clean the tree to get debian/control ... fakeroot debian/rules clean | 04:53 |
| rlaager | apw: Thanks. I'm mid-build using a different set of instructions, so hopefully they work sufficiently for this attempt. I'll try that on the next build. | 04:54 |
| tamil | Hi all,i am just a beginner ...i want to know how to develop our own ubuntu.... | 10:59 |
| apw | tamil, your own ubuntu en-toto or a specific piece | 11:02 |
| tamil | specific piece.... | 11:04 |
| tamil | i want to develop a kernel | 11:05 |
| tamil | sorry for my wrong words... | 11:06 |
| tamil | how to simulate that .... | 11:06 |
| apw | arple | 11:19 |
| AndreeeCZ | join #zeromq | 11:46 |
| AndreeeCZ | sry | 11:46 |
| apw | heh, happens to the best of us about 3 times a day | 11:46 |
| Skuggen | At least it wasn't a password :P | 11:47 |
| apw | having the same spot be the command line for your irc client and where you type to send, is dumb | 11:47 |
| apw | done that more than once too | 11:47 |
| xnox | apw, ship it, it looks good. | 15:38 |
| apw | xnox, what where when why ? | 15:38 |
| xnox | userspace tooling and dkms have migrated | 15:38 |
| xnox | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1519814 | 15:38 |
| ubot5 | Launchpad bug 1519814 in linux (Ubuntu Xenial) "spl/zfs fails to build on s390x" [Medium,In progress] | 15:38 |
| apw | xnox, ok next week being beta is a big worry for this, so i am going to propose we pump the kernel with that enabled (and i will try and make ppc build too, a packaging bu) | 15:48 |
| apw | xnox, and use the beta freeze week to get cking to hammer one or both to death, if they pass his scruitiny then we apply it and upload as the freeze ends | 15:49 |
| xnox | ack. | 15:49 |
| tseliot | rtg, apw: when do you plan on pulling in v4.4.6 ? | 16:09 |
| apw | tseliot, depends on beta as much as anything, but expect it likely in the next upload | 16:10 |
| apw | tseliot, what you needing from it | 16:10 |
| tseliot | apw: 53e609099daa023ad7771ec8351202f2a7bee1c1 and 6f0679556b563bcd3d433d5781454123f1d134c5 should be already there. I would need to add f8456804460f5c232f097e72051beea063f16074 on top of that | 16:11 |
| tseliot | (fixes for amdgpu, all from linux-stable) | 16:11 |
| apw | you are saying that even with .6 applied you need to request one more fix ? | 16:12 |
| apw | tseliot, ^ | 16:15 |
| tseliot | apw: yes, it seems like it | 16:15 |
| apw | rtg, ^ (as you are likely already applying it) | 16:15 |
| apw | tseliot, perhaps yuo could file a bug for that new one, so we can track it | 16:15 |
| tseliot | apw: sure | 16:16 |
| apw | now we are past ff we do need to be keeping better track of what we are applying and bugs are good for that | 16:16 |
| tseliot | I'll link it to the upstream report too https://bugzilla.kernel.org/show_bug.cgi?id=113891 | 16:17 |
| ubot5 | bugzilla.kernel.org bug 113891 in Video(DRI - non Intel) "[radeon] Display jitter" [High,Assigned] | 16:17 |
| awreece__ | When I run iostat -x, the disk utilization (and await, and queue size, etc) reported for md0 (my raid0 device) are all 0. Is this expected, and if so, why? | 16:23 |
| tseliot | apw, rtg: https://bugs.launchpad.net/linux/+bug/1558656 | 16:24 |
| ubot5 | Launchpad bug 1558656 in linux (Ubuntu) "[radeon] Display jitter" [High,Triaged] | 16:24 |
| apw | awreece__, that i assume is s/w raid, so all the real devices are underneath no ? | 16:25 |
| tseliot | apw: do I need to send the patch myself or is the bug report enough? | 16:29 |
| awreece__ | apw: yeah, I assume so | 16:30 |
| awreece__ | I believe md0, etc all are software raid | 16:31 |
| apw | tseliot, you would expedite the world if you send it | 16:31 |
| tseliot | apw: pull request or a simple patch? | 16:31 |
| apw | simple patch is fine | 16:32 |
| tseliot | ok, good | 16:32 |
| mamarley | apw: How often do those uploads occur? I hadn't noticed any sort of pattern, and https://wiki.ubuntu.com/Kernel/StableReleaseCadence doesn't seem to have information about development releases. | 16:42 |
| tseliot | apw: actually, never mind, that patch seems to be included too. Sorry for the noise | 16:51 |
| tseliot | rtg: ^ | 16:51 |
| lamont | jsalisbury: latest kernel makes me want to ask for another one... | 17:05 |
| lamont | jsalisbury: can I get the commitreverted kernel with the fix as-landed added? | 17:05 |
| lamont | jsalisbury: what I see now is that if the screen blanks (may require locking, but mine always locks before it blanks...), then anything on the right side of the top left workspace magically moves to the left side of the workspace to the right... This is not success, but I want to figuyre out if it's part of the original bug, or something new. (I expect that it's the former) | 17:06 |
| jsalisbury | lamont, So you want the kernel from comment #29 with the fix that just went into Xenial? | 17:16 |
| lamont | jsalisbury: that exactly | 17:18 |
| jsalisbury | lamont, sure, I'll build one and send you a link | 17:19 |
| lamont | ta | 17:19 |
| lamont | jsalisbury: my suspicion: with the just landed fix, the X server believes (sometime after screen blank, or maybe when it unblanks...) that we shifted from dual-head to single-head and then back | 17:20 |
| lamont | which would mean "still not done" | 17:20 |
| lamont | and I hope it's that, because bisecting it would be a royal PITA | 17:21 |
| jsalisbury | yeah | 17:21 |
| lamont | since it's "bisect and then add the just-landed commit" for each time | 17:21 |
| lamont | jsalisbury: thanks for the kernel -- it'll be tomorrow before I can test it | 21:50 |
| lamont | will advise in the bug | 21:50 |
| xnox | sbeattie, please stop! | 23:54 |
| xnox | sbeattie, you are doing too much! | 23:54 |
| xnox | sbeattie, from IBM we have two architectures: ppc64el and s390x. One is with powerpc64le tag the other is s39064. | 23:55 |
| xnox | sbeattie, s390x only exists in xenial, it's a brand new arch. | 23:55 |
| xnox | sbeattie, thus any bugs from "skipper" team or with tag architectures-s39064 or tag s390x do _not_ need any SRUs or backporting at all. | 23:56 |
| xnox | e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1556141 | 23:56 |
| ubot5 | Launchpad bug 1556141 in linux-raspi2 (Ubuntu Xenial) "s390/mm: four page table levels vs. fork" [Medium,New] | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!