/srv/irclogs.ubuntu.com/2015/12/08/#ubuntu-devel.txt

newb123I'm playing around with an experimental driver I wrote and at boot it keeps on dumping me into initramfs saying that /dev/disk/by-uuid/XXX.... does not exist. I've checked that the uuid is correct and blockdev --rereadpt /dev/vda displays the correct partitions. Any idea how I might go figuring out why /dev/disk/by-uuid doesn't exist01:01
=== nudtrobert1 is now known as nudtrobert
=== nudtrobert1 is now known as nudtrobert
Mirvpitti: should not be, but looking05:26
Mirvmaybe some #include problem in the qca-qt5 that has not seen updates in ages05:33
Mirvhmm, Debian does not have qca-qt5 and builds okteta without it05:50
Mirvaha, nope, they have 'qca2' ie different source name but same binary names05:52
Mirvand the newer version they have fix FTBFS with 5.5...05:52
Mirv(and looks like ubuntu also has qca2, but Kubuntu people have split of the qt5 part to its own source instead of having everything come from single source)06:05
pittiGood morning07:10
pittichiluk: it's not so much a merge (we have no modifications), but the newer version should rather be tested thoroughly07:10
chilukI completely agree.07:10
chilukthat's why I'd rather see it go in xenail while in development than something else.07:11
chilukpitti ^^07:11
pitticjwatson: I found out last night why so many tests were stuck "in progress" -- it was those which included a package build that failed07:11
chiluksometimes I wish IRC would just add the highlights accordingly07:11
pitticjwatson: fixed, and I reran all the tests over night, it's okay now07:12
pittichiluk: right07:12
chilukpitti, I think the "user" understands the issue of this not being SRU-able.07:12
pittichiluk: heuristic content based notifications -- just wait until freenode connects to the big google brain07:12
chilukbut I really think we need to bite the bullet and do it before xenial lands07:13
pittichiluk: the crash fix is for sure, but certainly only that backport, not the wholly new version07:13
=== tvoss_ is now known as tvoss
dholbachgood morning07:41
pittichiluk: did you already give that version some testing, with some basic use cases? or need me to do that?07:42
seb128hey dholbach ;-)07:42
chilukpitti I have not, and unfortunately I'm headed on another vacation here till monday.07:42
* dholbach hugs seb12807:43
chilukalso I should probably be sleeping... infinity must be rubbing off on me.07:43
* seb128 hugs dholbach back07:43
chilukand i don't want infinity rubbing anything on me.07:43
pittichiluk: ok, seems to work reasonably well here and it has a good test suite too07:55
chilukyeah it does have a reasonably good test suite.07:55
chilukwow that would be super awesome pitti.07:55
pitti(I synced it)07:56
pittiMirv: so five failures are overridden, what's left are okteta (see above), step (which looks unrelated, I'll hint it), and unity-scope-click (which looks flaky, I'll retry)08:31
pittistep is debian bug 786351, so someone needs to merge it08:34
ubottuDebian bug 786351 in step "Eigen2 support is deprecated in Eigen 3.2.x and will be removed in Eigen 3.3" [Wishlist,Fixed] http://bugs.debian.org/78635108:34
Mirvpitti: can you retry okteta, I uploaded a new qca-qt5 and it was published in proposed 38 minutes ago?08:37
pittiMirv: oh cool, thanks! triggered08:38
Mirvpitti: hmm not sure if the 2.1.1 is in archive indexes yet, I can't update my xenial(-proposed) lxc for some reason yet even though it was that many minutes ago08:51
Mirvusually that amount of time is enough, but no, not seeing https://launchpad.net/ubuntu/+source/qca-qt5/2.1.1-0ubuntu1 contents in Packages.gz yet08:52
pittiMirv: maybe ftpmaster already has it; but anyway, if it still fails we retry later08:54
pittiMirv: I'm looking into the step merge btw; but I'll ignore qt's tests once step is the only remaining regression08:54
pitti(I don't want to ignore it for other packages as they cause the step regression)08:54
Laneyslangasek: It has a patch to review and is in the sponsor queue, so I'm wondering who should review or otherwise deal with it09:02
ginggsthanks seb128 for the rebuilds :)09:14
seb128ginggs, yw, thanks for debdiffs and sorry for taking some extra days09:15
pittiMirv: uploaded step, that works on xenial release now09:19
cjwatsonpitti: aha, thanks!09:27
Mirvpitti: got now updated libqca-qt5-2-dev proposed and compiled okteta successfully with that09:43
Mirvlooking good on the autopkgtest infra too, I guess they got it from ftpmaster09:44
Mirvstill running though09:44
=== cpaelzer is now known as cpaelzer_afk
=== cpaelzer_afk is now known as cpaelzer
pittiMirv: but it still fails on the infra10:29
pittihttps://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/o/okteta/20151208_094327@/log.gz10:30
Mirvpitti: hmm, amd64 is still running at http://autopkgtest.ubuntu.com/running.shtml#pkg-okteta and armhf + i386 + ppc64el show success at eg http://autopkgtest.ubuntu.com/packages/o/okteta/xenial/armhf/10:33
pittiMirv: ah ok, so that was just an auto-triggered previous run10:33
pittiMirv: right, in the above log it still was 2.1.0.3-0ubuntu410:34
Mirvso once amd64 finishes it should be all green10:34
pittihttp://autopkgtest.ubuntu.com/packages/o/okteta/10:34
pittiindeed, nicely green on the others10:34
pittihttp://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src hasn't caught up yet, but it should soon10:34
Mirvxnox: did you get anywhere with the checkbox, or are you familiar with it so that you could get somewhere?10:53
Mirvxnox: I can't even build it locally for some reason, complies about some patching of vendorized_packages_removal.patch .. but as I linked yesterday, it did start to compile in the PPA but failing later in udev related tests11:01
xnoxMirv, not yet, i was at end of my day, and i simply added it to my todo list11:15
=== _salem is now known as salem_
=== cpaelzer is now known as cpaelzer_afk
xnoxokteta still runing, ok.11:53
=== cpaelzer_afk is now known as cpaelzer
xnoxpitti, okteta ftbfs12:07
xnoxpitti, can we skip it? and get qtbase in. It is good enough.12:07
xnoxMirv, ^12:07
xnoxalso okteta propbably needs a merge with debian experimental12:08
pittixnox: sure we can skip it, but it'll keep breaking other stuff if the new qt makes it ftbfs12:09
pittibut I thought the new qca-qt5 fixed that12:10
pittixnox: no, it's good, it passed12:10
pittixnox: results got published 10 s ago12:11
xnoxoh12:11
pittihttp://autopkgtest.ubuntu.com/packages/o/okteta/12:11
mdeslaur@pilot in12:11
=== 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: mdeslaur
xnoxpitti, it was gone from currently running, but it was not yet up on the package board.12:11
xnoxi guess there is a delay between the two12:11
xnoxok awesome12:11
pittixnox: right, autopkgtest.u.c. pulls every 5 mins12:11
pittistill waiting on http://autopkgtest.ubuntu.com/running.shtml#pkg-step12:11
pittithat should build again now too12:11
xnoxpitti, and does kwayland regression on ppc64el affect migration?12:12
pittioh, step succeeded too12:12
pittiso britney should stop complaining about qt the next run12:12
pittixnox: oh crap, yes; I'll hint over that12:13
xnoxpitti, and unity-scope-click?12:13
* xnox ponders why it failed12:13
pittiI reran that one, looked flaky12:13
xnoxpitti, unity-scope-click clearly had a network problem.12:13
xnoxbut can be peppered over, no?12:14
pittiah, so the rerun failed too12:15
pittixnox: ack, hinted, qt etc. will be a valid candidate on the next run12:16
pittiMirv: ^12:16
pitti(could still be some ABI transitions etc. on update_output, of course)12:16
pittixnox: FYI, ubuntu-meta is stuck on ubuntu-desktop uninstallability on s390x; perhaps add some [!s390] there?12:19
pittithere == to the seeds?12:19
xnoxi could do that, or i could get things building12:20
xnoxso i need qt5 on s390x next =)12:20
xnoxand to do that, we need current one migrated12:20
xnoxto upload next one ;-)12:20
Laneywasn't that caught up with poppler?12:21
rbasakI'm tempted to s/nagios-plugins/monitoring-plugins/ in the seeds since nagios-plugins-* are now transitional packages that will disappear after Xenial, and if I forget to change the seeds next cycle they will fall into universe.12:29
rbasakOTOH that will put nagios-plugins-basic/-standard transitonal packages into universe in Xenial.12:29
rbasakWhich may not be good I suppose if someone upgrading has main disabled maybe?12:30
rbasakI just answered my own question perhaps then - don't do until next cycle?12:30
cjwatsonWe normally seed transitionals with a comment saying to drop them after the next LTS12:30
cjwatsonimportant ones anyway12:30
cjwatsonBut changing to monitoring-plugins makes sense12:30
xnox=) Should wait for tests relating to qtbase-opensource-src 5.5.1+dfsg-6ubuntu2, but forced by pitti12:33
rbasakI meant if someone upgrading has universe disabled, sorry12:33
rbasakcjwatson: so should I change now and ignore the transitionals, or add the new ones and keep the transitionals for the transition in main with a comment to remove next cycle, or do nothing until next cycle?12:33
xnoxLaney, pitti, Mirv looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt i say it's foobar to transition =)12:34
cjwatsonrbasak: I would s/nagios-plugins/monitoring-plugins/ and add the transitionals with a comment12:34
rbasakcjwatson: OK, I'll do that. Thanks!12:34
Laneyxnox: A lot of those are because the other qt* aren't candidates yet12:35
Laney(I think)12:35
xnoxMirv, can you throw next qtbase in, which will build on s390x, cause there are binaries that are built with old poppler and they do become uninstallable with new qtbase and thus hold things up.12:35
xnoxMirv, and yes we do have qt 5.4 & old poppler based binaries in launchpad s390x xenial release pocket.12:35
xnoxand qtbase-opensource-src-gles  is still borked12:37
Laneyqtdeclarative, qtscript, maybe others12:38
xnoxand then it would still block on popler and blocked on s390x old popler, hence i do need another qtbase upload12:39
xnoxwhich we knew anyway, should have done it days ago.12:39
xnoxMirv, are you gonna make the next qtbase upload please?12:42
Mirvxnox: ok, sounds like there's still some things to fix or at least override, so I guess I can put your s390x enablement in12:45
xnoxMirv, yeap.12:45
xnoxMirv, and s390x are part of the blockers via poppler.12:45
Mirvpitti: I think kwin+rocs would need hinting for the other Qt packages too12:46
seb128doko, hey, did you see my question about pep8 yesterday?12:47
MirvLaney: pretty much all qtdeclr* qtscript etc are the same that are overridden for qtbase already (kwin, rocs) or already fixed but status not updated (marble, okteta)12:53
pittiMirv: didn't I already?13:13
pittiMirv: oh yes, it's currently landing13:14
Mirvpitti: what's currently landing?13:19
pittiMirv: qtbase-opensource-src and friends13:19
Mirvxnox: I think the checkbox with qt3d5-dev removed should be fixed because of the main <-> universe13:19
Mirvpitti: I thought qtmir-gles failure prevented that, plus xnox just convinced me to copy over ubuntu3 of qtbase which I did since the migration was supposed to take ages still :)13:19
pittioh, or it's that -- https://launchpad.net/ubuntu/+source/qtbase-opensource-src/+publishinghistory13:20
pittiit's a valid candidate, and https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-6ubuntu2 had no publication, which is usually teh case in between ubuntu2 and ubuntu313:20
pittiMirv: uh, so that will trigger everything again13:20
xnoxpitti, valid candidate.... yet piles of unisntallable packages and thus will not migrate.13:21
xnoxpitti, autopkgtest is not the only thing blocking qtbase migration.13:21
pittiok, I didn't check that yet13:21
Mirvpitti: yeah, xnox wants the s390x to proceed and apparently update_output has more work to be done13:21
xnoxpitti, 5th ctrl-f hit of 'qtbase' on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt13:22
xnoxin there there are a bunch of todos13:22
xnoxincluding s390x packages13:22
xnox* s390x: 4ti2, aweather, foxtrotgps, ....... and so on13:22
pittiok; hopefully this round of tests will be much quicker, with the infrastructure currently working and the eternal "test in progress" bug fixed13:23
xnoxMirv, awww, sybmols. do you want a patch for that?13:23
Mirvxnox: foxtrotgps is gtk, I wonder if there's an easy root problem13:23
Mirvxnox: yes please13:23
Mirvto the installability things13:24
xnoxit builds real quick without the tests =)13:24
Mirvanyway, I welcome any help on the migration at this point where things already start to be quite complex13:24
Mirvplus the dragging of the migration making train a bit more cumbersome13:24
Laneypitti: might want to skiptest if all that's changed is s390x conditionals13:29
* Laney goes to lunch13:29
pittiit's quite a bit more13:29
xnoxMirv, http://paste.ubuntu.com/13823021/ test building on s390x at the moment at https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/841020413:30
pittiwe don't need to wait for everything again though, let's just run a few to check that not everything is totally broken13:30
pittiLaney: but doesn't help if the necessary rdepends rebuilds haven't been done yet13:30
xnoxpitti, we shall have ubuntu4 in a second =)13:30
xnoxpmcgowan, rocking ipv6 =)13:31
* xnox likes ipv613:31
dokoseb128, do you remember packages other than prospector?13:36
seb128doko, I don't remember them but I fixed a few13:36
seb128it just seems suboptimal to carry ubuntu delta there13:37
seb128is there any reason the change doesn't make sense for Debian?13:37
seb128doko, http://launchpadlibrarian.net/222749166/shortuuid_0.4.2-4_0.4.2-4ubuntu1.diff.gz is another one you did13:38
seb128doko, http://launchpadlibrarian.net/222797987/actdiag_0.5.3-5_0.5.3-5ubuntu1.diff.gz as well13:38
dokota13:39
dokoseb128, I'm currently compiling the list of affected packages13:40
Mirvxnox: I'm also prebuilding in a landing PPA13:41
seb128doko, k, thanks13:41
dokocjwatson, https://bugs.debian.org/807366 this requires gcc-5-5.3, or else the options will be unknown13:53
ubottuDebian bug 807366 in ghc "ghc: disable PIE on Ubuntu/s390x" [Normal,Open]13:53
cjwatsondoko: ok, not sure that's a problem for ghc though?13:53
dokocjwatson, don't know, just in case it wants to pass this to the compiler13:55
cjwatsondoko: it will do, but backporting ghc is somebody else's problem :-)13:55
doko=)13:55
dokoseb128, http://bugs.debian.org/807409  feel free to comment on the issue when you find more. prospector now fixed too13:59
ubottuDebian bug 807409 in src:pep8 "using python3 to run the pep8 binary" [Wishlist,Open]13:59
seb128doko, thanks14:00
xnoxMirv, succeeds on s390x.14:17
xnoxMirv, so once it's ready copy it over please.14:17
Saviqtvoss, hey, u8 is crashing on me on exit http://pastebin.ubuntu.com/13824663/14:37
Laneyxnox: It helps it get to the next stage, which lets you see what needs updating still14:37
Saviqlooks like a dbus-cpp issue, or a media-hub one, wdyt?14:37
pete-woodspitti: hey! I still have this PR for python-dbusmock if you have some time (https://github.com/martinpitt/python-dbusmock/pull/17)14:55
pete-woodsI've tried to do all the NEWS / commit messages correctly14:55
pete-woodsand add tests, etc14:55
pete-woodsdammit, pep8 fail, fixing now14:56
Laneyhttps://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/a/ark/20151208_141408@/log.gz14:56
Laneylooks like that pkg-kde-tools upload was bad14:57
pittipete-woods: right, sorry, last days were a bit crazy with infra firefighting14:57
pete-woodspitti: no worries. figured you were just on holiday or something14:58
pittipete-woods: no, pretty much the opposite :)14:58
pete-woodsI've had floods / no power here for the last 4 days14:58
pittiurgh14:58
pete-woodsso I've not done much either14:58
pete-woodsFYI, one of the changes is non-trivial (the one that makes it support having 'secrets' properly)15:01
pete-woodsit intentionally removes some properties from the settings interface that should never have been present15:02
pete-woods(i.e. they don't exist on the real interface)15:02
pete-woodsI've tried to add a passable level of testing for it all15:02
xnoxMirv, what other change you need to land in checkbox?15:07
xnoxi fixed it's build.15:07
xnoxbarry, unittest is confused by a submodule named dbus, which import system dbus =(15:14
xnoxe.g. i have checkbox.dbus which does 'from dbus import SystemBus' and when running test it trips up on that.15:15
xnoxis there a way to instruct pytest to not "discover" that one?15:15
Mirvxnox: will do before I go to sleep15:19
xnoxMirv, well i need to upload my fix, i could upload it with whatever changes you had to land.15:21
xnoxotherwise i'll just upload a straight FTBFS fix.15:21
barryxnox: python 2?15:21
xnoxbarry, python3.5 special =)15:21
barryxnox: hmm.  absolute imports are the default in 3.  can you pastebin the traceback?15:22
xnoxbarry, http://paste.ubuntu.com/13825910/15:25
xnoxbarry, so ./setup.py test fails, yet python3.5 -m unittest -v -> succeeds correctly. i blame setuptools-foobarage.15:25
infinityapw: Hey, uhm.  There's no linux-meta for s390x.15:27
apwinfinity, oh oops, did we forget to add that?15:28
infinityapw: Yep.15:28
apwinfinity, we just need a -generic for that i presume ... will get that sorted15:28
infinityapw: And virtual.15:28
infinityapw: Since you did the split.15:28
apwnow that feel familiar ... why15:28
=== fginther` is now known as fginther
tvossSaviq, looking15:30
xnoxinfinity, apw - did you do the split?15:30
xnoxso far everything expects generic.....15:31
xnoxas i thought we don't have a virtual flavour yet.15:31
apwxnox, it is -generic, -generic gets split15:31
infinityxnox: Everything should be generic, except the MP I just rejected. :)15:31
barryxnox: yeah, it's suspicious, but i'm already suspicious of other setuptools foobarisms: LP: #152380615:31
ubottuLaunchpad bug 1523806 in system-image (Ubuntu) "/usr/sbin/system-image-dbus:UnicodeDecodeError:/usr/sbin/system-image-dbus@5:/usr/lib/python3/dist-packages/pkg_resources/__init__.py@3143:_call_aside:_initialize_master_working_set:_build_master:__init__:add_entry:find_on_path:from_location:_version_from_metadata:_version_from_file:decode" [Undecided,New] https://launchpad.net/bugs/152380615:31
xnoxinfinity, ack.15:31
Mirvxnox: what your fix, did you have something more than the symbols? the idea is that the armhf build is pre-done so it doesn't take time in the archives.15:31
barryxnox: is there a branch i can play with?15:32
xnoxMirv, checkbox, i fixed checkbox to not be crazy.15:32
Mirvxnox: the reason I'm doing the landing is your fix, I don't have anything else15:32
Mirvxnox: ah, sorry! I mixed to qtbase15:32
xnoxMirv, i thought you had something to be changed for checkbox - dependencies?15:32
Mirvxnox: excellent! so, remove the qt53d-dev from build-deps15:32
xnoxbarry, sbuild -A -d xenial checkbox_0.18-0ubuntu4 -> fails at the moment.15:32
Mirvxnox: so that qt3d-opensource-src can be demoted to universe... otherwise qt3d can't build (or couldn't in archives, but yes when binary-copied from landingn PPA) and I assume it'd block migration too15:33
xnoxbarry, it does crazy things, but in essence -> $ cd checkbox-old, in that package is borked. (./setup.py test does not work)15:33
xnoxbarry, or well pull-lp-source checkbox 0.18-0ubuntu415:33
tvossSaviq, that's rc-proposed?15:33
xnoxMirv, right, and checkbox doesn't need it? why it depends on it. Ok will drop15:34
Mirvxnox: well it didn't seem to require it (and it shouldn't, qt3d wasn't usable really before Qt 5.5), the debian/control looked like copy-paste from somewhere else15:34
* Mirv needs to go now, back to copy the qtbase from landing PPA in a 2-3h15:35
xnoxbarry, is that enough for you to play with checkbox? =))))15:35
xnoxMirv, checkbox fix is python brain-damage and 3 one-liners ;-)15:36
infinityOdd_Bloke: Looking at the [ "$PROJECT" = "ubuntu-cpc" ] in live-build, why do three arches 'add_task install server', and the rest don't?15:37
infinityOdd_Bloke: That feels rather broken in one direction or the other.15:37
xnoxinfinity, i guess on amd64 -virtual flavour is used which is the default.15:37
infinityxnox: Yes.15:38
xnoxoh, you are asking about server bits15:38
xnoxit is weird15:38
infinityxnox: Yes. :P15:38
xnoxyes Odd_Bloke what's up with that =)15:38
Odd_BlokeThat's what we were already doing, so I was aiming to retain parity between what we produced before and what we produced in the buildds.15:39
infinityFeels like only armhf and arm64 need special-casing there for kernel flavour and flash-kernel, and then the server task should move down to all arches.15:39
infinityOdd_Bloke: As in, the arches were always mismatched?15:39
tvossSaviq, let me see if I can come up with a distilled test case15:39
infinityOdd_Bloke: Can we aim for that to not be true, since we're doing an LTS? :P15:39
Odd_Blokeinfinity: Oh, you.15:39
Odd_Bloke:p15:39
infinityOdd_Bloke: Either the server task should be on all or none, up to you guys which is correct, but the mismatch clearly isn't.15:40
tvossSaviq, do you see the crash on regular shutdowns?15:40
Odd_Blokeinfinity: Yeah, I'll bring it up with the others.15:40
infinityxnox: So, in your MP, I'd drop the s390x stanza from that chunk entirely, since whatever Odd_Bloke decides, it'll wipe out ppc64el and s390x because they'll be the same as the default.15:42
barryxnox: i see 0.18-0ubuntu4 is building in -proposed.  i can pull down that srcpkg and build locally15:43
xnoxbarry, yeah, that one is "fixed" the packaging calls python3 -m unittest, instead of python3 setup.py test.15:43
xnoxbarry, but yeah, it should still fail if you do: cd checkbox-old; ./setup.py test15:44
barryxnox: ack15:44
infinityOdd_Bloke: Also, did you ever figure out why your powerpc images weren't bootable?  Cause the lack of a powerpc case in that switch could explain it. :P15:44
xnoxplars, i'm not sure where checkbox upstream is for "packaging" of "checkbox-old" but i have made changes to it - https://bugs.launchpad.net/checkbox/+bug/152396915:45
ubottuLaunchpad bug 1523969 in Checkbox "FTBFS on python3.5 in xenial" [Undecided,New]15:45
infinityOdd_Bloke: (needs KERNEL_FLAVOURS=powerpc64-smp and probably a manual install of whichever bootloader you're using, yaboot or grub2)15:45
Odd_Blokeinfinity: There is a stanza in my PPA version which I'm using. :)15:45
infinityOdd_Bloke: Ahh.15:45
infinityOdd_Bloke: So, first half of the question then, did you ever figure it out?15:45
plarsxnox: I'm probably not a good person to ask about that - talk to spineau probably15:45
infinityOdd_Bloke: Cause I might be able to find an hour or two to look at it.  We're getting to the point where we really want to move PPC into scalingstack.15:46
xnoxinfinity, so whilst that case shouldn't be there, it is correct, no?! =)15:47
xnoxi.e. does no harm ;-) until Odd_Bloke fixes the world to be a beautiful place to be in ;-)15:47
infinityxnox: Minus the KERNEL_FLAVOURS, it's "correct", but just adds noise, since he'll delete it shortly. :P15:47
infinity(And I suspect it's not correct, I tihnk cloud images aren't meant to have the server task)15:48
xnoxinfinity, as far as i can see we don't have virtual flavour yet, and default is virtual.15:48
infinityGiven that 99% of our cloud image users are x86, I'd expect that to be the template.15:48
infinityxnox: We don't have a virtual or generic yet.15:48
infinityxnox: That operates on metapackages.15:48
infinityxnox: We have no linux-meta.15:48
* xnox facepalms15:48
infinityxnox: One we have meta, we'll have both.15:48
xnoxinfinity, anyway, i'm not even building ubuntu-cpc, i only care about server at this point =)15:49
* infinity nods.15:49
xnoxi should stop touching nasty things15:49
infinitySo just drop that stanza and merge away, IMO.15:49
Odd_Blokexnox: I thought you cared. ;.;15:49
xnoxOdd_Bloke, that was 4 years ago and cross the road to say hello from the other side =)15:50
* xnox chuckles at his Adele reference15:50
xnox*I crossed15:50
xnoxi bet ogra_ is confused.com =)15:50
Odd_Blokexnox: Is it me you're looking for?15:51
xnox>_<15:51
Odd_Bloke^_^15:51
ogra_xnox, ??15:51
xnoxogra_, check irclogs.ubuntu.com in an hour ;-)15:52
mterrypitti, how do I retest a package's autopkgtests?  (without uploading a rebuild, if possible)  cpl-plugin-fors (and similar) got in a weird state when testing against latest gsl upload (ppc64el built against proposed, tested against release)15:53
ogra_:P15:53
spineauxnox: Thanks for you fix. We'll remove the checkbox-old very soon from xenial (replaced with the QML checkbox-converged). I'm just waiting on a few RFS to be processed for packages we're maintaining in debian. After a sync with ubuntu we'll update the xenial branch and those FTBFS will be auto solved.15:53
pittimterry: for now, ask me, Laney, slangasek, or infinity15:54
xnoxspineau, cool. well we need that bit now, to unblock 5.5 hence i uploaded minimal fix. i hope that's ok with you.15:54
pittimterry: does this look reasonable? http://paste.ubuntu.com/13826667/15:54
pittimterry: (from "retry-autopkgtest-regressions |grep cpl-plug")15:54
spineauxnox: it's ok, many thanks for your fix15:55
mterrypitti, and add astrometry.net15:55
mterrypitti, thanks!15:55
xnoxspineau, then just close the bug or whatever. no problem.15:56
pittimterry: kicked15:56
pittimterry: FTR, I'm off for 2 or 3 hours, checking IRC tonight again15:57
spineauxnox: ok15:57
mterrypitti, ack thanks15:59
barryxnox: it's a bug in checkbox: LP: #1523979 has a patch16:12
ubottuLaunchpad bug 1523979 in Next Generation Checkbox (GUI) "checkbox calls unittest.discover with an incorrect start_dir" [Undecided,New] https://launchpad.net/bugs/152397916:12
xnoxbarry, yeah, i was expecting something like this. your digging and explanation make sense =)16:14
barryxnox: cool.  can you take it from here?16:14
xnoxbarry, yes, thank you.16:14
barryxnox: thanks!16:14
xnoxbarry, at least it's not setuptools which are broken.16:14
xnoxand that's good.16:15
barryxnox: not in this case at least :)16:15
sil2100pitti, Mirv: hey guys! Any luck on the qt5 migration issues?16:17
dokobarry, for the python 2.7 testsuite I disabled the test_cpickle test, and everything is fine. it's now run as part of the "failing" tests in autopkg test, and should succeed16:17
Odd_Blokeinfinity: I did work out the bootability issue; we weren't doing a grub-install.16:18
Odd_Blokeinfinity: Which is actually _quite_ important.16:18
Odd_Bloke(This just in, etc.)16:18
Odd_Blokeinfinity: I've been sprinting two of the last three weeks, so I haven't actually looked at it since I fixed that; a quick check of whether or not that fixes powerpc booting as well as ppc64el booting would be good.16:19
Odd_Bloke(I confirmed the latter, but don't know if the lack of the former was due to my not really knowing which qemu flags to use :p)16:19
mdeslaur@pilot out16:21
=== 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:
xnoxsil2100, it's in progress.16:45
xnoxsil2100, and there is a lot more to do.16:45
xnoxsil2100, there should be a new qtbase to copy into archive done in one of the landings that mirv is maintaining.16:46
xnoxsil2100, how can i find all landing ppas that have qtbase-opensource-src?16:47
sil2100xnox: https://requests.ci-train.ubuntu.com/#/tickets?search=qtbase-opensource-src16:48
sil2100xnox: look for those that are not Landed or Abandoned16:48
sil2100xnox: thanks for the info!16:48
xnoxsil2100, i don't see it, there should be a ppa with ubuntu4 built i believe somewhere, which Mirv uploaded. if it is fully built, it will need a copy to the archive. let me find it via build records.16:49
xnoxsil2100, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-03216:51
xnoxsil2100, qtbase-opensource-src5.5.1+dfsg-6ubuntu4 is ready, can you copy that into xenial-proposed please?16:51
xnoxa better and fixed checkbox, is already in xenial-proposed.16:51
xnoxsil2100, ah, no, armhf is still building.16:52
xnoxsil2100, waiting on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-032/+build/8410224 to finish.16:52
xnox1.5h to go.16:52
sil2100xnox: ok, but once that's done, just the qtbase packages, right?16:52
slangasekmdeslaur, kees, stgraber: so is today's TB meeting cancelled by popular acclaim?  Not sure if there's something we should do to take it off calendars (fridge?) in that case16:53
xnoxsil2100, no, loads more too. we will need to unwind the popler abi transition in -proposed too, and whitelist through a few autopkgtests. I don't think we'll get it done today. But e.g. I need it to migrate as soon as possible, so will be working on unwinding proposed to get it done tonight/tomorrow.16:55
xnoxbut for now i'll be afk, until qtbase builds.16:55
sil2100xnox: was asking since the silo had many packages in it, didn't know if I was supposed to copy all of them or just qtbase from there16:56
mdeslaurslangasek: perhaps just update the wiki page stating that the meeting was cancelled?16:56
sil2100Anyway, thanks and let's see in some hours16:56
mdeslaurslangasek: and the mailing list16:56
xnoxsil2100, just qtbase, others have been copied before already as far as I understand things.16:56
stgraberslangasek: I'm fine with skipping it. I'm around but there's little point with nothing on the agenda16:58
sil2100xnox: ACK17:02
cjwatsonoh, bah, I clearly uploaded texlive-bin too early17:03
cjwatsondidn't notice poppler/s390x hadn't actually built17:03
Laneyyeah17:03
LaneyCould we remove the old poppler binaries from the bootstrap archive, maybe?17:04
xnoxLaney, queried, no.17:05
xnoxLaney, once we have qtbase in, i'll spend some time binNMU the lots until -proposed is happy.17:05
xnoxLaney, i'm afk until qtbase builds.17:05
Laneyxnox: If you did that you could start libreoffice building now17:07
Laneybut 'kay17:07
xnoxLaney, well Mirv insisted building in ppa, rather than -proposed. so we could have had s390x build in -proposed already.17:08
xnoxi could stage things in my non-virt ppa, meh. I'll go have dinner and sort things later.17:08
smosercjwatson, have you followed grub-emu + kexec at all ?17:52
smoserhttps://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-s390x-02-kexec-module-added-to-emu.patch?expand=117:52
Mirvxnox: the benefit is the armhf build time that was cut by doing it17:53
Mirvstill some 20 mins to go, then copy17:53
smoserhm.. i see http://people.ubuntu.com/~alanbell/uds-r/uds-r-foundations-r-powerpc-bootloaders-latest.txt . and the limited context there is almost the same as i'm after.  kernel + initrd as a loader.17:53
Mirvxnox: sil2100: I sometimes use the train in my own ways ;) since I'm not "publishing" it but copying, it's building in 03217:54
cjwatsonsmoser: I had a very brief look over it and asked the suse folks if they were going to upstream it; they indicated probably not since it wasn't really a proper architecture port, just an initramfs hack17:54
Mirvsil2100: so the autopkgtests were fixed but some new qtbase uploads to get s390x building (not available in landing PPA:s yet). a new look again tomorrow morning... (or during the night by US timezone people)17:55
smosercjwatson, so... the context is almost identical to what it was previously... except for s/ppc64el/s390/17:55
smoserwe need netboot like functionality on z series.17:56
Mirvxnox: hehe @ the checkbox, I'd have had zero idea about that..17:56
cjwatsonsmoser: yes, I'm aware of the context.  I'm not entirely opposed to integrating that, just haven't fully thought it through17:56
cjwatson(I think there are several more patches as well)17:57
smoserprobably.17:57
cjwatsonyeah, five in all17:57
smoserhaving "real grub" be the thing that parses a grub config file seems more desireable than having petitboot do it.17:57
cjwatsoncertainly17:57
smoserbut only if you can reasonably call the thing "real grub"17:57
cjwatson02 is non-upstreamable in its current form of course17:57
cjwatson(hardcodes systemctl, etc.)17:58
cjwatsonnot that that's necessarily an impediment17:58
Mirvxnox: ah now I finally understood that there's a poppler transition intertwined. thanks for the explanation.17:58
cjwatsonmy main concern is having to rebase all this stuff in future :-/17:58
smoseryeah.17:59
* Mirv sees lots of happening while visiting a christmas party.17:59
smoserbummer to see that they just call kexec.17:59
sil2100Mirv: ok, so leaving it in your hands then ;)17:59
Mirvsil2100: yes, I'll handle it before going to sleep17:59
smoseri'd hoped they'd written a kexec loader themselves. one without https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/129731617:59
ubottuLaunchpad bug 1297316 in kexec-tools (Ubuntu) "kexec doesn't load non-elf multiboot images" [Medium,Confirmed]17:59
cjwatsonanyway, by all means file a bug and we can tear our collective hair out about it.17:59
cjwatsonoh and also this patch set includes a zipl.conf parser ...18:00
cjwatsonand dracut hardcoding18:00
smoser:)18:00
cjwatsonand some weird stuff to do with hotkeys that I don't currently understand18:01
smoserwell, i assume that there is some work in petitboot too. i can file a bug. I wasn't really at the point where i woudl favor grub.18:01
smoserpetitboot has desire in that i know it works, and we already basically have to support it (powerNV).18:01
cjwatsonhaving more consistency across Ubuntu architectures would be good too18:01
smoserwhich is more consistency ?  we really can't get rid of ppc64+petitboot18:02
cjwatsongrub2 could at least in principle work on powerNV, no?18:06
cjwatsoneven if it doesn't today18:06
smoserin principal yes, but it'd be firmware change to remove petitboot18:07
cjwatsonsure18:07
cjwatsonI'm not pushing urgently for it, just that I'd rather pick something that can at least in principle do everything18:07
cjwatson(ok, petitboot sort of could as well, but it would be fairly daft to inject that for x86)18:08
smoseralthough if we wanted, we could kernel1+initrd1+petitboot (firmware) kexec -> kernel2+initrd2+grub-emu kexec -> real kernel+initrd18:08
smoser:)18:08
Mirvsil2100: xnox: ubuntu4 copied. also qt3d demoted and I did a qtmir-gles upload earlier based on the looks of what its autopkgtests complained (even though I couldn't reproduce any problem in just building it myself). finger crossed again, although I don't know about the poppler status etc and whatever else lurks in update-output.txt after these.18:14
smosercjwatson, filed bug 152402918:14
ubottubug 1524029 in grub2 (Ubuntu) "support grub-emu and kexec" [Undecided,New] https://launchpad.net/bugs/152402918:14
cjwatsonta18:16
=== cpaelzer is now known as cpaelzer_afk
=== pat_ is now known as Guest55002
=== cpaelzer_afk is now known as cpaelzer
xnoxMirv, thanks will be sorting things out shortly.18:56
=== cpaelzer is now known as cpaelzer_afk
=== cpaelzer_afk is now known as cpaelzer
barrydoko: ack.  if/when the upstream issue is resolved we can reenable it19:43
mterryLaney, can you help me with getting some autopkgtests restested?  I would like the system to reconsider libpdl-stats-perl, pyxplot, theseus, and visp (to help gsl get through)19:51
tewardthis may sound insane, but is it possible in a package build to extract the current 'tag' from `git tags` (since the source directory also has the .git from upstream) to define a variable for use during building/compiling of the package?  Trying to do it now but failing (only getting the build args and not what is wanted)20:17
zaytsevlaney: it took me awhile, but there we go: https://bugs.launchpad.net/ubuntu/+source/scons/+bug/1524058 <--- hopefully this time formatted according to the guidelines20:39
ubottuLaunchpad bug 1524058 in scons (Ubuntu) "Fix SConf.Streamer to work with non-unicode input on Python 2.x " [Undecided,New]20:39
cjwatsonteward: if it's in the source then you can do whatever you like as long as you declare the necessary build-deps20:41
=== salem_ is now known as _salem
=== cpaelzer is now known as cpaelzer_afk
BlackFateHello ppl, I try to bisect some kernel versions and one of the commits seems to fail during the build. What's the best approach at this point? Should I try and "git bisect skip" the problematic commit?22:41
tewardcjwatson: right, that's what's being done, but for some reason instead of extracting the tag data we want (the git command will only output the git tag we're on, not all of them), it's failing, and catching instead compiler args23:14
tewardcjwatson: and I have no idea how to fix that23:14
tewardcjwatson: or rather, it's being passed as part of compiler rules so... :/  (in the debian/rules)23:16
cjwatsonteward: Can you link to an example?23:19
tewardif i can find the 2FA key for my github, yes :P23:20
teward(though i'll pull it out of the code and put it into a paste, because codebase is 'not public' yet)23:20
cjwatsonteward: I suspect something like dodgy escaping in some bit of make/shell/whatever.23:21
tewardcjwatson: i would to, 'cept it's a go application, and there's no makefile (it's compiled by overriding dh_autoinstall)23:22
tewardthough it is a 'make' file (debian/rules), so maybe variable substitution is failing23:22
tewardthat's... odd... paste.ubuntu.com == lagging23:26
tewardcjwatson: this is essentially what is being attempted... http://paste.ubuntu.com/13839102/23:27
tewardcjwatson: can't figure out why it's failing, though if it's 'make' and it doesn't process Bash-style variable substitution...23:27
tewardmaybe that's why...23:27
* teward shrugs23:27
tewardcjwatson: i kind of inherited this thing, it's not my code :/23:27
tewardcjwatson: note that link is the 'slightly stripped' make rules, but it gives you the gist of what's being done in debian/rules at least :/23:29
sarnoldteward: make spawns a different shell for every line in a recipe. I think the export DAEMON_VERSION and umask lines are probably no-ops as a result23:29
tewardmmm23:30
tewardsarnold: well, there *is* something passed to the thing via the ldflags, it's setting the version string to '-extld=gcc' internally when it reaches these steps.23:30
tewardwhich makes me scratch my head23:31
tewardsarnold: so how would you suggest this be done, then, given that the version has to be 'dynamically updateable automatically via the git tags'23:31
sarnoldteward: I'd try 'go build -ldflags "-X main.Version $(git describe --tags)" -o ...'23:32
tewardsarnold: that's a headache given that the copy you see here is stripped - there's 16 individual `go build` lines :/23:33
tewardi'll test though23:33
sarnoldahh23:33
tewardand if that works, you get the gold star medal23:33
cjwatsonteward: $$(...)23:33
cjwatsonteward: $(...) does not do what you think there23:33
tewardcjwatson: $$(...) will do what we need?  (at the 'export' line?)23:33
tewardor do we have to do that for all variable sub?23:33
cjwatsonteward: also, each line is run in a separate shell23:33
sarnoldteward: then perhaps this is the starting point http://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html#Variables-in-Recipes23:33
tewardcjwatson: which is what sarnold said.23:33
cjwatsonright, you have at least two bugs :)23:34
tewardaahhhhhhhh23:34
tewardokay...23:34
cjwatsonteward: you would probably be better off splitting the content of that out to a separate script23:34
sarnoldcjwatson: hehe, nice :)23:34
sarnoldmmm. nice thinking outside of boxes :)23:34
cjwatsonteward: it's certainly possible to fix this up in make - $$(...), and convert the whole thing to a single shell command with ; or && separators - but it probably won't feel very natural23:35
tewardmmm23:35
cjwatsonteward: also the mentions of debian/PACKAGE/ smell like a template gone wrong23:35
tewardcjwatson: as i said i didn't write it :/23:36
cjwatsonbut I assume that's you obfuscating it23:36
tewardcjwatson: and yes23:36
tewardworks like a charm except for the version string so bleh23:36
tewardi'll stab this a little more :)23:36
tewardthanks for the pointers, cjwatson and sarnold23:36
cjwatsoncoo, ghc transition caused me to find a bug in LP's dep-wait handling23:37
* cjwatson declines to retry that one by hand23:37

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!