roaksoaxpitti: so I looked further into this, and have found the following:03:27
roaksoaxpitti: http://pastebin.ubuntu.com/15006344/03:27
roaksoaxpitti: so, maas-proxy is squid3 being run by MAAS. So it seems squid3 does not have a systemd service file, but does have an upstart job. So I wonder if that's causing everything to disable things?03:29
roaksoaxpitti: correct myself. In maas-proxy postinst we disable squid3, and I wonder if that's affecting maas-proxy being enabled?03:43
roaksoaxpitti: ok, I think I may have found the issue: http://paste.ubuntu.com/15006739/04:30
roaksoaxpitti: i had to change ordering to get maas-proxy to work, however, maas-dhcpd and maas-dhcpd6 still show:04:31
roaksoaxmaas-dhcpd.service is a disabled or a static unit, not starting it.04:31
roaksoaxmaas-dhcpd6.service is a disabled or a static unit, not starting it.04:31
roaksoaxpitti: and my guess is because there's 2 for service units for the same binary package.04:31
roaksoaxpitti: i wonder if there's a bug in the processing that's not correctly processing both entries? Or should a binary package nver have 2 service units ?04:32
pittiGood morning06:39
pittiroaksoax: binaries can have as many services as they want; and the order of calling dh_* should beo completly irrelevant06:40
=== shlomizadok__ is now known as shlomizadok
jrwrenare there any plans to update packaging guide to use git? http://packaging.ubuntu.com/html/packaging-new-software.html07:40
jrwrenman dh_make07:40
dholbachgood morning08:09
dokodid something recently change with alsa headers/libs?08:10
xnoxpitti, ubiquity uses http://start.ubuntu.com/connectivity-check08:11
xnoxand checks the checksum of that highly available file =)08:11
xnoxpitti, very similar to microsoft's connectivity check. apart from our text is longer =) and uses lorem ipsum08:12
pittixnox: right, but we don't seem to do that at all under unity08:16
xnoxpitti, yeah, i know. nor phone i don't think.08:17
xnoxpitti, conman will solve everything.08:17
* xnox giggles08:17
caribouxnox: did anything on s390x enablement for makedumpfile ?08:52
caribouxnox: I see that you marked the lp bug fix released08:52
xnoxcaribou, failing to parse first question08:52
caribouxnox: a bit fast, I was about to prepare the upload to debian,08:53
xnoxcaribou, i am happy to sync things when they are built in debian. but that like takes close to 24h =)08:54
xnoxand today is my last working day for the week.08:54
caribouxnox: that's fine, I'll do the debian bits & resync08:54
xnoxcaribou, i'm sure there will be more work needed. cause e.g. bootloader on s390x doesn't prepare any devices for dumps =/08:55
caribouor maybe wait a bit to see if it builds correctly08:55
xnoxdoes build https://launchpad.net/ubuntu/+source/makedumpfile/1:1.5.9-4ubuntu1/+build/899179208:55
Mirvcan someone help me parse the problem at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-032/xenial/amd64/c/cantor/20160210_064645@/log.gz ?08:56
MirvI was thinking maybe the python-numpy that's breaking other tests in proposed, but then again the silo autopkgtests shouldn't be using proposed anymore08:57
dokohmm, some -dev package dropped a dependency on libasound-dev08:58
Mirvlocally I don't have a problem installing the test dependencies on either xenial or xenial-proposed08:58
LocutusOfBorgyofel, hi! I actually uploaded jreen in Debian a while ago, and got accepted yesterday08:59
LocutusOfBorgI looked at the ubuntu package, and if agree I would like to fakesync it08:59
LocutusOfBorgbut I would like to ask you to give a quick look if possible08:59
LocutusOfBorgthe debian package is more complete, e.g. providing qt4 and qt5 packages09:00
Mirvah, not, if I've up-to-date xenial09:00
LocutusOfBorgmultiarch support09:00
Mirvpython3.4 is being removed09:00
* Mirv reads backlog in search of python3.4 breakage in xenial non-proposed09:00
xnoxMirv, findutils has breaks on python3.4, thus if you have python3.4 from release installed, and try to install findutils that will fail.09:01
xnoxMirv, and there is new enough python3.4 built in proposed, which i'm waiting to migrate over (autopkgtests are running)09:01
xnoxit's a subtle "Breaks: python3.4 (<< version in xenial-release" in findutils.09:02
Mirvxnox: ah... so I need to wait for that since the silos don't use proposed. thank you.09:02
xnoxMirv, yes. and cloud-images are broken, and doko has been fixing this with yesterdays uploads.09:03
xnoxjust need to migrate now.09:03
pittimeh, armhf test machines are still Qt'ed, after they've gotten perl'ed all yesterday and night09:05
xnoxMirv, also it's a bug if silos do not use proposed.09:05
xnoxslangasek, ^09:05
pittithey shouldn't use -proposed for running tests09:06
pitti(for builds, yes)09:06
xnoxMirv, do you see bugs in tests or builds?09:06
xnoxah looking up i see it's tests.09:06
Mirvxnox: tests, and yes that was just implemented09:06
xnoxMirv, yeah, just wait =)09:06
Mirvgood things come to those who wait09:06
dokoMirv, fix a ftbfs or two while waiting ;p09:08
Mirveveryone should have one http://www.einval.com/~steve/DebianT/guinness-debian-open.gif th-shirt09:08
MirvI'll work on this breaking test script...09:10
LocutusOfBorgLogan, ^^^^ (jreen pacage)09:13
dokocoreycb, pandas still fails its tests09:31
seb128xnox, you said you might be able to help on porting aptdaemon to packagekit 1 ... any chance you find some time for that next week? ;-)09:34
xnoxseb128, like the night before feature freeze? =)09:34
seb128xnox, if you like it this way, why not ;-)09:35
damasceneHi, how much time Midori browser maintainers have before they can not switch to WebKit2 because of feature freeze?09:45
seb128damascene, the feature freeze is on feb 18th09:49
seb128they can still ask for an exception after that09:49
damasceneok thank you seb128, I'll tell them to hurry up before feb 18th09:51
pittiapw, stgraber: FYI, lxc/trusty/ppc64el is green again, I just found out why trusty/ppc64el didn't work (http://autopkgtest.ubuntu.com/packages/l/lxc/)10:31
pittiapw: so you can un-mark this as known failure10:31
bdrung_workcjwatson, i saw your ITP for git-build-recipe. cool!10:48
_hchey all, I'm a DD working on getting the Android SDK into Debian.  I want to make sure that these packages are also included in Ubuntu 16.04, so we're working to get everything in Debian before Feb 18th.  Its mostly there already, but for some reason, the packages are not getting auto-imported into Ubuntu.  I just wanted to check whether I'm missing something that's blocking them.  Here's the list: https://qa.debian.org/developer.php10:52
dholbach_hc, "Not found"?10:56
sladenpresumably truncated by IRC at just the wrong point10:56
_hcdholbach: ^^11:00
cjwatsonI'm sure I've seen several of those getting imported11:01
cjwatsonbdrung_work: yw :)11:01
* cjwatson looks11:01
_hcis debian qa just out of date?11:01
bdrung_workcjwatson, is there an ETA when in can be used on launchpad?11:01
_hcall of the android-platform-* source packages should be at version 6.0.0 now11:01
mitya57_hc, android-platform-external-libunwind FTBFS on arm64 and thus stuck in xenial-proposed11:02
cjwatsonbdrung_work: Two weeks ago.11:02
mitya57_hc, android-platform-system-core needs old binaries removed because it dropped some archs11:04
mitya57And other packages depend on these two11:04
_hcthanks for the info11:04
cjwatsonyeah, looks like some archive admin unwinding to be done here, I'll look11:04
_hclooking at the FTBFS, its an odd one. is 16.04 using gcc 6?11:04
cjwatsonthe arm64 build of android-platform-external-libunwind doesn't block anything in itself11:04
mitya57No, gcc 511:04
cjwatsonunless something build-depends on that11:04
_hcyeah, some stuff bds on that11:05
cjwatsonlet me clarify, unless something build-depends on that and would be a regression if not built on arm6411:05
_hcalso, we had to do two of these as staged uploads since there are circular dependencies, so we might need to do the staging in ubuntu too11:05
bdrung_workcjwatson, is nest-part implemented?11:05
cjwatsonbdrung_work: not yet, that's the one major missing piece of the format11:06
cjwatsonon my list11:06
cjwatson_hc: details?11:06
bdrung_workcjwatson, rough ETA for that?11:06
cjwatson_hc: we can inject build-dependencies if we need to do a bootstrap step11:06
bdrung_worki use nest-part for audacity and vlc11:06
bdrung_worki am curious to switch to git for vlc11:07
cjwatsonbdrung_work: don't have an ETA yet, need to sit and rewrite the code11:07
_hcwe have a ~stage1 version of two packages that only build certain libs.  Then we can build the other packages against that, then we upload the full version of the first package11:07
cjwatsonWilliam brought up reasonable objections to my initial implementation attempt11:07
bdrung_workcjwatson, can you ping me once it is there?11:07
cjwatsonbdrung_work: can you just watch blog.launchpad.net instead?  I'm not going to remember to ping individuals :)11:07
cjwatsonbdrung_work: or subscribe to the bug11:07
cjwatsonbdrung_work: (https://bugs.launchpad.net/git-build-recipe/+bug/1537579)11:08
ubottuLaunchpad bug 1537579 in git-build-recipe "nest-part not implemented" [High,In progress]11:08
cjwatson_hc: which packages?11:08
_hcseamlik: which packages needed the staged uploads?11:08
bdrung_workcjwatson, I'll subscribe to the bug. thanks.11:08
cjwatson_hc: and can you point me to the staged versions?  (ideally it would be possible to build those just by using DEB_BUILD_PROFILE=stage1)11:08
seamlikandroid-platform-system-core and android-platform-build11:09
_hccjwatson: ^^^   seamlik actually did most of the work :)11:09
_hccjwatson: we are using git-buildpackage, so its all in git, if that is useful, or I guess debian-snapshot is another option.  in what form do you need those packages?11:10
cjwatson_hc: really don't care11:10
cjwatsonwhatever you have11:10
_hcthey are all here: https://anonscm.debian.org/git/android-tools/11:11
cjwatson_hc: android-libunwind and android-libunwind-dev are intentionally no longer built for armhf, is that right?11:12
_hcthat is correct11:12
_hcGoogle only supports building the SDK on i386 and amd6411:12
_hcit could be ported without a lot of effort, but we want to start with i386 and amd6411:13
_hcand get the whole thing in their first11:13
cjwatson_hc: and android-libcutils, android-libcutils-dev, android-liblog, android-liblog-dev, android-libzipfile, android-libzipfile-dev, android-system-dev are now intentionally built only on amd64/i386?11:13
seamlikAll of them are x86 only now11:14
cjwatsonI don't think any staging is needed; both android-platform-system-core and android-platform-build have built11:14
_hccool, that simplifies things :)11:15
seamlikThat easy?11:15
cjwatsonexcept for android-platform-build/arm6411:16
_hcseamlik: did you see the FTSBS error? Its odd https://launchpadlibrarian.net/236936154/buildlog_ubuntu-xenial-arm64.android-platform-external-libunwind_6.0.0+r26-3_BUILDING.txt.gz11:16
cjwatsonbecause it b-ds on binaries from android-platform-system-core/arm64 that you just told me you were intentionally no longer building11:16
seamlikYeah I prepared an update11:16
_hcah, ok, we uploaded things in a different order11:16
_hcso we'll fix that one11:17
seamlikOh, I mean an update for android-platform-build11:17
cjwatsonit's not a problem anyway, we don't really care if android-platform-build is harmlessly dep-waiting somewhere11:18
_hcoh, I see, that FTBFS for libunwind is on arm64, I keep seeing that as amd6411:18
seamlikI need to separate out Build-Depends-Indep11:19
seamlikSo that the B-D won't be uninstallable11:19
xnoxLaney, i hear vila wants to get brand new bzr into xenial =)11:20
Laneywe spoke11:21
cjwatson_hc: should all be cleared out in a bit11:21
_hcawesome, thank you11:21
_hcalso, at some point, we'll need to coordinate with Ubuntu people on the android-tools source package, since that is maintained separately in Ubuntu11:22
_hcwe've entirely replaced it in Debian11:22
_hcit is ok if that is unresolved in 16.0411:22
_hcthey just Conflict:11:22
cjwatsonYeah, I imagine you'll want to talk to the Ubuntu phone people, I don't know who's currently most relevant there11:23
_hcI emailed a list of people I found in the changelog11:23
cjwatsonsil2100 would probably at least have an idea who to direct you to for that11:23
seamlikI bet there's a channel for Ubuntu Touch?11:25
cjwatsonIt has a surprising name11:25
sil2100_hc: we do use android-tools for our flashing tools for ubuntu-touch from what I know11:27
sil2100_hc: how did it get replaced in Debian?11:27
_hcthe android-tools source package is pretty out of date11:27
sil2100i.e. what's the new package name?11:28
_hcandroid-tools is a custom bunch of code grabbed from various git repos11:28
_hcwe've been packaging it so that there is one source package per git repo11:28
_hcthe binary packages are now adb, fastboot, etc instead of android-tools-adb, android-tools-fastboot11:28
sil2100_hc: ok, good11:29
sil2100Let me fetch this doc and try to either start thinking about migrating our tools to use the new approach or at least forwarding it to the right people11:29
_hcthe one thing we will not be packaging is adbd, since that is meant to run on the Android device not on Debian/Ubuntu11:30
_hcbut of course Ubuntu Touch is the "android device", so it needs adbd11:31
_hcbut we welcome patches to our packages if they want to maintain adbd in this whole setup11:31
seamlikadbd is a "device" program which uses "device" version of libraries, which means a lot efforts to make11:33
_hcI gotta say, this room has always been quite responsive when I've brought issues here.  good to get stuff done :)11:33
seamlikIs anyone making a tool to automate the translation of Android.mk to a usable Makefile? That really simplifies the maintenance11:34
sil2100_hc: ok, noted :) Let me put that on my TODO list and try to take care of it in the nearest time-cycles11:34
cjwatsonpitti: Could you retry the various haskell-hoogle autopkgtests but in such a way that they use haskell-hoogle from -proposed?  They're all part of the same transition so won't land without the version in -proposed anyway11:39
xnoxcjwatson, is debconf's Default[armhf]: a thing, or is it some magic pre-processing?11:41
* xnox is failing to find authoritative document on how debconf templates can look like.11:41
pitti$ run-autopkgtest -s xenial --trigger=jquery/1.11.3+dfsg-4 --trigger=haskell-conduit/ --trigger=haskell-uniplate/1.6.12-4build1 --trigger=haskell-resourcet/1.1.7-1build1 --trigger=haskell-case-insensitive/ --trigger=haskell-http-types/0.9-2 --trigger=haskell-vector-algorithms/ --trigger=haskell-src-exts/1.17.1-1build111:41
pitti--trigger=haskell-blaze-builder/ --trigger=haskell-parsec/3.1.9-4build1 --trigger=haskell-text/ --trigger=haskell-vector/ --trigger=haskell-wai/ --trigger haskell-hoogle/4.2.43-3 haskell-hoogle11:41
pitticjwatson: ^ done11:42
asachmm. fresh xenial schroot hosted on a trusty box gives me: W: No sandbox user '_apt' on the system, can not drop privileges ... i think i heard chatter about brokenness due to sandbox user, but thought it was fixed by now.11:42
pittiyay, armhf queue is mostly over the hump11:42
asacor is this different?11:42
xnoxasac, on xenial hosts it is.11:43
pittiasac: yes, first apt 1.0 it was broken, but that got fixed in apt pretty quickly11:43
pittithis is now just a warning11:43
xnoxasac, either create _apt user on your host, or stop copying users from host inside the chroot.11:43
xnoxasac, or upgrade host apt to xenials one.11:43
xnoxright "trusty box".11:44
cjwatsonxnox: documentation is in debconf-devel(7); pretty sure your example is preprocessed.  what package is that in?11:46
cjwatsonpitti: thanks11:46
cjwatsonxnox: e.g. base-installer has a preprocessing script for this11:47
xnoxcjwatson, well choose-mirror uses that, and it has pre-processing. i was hoping to use same elsewhere.11:47
xnoxcjwatson, and it's all in perl... whatever happened to using m4 to preprocess things +)11:47
cjwatsonxnox: yeah you have to preprocess11:47
cjwatsonxnox: I thought you were under 3011:47
xnoxcjwatson, i shall use groovy script then.11:48
* xnox has weird m4 fetish i guess.11:48
asacxnox: how do i best create the user so it will not hurt me when upgrading to xenial in april?11:53
pittiasac: really, it should not hurt11:53
pittiasac: if that actually breaks anything, it's a bug11:53
asacpitti: do you have the current passwd line for that user in xenial?11:53
pittiasac: yes11:53
pitticjwatson: green again11:56
pittilibfile-slurper-perl/armhf too, that should be the last thing that blocks perl11:56
cjwatsonpitti: great, thanks11:56
pittiemtpy armhf queue!11:57
cjwatson$ grep -A1 adduser /var/lib/dpkg/info/apt.postinst11:57
cjwatson        adduser --force-badname --system --home /nonexistent  \11:57
cjwatson            --no-create-home --quiet _apt || true11:57
cjwatsonasac: ^- do that11:57
xnoxasac, adduser --force-badname --system --home /nonexistent  \11:57
xnox    --no-create-home --quiet _apt11:57
xnoxpitti, right queue empty, but will still take hours to finish python3.4 tests =)11:58
asaccool... /me runs that command11:58
pittixnox: yes, around 2.5 hours11:58
asaccjwatson: pitti: xnox: thanks a lot. works perfectly!11:59
pittiasac: OOI, what didn't work before?12:00
pittithis really ought not to be necessary12:00
asacpitti: i am on trusty box, created a  fresh xenial chroot, and then running apt-get update in the schroot i got:12:00
asacW: No sandbox user '_apt' on the system, can not drop privileges ...12:00
cjwatsonpitti: hm, did you do that on all arches?  (hoogle)12:01
asaci think that makes sense... maybe schroot could get a patch in trusty to do the magic12:01
xnox... which is a mostly harmless warning12:01
cjwatsonnot seeing it in either http://autopkgtest.ubuntu.com/packages/h/haskell-hoogle/xenial/s390x/ or http://autopkgtest.ubuntu.com/running.shtml12:01
cjwatsonpitti: oh never mind, I apparently can't read12:01
asacoh ok it wasnt an error. i was confused because i couldnt find the package that was in universe :P12:01
xnoxasac, did that warning prevent you from doing anything? or simply distaste of seeing it?12:01
asacanyway. warning gone is even better12:01
asaci thought it prevented me from using apt12:01
cjwatsonit's running on armhf, but maybe not on s390x?12:01
asacbut it didnt12:02
xnoxcjwatson, it could have completed on s390x and then there is 5 minute sync gap where one can see it nowhere12:02
pitticjwatson: I did, but it ran a bit later on armhf12:02
cjwatsonyeah, that just occurred to me12:02
xnoxnot running, not in queue, and results are being "uploaded" =)12:02
pitticjwatson: looking on s390x12:03
cjwatsonpitti: fancy being a techboarder for me?  I'd like to enable https://bugs.launchpad.net/launchpad/+bug/1517510 for xenial, since the necessary LP support has been rolled out now12:13
ubottuLaunchpad bug 1517510 in Launchpad itself "Add xz-compressed archive indexes" [High,Fix committed]12:13
pitticjwatson: ah, how can I help with that?12:13
cjwatsonin "lp-shell production devel":12:14
cjwatsonxenial = lp.load('/ubuntu/xenial')12:14
cjwatsonxenial.index_compressors = ['gzip', 'bzip2', 'xz']12:14
pitti>>> print(xenial.index_compressors)12:14
pitti[u'gzip', u'bzip2']12:14
pitticurrent value looks expected12:14
cjwatsonyeah, that's the default12:14
pitticjwatson: ok, done12:15
cjwatsonexcellent, thanks12:15
pittire-ran it with the print() and it's in12:15
cjwatsonI think we can remove bz2 pretty soon, but I want to check that nothing obviously explodes, and I think I need to add xz handling of Translation-* to debmirror12:15
cjwatsonconveniently I adopted debmirror recently12:16
pitticjwatson: can precise already read xz, or does that not even use bz2?12:16
cjwatsonpitti: well, we shouldn't change existing stables here12:16
cjwatsonpitti: I think it could read xz though12:16
pittioh, *slaps forehead*, I did that on _xenial_12:16
cjwatsonwe're a bit late in doing this12:16
pitticjwatson: i. e. let it bake on xenial for a bit, and bit by bit enable it on older releases after testing?12:17
pittiI mean, merely building those in addition shouldn't break much, it's disabling bz2 which could12:17
cjwatsonI wasn't planning to change older series at all12:17
cjwatsonnot least because for it to be useful we'd have to republish the release pocket12:17
pittiI thought you wanted to get rid of the bz2 compression in LP12:17
cjwatsonwhich generally we try not to do12:17
pittiah, good pointn12:17
cjwatsonoh, no, that's negligible code, I don't care about that12:18
cjwatsonI just don't want to keep three compression methods around for a series for very long - if nothing else it slows down publication12:18
cjwatsonpitti: While you're doing me favours :-), could you add ~ubuntu-archive-robot to ~launchpad-buildd-admins?  That bot already has fairly comprehensive privileges, and it would be convenient to be able to cron a thing to stab the arm64 build farm12:20
apwpitti, lxc> ack though the adt-matrix hints work the same way, they are for specific combinations only12:21
pitticjwatson: http://autopkgtest.ubuntu.com/packages/h/haskell-hoogle/ ← all green now, all arches caught up12:22
pittiapw: right; I meant, you should drop any hint for "lxc", we shouldn't have known regressions there any more12:23
cjwatsonpitti: Great, thanks.  Will keep an eye on excuses12:23
apwpitti, ack12:26
pitticjwatson: added u-a-robot12:27
cjwatsonpitti: thanks12:30
coreycbdoko, saw that about pandas, I'll take a look12:34
seb128Noskcaj, hey, your blueman update is still on top of e.u.c reports for xenial, do you plan to handle it/looks at the issue?12:39
seb128bdmurray, do you have any news on getting the xenial retracers fixed?12:40
=== alecu-natholiday is now known as alecu
pittiyay, perl landed13:00
cjwatsonpitti: oh good13:02
pitti~ 6000 tests, ugh :)13:02
caribouxnox: makedumpfile built for s390x on debian13:10
dokoLocutusOfBorg, you synced x11-apps, but now it ftbfs on ppc64el: https://launchpadlibrarian.net/235789778/buildlog_ubuntu-xenial-ppc64el.x11-apps_7.7+5+nmu1_BUILDING.txt.gz13:10
LocutusOfBorgI didn't sync it :)13:11
LocutusOfBorganyway, seems unrelated to my debian upload and I can't even retry the build13:12
julianksarnold: What's going on with #1531923 - it's getting really annoying now13:14
juliankbug #153192313:14
ubottubug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,Confirmed] https://launchpad.net/bugs/153192313:14
julianksilly ubottu13:14
LocutusOfBorgdoko, maybe the reason is the missing -std=gnu99?13:14
LocutusOfBorgI have no access to porterboxes in ubuntu, and not core-dev13:14
juliankThe missing lz4 in main is preventing some serious APT bugs from being fixed13:15
mdeslaurtyhicks: ^13:16
LocutusOfBorgdoko, going to sync mpi-defaults, changes are in debian13:18
LocutusOfBorgmapreri, ^^^13:18
cjwatsonpitti: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-037/excuses.html - I'm looking at the bulk of this, but the "test in progress" thing on unity-scopes-api/ppc64el, how can that be cleared?13:22
pitticjwatson: ah, I had to purge the ppc64el queue this morning as ppc64el got two kinds of breakages13:22
pittiI temporarily disabled it in bitney, but that doesn't apply to the train configs13:22
cjwatsonpitti: also, is there some equivalent of http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/amd64/ that also shows PPA runs?13:22
pitticjwatson: essentially, they need to be re-queued (using retry.cgi), I can deal with that13:23
cjwatsonok, thanks13:23
pitticjwatson: no, there's no web UI for those results, that's suposed to be on ci-train13:23
cjwatsonpitti: it is eventually, but there's a lag13:23
cjwatsonwhich is annoying if one is trying to iterate on necessary triggers13:24
pitticjwatson: I took the i386 regression retry.cgi link next to it and changed the URL13:24
pittinot that it'd help much, with this amount of red13:24
cjwatsonpitti: yeah, it needs some wider triggers in order to pass, I'm just trying to figure out what13:24
pittibbl, lunch13:25
Mirvfun, systemd update on 14.04 caused screen to lock (I mean just normal screenlock, enter password to unlock)13:32
mdeslaurMirv: hrm, perhaps similar to bug 1543883 that sarnold experienced13:41
ubottubug 1543883 in systemd (Ubuntu) "screen blanked during systemd-logind upgrade" [Undecided,New] https://launchpad.net/bugs/154388313:41
=== Foxtrot is now known as Guest20528
coreycbdoko, can we drop pandas 0.17.1-3ubuntu1 that is stuck in proposed?  I'd prefer to hold off until their next release.  too many intermittent test failures for big endian arches.13:53
cjwatsonpitti: ok, please could you disable xz on xenial again?  it's causing apt-ftparchive to crash, reason as yet undetermined14:17
pitticjwatson: ok, done14:18
cjwatsonI have a big strace to stare at as time permits14:18
cjwatsonmight just be that we need to build without liblzma for precise, but I need to work out why this didn't turn up on dogfood first14:20
cjwatsonmaybe just an insufficiently large test case14:20
marlincDoes anyone know if its possible to make the name specified with --bootloader-id when installing GRUB static? I set it when I installed GRUB but when the next GRUB update comes it gets overwritten14:23
marlincI use UEFI to boot between multiple operating systems14:24
LocutusOfBorghi xnox can I ask you the rationale for disabling mir on s390x (xorg-server?) I ask because I enabled mir on s390x for libsdl2-dev14:31
LocutusOfBorgI don't get why libmir is built everywhere, but packages using it shouldn't use on some architectures14:34
xnoxLocutusOfBorg, because there is no mir on s390x.14:36
LocutusOfBorgmmm and the library is built?14:36
cjwatsonlibmircommon5                    | 0.19.1+16.04.20160204-0ubuntu1 | xenial          | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x14:37
LocutusOfBorglibsdl2 has been built correctly there with mir support14:39
LocutusOfBorgcjwatson, does this mean mir is available everywhere?14:39
cjwatsonit would seem to be but what do I know14:40
cjwatson(it may well not work ...)14:40
LocutusOfBorgexactly my point14:40
LocutusOfBorgI would avoid to use it if it is broken14:41
LocutusOfBorgand probably bother the maintainer about not building everywhere14:41
LocutusOfBorgno mention in changelog14:43
LocutusOfBorginfinity disabled it in 0.13.1+15.10.20150520.1-0ubuntu114:45
LocutusOfBorgso I presume now the porting is complete14:45
LocutusOfBorg+  * Disable testsuite on powerpc until big-endian porting is complete.14:45
LocutusOfBorgsomebody re-enabled it and the testsuite is disabled now on big-endian14:49
cjwatsonpitti: is there any way at all that I can see the output of a ci-train test before bileto updates, maybe via snakefruit or something?14:56
cjwatsondoesn't have to be a web UI14:56
pitticjwatson: you mean more than the logtail on running.shtml?14:57
cjwatsonpitti: yeah, one that has finished14:57
pitticjwatson: CI train's britneys update every 30 mins  AFAIK; if you use staging, those update every 514:57
cjwatsonpitti: it's more like every 60+ at the moment14:58
pitticjwatson: ah yes, you could look at the swift directory14:58
pitticjwatson: which silo is that?14:58
cjwatsonpitti: 3714:58
pitticjwatson: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-037?format=plain14:58
cjwatsonpitti: ah, perfect, thanks14:58
pitticjwatson: there's "xml" (but not clickable either) and "json" too if you prefer that14:59
cjwatsonpitti: yeah, this is fine14:59
pitticjwatson: welcome to the comfortable web 3.0 ! :)15:05
pitticjwatson: more seriously, it shouldn't be too hard to slap together some wgets or urlopen()s to map a silo, package, and arch to a nice and small "show status and log link" CLI output15:06
pittiif that happens often15:06
pittiyou can show results for a particular package with e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-037?format=plain&prefix=xenial/amd64/u/unity-scopes-api/15:07
pittiappend "&delimiter=@" and you get only the results; the last line, with /log.gz and /results.tar gives pretty much everything one would want to know15:07
cjwatsonpitti: All right, I need deeper help here.  Can you see why my trigger in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-037/xenial/amd64/u/unity-scopes-api/20160210_150405@/log.gz is apparently insufficient?  Or do you have a convenient way to test complex sets of triggers like this?15:10
pitticjwatson: the triggers are fairly irrelevant for silos15:12
pitticjwatson: one idea is that this depends on something in xenial-proposed which hasn't landed yet15:12
cjwatsonpitti: In this case it needs a combination of all the stuff in the silo plus some things that are in -proposed15:12
cjwatsonIndeed, that15:12
pitticjwatson: PPA tests run against xenial plus the silo, not against xenial-proposed as well15:13
cjwatsonpitti: It needs at least libjsoncpp and capnproto, plus probably ubuntu-touch-meta15:13
pittias that is in many cases unintended and led to too many blockings15:13
cjwatsonpitti: So how do we disentangle this, since this stuff is needed in order to land those bits from -proposed?  Copy them into the silo?15:13
pitticjwatson: ah, so cleanes would probably be to land those first?15:13
cjwatsonpitti: We can't, the bits in the silo are part of landing those things :-/15:14
pittiah, tricky15:14
pittiso we land one transaction via both a silo and regular -proposed uploads?15:14
pittiyeah, would be better to land that all in one silo15:14
cjwatsonWell, part of it was an auto-sync from a month and a half ago15:14
cjwatsonSo you know15:14
cjwatsonAnd then phone people never land anything other than via silos15:14
pitticopying the -proposed packages into the silo  actually ought to work15:15
cjwatsonAll right, I'll give that a go15:15
jdstrandpitti: hi! looking at excuses, I see that ubuntu-core-launcher is a valid candidate for 14 days, but it didn't migrate15:15
pitticjwatson: or I restart the tests manually with enabling -proposed on those15:15
pitticjwatson: might be easier?15:16
jdstrandpitti: I didn't do that upload, but was planning one on top of that. is there anything special I/we should do?15:16
cjwatsonpitti: I think either way would work.  I can copy the packages, so let me try that first15:16
pittijdstrand: it breaks ubuntu-snappy, as per http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt15:16
pittijdstrand: so it won't land until ubuntu-snappy gets fixed/rebuilt/whatever to work with that ubuntu-core-laucher version15:17
pittijdstrand: presumably there are some Breaks:/versioned Depends:/library transition or something such?15:17
jdstrandoh, I was unaware of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt15:19
jdstrandpitti: thanks for the info. I'll let the snappy team handle that transition then15:19
pittijdstrand: to examine, start a xenial-proposed schroot (or chdist) and try to install ubuntu-snappy15:19
jdstrandkyrofa: fyi, ^15:19
seb128pitti, jdstrand, I think mvo was trying to get snappy binaires removed on powerpc/s390x so the new version migrates, unsure what's the status of that though15:20
jdstrandI suspect that xenial needs a 1.7.3 upload of ubuntu-snappy15:20
jdstrandbut I'll let them handle it15:20
seb128jdstrand, there is an update, it's blocked in proposed though because fails to build on powerpc/s390x15:20
seb128it has been this way for a while though15:21
jdstrandyeah, interesting. but the previous upload did build15:22
seb128like since novembre, I guess nobody in the snappy team has slots to look at those archs15:22
jdstrandbased ontheir ppa (which doesn't include s390x, it looke like 1.7.3 will ftbfs on arm6415:23
jdstrandI know that is a target arch-- maybe they'll fix it all up in one go15:23
jdstrandok, I'm not touching that15:23
jdstrandpitti, seb128: thanks again! :)15:23
bdmurrayseb128: The new version of gdb is running on them but we have had some issues with the Error Tracker. Things are running again though.15:23
seb128bdmurray, so we should start seing valid signatures/stacktraces for new retraces?15:24
bdmurrayseb128: I hope so but let me know if you see something amiss.15:24
tyhicksjuliank: sarnold has been tied up in other MIR security reviews15:26
tyhicksjuliank: there's still one MIR security review before it15:27
tyhicksjuliank: the good news is that it'll happen very soon15:28
xavigarciajhodapp: Hi! I think you pinged me yesterday, while I was already off...15:28
xavigarciajhodapp: was it about that focus and sound indicator bug?15:28
seb128bdmurray, k, the daily view still has mostly backtraces without symbols but let's see if that improves in the next days when retracers do new ones15:28
bdmurrayseb128: we do have a queue of things to retrace at the moment due not accepting crashes for a bit15:29
tmartinshey guys! Anyone here is experimenting Neutron 8.0.0 b2 on Xenial ?15:30
* pitti re-enables ppc64el in britney15:35
LocutusOfBorgginggs, I'm gonna sync mumps15:38
LocutusOfBorgdebian has the delta15:39
slangasekxnox: what silo was not using -proposed? AFAIK that would've required someone to manually change the setting15:39
xnoxslangasek, false alarm. for built proposed was used, it's just for autopkgtest proposed is not used, by default.15:40
xnoxwell, magic is done there to try things, with -release only bias.15:40
ginggsLocutusOfBorg: sure, go ahead15:41
LocutusOfBorgdoko, stealing your tomahawk rebuild, because of the new jreen multiarch, I'm not sure it  is needed, but since a lot changed I prefer to be safe16:39
infinityLocutusOfBorg, xnox: the Mir big-endian issues only affect the display server, not the client libs, so it's perfectly fine to *link* to Mir on ppc/s390x, even if an s390x mir display probably wouldn't work right if someone tried.  And having arch-specific deltas is a bit of a pain to maintain.16:52
LocutusOfBorgso the next xorg-server can drop the delta? (that bit)? wonderful16:52
LocutusOfBorgtjaalton, ^^^16:57
jderoserharper: turns out qemu wants to open /usr/share/OVMF/OVMF_CODE.fd read-write also, so it seems you need per-instances copies of both OVMF_CODE.fd and OVMF_VARS.fd17:01
rharperjderose: can you confirm that it made changes to the _CODE.fd ?17:01
rharperthat doesn't seem correct, maybe we can run it with a readonly parameter17:01
rharper-drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd17:02
rharperjderose: try that17:02
rharpershould force a ro open on the CODE.fd instead of default rw open17:02
jderoserharper: still working through my VM install, but thus far it hasn't modified OVMF_CODE.fd17:02
jderoseah, good idea... i'll try the readonly option17:02
rharperok, it shouldn't so should be safe to run with ,readonly17:02
jderoserharper: no luck... with the readonly option for OVMF_CODE.fd, it seems to break UEFI mode... it tries to PXE boot in BIOS mode instead of booting from the ISO in UEFI mode17:14
rharperthat can't be right;  can you open a bug for that ?17:14
rharperI'd like to track the right thing here17:14
jderoseyeah, not what i was expecting. oh, and after my previous VM install completing and rebooting, my per-instance OVMF_CODE.fd copy still hadn't been modified17:15
jderoserharper: sure. think i should file it against qemu or ovmf?17:15
rharperjderose: either, and we'll add an affects the other package17:16
rharperit feels like ovmf17:16
rharperas qemu did what you asked (readonly)17:16
rharperbut it's also possible something funking is going on with the pflash emu ?17:16
jderoserharper: i still haven't read through the entire thing yet, but this was linked in that debian bug, is quite useful - http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt17:17
jderoserharper: could be, although everything seemed to work fine when i used a per-instance writable copy of both OVMF_CODE.fd and OVMF_VARS.fd... which to my kinda suggests it isn't a general problem with pflash emulation17:18
rharperjderose: well, I mean, the _CODE.fd is _supposed_ to be read-only; and when we mark it that way, the code doesn't behave the same17:19
rharperthat was the reason for the split in the first place17:19
rharpersomeone misplaced a write in there somewhere =)17:19
rharperjderose: did you order the pflash arguments with readonly first and then the writable ?17:20
rharperthat whitepaper mentions order mattering due to how it;s mapped into ram17:21
rharper"This way qemu configures two flash chips consecutively, with start addresses17:21
rharpergrowing downwards, which is transparent to OVMF."17:21
jderoserharper: i used "-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd"17:21
rharperand then the second one for vars17:22
jderoseoh, and i put the OVMF_VARS.fd -drive argument after the OVMF_CODE.fd" one17:22
rharperthat seems correct17:22
* rharper tries locally17:22
jderosejust minus "readonly" onthe 2nd17:22
rharperjderose: oh, can you reset your local _VARS.fd and try again ?17:24
rharperI've seen "boot" behavior change after UEFI has updated the _VARS.fd17:24
rharperqemu-system-x86_64 -enable-kvm -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,readonly,format=raw -drive file=local_vars.fd,if=pflash,format=raw -cdrom /home/rharper/work/iso/ubuntu-14.04.3-desktop-amd64.iso17:25
rharperjderose: for a fresh _Vars file, that boots the iso fine for me17:25
naccslangasek: so, how worth it is it for me to reduce the number of packages needing to be altered in the bootstrap to the smallest set possible? I can do it, I think, just requires kind of starting over and vetting the process out again, to some extent17:25
slangaseknacc: how big is the bootstrap set currently?17:26
jderoserharper: ah yeah! it works for me now too. i guess some change in _VARS.fd caused something screwy before i tried the system-wide _CODE.fd with readonly17:26
rharperjderose: yeah!17:27
jderoserharper: thank you very much for your help on this! want me to still file a bug?17:27
jderosecool, thanks again17:27
rharperyou may need to run efibootmgr in the guest17:27
rharperIIUC, you successfully installed17:27
rharperthe default boot device is going to be set to a disk after install17:27
rharperyou'd need to either use efibootmgr to control what to boot next time17:27
jderoseright. i believe efibootmanager is always installed in UEFI desktop and server installs17:27
rharperor manually interrupt17:28
rharperand use shell to fix up17:28
rharperjderose: thanks for testing =)17:28
jderosenp :)17:28
naccslangasek: I believe around 7317:31
naccslangasek: 73 packages, that is, including the eventual targets of the bootstrap17:31
slangaseknacc: not sure what you mean by "eventual targets" :)  do you mean there are 73 builds total to be triggered, or 73 source packages that need to be built uncleanly for the bootstrap?17:32
naccslangasek: sorry, so the need for the bootstrap is circular dependencies between phpunit, doctrine and symfony (roughly). so 3 of the 73 src packages in that list are those ones. 70 src packages have to be built uncleanly, in order to get to that point (the way I did it originally)17:34
cjwatsonuncleanly as in against feature-reduced versions of their dependencies, or uncleanly as in source modifications?17:35
naccthe former17:35
cjwatsonthat's mildly vexing but not a huge problem17:35
nacci.e., staged builds17:35
cjwatsonsource modifications are the main hassle17:35
cjwatsoncan the starting three be built using just what's in the Ubuntu archive, or do they need binaries injected from somewhere to satisfy build-deps?17:36
naccyeah, that makes sense, there are some new packages and updated versions needed too, not sure if that would be in the same boat as "source modifications"?17:36
cjwatsonI only count source modifications that would not end up in the Ubuntu archive17:37
naccah then there are zero of those -- in the cases i had to do source modifications for bootstrap during my ppa builds, i reverted them in the final version17:37
nacc(above was necessary since i can't do staged builds in the ppa)17:37
cjwatsonI thought you just said there were three of those, phpunit, doctrine, symfony17:37
cjwatsonI mean source modifications for staged builds17:38
naccoh sorry, i misread!17:38
nacc*not* end up in the archive17:38
nacceven that, i think, is pretty small ... but i'd need to go look at my list again17:39
nacclet me start over, though17:39
nacci was looking at removing php5 from the archive and moving php7 to main17:39
naccbut that requires making sure everything can still build :)17:39
naccso there was a "tight" b-d loop between symfony, phpunit and doctrine ... and phpunit in turn is a b-d of many php packages so they can run their unit tests17:40
cjwatsonso, basically we want a sequence of operations that can take us from the current Ubuntu archive to the desired state.  it's fine to use a PPA for staging (though anything we use for this we'll want to be devirtualised and specially privileged, if the end result is going to be copied into the archive)17:40
naccright, that's what i'm working on doing now via bugs and debdiffs and then i'll provide in the bug my explicit sequence17:40
cjwatsonbut the more that can be straight source copies and the fewer manual uploads need to happen, the less effort it is17:40
cjwatsonif necessary, we can also bootstrap from binaries in Debian17:41
cjwatsonthe way we do that would be to do one build cycle in an Ubuntu environment where the first build takes Debian binaries as its build-deps, and then use the output of that build as build-dependencies for builds that end up in Ubuntu17:42
cjwatsonto make sure everything is clean and we aren't including stuff we can't rebuild17:42
cjwatsonso if the bootstrap is already done in Debian (I haven't checked) and we can save a lot of effort by starting there, that's legitimate17:42
naccI think I follow -- the issue here is that because we need to re-spin the binary packages so they refer to php7 as their deps (dh_php, dh_phpcomposer, dh_phppear updates) which hasn't been done in Debian17:43
* cjwatson nods17:43
naccbut for many packages that occurs by updating pkg-php-tools and php-pear and then rebuilds17:43
cjwatsonI assume this isn't all architecture-independent code?17:43
slangaseknacc: yeah, 70 packages that I can throw at the wall with no source modifications, not worth a lot of your time to reduce the size of this set17:44
naccslangasek: ok, that's good to hear :/ i was starting to get a little stressed trying to rework the flow17:45
cjwatsonslangasek: BTW do you know about bootstrap-package in u-a-t?17:45
cjwatsonfrom the sound of things may not be useful for this particular case, but it's newish and can be handy for things of this type17:45
nacccjwatson: well, the core php code (bits of the interpreter) is arch-specific, as it's compiled. But i think all the php pear/pecl modules are arch-independent17:46
nacccjwatson: in this bootstrap that means roughly i think 5-10 packages that are arch-specific17:46
nacccjwatson: but i'm not sure if that's what you were asking17:46
cjwatsonright, more than 0 was what I was asking17:46
cjwatsonsince that definitely means it needs to go in a devirt ppa :)17:46
slangasekcjwatson: I had not heard of this, I'll look thanks :)17:47
slangasekdevirt ppa> ah good point17:48
tewardfor those with knowledge of sbuild, can sbuild run armhf builds on non-arm (amd64) host infrastructures?  does it use some type of virtualization to achieve it?17:48
cjwatsonteward: (a) yes (mk-sbuild --target=armhf can help) (b) it uses qemu-user-static17:48
cjwatsonteward: this is basically what LP did for virtualised armhf PPAs until last week, so same reliability issues apply17:49
tewardcjwatson: so, --target=armhf is needed alongside --arch=armhf, or...?17:50
* teward knows how to make a 32bit schroot by passing --arch=i386, but isn't sure how to achieve this for arm17:51
nacccjwatson: slangasek: if you read the spec at https://wiki.debian.org/BuildProfileSpec, specifically, the example in "Build-Depends syntax extension (restriction formulas)" ... I believe the way to specify that a b-d should not be enforced in either build profile nocheck or stage1 is 'Build-Depends: foo <!nocheck !stage1>' rather than 'Build-Depends: foo <!nocheck> <!stage1>'. Does that seem correct to y17:54
naccou? The phrasing in their example confused me, which led me to do it the wrong way for some packages, I think (and I'll go fix up the debdiffs now)17:54
tewardblah i should just read wiki pages17:55
tewardcjwatson: thanks17:55
slangaseknacc: your reading seems intuitive to me, but I don't know what the code itself does17:55
cjwatsonnacc: That would mean "not nocheck or not stage1", which is unconditionally true - I think you want "<!nocheck !stage1>"17:57
cjwatsonhm, but they have a contrary example17:57
naccslangasek: yeah, i tested just now and i think i'm right and the wiki text of "if neither the profile stage1 nor the profile cross are active" is not exactly right. It should read: "In the example above, the package would depend on foo for i386 or arm, unless both the profile stage1 and the profile cross are active."17:57
nacccjwatson: right, so what you wrote is what i think it should be too17:57
naccbut their example is wrong, i think :)17:58
naccor the english is off17:58
cjwatsonI'm not sure.  Run each one through sbuild -Pstage1 and see what happens?17:58
naccjust tested it17:58
cjwatsonEr, --profiles=stage117:58
naccyeah, it should be <!nocheck !stage1>17:58
* nacc spent some time just now thinking in english in CNF ... or trying to17:58
cjwatsonIt would be less surprising to me to find that the example was wrong, than to find that the logic was dramatically different for negated restrictions17:58
slangasekyeah. my understanding is that conditions within a <> are ANDed, and separate <> blocks are ORed17:59
slangasekglad to hear that the code agrees with our intuition ;)17:59
cjwatsonnacc: oh, and I've just realised that I was in fact agreeing with you above where I thought I was disagreeing with you.  As you were ...17:59
nacccjwatson: :) np17:59
nacci'll send an update to the wiki and see if debian picks it up18:00
tewardcjwatson: i have a very evil question - I have an RPi2, with Ubuntu on it; would it be possible to create an armhf build environment *on* that armhf infrastructure, so crosscompiling isn't necessary?  And if so, is that as simple as doing --arch=armhf instead of --target=armhf since it's native there?18:08
slangasekteward: you don't even need to specify --arch in that case18:10
tewardslangasek: nice.  force of habit to do that though :)18:10
tewardi guess i'll start poking my rpi then to turn it into an (albeit really slow) builder18:10
slangasekteward: just to be clear: mk-sbuild --target=armhf on amd64 gives you a cross-builder, which works for many things but not all, and is really fast.  mk-sbuild --arch=armhf gives you a cross-architecture, native builder (running everything under qemu), which is slower than a cross-builder and probably works for more things but still has various known failures (including anything using Qt).  And a na18:13
slangasektive chroot on RPi2 is probably about as fast as the ...18:13
slangasek... cross-chroot option, maybe faster, and should be able to build everything.18:13
tewardslangasek: most of the stuff being sent to the builder is headless, so meh18:14
tewardbut yeah i'm likely going to pursue using the RPi as a builder.  Though, i have to make sure it's on a supported distro first, I think the RPi2 I have had MATE 15.04 on it, which EOL'd.18:14
sarnoldhey teward; my pandaboard destroyed an sd card under what felt like a light write workload.. setting up a cross-compile environment may give faster builds and be more robust..18:16
tewardsarnold: well it's a good thing i have a lot of SD cards, but we're talking one build a month on this thing ;)18:17
tewardi'm building the cross-compile env anyways18:17
sarnoldah okay :)18:17
tewardsarnold: most of my stuff goes to the PPAs for arm building, after amd64/i386 builds fine, anyways, but in this case the PPAs arent a valid option (internal private builds that incorporate private repo sources that only exist here and can't get included in the PPAs)18:19
sarnoldteward: interesting, I hadn't heard that before.. I don't step much outside the simple and easy center :)18:21
tewardi've got a couple RPis here that rely on certain 'all' packages to be available from an internal private repo here ;)18:21
tewardbecause it's not publicly released yet18:21
tewardblah slow internet is slow18:24
cjwatsoner, yes, I conflated --target=armhf and --arch=armhf earlier18:37
dobeysarnold: might be better to use an actual ssd/hdd if using the device as a builder, than relying on an SD card :)18:42
sarnolddobey: yeah; of course that would go through a usb-sata interface.. also not ideal ;)18:43
sarnoldI was just using mine for irssi and occasional rtorrent use; now it's only irssi. heh.18:44
dobeysarnold: well, if you have usb 3, it's not too bad18:46
sarnolddobey: I must admit I never looked but ijust sort of assumed the pandaboard didn't have usb3 :)18:47
dobeysarnold: well, yeah, pandaboard probably doesn't have much. but rpi2 has usb3 doesn't it? :)18:48
sarnolddobey: ooh? nice. yeah. that'd be the way to go :)18:48
dobeywell not sure now. their web page doesn't have any actual specs18:49
tewarddobey: last I checked it's USB218:49
dobeyit just says "4 USB ports"18:49
tewardUSB3 would be blue I think?18:49
dobeyteward: it doesn't have to be blue, but they commonly are18:49
tewardi'll check once I replace the RPi2 image I have with the latest Ubuntu MATE one ('cause I like the GUI there, and need the GUI to make wifi config easier heh)18:50
dobeyengadget says 2.0 though18:50
tewardpretty sure it's 2.018:50
hallynok, so if package x (let's say numa :) has dh_makeshlibs -V, and package y (oh, let's say qemu) build-deps on that;  the implication is what?  Just that any *build* qemu from (say) y serious can't be installed on xenial without rebulding?18:51
hallyn(which with ppas and backports isn't *really* an issue for us?)18:51
hallynor is it more?18:51
dobeyusb 2/sata bridge might still be faster than the sd card. not sure18:52
tmartinsHey guys, any chance to have the latest Enlightenment LibEFL on Xenial ?18:53
dobeytmartins: is it in debian already?18:55
dobeytmartins: seems the version in xenial is just a sync from debian; would probably be bets to get it into debian first. and hopefully it doesn't break e1718:57
tmartinsBut, for example, DPDK is only available on Ubuntu...   =P18:57
hallynsarnold: ^ do you know offhand?  (about dh_makeshlibs -V implications)18:59
sarnoldhallyn: sorry, no, I rarely make changes that large to packaging18:59
hallynok thx19:00
hallynstgraber: ?19:00
dobeyhallyn: in your example, it means if numa is newer in y than in x (assuming all the other libs are bin compat), that qemu built against the version in y, will indeed need rebuilt against the x numa, to install on x19:06
dobeyor both newer versions will need to be installed, to satisfy the deps19:07
dobeyat least, that is my understanding from what man dh_makeshlibs says19:07
dokobarry, why is the setuptools wheel not necessary anymore?19:08
dobeyi don't think that's an issue though, because we tend to maintain the "things must be rebuilt anyway" mindset19:08
hallyndobey: right;  it was an issue in debian bc they couldn't put the qemu packages into wheezy after a numa upgrade, but we don't do that.19:09
hallynso yeah i think we can just do it.19:09
dobeyright, we always rebuild when sticking things in -updates or -backports, and generally try to keep version numbering which won't break the upgrade path19:12
hallynyay, so i'll enable :)  thx19:14
dokoginggs, please could you have a look at http://people.canonical.com/~ubuntu-archive/nbs.html, removing the libdcmtk2-dev references, or verifying that these are obsolete (e.g. there are alternatives or provides)19:14
ricotzdoko, hi, could you pick up this aptitude merge -- https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/6059699/+listing-archive-extra19:14
ginggsdoko, i'm looking, but i'm not sure what i'm looking at :)19:16
dokoginggs, libdcmtk2-dev is a package which only exists as a binary package, without a source being built from. the other packages reference this package, so these references must be removed before we can remove the libdcmtk2-dev binary19:21
barrydoko: because we create the wheels at pip build time using the dirtbike rewheeling tool19:24
dokothat's dirty19:24
barrynot really19:26
ginggsdoko, so odin, for example has build-depends on libdcmtk-dev | libdcmtk2-dev | libdcmtk1-dev19:26
dokosure, you can ignore this19:28
ginggsthe latest upload of dcmtk has libdcmtk-dev19:28
dokoricotz, please could you ask a lp question to enable this ppa for s390x and ppc64el, and show the results for all these archs?19:29
ginggsodil has libdcmtk-dev | libdcmtk2-dev19:30
ginggsdcmtkkpp has libdcmtk-dev | libdcmtk2-dev19:32
=== catbus1 is now known as catbus1-afk
ginggsdoko, ok libinsighttoolkit4-dev still depends on libdcmtk2-dev19:35
ginggsLocutusOfBorg: do you feel like doing another merge of insighttoolkit4? 4.9.0-1 was uploaded19:36
hallynhey - so bug 1541736 requests bacula in x demotion to universe;  i could sync, but is a manual step needed for demotion, or will that happen automatically due to build-deps on universe pkgs?  (I assume it won't, and rather it will hang in -proposed)19:41
ubottubug 1541736 in bacula (Ubuntu) "Sync bacula 7.0.5+dfsg-4 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/154173619:41
ginggsLocutusOfBorg:  except 4.9.0-1 in debian still depends on libdcmtk2-dev19:41
hallynnacc: I trust you've built+tested bacula from debian and found no problems in x?19:41
nacchallyn: right, i found no issues and our delta was all fixed upstream or due to being in main19:42
hallynnacc: cool - then we just need an archive admin to edumacate us on how to demote to universe19:42
ginggsLocutusOfBorg, doko: but libdcmtk-dev provides libdcmtk2-dev https://anonscm.debian.org/cgit/debian-med/dcmtk.git/tree/debian/control#n73 so i think we a re all good19:45
ricotzdoko, can do, ppc64el is possible already19:45
sarnoldhallyn: I think I've heard before that they make a final pass through the bugs to look for "demote to universe" a week or so before release19:47
sarnoldhallyn: probably assign or subscribe to the ubuntu archive admin team to make sure it's on their list when they look :)19:48
hallynsarnold: does that mean we shoul djust do the sync and leave the result in proposed, or just leave the bug open wiating for them?19:48
hallynnacc: ^19:48
sarnoldhallyn: I like the idea of the sync and -proposed, and also leaving a bug open ;)19:49
hallynsounds good.  nacc: pls assign the bug to ubuntu archive team, i'll initiate the sync19:49
nacchallyn: will do19:50
dokoginggs, ta, thanks for the analysis. removing libdcmtk2-dev19:57
ginggsdoko: yw19:59
dokomwhudson, please could you have a look at http://people.canonical.com/~ubuntu-archive/nbs.html ? packages referencing golang-testify-dev, not built anymore20:03
infinityhallyn: I don't understand why that bug requests demotion to universe.20:28
infinityhallyn: There's literally no explanation, and it's seeded in supported for all flavours (including ubuntu).20:29
infinitynacc: ^20:30
jtaylorinfinity: is glibc update stillon the schedule?20:32
infinityjtaylor: Yep.20:32
smoseri need some help20:36
smoseri have a system that is up.20:36
smoserssh running20:36
smoseranother system attempt ssh in.20:36
smoseranother system attempt ssh in.20:37
infinityPassword or key auth?  If the latter, using insecure keys which are disabled by default in Xenial?20:37
smoserssh client looks like this:20:37
smoser http://paste.ubuntu.com/15010918/20:37
mwhudsondoko: i don't know anything at all about any of those packages20:43
mwhudsonbut i can try and figure stuff out i guess :-)20:43
mwhudsoninfinity: how's the head today?20:44
dokomwenning, that would be appreciated20:44
dokomwhudson, ^^^20:45
sarnoldsmoser: similar-looking bug report https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/153479220:49
ubottuLaunchpad bug 1534792 in openssh (Ubuntu) "unable to connect" [Undecided,Incomplete]20:49
infinitymwhudson: Wobbling about atop my neck, more or less as it's meant to.20:49
mwhudsoninfinity: shall we talk go toolchains vs lts releases then?20:50
smosersarnold, even telnet 22 i get just dropped immediately20:52
smoserConnection closed by foreign host20:52
smoseri *can* ssh from that system to itself either by localhost or by ip address20:52
mdeslaurxnox: wow, 35%!! /me hugs xnox20:53
naccinfinity: i apologize, still learning and was told to simply put it in the bug report. Will work on the seed changes20:53
sarnoldsmoser: actually that's pretty good -- that's a -way- simpler problem to debug :)20:53
smoseroh . yeah. the telnet.20:54
naccsmoser: how do i go about updating the seed to not refer to bacula?20:54
infinitymwhudson: Will you be around in an hour?  I need to get some paperwork out of the way today before the east coast of the US takes off.20:55
mwhudsoninfinity: yes20:55
infinitymwhudson: Shiny.20:55
rcjslangasek, xnox: I have an upstart/mountall question.  Trying to fix up a container environment that has replaced mountall and isn't getting timing for upstart emits correct (cloud-init jobs start out of order as a result).20:56
smosernacc, you can make a change to http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.xenial/files20:59
smoserand submit a merge proposal20:59
rcjthey have http://paste.ubuntu.com/15011062/ for mountall.override.  Talking with smoser I learned that 'filesystem' shouldn't be emitted until after '/' is rw and that doesn't occur until after all jobs depending on '/' (when RO) complete.  So without 'mountall(1M)' in the picture, what is the right way to emit signals to replace it?21:00
mwhudsonxnox: https://bugs.launchpad.net/ubuntu/+source/golang-github-aws-aws-sdk-go/+bug/1534346 links to your ppa but you've deleted all the packages (and so build logs)?21:01
ubottuLaunchpad bug 1534346 in unity-scope-snappy (Ubuntu) "FTBFS with golang-go 1.6 beta2" [Undecided,New]21:01
mwhudsondoko: oh, golang-testify-dev is now golang-github-stretchr-testify-dev21:02
mwhudsonis there a similar nbs page for debian?21:02
naccsmoser: thanks21:02
mwhudsonbecause i'd be really surprised if any of these packages had a delta21:03
hallyninfinity: the demotion is just so that we can drop all delta with debian;  i.e. recommend mt-st - really that's the only one i see offhand21:03
infinityhallyn: Is that worth dropping support?21:04
mwhudsoner but golang-github-stretchr-testify-dev Provides: golang-testify-dev21:05
mwhudsondoko: i think golang-testify-dev can in fact be removed safely21:07
mwhudsondoko: because the new golang-github-stretchr-testify-dev package has "Provides: golang-testify-dev"21:08
mwhudsondoko: is that the sort of conclusion you wanted me to reach? :-)21:08
dokomwhudson, please file an isss21:09
dokomwhudson, please file an issue even21:09
mwhudsondoko: on https://launchpad.net/ubuntu/+source/golang-testify ?21:09
dokoyes, please21:09
hallyninfinity: as in security fixes i guess?21:10
hallyn(imo yes, but i neither use nor know anyone depending on bacula)21:10
* hallyn does wonder why mt-st is not in main21:11
mwhudsondoko: https://bugs.launchpad.net/ubuntu/+source/golang-testify/+bug/1544291 (i subscribed ~ubuntu-archive, anything else needed?)21:12
ubottuLaunchpad bug 1544291 in golang-testify (Ubuntu) "please remove golang-testify-dev package" [Undecided,New]21:12
hallynonly bugs against htat baby are requests for syncing21:12
hallynnacc: was there anything other than mt-st that was cause for demoting bacula?21:12
hallynkirkland: what is your view on bacula support for server?  do we care whether it is in main?21:13
nacchallyn: we don't want to support it anymore, afaict, kirkland has already acked demoting it21:17
hallynkirkland: could add a comment to https://bugs.launchpad.net/ubuntu/+source/bacula/+bug/1541736 acking demotion?21:19
ubottuLaunchpad bug 1541736 in bacula (Ubuntu) "Sync bacula 7.0.5+dfsg-4 (main) from Debian unstable (main)" [Wishlist,Fix released]21:19
smoserok. for my ssh bug above.21:41
smoserif i am pinging the remote host or have ssh'd to it, then i can initiate an ssh connection fine.21:42
infinitysmoser: Broken stateful firewall?21:43
smoseri'm guessing its got something to do with21:44
smoser From icmp_seq=11 Redirect Host(New nexthop:
smoserwhat i have is a flat network
smoserand on that is a maas system. when it installs nodes it tells them that it is their gateway ( and that they have a /26 network under
smoseri've another host with almost idential networking ( instead of but running trusty.  i've also run other ubuntu with this fine.21:47
=== DalekSec_ is now known as DalekSec
=== funkyHat_ is now known as funkyHat
=== balkamos_ is now known as balkamos
rharperworking on the strongswan merge for xenial, adding virtual packages to handle the dist-upgrade, when I debuild -S the source, lintian spews many of these: https://lintian.debian.org/tags/not-binnmuable-any-depends-all.html  ...  I found this discussion: http://comments.gmane.org/gmane.linux.debian.devel.mentors/72433 and not sure what, if anything I should do in my debian/control file to address the warning/errors21:48
smoserrunning sshd in the foreground with :sudo /usr/sbin/sshd -D -d -d -d -e21:50
=== mariogrip_ is now known as mariogrip
mwhudsonrharper: i thiiiiiiiiiink but hardly know for sure that those warnings don't really apply for ubuntu21:50
smoserbasically doesn't see it getting a connection21:50
smoserbut tcpdum pdoes show some data.21:50
smosertcpdump port 22 -vv shows:21:50
smoser http://paste.ubuntu.com/15011373/21:50
rharpermwhudson: yeah, I tried the suggestion (using (= ${source:Version}) instead but that didn't seem to help; but I _really_ don't understand what's going on w.r.t the warning21:51
rharperthe package builds fine in my sbuild and works when installed etc;  but there are enough of the warnings (due to all of the virtual packages) that it fills the screen and demands some attention21:52
mwhudsonrharper: i think the warning is about something that will go back in a situation that does not occur in debian21:52
mwhudson*does not occur in ubuntu*21:52
mwhudsonrharper: https://wiki.debian.org/binNMU21:53
mwhudsonrharper: we don't have binary uploads at all21:53
rharperbtw, google says no when I tried to search with "${source:Version}"21:53
rharperwhich I thought was funny21:53
rharpertrying to google to find out why google does't like source:Version21:53
rharperwas also fun and fruitless21:54
rharpersearching for ource:Version, got google to auto search for source:Version for me21:54
rharperdid you mean this? (yes, I did, but you wouldn't let me search for that!)21:54
rharpermwhudson: ok, yes, I'll ignore those and go back to wondering why ppa build of the successful sbuild fails21:55
cheryljIs there someone around who could help me with an ssh issue on xenial?  I'm seeing that when I run ssh  <host> <command> I get the correct output, but if I run ssh -t <host> <command>, I get nothing21:59
cheryljSee:  http://paste.ubuntu.com/15011347/21:59
smosercherylj, that is interesting.22:00
smoseras i was just above typing ssh issues too22:01
mwhudsoncherylj: fwiw i can't reproduce that sshing into a xenial lxd22:02
mwhudsonbut i don't really know what that indicates22:02
smoseralthough mine fail with connection closed even on telnet 2222:02
cheryljmwhudson: yeah I provisioned a new xenial machine and couldn't recreate.22:02
cheryljmwhudson: this is a machine that was provisioned through juju22:03
mwhudsoncherylj: oh awesome22:03
rharperobviously it was *jujus* fault =P22:03
cheryljI have no idea what to look at that could cause the difference22:03
smosercherylj, and mine was provisioned with maas22:03
mwhudsoni guess you could diff /etc/ssh/sshd_config on the machines22:03
=== stgraber_ is now known as stgraber
mwhudsonand check the package versions are the same22:03
smoseradmittedly i have kind of funky networking. but funky  networking that works fine with trusty.22:04
cheryljmwhudson: the package versions are the same22:04
mwhudsoncherylj: can you log in ok with ssh?\22:04
rharperwouldn't ssh client complain somewhere about failed psuedo-tty allocation ?22:04
cheryljmwhudson: yes22:04
rharper-t requests one22:04
mwhudsoncherylj: ssh -vvv ?22:04
smoseryeah. add some -vvv22:04
cheryljI did that, let me paste the diff22:05
mwhudsonand look for logs on the server?22:05
smoseror run the daemon in the foreground with '/usr/bin/sshd -D -d -d -d -e'22:05
rharperdifferent port though22:05
rharperdon't mess with the working one =)22:05
smoseri'm stil kind of hoping cherylj has my problem too. and just doenst know it.22:06
smoserdoes telnet 2222:06
slangasekrcj: replaced mountall> aigh it burns22:06
smosergive you a ssh prompt ? or just drop it.22:06
cheryljmwhudson: the /etc/ssh/sshd_config is the same for the two machines22:08
mwhudsoncherylj: i guess that's not very surprising but oh well22:09
mwhudsoncherylj: -vvv?22:10
cheryljmwhudson: success case:  http://paste.ubuntu.com/15011479/22:11
cheryljmwhudson: failed case:  http://paste.ubuntu.com/15011482/22:11
mwhudsoncherylj: huh it almost looks like a race between output and exit status?22:14
cheryljmwhudson:  yeah, I was wondering about that22:14
mwhudsoncherylj: have you tried silly things like tacking "; sleep 1" on the end, or running some command that has side effects on the system so you can see if it's being executed at all?22:14
cheryljmwhudson: ha!22:17
cherylj$ ssh -t ubuntu@ "lsb_release -c; sleep 5"22:17
cheryljConnection to closed.22:17
rharperhrm, why might i386 build fail when x86_64 succeeds  (failure in linking)22:17
mwhudsoncherylj: i'm fairly sure that's supposed to be impossible :(22:18
cheryljmwhudson: sounds like it's time to open a bug?22:18
mwhudsonyeah, i guess22:18
cheryljbut I have no idea why it's different on this machine vs another22:19
mwhudsonis it reproducible at all>?22:19
cheryljmwhudson: yes, we hit it in CI consistently22:19
mwhudsoncherylj: oh, it's simple then: CI is infested with malicious demons22:19
cheryljof course, why didn't I think of that!22:19
rharpermwhudson: hehe22:20
rcjslangasek, it's a container environment that runs linux in a opensolaris (joyent smartos) zone22:20
mwhudsoncherylj: still at least a reproduction case makes actually fixing the bug feasible22:20
mwhudsoncherylj: when did the bug start?22:21
cheryljmwhudson: I need to look at the CI logs to see when we started hitting it22:22
cheryljgive me a few22:22
mwhudsonlast openssh upload was about three weeks ago22:22
=== mnepton is now known as mneptok
=== stokachu_ is now known as stokachu
rcjslangasek, I have asked if they can stop diverting around the real mountall but that may not be possible in the current environment22:23
rcjI've tried rewriting their mountall override but haven't found something that works (as I'm taking shots in the dark) so mostly I end up with a container that doesn't boot (deadlock?) and I have to start again.  Thus the question to someone that knows what's going on with upstart/mountall and could say if it's even possible to do this in an upstart job without mountall22:26
naccslangasek: ok, i'm on my last 3 packages122:29
naccs/1/!/ ;)22:29
naccslangasek: need some help/advice on one of them, if you have a second, though22:29
slangaseknacc: hit me22:29
slangasekrcj: so I believe it is possible and the devil is in the details22:30
=== pitti` is now known as pitti
naccslangasek: ok, so php-doctrine-cache-bundle BDs on php-symfony-doctrine-bridge ... php-symfony-doctrine-bridge BDs on php-doctrine-bundle which BDs on php-doctrine-cache-bundle. In my PPA I made an alternative autoload.php.tpl (which i can do with the staged build), but basically i need to have the stage1 php-doctrine-cache-bundle binary not depend on php-symfony-doctrine-bridge22:33
=== pitti is now known as Guest3706
naccslangasek: oh ... i wonder if i could have two version of the binary package in the ocntrol file, toggled by Build-Profiles?22:34
slangaseknacc: profile qualifiers can be applied to hard-coded dependencies listed in debian/control, not just to build-dependencies22:35
naccslangasek: oh! that's not mentioned on the wiki page :)22:35
nacceasy enough then22:35
slangaseknacc: I don't know that you can toggle the whole stanza, but it should work for the evaluation of the binary control files22:36
naccok, i'll test that now22:36
slangaseknacc: obviously, test this to make sure I'm not blowing smoke :)22:36
naccslangasek: :)22:37
slangaseknacc: if that fails, option 2 is to not hard-code this dependency in debian/control at all, but move it into a substvar that's generated from debian/rules in a profile-dependent manner22:39
rcjslangasek, I'll pursue the details through a bug rather than IRC.  Thanks.22:45
=== Guest3706 is now known as pitti
naccslangasek: sigh, it *does* work, except this package is also using dh_phpcomposer and composer.json specifies the same dependency :/ would it be appropriate for me to not use the var in stage1 and list out the other deps manually in the control file?22:55
slangaseknacc: for stage1, hack it any way you like that gets you the proper result ;)22:56
naccslangasek: heh22:56
slangaseknacc: and if the Debian maintainer has an opinion about the ugliness of the hack, you can negotiate with them later.  But I absolutely don't care :-)22:56
mwhudsoninfinity: how's the paperwork?23:01
mwhudsoninfinity: i'm going to disappear in 2.5 hours or so and i need to do some afk stuff before then23:19
naccslangasek: ok, I think I have my list of bootstraps filed as bugs and sequenced. WOuld it be worth us interlocking on that list now, or do you want me to only ping you or another admin once i have the full list written out?23:22
naccfull list = 400+ packages, that is23:22
infinitymwhudson: I'm aroundish now.23:25
mwhudsoninfinity: \o/23:25
mwhudsoninfinity: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1536882 https://wiki.ubuntu.com/MichaelHudsonDoyle/Go15InTrusty23:26
ubottuLaunchpad bug 1536882 in golang (Ubuntu) "upload golang1.5 package for trusty" [Undecided,New]23:26
infinitymwhudson: Right.  Want to mumble or something?23:27
mwhudsoninfinity: sure, although i don't think i actually have mumble installed23:27
infinitymwhudson: Or a hangout...23:27
mwhudsonwould be easier23:27
infinitymwhudson: Not picky.23:28
mwhudsonhangout then23:28
* mwhudson can't remember how to start a hangout23:29
mwhudsonoh there23:29
mwhudsoninfinity: i've invited the canonical you, i think23:29

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