| === balloons is now known as Guest90681 | ||
| === tlyu_ is now known as tlyu | ||
| === nudtrobert1 is now known as nudtrobert | ||
| pitti | Good morning | 05:08 |
|---|---|---|
| === nudtrobert1 is now known as nudtrobert | ||
| === nudtrobert1 is now known as nudtrobert | ||
| dholbach | good morning | 07:27 |
| seb128 | hey dholbach | 07:27 |
| dholbach | hey seb128 | 07:27 |
| dholbach | @pilot in | 07:27 |
| === udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach | ||
| seb128 | dholbach, good way to start the week ;-) | 07:28 |
| dholbach | :) | 07:28 |
| seb128 | dholbach, I'm going to do a shift this week as well, now that xenial is open we can upload things | 07:28 |
| dholbach | nice | 07:28 |
| darkxst | seb128, dholbach one of these days I will do a patch pilot shift ;) | 08:02 |
| seb128 | ;-) | 08:02 |
| dholbach | go go go! | 08:02 |
| dholbach | :) | 08:02 |
| darkxst | how would one add it to the calender? | 08:10 |
| seb128 | dholbach, ^ | 08:20 |
| dholbach | darkxst, you'd be the first non-Canonical person to enter :-) | 08:22 |
| dholbach | darkxst, on https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews?action=raw I added all the folks who are in Canonical who are part of the patch pilot scheme and I regularly create schedule: basically I just go from top to bottom and create an all-day event for folks - everyone's free to move it to another day or do as they please - it's mostly a reminder for folks to not forget their pilot shift | 08:23 |
| dholbach | darkxst, I'm happy to add you to it :) | 08:23 |
| seb128 | pitti, can you skip the kcoreaddons test that block shared-mime-info? that doesn't seem to have anything to do with it | 08:24 |
| seb128 | "cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C" | 08:24 |
| pitti | right, that looks like it needs to be fixed in kcoreaddons itself | 08:25 |
| pitti | seb128: done | 08:26 |
| LocutusOfBorg1 | hi folks, can anybody please retry boinc/powerpc on xenial? | 08:26 |
| seb128 | pitti, also do you know why atk1.0 deja-dups items are flagged as regression when the current log are "pass"? | 08:26 |
| LocutusOfBorg1 | https://launchpad.net/ubuntu/+source/boinc/7.6.12+dfsg-1/+build/8176050 | 08:26 |
| seb128 | pitti, danke | 08:26 |
| seb128 | LocutusOfBorg1, done | 08:26 |
| pitti | seb128: yes; britney is veeeery slow, so it takes a fair while to catch up | 08:27 |
| seb128 | k | 08:27 |
| pitti | Generated: 2015.10.26 06:12:10 +0000 | 08:27 |
| seb128 | so it's going to autosort itself? | 08:27 |
| pitti | yes | 08:27 |
| seb128 | great | 08:27 |
| seb128 | danke | 08:27 |
| pitti | and snakefruit's load is 27, that doesn't help either :) | 08:27 |
| pitti | every morning there's some "git gc" process which is enormously resource hungy | 08:28 |
| LocutusOfBorg1 | thanks seb128 ! | 08:29 |
| seb128 | LocutusOfBorg1, yw! | 08:29 |
| darkxst | dholbach, sure why not, can only help my quest for core-dev | 08:29 |
| LocutusOfBorg1 | I'm still wondering why wx wasn't installable, but it seems now | 08:30 |
| darkxst | random dates won't work though | 08:30 |
| dholbach | ok | 08:31 |
| darkxst | dholbach, can do about nowish mon-wed | 08:32 |
| dholbach | darkxst, if you don't use google calendar - so you would have more control about wherever the shift goes, I could just send you a reminder once a month - would that work? | 08:33 |
| seb128 | dholbach reviews desktop code merges now ;-) | 08:34 |
| dholbach | seb128, somebody has to do it :-P | 08:34 |
| pitti | infinity: I already merged util-linux some three weeks ago in my PPA, so I'm stealing your merge | 09:10 |
| xnox | doko: looks like a charming CMake way to say I don't like Mondays after the clock change =) | 09:21 |
| xnox | doko: it built none-the-less no? https://launchpad.net/ubuntu/+source/blender/2.75.a+dfsg0-2ubuntu2/+build/8187750 | 09:28 |
| zyga | good morning | 09:38 |
| seb128 | bdmurray, hey, do you have any idea about what's wrong with the retracing from https://errors.ubuntu.com/problem/a93e2f9c2eb0609a371e49d66ea4f99676bfe0a0 | 09:41 |
| seb128 | https://errors.ubuntu.com/problem/f56ac1ed80490e348e35a741110483c2c1108860 as well | 09:41 |
| seb128 | https://errors.ubuntu.com/problem/4dcfd17e064c21fad59ef326eb44f171c90cfe79 | 09:42 |
| === _morphis is now known as morphis | ||
| === oSoMoN_ is now known as oSoMoN | ||
| dholbach | @pilot out | 11:34 |
| === udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === _salem is now known as salem_ | ||
| === mpt_ is now known as mpt | ||
| cjwatson | doko: haskell-*/armhf is failing with "/usr/bin/ld.gold: error: unrecognised output emulation: armelf_linux_eabi" (the string "armelf" appears nowhere in the ghc source package, so not quite sure where this is coming from) - is that a known incompatibility? | 12:01 |
| cjwatson | doko: aha, never mind, I just found https://launchpadlibrarian.net/222806891/binutils_2.25.51.20151022-0ubuntu1_2.25.51.20151022-0ubuntu2.diff.gz | 12:16 |
| ricotz | hi, is there a semi-official gcc 4.9.x backport for trusty? | 12:38 |
| === smoser` is now known as smoser | ||
| tkamppeter | syncpackage does not work for me any more. I am on Wily and I want to sync a Debian unstable package to xenial. | 12:59 |
| tkamppeter | Sorry, I was on the wrong terminal. It is working now. | 13:01 |
| === Guest90681 is now known as balloons | ||
| pitti | apw: linux/i386 now consistently fails with https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/l/linux/20151025_165408@/log.gz | 13:36 |
| pitti | apw: "ImportError: No module named LibAppArmor" and some "not found" on easyprof | 13:37 |
| pitti | apw: amd64 is the same; I'll force-badtest it for now | 13:37 |
| pitti | apw: want a bug about it? | 13:37 |
| doko | xnox, no, that's with the one reverted to 3.2.2 | 13:39 |
| xnox | =( | 13:39 |
| pitti | doko: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python-jsonschema/20151026_131540@/log.gz started failing with "ImportError: No module named functools32"; does that ring a bell? | 13:40 |
| pitti | (on python 2.7; the python3 test is fine) | 13:41 |
| * pitti uploads the libgif4 -> libgif7 transition to unblock some stuff | 13:44 | |
| mgedmin | functools32 is https://pypi.python.org/pypi/functools32 | 13:44 |
| mgedmin | presumably on python3 it can use functools from the stdlib | 13:44 |
| mgedmin | wily has http://packages.ubuntu.com/wily/python-functools32 | 13:44 |
| mgedmin | missing dependency? | 13:45 |
| doko | pitti, why is a package building only a python2 module running python3 tests? | 13:46 |
| pitti | doko: Binary: python-jsonschema, python3-jsonschema | 13:46 |
| pitti | thanks mgedmin ; I'll have a look at the package | 13:47 |
| pitti | doko: right, so I indeed think python-jsonschema is missing a python-functools32 dep, I'll loko into it | 13:47 |
| pitti | so nevermind, I didn't realize it wasn't an internal module | 13:47 |
| doko | jamespage, lifeless, barry, pitti: looks like openstack let's bitrot these forks of the standard library. seen before | 13:48 |
| doko | pitti, python-jsonschema is dep-wait, write a MIR ;) | 13:49 |
| barry | doko, lifeless, jamespage how badly does openstack need the bleeding edge? | 13:49 |
| pitti | doko: ah, indeed that's it -- the new source in -proposed actually does have Depends: python-functools32, but it doesn't build | 13:49 |
| Odd_Bloke | infinity: cjwatson: wgrant: https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1510095 is needed for moving all of our building in to LP (which is on the powerpc critical path). | 13:50 |
| ubottu | Launchpad bug 1510095 in live-build (Ubuntu) "live-build doesn't know the correct name for kernels in /boot" [Undecided,New] | 13:50 |
| pitti | doko: and yeah, seems madly backporting stuff from python 3 instead of just moving to python 3 :( | 13:50 |
| Odd_Bloke | Next up: preparing a livecd-rootfs patch | 13:50 |
| melodie | hello | 13:50 |
| melodie | I would like to create pool and dist in Bento Openbox, and although I know there are docs about it, I'm not sure it applies to ISOS. Any advice on where to start the right way? | 13:51 |
| cjwatson | Odd_Bloke: will extend a little and apply | 13:53 |
| infinity | Odd_Bloke: Ahh, nice catch. We've never done a ppc64el livefs (other than server, which doesn't install a kernel), so never noticed, I guess. | 13:55 |
| infinity | It would probably make more sense to make the vmlinu[z|x] code just look for both, rather than hardcoding what each arch ships, so we don't have to hunt down what to change if we flip ppc to vmlinuz in the future. | 13:56 |
| infinity | cjwatson: ^ | 13:56 |
| infinity | Currently, some ppc64el boot modes are incapable of booting anything but a coff binary, but that's meant to be fixed $some_day. | 13:57 |
| cjwatson | OK if you make me do that then I don't have time now. | 13:58 |
| cjwatson | But I can apply a trivially extended version of Odd_Bloke's patch now. | 13:58 |
| infinity | cjwatson: Haha. No. Go ahead and apply his patch, I just need to make a mental note that it's there. | 13:58 |
| cjwatson | OK, done. | 13:58 |
| infinity | cjwatson: I was considering going through the pain of a live-build merge this cycle, so might clean up things like that along the way. | 13:58 |
| cjwatson | Yep. | 13:59 |
| pitti | urgh, new giflib 5 isn't even in Debian yet | 14:00 |
| doko | cjwatson, here is one more haskell issue: https://launchpad.net/ubuntu/+source/gcl/2.6.12-26 (if you would like to have a look, I assume it's triggered by binutils) | 14:37 |
| cjwatson | doko: Pretty sure that's Lisp, not Haskell | 14:40 |
| doko | ouch | 14:40 |
| cjwatson | I have no idea about Lisp stuff, sorry | 14:40 |
| doko | I'll ping camm about it | 14:41 |
| chiluk | mterry, can we get bug 1432871 pushed back into vivid today? I've seen no complaints. | 14:45 |
| ubottu | bug 1432871 in coreutils (Ubuntu Vivid) "`df` shows bind mounts instead of real mounts." [Undecided,In progress] https://launchpad.net/bugs/1432871 | 14:45 |
| chiluk | mterry I'll work on the trusty backport today as well. It's entirely likely that the same patch will simply apply to trusty.. | 14:46 |
| mterry | chiluk, ah yes... ok, will try to upload to vivid today | 14:46 |
| chiluk | mterry patch is https://bugs.launchpad.net/ubuntu/vivid/+source/coreutils/+bug/1432871/comments/9 | 14:47 |
| ubottu | Launchpad bug 1432871 in coreutils (Ubuntu Vivid) "`df` shows bind mounts instead of real mounts." [Undecided,In progress] | 14:47 |
| mterry | chiluk, yeah. And I won't include a merge from Debian that causes a FTBFS this time :) | 14:47 |
| doko | tumbleweed, barry: http://autopkgtest.ubuntu.com/packages/p/python-cffi/xenial/amd64/ the 3.5 tests seem to succeed, the 2.7 tests are failing ... | 14:47 |
| chiluk | mterry lol | 14:47 |
| doko | pitti, http://autopkgtest.ubuntu.com/packages/p/python-astropy/xenial/amd64/ do I interpret it correctly that there's just some stderr output with the 3.5 tests that lets the tests fail? | 14:50 |
| pitti | doko: right; seems easy enough to fix, I'll add it to my list | 14:51 |
| pitti | doko: doesn't seem to be the only blocker left, but if/once it is we can also easily hint it | 14:52 |
| pitti | doko: (I assume you go through p3-defaults) | 14:52 |
| doko | yep | 14:52 |
| pitti | doko: the postgresql-multicorn one is also something different; I'll hint it for now | 14:53 |
| pitti | ah well, I don't want to let the new multicorn in, so I'd rather hint python3-defaults once we analyzed all regressions there | 14:53 |
| tjaalton | huh, 15.10 is not able to resize win10 partitions? | 14:54 |
| tjaalton | or is it because of the nvme device | 14:56 |
| doko | zyga, !!! | 15:03 |
| tumbleweed | doko: yeah, I'm looking at cffi tests | 15:04 |
| bdmurray | seb128: I'll dig into that error. Could you have a look at https://code.launchpad.net/~brian-murray/software-properties/bug-1506169/+merge/275560? | 15:05 |
| doko | zyga, pitti: is this just missing test dependency? but then, why does it succeed on the other archs? http://autopkgtest.ubuntu.com/packages/c/checkbox-support/xenial/armhf/ | 15:05 |
| pitti | doko: python3-dbus is already installed on cloud images (http://cloud-images.ubuntu.com/wily/current/wily-server-cloudimg-amd64.manifest) | 15:06 |
| pitti | doko: so most probably missing test dep, yes | 15:06 |
| pitti | doko: aptdaemon/armhf failure will go to pass in next britney run, FYI | 15:23 |
| doko | mvo, mind looking at http://autopkgtest.ubuntu.com/packages/a/apt-clone/xenial/amd64/ ? | 15:24 |
| pitti | jdstrand: wrt. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/c/click-apparmor/20151026_130250@/log.gz, is "touch: cannot touch ‘/usr/share/click/frameworks/ubuntu-sdk-13.10.framework’: No such file or directory" expected? | 15:24 |
| lifeless | doko: reallu don't appreciate the nasty tone there, since functools32 has taken me nearly a year to get access to update it | 15:25 |
| pitti | mvo, doko: I filed bug 1510060 about that this morning with some initial analysis, but I don't know further from there | 15:25 |
| ubottu | bug 1510060 in apt-clone (Ubuntu) "test regression: TestCloneUpgrade.test_clone_upgrade_synthetic" [High,New] https://launchpad.net/bugs/1510060 | 15:25 |
| jdstrand | pitti: no. I need to look at it | 15:25 |
| pitti | jdstrand: i. e. was the 13.10 framework dropped or so? | 15:25 |
| jdstrand | maybe | 15:26 |
| lifeless | doko: and I haven't had time since getting that access (about 1.5 weeks ago!) to action merging all the fixes and getting a release done. The author, noone to do with OpenStack abandoned it further back than that | 15:26 |
| jdstrand | but I need to look why the touch is being done | 15:26 |
| lifeless | doko: and unittest2 and mock were left abandoned by voidspace, who works @ Canonical on non-Python stuff now | 15:27 |
| lifeless | doko: so I picked them up to help folk, so again, not 'openstack bitrotting forks of stdlib stuff' | 15:27 |
| doko | lifeless, I only see it used by openstack packages | 15:28 |
| lifeless | doko: not sure what that has to do with the upstream maintenance etc | 15:28 |
| lifeless | op, sorry, I was thinking of funcsigs, functools32 is a different one again | 15:29 |
| pitti | doko: apt-clone and apport have force-badtest btw, you can ignore these | 15:29 |
| * doko starts packaging ipython 4.0 | 15:29 | |
| lifeless | doko: which is maintained here - https://github.com/MiCHiLU/python-functools32 - I don't recognise the person as having anything to do with OpenStack | 15:30 |
| jdstrand | pitti: ok, it is simply setting up a minimal framework. I'm guesssing /usr/share/click/frameworks doesn't exist | 15:30 |
| lifeless | barry: generally our minimum versions are either very accurate - bumped when we need a feature not in old versions | 15:30 |
| jdstrand | pitti: ie, it is creating that framework file by touch it | 15:30 |
| lifeless | barry: *or* | 15:30 |
| jdstrand | touching* | 15:30 |
| pitti | jdstrand: right; I just wondered what changed since wily | 15:30 |
| jdstrand | idk | 15:30 |
| lifeless | barry: wild guesses, for new deps where we don't know what minimum version is needed we just pick the current release at the time we add it to the system | 15:30 |
| jdstrand | Depends: @, click | 15:30 |
| jdstrand | click is supposed to ship that dir | 15:31 |
| pitti | jdstrand: note that a whole load of stuff was copied from the overlay PPA to xenial, so it doesn't need to be a change uploded to xenial directly | 15:31 |
| jdstrand | I don't yet have any xenial stuff setup. I was literally just about to do that | 15:31 |
| lifeless | doko: https://pypi.python.org/pypi/functools32 seems to be getting quite some downloads | 15:31 |
| pitti | jdstrand: ok, so the idea is that the dir exists via the "click" package? | 15:31 |
| pitti | jdstrand: ack, let me run the test here and shell into it | 15:31 |
| lifeless | doko: so maybe most users are not OpenStack but not packaged in Ubuntu | 15:31 |
| jdstrand | pitti: yes | 15:32 |
| jdstrand | pitti: hmm, maybe only on older versions | 15:32 |
| lifeless | doko: anyhow it would be really nice if perhaps you assumed good faith, or talked to OpenStack folk, before casting aspersions like 'bitrot' and 'fork' around | 15:32 |
| jdstrand | $ dpkg -S /usr/share/click/frameworks/ | 15:32 |
| jdstrand | ubuntu-sdk-libs:amd64: /usr/share/click/frameworks | 15:32 |
| jdstrand | on vivid: $ dpkg -S /usr/share/click/frameworks | 15:33 |
| jdstrand | click: /usr/share/click/frameworks | 15:33 |
| pitti | jdstrand: in the VM now; indeed no /usr/share/click/frameworks/ dir here | 15:33 |
| lifeless | barry: if there is a specific library you want a read on, looking in git blame openstack/requirements:global-requirements.txt should let you see the reason we revised the version specifier on it | 15:33 |
| pitti | dpkg-query: no path found matching pattern /usr/share/click/frameworks | 15:33 |
| pitti | jdstrand: ubuntu-sdk-libs isn't installed, just click (and that doesn't ship that dir) | 15:34 |
| pitti | jdstrand: if this just creates a "fake" framework, would a simple mkdir -p be correct? or do you want to test that the dir is there already? | 15:34 |
| jdstrand | pitti: that is what I was thinking | 15:35 |
| jdstrand | pitti: I was going to look at click-apparmor today anyway | 15:35 |
| pitti | jdstrand: ok; seems straightforward enough, I just wanted to check with you that we don't do something bad | 15:35 |
| barry | lifeless: ack | 15:35 |
| jdstrand | pitti: if you want to do this right now, feel free, otherwise I can do it in a little while | 15:35 |
| lifeless | barry: (or ask me and I'll do that + use memory :)) | 15:36 |
| barry | lifeless: :) | 15:36 |
| seb128 | bdmurray, hey, ok, going to have a look | 15:36 |
| pitti | jdstrand: as you wish; but I guess it'll unblock python3-defaults faster and take off some pressure? | 15:36 |
| jdstrand | pitti: doko did ping me about it, yes | 15:36 |
| pitti | jdstrand: I'll upload it then, seems we generally agree | 15:36 |
| jdstrand | but like I said, I'll get to it today | 15:36 |
| jdstrand | sure, that's fine | 15:36 |
| pitti | jdstrand: thanks for checking! | 15:36 |
| jdstrand | np :) | 15:37 |
| pitti | works fine now, uploaded | 15:40 |
| jdstrand | yay | 15:40 |
| pitti | doko: hinted p-multicorn | 15:41 |
| pitti | doko: so we're down to p-cffi and ipython AFAICS | 15:42 |
| * pitti waves good bye, time for French class | 15:44 | |
| doko | pitti, looking at ipython, maybe we can wave this too | 15:47 |
| didrocks | pitti: bon courage ! | 15:47 |
| lifeless | ddddd | 15:50 |
| seb128 | bdmurray, I don't really know the driver part of the source but cyphermox worked on it so maybe he's better placed to ack that | 15:53 |
| apw | pitti, best to file bugs about adt failures yes, we can close them or reassign them | 15:55 |
| mvo | pitti: thanks, I have a look at the apt-clone issue later or tomorrow | 15:56 |
| seb128 | doko, is there any reason you didn't send http://launchpadlibrarian.net/158604914/graphite2_1.2.4-1_1.2.4-1ubuntu1.diff.gz to Debian? seems to be the only diff we have on that package, crossbuilding could be useful in Debian as well or it doesn't apply to them for some reason? | 16:28 |
| doko | seb128, the cmake cross build patches are not in debian. not sure why xnox didn't forward these | 16:29 |
| seb128 | xnox, ^ | 16:35 |
| xnox | ... because they were not welcome there at the time. | 16:36 |
| xnox | and i kind of change employment before finishing upstreaming them. | 16:36 |
| xnox | there is extensive patch to cmake itself. Which has not been adopted either in debian, nor upstream. | 16:37 |
| seb128 | k | 16:38 |
| teward | anyone able to help me debug an sbuild problem? Namely, this shows up, when trying to local build a Xenial package, and the schroot was newly created with mk-sbuild. http://paste.ubuntu.com/12971214/ | 16:40 |
| teward | (it's hampering test building) | 16:40 |
| infinity | teward: What's your union type in /etc/schroot/chroot.d/whatever? | 17:11 |
| infinity | teward: And does it match what you have for working chroots? | 17:12 |
| teward | infinity: i'm thinking it's a problem with the kernel | 17:12 |
| teward | i'm on the lts-vivid kernel, on Trusty, and there's kernel errors - kernel errors to syslog and dmesg here: http://paste.ubuntu.com/12971437/ | 17:12 |
| infinity | teward: Well, do your previous schroots have the same issue? | 17:12 |
| teward | infinity: yep | 17:12 |
| teward | all schroots do | 17:12 |
| teward | hence why i'm thinking kernel | 17:12 |
| teward | (potentially) | 17:13 |
| teward | esp. given the dmesg and syslog errors | 17:13 |
| teward | i have an older kernel still installed i'm going to test on | 17:13 |
| infinity | apw: Did you ever SRU back the sbuild changes needed for overlay/overlayfs on lts-vivid? | 17:13 |
| apw | infinity, i believe arges did in the end for us | 17:13 |
| infinity | It's in -proposed. | 17:14 |
| infinity | \o/ | 17:14 |
| infinity | teward: Upgrade to the schroot in trusty-proposed and try with that. | 17:14 |
| arges | yup | 17:14 |
| teward | upgrading, standby | 17:14 |
| infinity | And v-done ten days ago, how did that slip past us? | 17:14 |
| * infinity releases. | 17:14 | |
| teward | fixed | 17:15 |
| infinity | And released to updates. | 17:15 |
| teward | infinity: apw: thank you both :) | 17:15 |
| infinity | apw: Oh, which reminds me. Does wily (or lts-wily) have the compat code? | 17:18 |
| apw | infinity, both should indeed | 17:18 |
| infinity | apw: I don't remember what we decided there. Keep the compat stuff all the way to X, or just in lts-w and lts-x, or...? | 17:18 |
| apw | UBUNTU: SAUCE: overlay: add backwards compatible overlayfs format support V4 | 17:19 |
| apw | we decided we needed it all the way to lts-x, and we might turn it off in x, but even that is not set in stone | 17:19 |
| infinity | apw: Well, if we have it in X, then we're supporting it all the way to lts-18.04 as well. We need to cut it off at some point. | 17:20 |
| infinity | apw: But yes, lts-x needs it for obvious reasons. | 17:20 |
| apw | infinity, i think x likely off and lts-x on, so x is the last kernel which has to carry the patch | 17:20 |
| apw | infinity, and it is a CONFIG_* so we can do that | 17:20 |
| infinity | apw: Kay. Should probably turn it off on the first 4.3.0 upload, so we have plenty of time to deal with potential fallout and sort out lts->lts upgrade scenarios and other crap. | 17:21 |
| apw | infinity, yep, concur with all that | 17:21 |
| apw | infinity, i suspect we need it enabled in X just _really_hard_ to actually use, like a sysctl to turn it on | 17:22 |
| infinity | apw: I'm not sure that helps, really. I mean, if you reboot and your overlays don't come back, will hunting for a sysctl be the first thing you do? :P | 17:22 |
| apw | infinity, nope, its a nightmare :) | 17:23 |
| apw | infinity, we do have a migration script which is something and in theory it is reversible too | 17:23 |
| infinity | apw: I guess if it vomits in dmesg with a very loud "THIS IS DEPRECATED, ENABLE /proc/foo=1 TO TEMPORARILY ENABLE OVERLAYFS IF YOU NEED TO RECOVER LOST DATA, THEN MIGRATE TO OVERLAY ASAP" | 17:23 |
| infinity | apw: So, the filesystem would need to be built in for that to work, and just if /proc/foo != 1, vomit to dmesg, else mount stuff, but still yell. | 17:24 |
| infinity | apw: Yelling in either case being appropriate, so people don't just enable and forget about it. | 17:24 |
| apw | yeah | 17:25 |
| infinity | apw: Could also yell to stderr in the userspace helper, for people who suck at reading dmesg. | 17:25 |
| infinity | apw: That should cover most bases, except for people being intentionally dense. | 17:26 |
| apw | yeah indeed | 17:26 |
| teward | infinity: apw: so when X comes around what will I need to do? I tend to stick LTS-to-LTS, so if all my schroots break, what's the solution for that? Or is that undetermined? | 17:30 |
| teward | (by that point I may redo my schroots though) | 17:30 |
| infinity | teward: If your schroots aren't persistent, it's just a matter of s/overlayfs/overlay/ in the config files. | 17:30 |
| teward | ahh, okay | 17:31 |
| apw | right, depends what you are using it for | 17:31 |
| infinity | teward: If they are persistent, you'll want to shut down the sessions (saving whatever data you need), and start new sessions after the above sed. | 17:31 |
| infinity | teward: If you don't intend to downgrade from lts-v to 3.16 or 3.13 ever again, you can do that today. | 17:31 |
| teward | I don't, actually, the only reason I kept the older kernels around was schroot not working but I never bothered to hunt down the cause | 17:32 |
| teward | infinity: thanks by the way for helping me debug this :) | 17:35 |
| infinity | NP. | 17:35 |
| infinity | apw: lxc is the usecase that scares me, since I think they're more likely to have persistent overlays across reboots. | 17:35 |
| infinity | apw: But maybe lxc itself knows enough about its roots to do a clever migration on upgrade. | 17:36 |
| infinity | apw: Probably a chat with stgraber is in order. | 17:36 |
| apw | infinity, yep, its a problem indeed. they made it very hard for us when they did this | 17:36 |
| infinity | apw: Well, if you have migration code that works, the schroot and lxc persistence-on-boot jobs can both check running kernel version, if high enough, scan all roots that are listed as overlayfs, call migration script, sed config files, then recover sessions. | 17:40 |
| infinity | apw: It's gross, but workable. | 17:40 |
| apw | infinity, yeah, i guess indeed | 17:40 |
| infinity | apw: There's no going back to 3.13 at that point, but I think trying to support that is insane. | 17:41 |
| infinity | apw: Well, we could call your script in reverse if the kernel version drops again, but ew, no. | 17:42 |
| apw | infinity, well the conversion is in principle reversible at least | 17:42 |
| infinity | apw: Except for the purpose of dist-upgrade having to function, we won't in any support running xenial on 3.13, so I think people should expect a bit of breakage if they reboot into the old kernel. | 17:43 |
| infinity | apw: YMMV, etc. | 17:43 |
| infinity | apw: We could at least maybe be kind enough to semaphore the upgrade's occurred and not try to recover sessions after a downgrade, if that would be potentially destructive. | 17:45 |
| infinity | apw: But I don't think thinking too hard about downgrades is worth it. | 17:45 |
| apw | infinity, indeed | 17:53 |
| teward | infinity: mk-sbuild breaks now though | 18:01 |
| teward | i think | 18:01 |
| apw | teward, if so that is broken, and file a bug for sure | 18:01 |
| teward | apw: well it errored for a different schroot | 18:02 |
| teward | so i'm removing one that I need to remake and testing | 18:02 |
| teward | if the error happens there, then there'll be a bug | 18:02 |
| teward | and a link here | 18:02 |
| teward | i wonder though if it's because the older schroots here don't support? | 18:04 |
| * teward shrugs | 18:04 | |
| bdmurray | seb128: the retraced stacktrace was empty - http://pastebin.ubuntu.com/12972040/ | 18:14 |
| hjd | Could someone please poke https://launchpad.net/ubuntu/+source/felix-main for a rebuild in xenial. Now that a newer version of felix-bundlerepository, I think it might work a bit better :) | 18:38 |
| cjwatson | hjd: done | 18:39 |
| hjd | cjwatson: Thank you :) | 18:42 |
| * hjd may end up going through the list of ftbfs issues in xenial looking for more low-hanging fruit | 18:44 | |
| teward | apw: E: /etc/schroot/chroot.d/sbuild-wheezy-i386: line 11 [wheezy-i386] union-type: Unknown filesystem union type ‘overlay’ <-- i have a wheezy schroot for nginx test builds, but if 'overlay' won't work here, and mk-sbuild complains here... | 18:49 |
| teward | it appears to correctly build the source-xenial-amd64 schroot but then throws that error | 18:50 |
| * tumbleweed has given up on unionfs for sbuild, for the moment. Tarballs work (although they are slow and annoying) | 18:51 | |
| tumbleweed | err overlayfs | 18:51 |
| teward | tumbleweed: i'm on lts-vivid kernel so everything's using 'overlay' now and that appears to error | 18:51 |
| tumbleweed | (but that's Debian's kernel, not Ubuntu's...) | 18:51 |
| tumbleweed | IIRC overlayfs support was only added to sbuild fairly recently | 18:52 |
| * teward shrugs | 18:52 | |
| tumbleweed | but it causes kernel lockups for me | 18:52 |
| apw | teward, sounds like we need "more" support, sigh | 18:52 |
| apw | please file a bug so we don't forget to look at it | 18:52 |
| teward | apw: ack, against what? devscripts? | 18:53 |
| teward | erm. ubuntu-dev-scripts or w/e provides mk-sbuild ? | 18:53 |
| teward | wow it fails schroot for all old releases | 18:53 |
| === bipul is now known as away_bipul | ||
| teward | apw: E:Critical | 18:53 |
| teward | apw: so now there's massive failure | 18:55 |
| teward | :/ | 18:55 |
| teward | apw: and it appears to be related to older releases | 18:55 |
| teward | my wily schroot is affected | 18:55 |
| apw | teward, well mk-sbuild works in wily i am pretty sure, hmmm | 18:56 |
| apw | anyhow, file a bug with nice verbose what you are doing in there | 18:56 |
| === away_bipul is now known as bipul | ||
| melodie | hi again, | 19:03 |
| melodie | I would like to create pool and dist in Bento Openbox, and although I know there are docs about it, I'm not sure it applies to ISOS. Any advice on where to start the right way? | 19:03 |
| melodie | I asked earlier today and didn't get any answer, so if anyone has an idea about it, I'd be glad | 19:09 |
| sarnold | melodie: are you making a CD installer or an apt repository? | 19:11 |
| aalex | hello | 19:11 |
| aalex | When is the next freeze for Ubuntu 16.04 ? | 19:11 |
| aalex | And should my package be in Debian unstable or testing for it to be included? | 19:12 |
| aalex | Thank you :) | 19:12 |
| melodie | hi sarnold an ISO live desktop | 19:12 |
| melodie | aalex in Debian anyway, for the details you could ask questions at #debian-mentors on irc.oftc.net | 19:14 |
| hjd | aalex: The automatic Debian import doesn't seem to stop before medio Febraruary (https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule) | 19:15 |
| aalex | melodie: my software is already in debian, but there are bugs with it... I just need to know when I should fix them so that it's in Ubuntu | 19:15 |
| sarnold | aalex: the next freeze is probably a beta1 freeze, moths away, but perhaps existing users in debian would like those bugs fixed too :) | 19:16 |
| teward | apw: grr, it's every schroot not supporting 'overlay' now... something weird must be going on :/ | 19:16 |
| aalex | hjd: thanks a lot. That is useful to me. | 19:18 |
| aalex | sarnold: mid-february is fine? I will, of course, do another release as soon as possible, but at least I then know that I don't need to spend a few nights without sleep in order to fix this for the next freeze. :) | 19:19 |
| melodie | sarnold so for a CD, would you have any lead for me? | 19:19 |
| sarnold | melodie: sorry, not really, I was just unclear about what it was you were trying to make :) | 19:20 |
| sarnold | aalex: yes, please get some sleep :) | 19:20 |
| teward | apw: switching the union type to 'overlayfs' resolved the issues - so it's a case of pure 'overlay' not being supported | 19:21 |
| teward | yet | 19:21 |
| melodie | I'm not trying, I do a version with Openbox (for end users), but so far I have not used pool and dist, and I'd like to start adding them | 19:21 |
| melodie | just I need insights on how that works: just add them, and the system will be aware about them or are there special configs needed? no clue yet | 19:22 |
| melodie | sarnold Bento Openbox: http://linuxvillage.org/en/ and http://bentovillage.me | 19:23 |
| sarnold | nice :) | 19:25 |
| melodie | sarnold thanks :D | 19:27 |
| teward | infinity: poke - changing 'overlayfs' to 'overlay' by simple sed (with none of the sessions in use) didn't work, prompted the errors i'm seeing. | 19:31 |
| teward | apw: infinity: https://bugs.launchpad.net/ubuntu/+source/sbuild/+bug/1510245 is the relevant bug for this latest headache | 19:31 |
| ubottu | Launchpad bug 1510245 in sbuild (Ubuntu) "sbuild schroots fail for older releases which don't support 'overlay' and only support 'overlayfs'" [Undecided,New] | 19:31 |
| teward | infinity: so I don't think we can use 'overlay' in place of 'overlayfs' until we actually are on Xenial (so my Trusty system will need overlayfs still) | 19:31 |
| infinity | teward: Oh. We may not have backported that fully, then. :P | 19:51 |
| infinity | teward: Not sure I'd consider that a bug, to be honest, since having only some of the kernel support overlay would be confusing anyway. | 19:51 |
| teward | infinity: only following what apw said, file a bug. | 19:52 |
| teward | infinity: but in any case, overlay isn't fully backported | 19:52 |
| teward | but the schroot update was needed to 'work' with overlayfs it appears, on lts-vivid and later | 19:52 |
| teward | infinity: if it's 'not a bug' then Invalid is always a viable option :0 | 19:53 |
| teward | :) * | 19:53 |
| teward | that isn't, however, in my purview to set :) | 19:54 |
| teward | at least not for this :) | 19:54 |
| teward | infinity: it does, however, pose an interesting question for Xenial, which I think you had brought up: do we do the 'migration' and 'upgrade' automagically, or do we just error saying that they have to update the union type or such | 19:55 |
| infinity | teward: Yeah. Andy and I will argue drunkenly about that next week. | 19:56 |
| teward | infinity: my two cents: error, but be useful in the error message, and say that overlayfs is not supported, or such, if you're on Xenial | 19:56 |
| teward | but of course, that's just my opinion, I'll leave it to you all for the decision :) | 19:57 |
| teward | infinity: in any case, thank you and apw for solving the 'lack of overlayfs support' issue I was seeing earlier xD | 19:57 |
| mterry | barry, have you had any luck with community involvement in python3 ports? Might it be worth while to have a UOS session detailing the places people could help? (I'd gladly talk about what needs to happen for duplicity in such a session) | 20:31 |
| barry | mterry: not so much with the ubuntu community specifically that i can recall, but in the wider debian+ubuntu world, lots of great contributions | 20:32 |
| mterry | barry, well still, do you have any UOS sessions you are running in which you could plug the effort? If not, maybe I'll make a little blog post and calling out duplicity as something I could mentor | 20:44 |
| mterry | barry, worst case if none of us get to it, we could end up dropping deja-dup... I certainly wouldn't mind. Though I don't know how invested seb128 is in having a backup UI | 20:45 |
| barry | mterry: we have a session on python3 plans for xenial. should we piggyback on that? http://summit.ubuntu.com/uos-1511/meeting/22568/python3-only-on-the-images/ | 20:52 |
| mterry | barry, ah that session is exactly what I was hoping we had. Just a shout out in there for help might be good. I assume we still have that spreadsheet of work-needing-to-be-done that we could point people at | 20:54 |
| barry | mterry: we do but it's probably horribly out of date | 20:54 |
| mterry | barry, I'll make sure to attend, but don't need to speak | 20:54 |
| mterry | barry, fair | 20:55 |
| barry | mterry: awesome. plugs are always helpful :) | 20:55 |
| mterry | barry, so where does /sbin/system-image-upgrader live / come from? (it's the command used when upgrading the system image) | 21:22 |
| mterry | It doesn't seem to be on my device normally | 21:22 |
| barry | mterry: do you mean the magical blob that runs in recovery? | 21:24 |
| mterry | barry, yeah | 21:24 |
| barry | mterry: fwiw, i have never touched that, and only looked at the code once or twice | 21:24 |
| barry | mterry: the best i can point you at is: https://wiki.ubuntu.com/ImageBasedUpgrades/Upgrader | 21:25 |
| mterry | OK. thanks | 21:25 |
| barry | but warning that that wiki page could e way out of date | 21:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!