| roaksoax | pitti: so I looked further into this, and have found the following: | 03:27 |
|---|---|---|
| roaksoax | pitti: http://pastebin.ubuntu.com/15006344/ | 03:27 |
| roaksoax | pitti: 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 |
| roaksoax | pitti: correct myself. In maas-proxy postinst we disable squid3, and I wonder if that's affecting maas-proxy being enabled? | 03:43 |
| roaksoax | pitti: ok, I think I may have found the issue: http://paste.ubuntu.com/15006739/ | 04:30 |
| roaksoax | pitti: i had to change ordering to get maas-proxy to work, however, maas-dhcpd and maas-dhcpd6 still show: | 04:31 |
| roaksoax | maas-dhcpd.service is a disabled or a static unit, not starting it. | 04:31 |
| roaksoax | maas-dhcpd6.service is a disabled or a static unit, not starting it. | 04:31 |
| roaksoax | pitti: and my guess is because there's 2 for service units for the same binary package. | 04:31 |
| roaksoax | pitti: 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 |
| pitti | Good morning | 06:39 |
| pitti | roaksoax: binaries can have as many services as they want; and the order of calling dh_* should beo completly irrelevant | 06:40 |
| === shlomizadok__ is now known as shlomizadok | ||
| jrwren | are there any plans to update packaging guide to use git? http://packaging.ubuntu.com/html/packaging-new-software.html | 07:40 |
| jrwren | man dh_make | 07:40 |
| dholbach | good morning | 08:09 |
| doko | did something recently change with alsa headers/libs? | 08:10 |
| doko | https://launchpadlibrarian.net/237700070/buildlog_ubuntu-xenial-amd64.simon_0.4.1-0ubuntu7_BUILDING.txt.gz | 08:10 |
| xnox | pitti, ubiquity uses http://start.ubuntu.com/connectivity-check | 08:11 |
| xnox | and checks the checksum of that highly available file =) | 08:11 |
| xnox | pitti, very similar to microsoft's connectivity check. apart from our text is longer =) and uses lorem ipsum | 08:12 |
| pitti | xnox: right, but we don't seem to do that at all under unity | 08:16 |
| xnox | pitti, yeah, i know. nor phone i don't think. | 08:17 |
| xnox | pitti, conman will solve everything. | 08:17 |
| xnox | =) | 08:17 |
| * xnox giggles | 08:17 | |
| caribou | xnox: did anything on s390x enablement for makedumpfile ? | 08:52 |
| caribou | xnox: I see that you marked the lp bug fix released | 08:52 |
| xnox | commited | 08:52 |
| xnox | caribou, failing to parse first question | 08:52 |
| caribou | xnox: a bit fast, I was about to prepare the upload to debian, | 08:53 |
| xnox | =) | 08:53 |
| xnox | caribou, i am happy to sync things when they are built in debian. but that like takes close to 24h =) | 08:54 |
| xnox | and today is my last working day for the week. | 08:54 |
| caribou | xnox: that's fine, I'll do the debian bits & resync | 08:54 |
| xnox | caribou, i'm sure there will be more work needed. cause e.g. bootloader on s390x doesn't prepare any devices for dumps =/ | 08:55 |
| caribou | or maybe wait a bit to see if it builds correctly | 08:55 |
| xnox | does build https://launchpad.net/ubuntu/+source/makedumpfile/1:1.5.9-4ubuntu1/+build/8991792 | 08:55 |
| Mirv | can 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 |
| Mirv | I was thinking maybe the python-numpy that's breaking other tests in proposed, but then again the silo autopkgtests shouldn't be using proposed anymore | 08:57 |
| doko | hmm, some -dev package dropped a dependency on libasound-dev | 08:58 |
| Mirv | locally I don't have a problem installing the test dependencies on either xenial or xenial-proposed | 08:58 |
| LocutusOfBorg | yofel, hi! I actually uploaded jreen in Debian a while ago, and got accepted yesterday | 08:59 |
| LocutusOfBorg | I looked at the ubuntu package, and if agree I would like to fakesync it | 08:59 |
| LocutusOfBorg | but I would like to ask you to give a quick look if possible | 08:59 |
| LocutusOfBorg | the debian package is more complete, e.g. providing qt4 and qt5 packages | 09:00 |
| Mirv | ah, not, if I've up-to-date xenial | 09:00 |
| LocutusOfBorg | multiarch support | 09:00 |
| Mirv | python3.4 is being removed | 09:00 |
| * Mirv reads backlog in search of python3.4 breakage in xenial non-proposed | 09:00 | |
| xnox | Mirv, 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 |
| xnox | Mirv, and there is new enough python3.4 built in proposed, which i'm waiting to migrate over (autopkgtests are running) | 09:01 |
| xnox | it's a subtle "Breaks: python3.4 (<< version in xenial-release" in findutils. | 09:02 |
| Mirv | xnox: ah... so I need to wait for that since the silos don't use proposed. thank you. | 09:02 |
| xnox | Mirv, yes. and cloud-images are broken, and doko has been fixing this with yesterdays uploads. | 09:03 |
| xnox | just need to migrate now. | 09:03 |
| pitti | meh, armhf test machines are still Qt'ed, after they've gotten perl'ed all yesterday and night | 09:05 |
| xnox | Mirv, also it's a bug if silos do not use proposed. | 09:05 |
| xnox | slangasek, ^ | 09:05 |
| pitti | they shouldn't use -proposed for running tests | 09:06 |
| pitti | (for builds, yes) | 09:06 |
| xnox | Mirv, do you see bugs in tests or builds? | 09:06 |
| xnox | ah looking up i see it's tests. | 09:06 |
| Mirv | xnox: tests, and yes that was just implemented | 09:06 |
| xnox | Mirv, yeah, just wait =) | 09:06 |
| Mirv | good things come to those who wait | 09:06 |
| doko | Mirv, fix a ftbfs or two while waiting ;p | 09:08 |
| Mirv | everyone should have one http://www.einval.com/~steve/DebianT/guinness-debian-open.gif th-shirt | 09:08 |
| Mirv | I'll work on this breaking test script... | 09:10 |
| LocutusOfBorg | Logan, ^^^^ (jreen pacage) | 09:13 |
| doko | coreycb, pandas still fails its tests | 09:31 |
| seb128 | xnox, 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 |
| xnox | seb128, like the night before feature freeze? =) | 09:34 |
| seb128 | xnox, if you like it this way, why not ;-) | 09:35 |
| damascene | Hi, how much time Midori browser maintainers have before they can not switch to WebKit2 because of feature freeze? | 09:45 |
| seb128 | damascene, the feature freeze is on feb 18th | 09:49 |
| seb128 | they can still ask for an exception after that | 09:49 |
| damascene | ok thank you seb128, I'll tell them to hurry up before feb 18th | 09:51 |
| pitti | apw, 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 |
| pitti | apw: so you can un-mark this as known failure | 10:31 |
| bdrung_work | cjwatson, i saw your ITP for git-build-recipe. cool! | 10:48 |
| _hc | hey 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.php | 10:52 |
| dholbach | _hc, "Not found"? | 10:56 |
| sladen | presumably truncated by IRC at just the wrong point | 10:56 |
| _hc | https://qa.debian.org/developer.php?login=android-tools-devel%40lists.alioth.debian.org | 11:00 |
| _hc | dholbach: ^^ | 11:00 |
| cjwatson | I'm sure I've seen several of those getting imported | 11:01 |
| cjwatson | bdrung_work: yw :) | 11:01 |
| * cjwatson looks | 11:01 | |
| _hc | is debian qa just out of date? | 11:01 |
| bdrung_work | cjwatson, is there an ETA when in can be used on launchpad? | 11:01 |
| _hc | all of the android-platform-* source packages should be at version 6.0.0 now | 11:01 |
| mitya57 | _hc, android-platform-external-libunwind FTBFS on arm64 and thus stuck in xenial-proposed | 11:02 |
| cjwatson | bdrung_work: Two weeks ago. | 11:02 |
| cjwatson | https://blog.launchpad.net/cool-new-stuff/beta-test-git-recipes | 11:02 |
| bdrung_work | cool | 11:02 |
| dholbach | https://launchpadlibrarian.net/236936154/buildlog_ubuntu-xenial-arm64.android-platform-external-libunwind_6.0.0+r26-3_BUILDING.txt.gz | 11:03 |
| mitya57 | _hc, android-platform-system-core needs old binaries removed because it dropped some archs | 11:04 |
| mitya57 | And other packages depend on these two | 11:04 |
| _hc | thanks for the info | 11:04 |
| cjwatson | yeah, looks like some archive admin unwinding to be done here, I'll look | 11:04 |
| _hc | looking at the FTBFS, its an odd one. is 16.04 using gcc 6? | 11:04 |
| cjwatson | the arm64 build of android-platform-external-libunwind doesn't block anything in itself | 11:04 |
| mitya57 | No, gcc 5 | 11:04 |
| cjwatson | unless something build-depends on that | 11:04 |
| _hc | yeah, some stuff bds on that | 11:05 |
| cjwatson | let me clarify, unless something build-depends on that and would be a regression if not built on arm64 | 11:05 |
| _hc | also, 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 too | 11:05 |
| bdrung_work | cjwatson, is nest-part implemented? | 11:05 |
| cjwatson | bdrung_work: not yet, that's the one major missing piece of the format | 11:06 |
| cjwatson | on my list | 11:06 |
| cjwatson | _hc: details? | 11:06 |
| bdrung_work | cjwatson, rough ETA for that? | 11:06 |
| cjwatson | _hc: we can inject build-dependencies if we need to do a bootstrap step | 11:06 |
| bdrung_work | i use nest-part for audacity and vlc | 11:06 |
| bdrung_work | i am curious to switch to git for vlc | 11:07 |
| cjwatson | bdrung_work: don't have an ETA yet, need to sit and rewrite the code | 11:07 |
| _hc | we 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 package | 11:07 |
| cjwatson | William brought up reasonable objections to my initial implementation attempt | 11:07 |
| bdrung_work | cjwatson, can you ping me once it is there? | 11:07 |
| cjwatson | bdrung_work: can you just watch blog.launchpad.net instead? I'm not going to remember to ping individuals :) | 11:07 |
| cjwatson | bdrung_work: or subscribe to the bug | 11:07 |
| cjwatson | bdrung_work: (https://bugs.launchpad.net/git-build-recipe/+bug/1537579) | 11:08 |
| ubottu | Launchpad bug 1537579 in git-build-recipe "nest-part not implemented" [High,In progress] | 11:08 |
| cjwatson | _hc: which packages? | 11:08 |
| _hc | seamlik: which packages needed the staged uploads? | 11:08 |
| bdrung_work | cjwatson, 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 |
| seamlik | android-platform-system-core and android-platform-build | 11:09 |
| _hc | cjwatson: ^^^ seamlik actually did most of the work :) | 11:09 |
| _hc | cjwatson: 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 care | 11:10 |
| cjwatson | whatever you have | 11:10 |
| _hc | they 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 |
| _hc | that is correct | 11:12 |
| _hc | Google only supports building the SDK on i386 and amd64 | 11:12 |
| _hc | it could be ported without a lot of effort, but we want to start with i386 and amd64 | 11:13 |
| _hc | and get the whole thing in their first | 11: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 |
| _hc | yeah | 11:13 |
| seamlik | All of them are x86 only now | 11:14 |
| cjwatson | I don't think any staging is needed; both android-platform-system-core and android-platform-build have built | 11:14 |
| _hc | cool, that simplifies things :) | 11:15 |
| seamlik | That easy? | 11:15 |
| cjwatson | except for android-platform-build/arm64 | 11:16 |
| _hc | seamlik: 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.gz | 11:16 |
| cjwatson | because it b-ds on binaries from android-platform-system-core/arm64 that you just told me you were intentionally no longer building | 11:16 |
| seamlik | Yeah I prepared an update | 11:16 |
| _hc | ah, ok, we uploaded things in a different order | 11:16 |
| _hc | so we'll fix that one | 11:17 |
| seamlik | Oh, I mean an update for android-platform-build | 11:17 |
| cjwatson | it's not a problem anyway, we don't really care if android-platform-build is harmlessly dep-waiting somewhere | 11:18 |
| _hc | oh, I see, that FTBFS for libunwind is on arm64, I keep seeing that as amd64 | 11:18 |
| seamlik | I need to separate out Build-Depends-Indep | 11:19 |
| seamlik | So that the B-D won't be uninstallable | 11:19 |
| xnox | Laney, i hear vila wants to get brand new bzr into xenial =) | 11:20 |
| Laney | we spoke | 11:21 |
| cjwatson | _hc: should all be cleared out in a bit | 11:21 |
| _hc | awesome, thank you | 11:21 |
| _hc | also, at some point, we'll need to coordinate with Ubuntu people on the android-tools source package, since that is maintained separately in Ubuntu | 11:22 |
| _hc | we've entirely replaced it in Debian | 11:22 |
| _hc | it is ok if that is unresolved in 16.04 | 11:22 |
| _hc | they just Conflict: | 11:22 |
| cjwatson | Yeah, I imagine you'll want to talk to the Ubuntu phone people, I don't know who's currently most relevant there | 11:23 |
| _hc | I emailed a list of people I found in the changelog | 11:23 |
| cjwatson | sil2100 would probably at least have an idea who to direct you to for that | 11:23 |
| seamlik | I bet there's a channel for Ubuntu Touch? | 11:25 |
| cjwatson | It has a surprising name | 11:25 |
| cjwatson | #ubuntu-touch | 11:25 |
| sil2100 | _hc: we do use android-tools for our flashing tools for ubuntu-touch from what I know | 11:27 |
| _hc | right | 11:27 |
| sil2100 | _hc: how did it get replaced in Debian? | 11:27 |
| _hc | the android-tools source package is pretty out of date | 11:27 |
| sil2100 | i.e. what's the new package name? | 11:28 |
| _hc | android-tools is a custom bunch of code grabbed from various git repos | 11:28 |
| _hc | we've been packaging it so that there is one source package per git repo | 11:28 |
| _hc | https://wiki.debian.org/AndroidTools | 11:28 |
| _hc | the binary packages are now adb, fastboot, etc instead of android-tools-adb, android-tools-fastboot | 11:28 |
| sil2100 | _hc: ok, good | 11:29 |
| sil2100 | Let 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 people | 11:29 |
| _hc | the one thing we will not be packaging is adbd, since that is meant to run on the Android device not on Debian/Ubuntu | 11:30 |
| _hc | but of course Ubuntu Touch is the "android device", so it needs adbd | 11:31 |
| _hc | but we welcome patches to our packages if they want to maintain adbd in this whole setup | 11:31 |
| seamlik | adbd is a "device" program which uses "device" version of libraries, which means a lot efforts to make | 11:33 |
| _hc | I gotta say, this room has always been quite responsive when I've brought issues here. good to get stuff done :) | 11:33 |
| seamlik | Is anyone making a tool to automate the translation of Android.mk to a usable Makefile? That really simplifies the maintenance | 11:34 |
| sil2100 | _hc: ok, noted :) Let me put that on my TODO list and try to take care of it in the nearest time-cycles | 11:34 |
| cjwatson | pitti: 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 anyway | 11:39 |
| xnox | cjwatson, 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/1.2.6.1-1build1 --trigger=haskell-uniplate/1.6.12-4build1 --trigger=haskell-resourcet/1.1.7-1build1 --trigger=haskell-case-insensitive/1.2.0.5-1build1 --trigger=haskell-http-types/0.9-2 --trigger=haskell-vector-algorithms/0.7.0.1-3build1 --trigger=haskell-src-exts/1.17.1-1build1 | 11:41 |
| pitti | --trigger=haskell-blaze-builder/0.4.0.1-3build1 --trigger=haskell-parsec/3.1.9-4build1 --trigger=haskell-text/1.2.2.0-1 --trigger=haskell-vector/0.11.0.0-1 --trigger=haskell-wai/3.0.5.0-1 --trigger haskell-hoogle/4.2.43-3 haskell-hoogle | 11:41 |
| pitti | cjwatson: ^ done | 11:42 |
| asac | hmm. 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 |
| pitti | yay, armhf queue is mostly over the hump | 11:42 |
| asac | or is this different? | 11:42 |
| xnox | asac, on xenial hosts it is. | 11:43 |
| pitti | asac: yes, first apt 1.0 it was broken, but that got fixed in apt pretty quickly | 11:43 |
| pitti | this is now just a warning | 11:43 |
| xnox | asac, either create _apt user on your host, or stop copying users from host inside the chroot. | 11:43 |
| xnox | asac, or upgrade host apt to xenials one. | 11:43 |
| xnox | right "trusty box". | 11:44 |
| cjwatson | xnox: documentation is in debconf-devel(7); pretty sure your example is preprocessed. what package is that in? | 11:46 |
| cjwatson | pitti: thanks | 11:46 |
| asac | hehe | 11:46 |
| cjwatson | xnox: e.g. base-installer has a preprocessing script for this | 11:47 |
| xnox | cjwatson, well choose-mirror uses that, and it has pre-processing. i was hoping to use same elsewhere. | 11:47 |
| xnox | cjwatson, and it's all in perl... whatever happened to using m4 to preprocess things +) | 11:47 |
| cjwatson | xnox: yeah you have to preprocess | 11:47 |
| cjwatson | xnox: I thought you were under 30 | 11:47 |
| xnox | cjwatson, i shall use groovy script then. | 11:48 |
| * xnox has weird m4 fetish i guess. | 11:48 | |
| asac | xnox: how do i best create the user so it will not hurt me when upgrading to xenial in april? | 11:53 |
| pitti | asac: really, it should not hurt | 11:53 |
| pitti | asac: if that actually breaks anything, it's a bug | 11:53 |
| asac | pitti: do you have the current passwd line for that user in xenial? | 11:53 |
| pitti | asac: yes | 11:53 |
| pitti | cjwatson: green again | 11:56 |
| pitti | libfile-slurper-perl/armhf too, that should be the last thing that blocks perl | 11:56 |
| cjwatson | pitti: great, thanks | 11:56 |
| pitti | emtpy armhf queue! | 11:57 |
| cjwatson | $ grep -A1 adduser /var/lib/dpkg/info/apt.postinst | 11:57 |
| cjwatson | adduser --force-badname --system --home /nonexistent \ | 11:57 |
| cjwatson | --no-create-home --quiet _apt || true | 11:57 |
| cjwatson | asac: ^- do that | 11:57 |
| xnox | asac, adduser --force-badname --system --home /nonexistent \ | 11:57 |
| xnox | --no-create-home --quiet _apt | 11:57 |
| xnox | pitti, right queue empty, but will still take hours to finish python3.4 tests =) | 11:58 |
| asac | cool... /me runs that command | 11:58 |
| pitti | xnox: yes, around 2.5 hours | 11:58 |
| asac | cjwatson: pitti: xnox: thanks a lot. works perfectly! | 11:59 |
| pitti | asac: OOI, what didn't work before? | 12:00 |
| pitti | this really ought not to be necessary | 12:00 |
| asac | pitti: i am on trusty box, created a fresh xenial chroot, and then running apt-get update in the schroot i got: | 12:00 |
| asac | W: No sandbox user '_apt' on the system, can not drop privileges ... | 12:00 |
| cjwatson | pitti: hm, did you do that on all arches? (hoogle) | 12:01 |
| asac | i think that makes sense... maybe schroot could get a patch in trusty to do the magic | 12:01 |
| xnox | ... which is a mostly harmless warning | 12:01 |
| cjwatson | not seeing it in either http://autopkgtest.ubuntu.com/packages/h/haskell-hoogle/xenial/s390x/ or http://autopkgtest.ubuntu.com/running.shtml | 12:01 |
| cjwatson | pitti: oh never mind, I apparently can't read | 12:01 |
| asac | oh ok it wasnt an error. i was confused because i couldnt find the package that was in universe :P | 12:01 |
| xnox | asac, did that warning prevent you from doing anything? or simply distaste of seeing it? | 12:01 |
| asac | anyway. warning gone is even better | 12:01 |
| asac | i thought it prevented me from using apt | 12:01 |
| cjwatson | it's running on armhf, but maybe not on s390x? | 12:01 |
| asac | but it didnt | 12:02 |
| xnox | cjwatson, it could have completed on s390x and then there is 5 minute sync gap where one can see it nowhere | 12:02 |
| pitti | cjwatson: I did, but it ran a bit later on armhf | 12:02 |
| cjwatson | yeah, that just occurred to me | 12:02 |
| xnox | not running, not in queue, and results are being "uploaded" =) | 12:02 |
| pitti | :q | 12:03 |
| pitti | cjwatson: looking on s390x | 12:03 |
| cjwatson | pitti: 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 now | 12:13 |
| ubottu | Launchpad bug 1517510 in Launchpad itself "Add xz-compressed archive indexes" [High,Fix committed] | 12:13 |
| pitti | cjwatson: ah, how can I help with that? | 12:13 |
| cjwatson | in "lp-shell production devel": | 12:14 |
| cjwatson | xenial = lp.load('/ubuntu/xenial') | 12:14 |
| cjwatson | xenial.index_compressors = ['gzip', 'bzip2', 'xz'] | 12:14 |
| cjwatson | xenial.lp_save() | 12:14 |
| pitti | >>> print(xenial.index_compressors) | 12:14 |
| pitti | [u'gzip', u'bzip2'] | 12:14 |
| pitti | current value looks expected | 12:14 |
| cjwatson | yeah, that's the default | 12:14 |
| pitti | cjwatson: ok, done | 12:15 |
| cjwatson | excellent, thanks | 12:15 |
| pitti | re-ran it with the print() and it's in | 12:15 |
| pitti | \o/ | 12:15 |
| cjwatson | I 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 debmirror | 12:15 |
| cjwatson | conveniently I adopted debmirror recently | 12:16 |
| pitti | cjwatson: can precise already read xz, or does that not even use bz2? | 12:16 |
| cjwatson | pitti: well, we shouldn't change existing stables here | 12:16 |
| cjwatson | pitti: I think it could read xz though | 12:16 |
| pitti | oh, *slaps forehead*, I did that on _xenial_ | 12:16 |
| cjwatson | we're a bit late in doing this | 12:16 |
| pitti | cjwatson: i. e. let it bake on xenial for a bit, and bit by bit enable it on older releases after testing? | 12:17 |
| pitti | I mean, merely building those in addition shouldn't break much, it's disabling bz2 which could | 12:17 |
| pitti | right? | 12:17 |
| cjwatson | I wasn't planning to change older series at all | 12:17 |
| pitti | ok | 12:17 |
| cjwatson | not least because for it to be useful we'd have to republish the release pocket | 12:17 |
| pitti | I thought you wanted to get rid of the bz2 compression in LP | 12:17 |
| cjwatson | which generally we try not to do | 12:17 |
| pitti | ah, good pointn | 12:17 |
| cjwatson | oh, no, that's negligible code, I don't care about that | 12:18 |
| cjwatson | I just don't want to keep three compression methods around for a series for very long - if nothing else it slows down publication | 12:18 |
| cjwatson | pitti: 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 farm | 12:20 |
| apw | pitti, lxc> ack though the adt-matrix hints work the same way, they are for specific combinations only | 12:21 |
| pitti | cjwatson: http://autopkgtest.ubuntu.com/packages/h/haskell-hoogle/ ← all green now, all arches caught up | 12:22 |
| pitti | apw: right; I meant, you should drop any hint for "lxc", we shouldn't have known regressions there any more | 12:23 |
| cjwatson | pitti: Great, thanks. Will keep an eye on excuses | 12:23 |
| apw | pitti, ack | 12:26 |
| pitti | cjwatson: added u-a-robot | 12:27 |
| cjwatson | pitti: thanks | 12:30 |
| coreycb | doko, saw that about pandas, I'll take a look | 12:34 |
| seb128 | Noskcaj, 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 |
| seb128 | bdmurray, do you have any news on getting the xenial retracers fixed? | 12:40 |
| === alecu-natholiday is now known as alecu | ||
| pitti | yay, perl landed | 13:00 |
| cjwatson | pitti: oh good | 13:02 |
| pitti | ~ 6000 tests, ugh :) | 13:02 |
| caribou | xnox: makedumpfile built for s390x on debian | 13:10 |
| doko | LocutusOfBorg, 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.gz | 13:10 |
| LocutusOfBorg | I didn't sync it :) | 13:11 |
| LocutusOfBorg | anyway, seems unrelated to my debian upload and I can't even retry the build | 13:12 |
| LocutusOfBorg | ENOPERMISSION | 13:12 |
| doko | meh | 13:13 |
| juliank | sarnold: What's going on with #1531923 - it's getting really annoying now | 13:14 |
| juliank | bug #1531923 | 13:14 |
| ubottu | bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,Confirmed] https://launchpad.net/bugs/1531923 | 13:14 |
| juliank | silly ubottu | 13:14 |
| LocutusOfBorg | doko, maybe the reason is the missing -std=gnu99? | 13:14 |
| LocutusOfBorg | I have no access to porterboxes in ubuntu, and not core-dev | 13:14 |
| juliank | The missing lz4 in main is preventing some serious APT bugs from being fixed | 13:15 |
| mdeslaur | tyhicks: ^ | 13:16 |
| LocutusOfBorg | doko, going to sync mpi-defaults, changes are in debian | 13:18 |
| LocutusOfBorg | mapreri, ^^^ | 13:18 |
| cjwatson | pitti: 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 |
| pitti | cjwatson: ah, I had to purge the ppc64el queue this morning as ppc64el got two kinds of breakages | 13:22 |
| pitti | I temporarily disabled it in bitney, but that doesn't apply to the train configs | 13:22 |
| cjwatson | pitti: also, is there some equivalent of http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/amd64/ that also shows PPA runs? | 13:22 |
| pitti | cjwatson: essentially, they need to be re-queued (using retry.cgi), I can deal with that | 13:23 |
| cjwatson | ok, thanks | 13:23 |
| pitti | cjwatson: no, there's no web UI for those results, that's suposed to be on ci-train | 13:23 |
| cjwatson | pitti: it is eventually, but there's a lag | 13:23 |
| cjwatson | which is annoying if one is trying to iterate on necessary triggers | 13:24 |
| pitti | cjwatson: I took the i386 regression retry.cgi link next to it and changed the URL | 13:24 |
| pitti | not that it'd help much, with this amount of red | 13:24 |
| cjwatson | pitti: yeah, it needs some wider triggers in order to pass, I'm just trying to figure out what | 13:24 |
| pitti | bbl, lunch | 13:25 |
| Mirv | fun, systemd update on 14.04 caused screen to lock (I mean just normal screenlock, enter password to unlock) | 13:32 |
| mdeslaur | Mirv: hrm, perhaps similar to bug 1543883 that sarnold experienced | 13:41 |
| ubottu | bug 1543883 in systemd (Ubuntu) "screen blanked during systemd-logind upgrade" [Undecided,New] https://launchpad.net/bugs/1543883 | 13:41 |
| === Foxtrot is now known as Guest20528 | ||
| coreycb | doko, 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 |
| cjwatson | pitti: ok, please could you disable xz on xenial again? it's causing apt-ftparchive to crash, reason as yet undetermined | 14:17 |
| pitti | cjwatson: ok, done | 14:18 |
| cjwatson | thanks | 14:18 |
| cjwatson | I have a big strace to stare at as time permits | 14:18 |
| cjwatson | might 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 first | 14:20 |
| cjwatson | maybe just an insufficiently large test case | 14:20 |
| marlinc | Does 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 overwritten | 14:23 |
| marlinc | I use UEFI to boot between multiple operating systems | 14:24 |
| LocutusOfBorg | hi xnox can I ask you the rationale for disabling mir on s390x (xorg-server?) I ask because I enabled mir on s390x for libsdl2-dev | 14:31 |
| LocutusOfBorg | I don't get why libmir is built everywhere, but packages using it shouldn't use on some architectures | 14:34 |
| xnox | LocutusOfBorg, because there is no mir on s390x. | 14:36 |
| LocutusOfBorg | mmm and the library is built? | 14:36 |
| cjwatson | hmm? | 14:37 |
| cjwatson | libmircommon5 | 0.19.1+16.04.20160204-0ubuntu1 | xenial | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x | 14:37 |
| LocutusOfBorg | libsdl2 has been built correctly there with mir support | 14:39 |
| LocutusOfBorg | cjwatson, does this mean mir is available everywhere? | 14:39 |
| cjwatson | it would seem to be but what do I know | 14:40 |
| cjwatson | (it may well not work ...) | 14:40 |
| LocutusOfBorg | exactly my point | 14:40 |
| LocutusOfBorg | I would avoid to use it if it is broken | 14:41 |
| LocutusOfBorg | and probably bother the maintainer about not building everywhere | 14:41 |
| LocutusOfBorg | https://launchpadlibrarian.net/236307381/mir_0.19.1+16.04.20160204-0ubuntu1.diff.gz | 14:42 |
| LocutusOfBorg | no mention in changelog | 14:43 |
| LocutusOfBorg | infinity disabled it in 0.13.1+15.10.20150520.1-0ubuntu1 | 14:45 |
| LocutusOfBorg | so I presume now the porting is complete | 14:45 |
| LocutusOfBorg | + * Disable testsuite on powerpc until big-endian porting is complete. | 14:45 |
| LocutusOfBorg | somebody re-enabled it and the testsuite is disabled now on big-endian | 14:49 |
| LocutusOfBorg | http://bazaar.launchpad.net/~mir-team/mir/0.19/revision/2617.2.2 | 14:49 |
| cjwatson | pitti: 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 |
| cjwatson | doesn't have to be a web UI | 14:56 |
| pitti | cjwatson: you mean more than the logtail on running.shtml? | 14:57 |
| cjwatson | pitti: yeah, one that has finished | 14:57 |
| pitti | cjwatson: CI train's britneys update every 30 mins AFAIK; if you use staging, those update every 5 | 14:57 |
| cjwatson | pitti: it's more like every 60+ at the moment | 14:58 |
| pitti | cjwatson: ah yes, you could look at the swift directory | 14:58 |
| pitti | cjwatson: which silo is that? | 14:58 |
| cjwatson | pitti: 37 | 14:58 |
| pitti | cjwatson: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-037?format=plain | 14:58 |
| cjwatson | pitti: ah, perfect, thanks | 14:58 |
| pitti | cjwatson: there's "xml" (but not clickable either) and "json" too if you prefer that | 14:59 |
| cjwatson | pitti: yeah, this is fine | 14:59 |
| pitti | cjwatson: welcome to the comfortable web 3.0 ! :) | 15:05 |
| pitti | cjwatson: 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 output | 15:06 |
| pitti | if that happens often | 15:06 |
| pitti | you 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 |
| pitti | append "&delimiter=@" and you get only the results; the last line, with /log.gz and /results.tar gives pretty much everything one would want to know | 15:07 |
| cjwatson | pitti: 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 |
| pitti | cjwatson: the triggers are fairly irrelevant for silos | 15:12 |
| pitti | cjwatson: one idea is that this depends on something in xenial-proposed which hasn't landed yet | 15:12 |
| cjwatson | pitti: In this case it needs a combination of all the stuff in the silo plus some things that are in -proposed | 15:12 |
| cjwatson | Indeed, that | 15:12 |
| pitti | cjwatson: PPA tests run against xenial plus the silo, not against xenial-proposed as well | 15:13 |
| cjwatson | pitti: It needs at least libjsoncpp and capnproto, plus probably ubuntu-touch-meta | 15:13 |
| pitti | as that is in many cases unintended and led to too many blockings | 15:13 |
| cjwatson | pitti: 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 |
| pitti | cjwatson: ah, so cleanes would probably be to land those first? | 15:13 |
| cjwatson | pitti: We can't, the bits in the silo are part of landing those things :-/ | 15:14 |
| pitti | ah, tricky | 15:14 |
| pitti | so we land one transaction via both a silo and regular -proposed uploads? | 15:14 |
| pitti | yeah, would be better to land that all in one silo | 15:14 |
| cjwatson | Well, part of it was an auto-sync from a month and a half ago | 15:14 |
| cjwatson | So you know | 15:14 |
| cjwatson | And then phone people never land anything other than via silos | 15:14 |
| pitti | copying the -proposed packages into the silo actually ought to work | 15:15 |
| cjwatson | All right, I'll give that a go | 15:15 |
| cjwatson | thanks | 15:15 |
| jdstrand | pitti: hi! looking at excuses, I see that ubuntu-core-launcher is a valid candidate for 14 days, but it didn't migrate | 15:15 |
| pitti | cjwatson: or I restart the tests manually with enabling -proposed on those | 15:15 |
| pitti | cjwatson: might be easier? | 15:16 |
| jdstrand | pitti: I didn't do that upload, but was planning one on top of that. is there anything special I/we should do? | 15:16 |
| cjwatson | pitti: I think either way would work. I can copy the packages, so let me try that first | 15:16 |
| pitti | jdstrand: it breaks ubuntu-snappy, as per http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt | 15:16 |
| pitti | jdstrand: so it won't land until ubuntu-snappy gets fixed/rebuilt/whatever to work with that ubuntu-core-laucher version | 15:17 |
| pitti | jdstrand: presumably there are some Breaks:/versioned Depends:/library transition or something such? | 15:17 |
| jdstrand | oh, I was unaware of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt | 15:19 |
| jdstrand | pitti: thanks for the info. I'll let the snappy team handle that transition then | 15:19 |
| pitti | jdstrand: to examine, start a xenial-proposed schroot (or chdist) and try to install ubuntu-snappy | 15:19 |
| jdstrand | kyrofa: fyi, ^ | 15:19 |
| pitti | ack | 15:19 |
| seb128 | pitti, 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 though | 15:20 |
| jdstrand | I suspect that xenial needs a 1.7.3 upload of ubuntu-snappy | 15:20 |
| jdstrand | but I'll let them handle it | 15:20 |
| seb128 | jdstrand, there is an update, it's blocked in proposed though because fails to build on powerpc/s390x | 15:20 |
| seb128 | it has been this way for a while though | 15:21 |
| jdstrand | yeah, interesting. but the previous upload did build | 15:22 |
| seb128 | like since novembre, I guess nobody in the snappy team has slots to look at those archs | 15:22 |
| jdstrand | based ontheir ppa (which doesn't include s390x, it looke like 1.7.3 will ftbfs on arm64 | 15:23 |
| seb128 | :-/ | 15:23 |
| jdstrand | I know that is a target arch-- maybe they'll fix it all up in one go | 15:23 |
| jdstrand | ok, I'm not touching that | 15:23 |
| jdstrand | pitti, seb128: thanks again! :) | 15:23 |
| bdmurray | seb128: 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 |
| seb128 | yw! | 15:23 |
| seb128 | bdmurray, so we should start seing valid signatures/stacktraces for new retraces? | 15:24 |
| bdmurray | seb128: I hope so but let me know if you see something amiss. | 15:24 |
| tyhicks | juliank: sarnold has been tied up in other MIR security reviews | 15:26 |
| tyhicks | juliank: there's still one MIR security review before it | 15:27 |
| tyhicks | juliank: the good news is that it'll happen very soon | 15:28 |
| xavigarcia | jhodapp: Hi! I think you pinged me yesterday, while I was already off... | 15:28 |
| xavigarcia | jhodapp: was it about that focus and sound indicator bug? | 15:28 |
| seb128 | bdmurray, 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 ones | 15:28 |
| bdmurray | seb128: we do have a queue of things to retrace at the moment due not accepting crashes for a bit | 15:29 |
| seb128 | k | 15:29 |
| tmartins | hey guys! Anyone here is experimenting Neutron 8.0.0 b2 on Xenial ? | 15:30 |
| * pitti re-enables ppc64el in britney | 15:35 | |
| LocutusOfBorg | ginggs, I'm gonna sync mumps | 15:38 |
| LocutusOfBorg | debian has the delta | 15:39 |
| slangasek | xnox: what silo was not using -proposed? AFAIK that would've required someone to manually change the setting | 15:39 |
| xnox | slangasek, false alarm. for built proposed was used, it's just for autopkgtest proposed is not used, by default. | 15:40 |
| xnox | well, magic is done there to try things, with -release only bias. | 15:40 |
| ginggs | LocutusOfBorg: sure, go ahead | 15:41 |
| LocutusOfBorg | thanks | 15:42 |
| LocutusOfBorg | doko, 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 safe | 16:39 |
| infinity | LocutusOfBorg, 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 |
| LocutusOfBorg | so the next xorg-server can drop the delta? (that bit)? wonderful | 16:52 |
| LocutusOfBorg | tjaalton, ^^^ | 16:57 |
| jderose | rharper: 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.fd | 17:01 |
| rharper | jderose: can you confirm that it made changes to the _CODE.fd ? | 17:01 |
| rharper | that doesn't seem correct, maybe we can run it with a readonly parameter | 17:01 |
| rharper | -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd | 17:02 |
| rharper | jderose: try that | 17:02 |
| rharper | should force a ro open on the CODE.fd instead of default rw open | 17:02 |
| jderose | rharper: still working through my VM install, but thus far it hasn't modified OVMF_CODE.fd | 17:02 |
| jderose | ah, good idea... i'll try the readonly option | 17:02 |
| rharper | ok, it shouldn't so should be safe to run with ,readonly | 17:02 |
| jderose | rharper: 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 mode | 17:14 |
| rharper | hrm | 17:14 |
| rharper | that can't be right; can you open a bug for that ? | 17:14 |
| rharper | I'd like to track the right thing here | 17:14 |
| jderose | yeah, 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 modified | 17:15 |
| jderose | rharper: sure. think i should file it against qemu or ovmf? | 17:15 |
| rharper | jderose: either, and we'll add an affects the other package | 17:16 |
| rharper | it feels like ovmf | 17:16 |
| rharper | as qemu did what you asked (readonly) | 17:16 |
| jderose | true | 17:16 |
| rharper | but it's also possible something funking is going on with the pflash emu ? | 17:16 |
| jderose | rharper: 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.txt | 17:17 |
| jderose | rharper: 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 emulation | 17:18 |
| rharper | jderose: 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 same | 17:19 |
| rharper | that was the reason for the split in the first place | 17:19 |
| rharper | someone misplaced a write in there somewhere =) | 17:19 |
| jderose | gotcha | 17:20 |
| rharper | jderose: did you order the pflash arguments with readonly first and then the writable ? | 17:20 |
| rharper | that whitepaper mentions order mattering due to how it;s mapped into ram | 17:21 |
| rharper | "This way qemu configures two flash chips consecutively, with start addresses | 17:21 |
| rharper | growing downwards, which is transparent to OVMF." | 17:21 |
| jderose | rharper: i used "-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd" | 17:21 |
| rharper | and then the second one for vars | 17:22 |
| jderose | oh, and i put the OVMF_VARS.fd -drive argument after the OVMF_CODE.fd" one | 17:22 |
| jderose | yeah | 17:22 |
| rharper | that seems correct | 17:22 |
| * rharper tries locally | 17:22 | |
| jderose | just minus "readonly" onthe 2nd | 17:22 |
| rharper | jderose: oh, can you reset your local _VARS.fd and try again ? | 17:24 |
| jderose | sure | 17:24 |
| rharper | I've seen "boot" behavior change after UEFI has updated the _VARS.fd | 17:24 |
| rharper | qemu-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.iso | 17:25 |
| rharper | jderose: for a fresh _Vars file, that boots the iso fine for me | 17:25 |
| nacc | slangasek: 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 extent | 17:25 |
| slangasek | nacc: how big is the bootstrap set currently? | 17:26 |
| jderose | rharper: 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 readonly | 17:26 |
| rharper | jderose: yeah! | 17:27 |
| jderose | rharper: thank you very much for your help on this! want me to still file a bug? | 17:27 |
| rharper | no | 17:27 |
| jderose | cool, thanks again | 17:27 |
| rharper | you may need to run efibootmgr in the guest | 17:27 |
| rharper | IIUC, you successfully installed | 17:27 |
| rharper | the default boot device is going to be set to a disk after install | 17:27 |
| rharper | you'd need to either use efibootmgr to control what to boot next time | 17:27 |
| jderose | right. i believe efibootmanager is always installed in UEFI desktop and server installs | 17:27 |
| rharper | or manually interrupt | 17:28 |
| jderose | yeah | 17:28 |
| rharper | and use shell to fix up | 17:28 |
| rharper | jderose: thanks for testing =) | 17:28 |
| jderose | np :) | 17:28 |
| nacc | slangasek: I believe around 73 | 17:31 |
| nacc | slangasek: 73 packages, that is, including the eventual targets of the bootstrap | 17:31 |
| slangasek | nacc: 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 |
| nacc | slangasek: 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 |
| cjwatson | uncleanly as in against feature-reduced versions of their dependencies, or uncleanly as in source modifications? | 17:35 |
| nacc | the former | 17:35 |
| cjwatson | that's mildly vexing but not a huge problem | 17:35 |
| nacc | i.e., staged builds | 17:35 |
| cjwatson | source modifications are the main hassle | 17:35 |
| cjwatson | can 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 |
| nacc | yeah, 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 |
| cjwatson | I only count source modifications that would not end up in the Ubuntu archive | 17:37 |
| nacc | ah 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 version | 17:37 |
| nacc | (above was necessary since i can't do staged builds in the ppa) | 17:37 |
| cjwatson | I thought you just said there were three of those, phpunit, doctrine, symfony | 17:37 |
| cjwatson | I mean source modifications for staged builds | 17:38 |
| nacc | oh sorry, i misread! | 17:38 |
| nacc | *not* end up in the archive | 17:38 |
| nacc | even that, i think, is pretty small ... but i'd need to go look at my list again | 17:39 |
| nacc | let me start over, though | 17:39 |
| nacc | i was looking at removing php5 from the archive and moving php7 to main | 17:39 |
| nacc | but that requires making sure everything can still build :) | 17:39 |
| nacc | so 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 tests | 17:40 |
| cjwatson | so, 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 |
| nacc | right, that's what i'm working on doing now via bugs and debdiffs and then i'll provide in the bug my explicit sequence | 17:40 |
| cjwatson | but the more that can be straight source copies and the fewer manual uploads need to happen, the less effort it is | 17:40 |
| nacc | yep | 17:41 |
| cjwatson | if necessary, we can also bootstrap from binaries in Debian | 17:41 |
| cjwatson | the 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 Ubuntu | 17:42 |
| cjwatson | to make sure everything is clean and we aren't including stuff we can't rebuild | 17:42 |
| cjwatson | so 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 legitimate | 17:42 |
| nacc | I 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 Debian | 17:43 |
| * cjwatson nods | 17:43 | |
| nacc | but for many packages that occurs by updating pkg-php-tools and php-pear and then rebuilds | 17:43 |
| cjwatson | I assume this isn't all architecture-independent code? | 17:43 |
| slangasek | nacc: 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 set | 17:44 |
| nacc | slangasek: ok, that's good to hear :/ i was starting to get a little stressed trying to rework the flow | 17:45 |
| cjwatson | slangasek: BTW do you know about bootstrap-package in u-a-t? | 17:45 |
| cjwatson | from the sound of things may not be useful for this particular case, but it's newish and can be handy for things of this type | 17:45 |
| nacc | cjwatson: 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-independent | 17:46 |
| nacc | cjwatson: in this bootstrap that means roughly i think 5-10 packages that are arch-specific | 17:46 |
| nacc | cjwatson: but i'm not sure if that's what you were asking | 17:46 |
| cjwatson | right, more than 0 was what I was asking | 17:46 |
| cjwatson | since that definitely means it needs to go in a devirt ppa :) | 17:46 |
| slangasek | cjwatson: I had not heard of this, I'll look thanks :) | 17:47 |
| slangasek | devirt ppa> ah good point | 17:48 |
| teward | for 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 |
| cjwatson | teward: (a) yes (mk-sbuild --target=armhf can help) (b) it uses qemu-user-static | 17:48 |
| cjwatson | teward: this is basically what LP did for virtualised armhf PPAs until last week, so same reliability issues apply | 17:49 |
| teward | indeed... | 17:50 |
| teward | cjwatson: 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 arm | 17:51 | |
| nacc | cjwatson: 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 y | 17:54 |
| nacc | ou? 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 |
| teward | blah i should just read wiki pages | 17:55 |
| teward | cjwatson: thanks | 17:55 |
| slangasek | nacc: your reading seems intuitive to me, but I don't know what the code itself does | 17:55 |
| cjwatson | nacc: That would mean "not nocheck or not stage1", which is unconditionally true - I think you want "<!nocheck !stage1>" | 17:57 |
| cjwatson | hm, but they have a contrary example | 17:57 |
| nacc | slangasek: 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 |
| nacc | cjwatson: right, so what you wrote is what i think it should be too | 17:57 |
| nacc | but their example is wrong, i think :) | 17:58 |
| nacc | or the english is off | 17:58 |
| cjwatson | I'm not sure. Run each one through sbuild -Pstage1 and see what happens? | 17:58 |
| nacc | just tested it | 17:58 |
| cjwatson | Er, --profiles=stage1 | 17:58 |
| nacc | yeah, it should be <!nocheck !stage1> | 17:58 |
| * nacc spent some time just now thinking in english in CNF ... or trying to | 17:58 | |
| cjwatson | It would be less surprising to me to find that the example was wrong, than to find that the logic was dramatically different for negated restrictions | 17:58 |
| nacc | yeah | 17:58 |
| slangasek | yeah. my understanding is that conditions within a <> are ANDed, and separate <> blocks are ORed | 17:59 |
| slangasek | glad to hear that the code agrees with our intuition ;) | 17:59 |
| cjwatson | nacc: 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 |
| nacc | cjwatson: :) np | 17:59 |
| nacc | i'll send an update to the wiki and see if debian picks it up | 18:00 |
| teward | cjwatson: 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 |
| slangasek | teward: you don't even need to specify --arch in that case | 18:10 |
| teward | slangasek: nice. force of habit to do that though :) | 18:10 |
| teward | i guess i'll start poking my rpi then to turn it into an (albeit really slow) builder | 18:10 |
| slangasek | teward: 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 na | 18:13 |
| slangasek | tive 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 |
| teward | slangasek: most of the stuff being sent to the builder is headless, so meh | 18:14 |
| teward | but 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 |
| sarnold | hey 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 |
| teward | sarnold: 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 |
| teward | i'm building the cross-compile env anyways | 18:17 |
| sarnold | ah okay :) | 18:17 |
| teward | sarnold: 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 |
| sarnold | teward: interesting, I hadn't heard that before.. I don't step much outside the simple and easy center :) | 18:21 |
| teward | indeed | 18:21 |
| teward | i've got a couple RPis here that rely on certain 'all' packages to be available from an internal private repo here ;) | 18:21 |
| teward | because it's not publicly released yet | 18:21 |
| teward | blah slow internet is slow | 18:24 |
| cjwatson | er, yes, I conflated --target=armhf and --arch=armhf earlier | 18:37 |
| dobey | sarnold: might be better to use an actual ssd/hdd if using the device as a builder, than relying on an SD card :) | 18:42 |
| sarnold | dobey: yeah; of course that would go through a usb-sata interface.. also not ideal ;) | 18:43 |
| sarnold | I was just using mine for irssi and occasional rtorrent use; now it's only irssi. heh. | 18:44 |
| dobey | sarnold: well, if you have usb 3, it's not too bad | 18:46 |
| sarnold | dobey: I must admit I never looked but ijust sort of assumed the pandaboard didn't have usb3 :) | 18:47 |
| dobey | sarnold: well, yeah, pandaboard probably doesn't have much. but rpi2 has usb3 doesn't it? :) | 18:48 |
| sarnold | dobey: ooh? nice. yeah. that'd be the way to go :) | 18:48 |
| dobey | well not sure now. their web page doesn't have any actual specs | 18:49 |
| teward | dobey: last I checked it's USB2 | 18:49 |
| dobey | it just says "4 USB ports" | 18:49 |
| teward | USB3 would be blue I think? | 18:49 |
| dobey | teward: it doesn't have to be blue, but they commonly are | 18:49 |
| teward | i'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 |
| dobey | engadget says 2.0 though | 18:50 |
| teward | pretty sure it's 2.0 | 18:50 |
| hallyn | ok, 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 |
| hallyn | or is it more? | 18:51 |
| dobey | usb 2/sata bridge might still be faster than the sd card. not sure | 18:52 |
| tmartins | Hey guys, any chance to have the latest Enlightenment LibEFL on Xenial ? | 18:53 |
| dobey | tmartins: is it in debian already? | 18:55 |
| tmartins | nop | 18:55 |
| dobey | tmartins: 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 e17 | 18:57 |
| tmartins | But, for example, DPDK is only available on Ubuntu... =P | 18:57 |
| tmartins | Mmm... | 18:57 |
| hallyn | sarnold: ^ do you know offhand? (about dh_makeshlibs -V implications) | 18:59 |
| sarnold | hallyn: sorry, no, I rarely make changes that large to packaging | 18:59 |
| hallyn | ok thx | 19:00 |
| hallyn | stgraber: ? | 19:00 |
| dobey | hallyn: 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 x | 19:06 |
| dobey | or both newer versions will need to be installed, to satisfy the deps | 19:07 |
| dobey | at least, that is my understanding from what man dh_makeshlibs says | 19:07 |
| doko | barry, why is the setuptools wheel not necessary anymore? | 19:08 |
| dobey | i don't think that's an issue though, because we tend to maintain the "things must be rebuilt anyway" mindset | 19:08 |
| hallyn | dobey: 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 |
| hallyn | so yeah i think we can just do it. | 19:09 |
| hallyn | thanks! | 19:09 |
| dobey | right, we always rebuild when sticking things in -updates or -backports, and generally try to keep version numbering which won't break the upgrade path | 19:12 |
| hallyn | yay, so i'll enable :) thx | 19:14 |
| doko | ginggs, 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 |
| ricotz | doko, hi, could you pick up this aptitude merge -- https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/6059699/+listing-archive-extra | 19:14 |
| ginggs | doko, i'm looking, but i'm not sure what i'm looking at :) | 19:16 |
| doko | ginggs, 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 binary | 19:21 |
| barry | doko: because we create the wheels at pip build time using the dirtbike rewheeling tool | 19:24 |
| doko | that's dirty | 19:24 |
| barry | well | 19:26 |
| barry | not really | 19:26 |
| ginggs | doko, so odin, for example has build-depends on libdcmtk-dev | libdcmtk2-dev | libdcmtk1-dev | 19:26 |
| doko | sure, you can ignore this | 19:28 |
| ginggs | the latest upload of dcmtk has libdcmtk-dev | 19:28 |
| doko | ricotz, 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 |
| ginggs | odil has libdcmtk-dev | libdcmtk2-dev | 19:30 |
| ginggs | dcmtkkpp has libdcmtk-dev | libdcmtk2-dev | 19:32 |
| === catbus1 is now known as catbus1-afk | ||
| ginggs | doko, ok libinsighttoolkit4-dev still depends on libdcmtk2-dev | 19:35 |
| ginggs | LocutusOfBorg: do you feel like doing another merge of insighttoolkit4? 4.9.0-1 was uploaded | 19:36 |
| hallyn | hey - 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 |
| ubottu | bug 1541736 in bacula (Ubuntu) "Sync bacula 7.0.5+dfsg-4 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1541736 | 19:41 |
| ginggs | LocutusOfBorg: except 4.9.0-1 in debian still depends on libdcmtk2-dev | 19:41 |
| hallyn | nacc: I trust you've built+tested bacula from debian and found no problems in x? | 19:41 |
| nacc | hallyn: right, i found no issues and our delta was all fixed upstream or due to being in main | 19:42 |
| hallyn | nacc: cool - then we just need an archive admin to edumacate us on how to demote to universe | 19:42 |
| ginggs | LocutusOfBorg, 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 good | 19:45 |
| ricotz | doko, can do, ppc64el is possible already | 19:45 |
| sarnold | hallyn: 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 release | 19:47 |
| sarnold | hallyn: probably assign or subscribe to the ubuntu archive admin team to make sure it's on their list when they look :) | 19:48 |
| hallyn | sarnold: 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 |
| hallyn | nacc: ^ | 19:48 |
| sarnold | hallyn: I like the idea of the sync and -proposed, and also leaving a bug open ;) | 19:49 |
| hallyn | sounds good. nacc: pls assign the bug to ubuntu archive team, i'll initiate the sync | 19:49 |
| nacc | hallyn: will do | 19:50 |
| hallyn | thx | 19:50 |
| doko | ginggs, ta, thanks for the analysis. removing libdcmtk2-dev | 19:57 |
| ginggs | doko: yw | 19:59 |
| doko | mwhudson, please could you have a look at http://people.canonical.com/~ubuntu-archive/nbs.html ? packages referencing golang-testify-dev, not built anymore | 20:03 |
| infinity | hallyn: I don't understand why that bug requests demotion to universe. | 20:28 |
| infinity | hallyn: There's literally no explanation, and it's seeded in supported for all flavours (including ubuntu). | 20:29 |
| infinity | nacc: ^ | 20:30 |
| jtaylor | infinity: is glibc update stillon the schedule? | 20:32 |
| infinity | jtaylor: Yep. | 20:32 |
| smoser | hey. | 20:35 |
| smoser | i need some help | 20:36 |
| smoser | i have a system that is up. | 20:36 |
| smoser | ssh running | 20:36 |
| smoser | xenial | 20:36 |
| smoser | another system attempt ssh in. | 20:36 |
| smoser | another system attempt ssh in. | 20:37 |
| infinity | Password or key auth? If the latter, using insecure keys which are disabled by default in Xenial? | 20:37 |
| smoser | ssh client looks like this: | 20:37 |
| smoser | http://paste.ubuntu.com/15010918/ | 20:37 |
| mwhudson | doko: i don't know anything at all about any of those packages | 20:43 |
| mwhudson | but i can try and figure stuff out i guess :-) | 20:43 |
| mwhudson | infinity: how's the head today? | 20:44 |
| doko | mwenning, that would be appreciated | 20:44 |
| doko | mwhudson, ^^^ | 20:45 |
| sarnold | smoser: similar-looking bug report https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1534792 | 20:49 |
| ubottu | Launchpad bug 1534792 in openssh (Ubuntu) "unable to connect" [Undecided,Incomplete] | 20:49 |
| infinity | mwhudson: Wobbling about atop my neck, more or less as it's meant to. | 20:49 |
| mwhudson | infinity: shall we talk go toolchains vs lts releases then? | 20:50 |
| smoser | sarnold, even telnet 22 i get just dropped immediately | 20:52 |
| smoser | Connection closed by foreign host | 20:52 |
| smoser | i *can* ssh from that system to itself either by localhost or by ip address | 20:52 |
| mdeslaur | xnox: wow, 35%!! /me hugs xnox | 20:53 |
| nacc | infinity: i apologize, still learning and was told to simply put it in the bug report. Will work on the seed changes | 20:53 |
| sarnold | smoser: actually that's pretty good -- that's a -way- simpler problem to debug :) | 20:53 |
| smoser | oh . yeah. the telnet. | 20:54 |
| nacc | smoser: how do i go about updating the seed to not refer to bacula? | 20:54 |
| infinity | mwhudson: 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 |
| mwhudson | infinity: yes | 20:55 |
| infinity | mwhudson: Shiny. | 20:55 |
| rcj | slangasek, 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 |
| smoser | nacc, you can make a change to http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.xenial/files | 20:59 |
| smoser | and submit a merge proposal | 20:59 |
| rcj | they 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 |
| mwhudson | xnox: 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 |
| ubottu | Launchpad bug 1534346 in unity-scope-snappy (Ubuntu) "FTBFS with golang-go 1.6 beta2" [Undecided,New] | 21:01 |
| mwhudson | doko: oh, golang-testify-dev is now golang-github-stretchr-testify-dev | 21:02 |
| mwhudson | is there a similar nbs page for debian? | 21:02 |
| nacc | smoser: thanks | 21:02 |
| mwhudson | because i'd be really surprised if any of these packages had a delta | 21:03 |
| hallyn | infinity: 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 offhand | 21:03 |
| infinity | hallyn: Is that worth dropping support? | 21:04 |
| mwhudson | er but golang-github-stretchr-testify-dev Provides: golang-testify-dev | 21:05 |
| mwhudson | doko: i think golang-testify-dev can in fact be removed safely | 21:07 |
| mwhudson | doko: because the new golang-github-stretchr-testify-dev package has "Provides: golang-testify-dev" | 21:08 |
| mwhudson | doko: is that the sort of conclusion you wanted me to reach? :-) | 21:08 |
| doko | mwhudson, please file an isss | 21:09 |
| doko | mwhudson, please file an issue even | 21:09 |
| mwhudson | doko: on https://launchpad.net/ubuntu/+source/golang-testify ? | 21:09 |
| doko | yes, please | 21:09 |
| hallyn | infinity: 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 main | 21:11 | |
| mwhudson | doko: https://bugs.launchpad.net/ubuntu/+source/golang-testify/+bug/1544291 (i subscribed ~ubuntu-archive, anything else needed?) | 21:12 |
| ubottu | Launchpad bug 1544291 in golang-testify (Ubuntu) "please remove golang-testify-dev package" [Undecided,New] | 21:12 |
| hallyn | only bugs against htat baby are requests for syncing | 21:12 |
| hallyn | nacc: was there anything other than mt-st that was cause for demoting bacula? | 21:12 |
| hallyn | kirkland: what is your view on bacula support for server? do we care whether it is in main? | 21:13 |
| nacc | hallyn: we don't want to support it anymore, afaict, kirkland has already acked demoting it | 21:17 |
| hallyn | kirkland: could add a comment to https://bugs.launchpad.net/ubuntu/+source/bacula/+bug/1541736 acking demotion? | 21:19 |
| ubottu | Launchpad bug 1541736 in bacula (Ubuntu) "Sync bacula 7.0.5+dfsg-4 (main) from Debian unstable (main)" [Wishlist,Fix released] | 21:19 |
| smoser | ok. for my ssh bug above. | 21:41 |
| smoser | if i am pinging the remote host or have ssh'd to it, then i can initiate an ssh connection fine. | 21:42 |
| infinity | smoser: Broken stateful firewall? | 21:43 |
| smoser | i'm guessing its got something to do with | 21:44 |
| smoser | From 10.7.10.1: icmp_seq=11 Redirect Host(New nexthop: 10.7.2.103) | 21:44 |
| smoser | http://paste.ubuntu.com/15011341/ | 21:44 |
| smoser | what i have is a flat network 10.7.0.0/16 | 21:45 |
| smoser | and on that is a maas system. when it installs nodes it tells them that it is their gateway (10.7.10.1) and that they have a /26 network under 10.7.10.0/ | 21:46 |
| smoser | i've another host with almost idential networking (10.7.10.62 instead of 10.7.10.61) 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 | ||
| rharper | working 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/errors | 21:48 |
| smoser | running sshd in the foreground with :sudo /usr/sbin/sshd -D -d -d -d -e | 21:50 |
| === mariogrip_ is now known as mariogrip | ||
| mwhudson | rharper: i thiiiiiiiiiink but hardly know for sure that those warnings don't really apply for ubuntu | 21:50 |
| smoser | basically doesn't see it getting a connection | 21:50 |
| smoser | but tcpdum pdoes show some data. | 21:50 |
| smoser | tcpdump port 22 -vv shows: | 21:50 |
| smoser | http://paste.ubuntu.com/15011373/ | 21:50 |
| rharper | mwhudson: 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 warning | 21:51 |
| rharper | the 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 attention | 21:52 |
| mwhudson | rharper: i think the warning is about something that will go back in a situation that does not occur in debian | 21:52 |
| mwhudson | errr | 21:52 |
| mwhudson | *does not occur in ubuntu* | 21:52 |
| mwhudson | rharper: https://wiki.debian.org/binNMU | 21:53 |
| rharper | thanks | 21:53 |
| mwhudson | rharper: we don't have binary uploads at all | 21:53 |
| rharper | btw, google says no when I tried to search with "${source:Version}" | 21:53 |
| rharper | which I thought was funny | 21:53 |
| rharper | trying to google to find out why google does't like source:Version | 21:53 |
| rharper | was also fun and fruitless | 21:54 |
| rharper | searching for ource:Version, got google to auto search for source:Version for me | 21:54 |
| rharper | did you mean this? (yes, I did, but you wouldn't let me search for that!) | 21:54 |
| mwhudson | lolz | 21:54 |
| rharper | mwhudson: ok, yes, I'll ignore those and go back to wondering why ppa build of the successful sbuild fails | 21:55 |
| cherylj | Is 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 nothing | 21:59 |
| cherylj | See: http://paste.ubuntu.com/15011347/ | 21:59 |
| smoser | cherylj, that is interesting. | 22:00 |
| smoser | as i was just above typing ssh issues too | 22:01 |
| smoser | fun | 22:01 |
| mwhudson | cherylj: fwiw i can't reproduce that sshing into a xenial lxd | 22:02 |
| mwhudson | but i don't really know what that indicates | 22:02 |
| smoser | although mine fail with connection closed even on telnet 22 | 22:02 |
| cherylj | mwhudson: yeah I provisioned a new xenial machine and couldn't recreate. | 22:02 |
| cherylj | mwhudson: this is a machine that was provisioned through juju | 22:03 |
| mwhudson | cherylj: oh awesome | 22:03 |
| rharper | well | 22:03 |
| rharper | hehe | 22:03 |
| rharper | obviously it was *jujus* fault =P | 22:03 |
| cherylj | I have no idea what to look at that could cause the difference | 22:03 |
| cherylj | :P | 22:03 |
| smoser | cherylj, and mine was provisioned with maas | 22:03 |
| mwhudson | i guess you could diff /etc/ssh/sshd_config on the machines | 22:03 |
| === stgraber_ is now known as stgraber | ||
| mwhudson | and check the package versions are the same | 22:03 |
| smoser | admittedly i have kind of funky networking. but funky networking that works fine with trusty. | 22:04 |
| cherylj | mwhudson: the package versions are the same | 22:04 |
| mwhudson | cherylj: can you log in ok with ssh?\ | 22:04 |
| rharper | wouldn't ssh client complain somewhere about failed psuedo-tty allocation ? | 22:04 |
| cherylj | mwhudson: yes | 22:04 |
| rharper | -t requests one | 22:04 |
| mwhudson | hmm | 22:04 |
| mwhudson | cherylj: ssh -vvv ? | 22:04 |
| smoser | yeah. add some -vvv | 22:04 |
| cherylj | I did that, let me paste the diff | 22:05 |
| mwhudson | and look for logs on the server? | 22:05 |
| smoser | or run the daemon in the foreground with '/usr/bin/sshd -D -d -d -d -e' | 22:05 |
| rharper | different port though | 22:05 |
| rharper | don't mess with the working one =) | 22:05 |
| smoser | i'm stil kind of hoping cherylj has my problem too. and just doenst know it. | 22:06 |
| smoser | does telnet 54.179.131.88 22 | 22:06 |
| slangasek | rcj: replaced mountall> aigh it burns | 22:06 |
| smoser | give you a ssh prompt ? or just drop it. | 22:06 |
| cherylj | mwhudson: the /etc/ssh/sshd_config is the same for the two machines | 22:08 |
| mwhudson | cherylj: i guess that's not very surprising but oh well | 22:09 |
| mwhudson | cherylj: -vvv? | 22:10 |
| cherylj | mwhudson: success case: http://paste.ubuntu.com/15011479/ | 22:11 |
| cherylj | mwhudson: failed case: http://paste.ubuntu.com/15011482/ | 22:11 |
| mwhudson | cherylj: huh it almost looks like a race between output and exit status? | 22:14 |
| cherylj | mwhudson: yeah, I was wondering about that | 22:14 |
| mwhudson | cherylj: 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 |
| cherylj | mwhudson: ha! | 22:17 |
| cherylj | $ ssh -t ubuntu@54.179.131.88 "lsb_release -c; sleep 5" | 22:17 |
| cherylj | Codename:xenial | 22:17 |
| cherylj | Connection to 54.179.131.88 closed. | 22:17 |
| rharper | hrm, why might i386 build fail when x86_64 succeeds (failure in linking) | 22:17 |
| mwhudson | cherylj: i'm fairly sure that's supposed to be impossible :( | 22:18 |
| cherylj | mwhudson: sounds like it's time to open a bug? | 22:18 |
| mwhudson | yeah, i guess | 22:18 |
| cherylj | but I have no idea why it's different on this machine vs another | 22:19 |
| mwhudson | is it reproducible at all>? | 22:19 |
| cherylj | mwhudson: yes, we hit it in CI consistently | 22:19 |
| mwhudson | cherylj: oh, it's simple then: CI is infested with malicious demons | 22:19 |
| cherylj | of course, why didn't I think of that! | 22:19 |
| rharper | mwhudson: hehe | 22:20 |
| rcj | slangasek, it's a container environment that runs linux in a opensolaris (joyent smartos) zone | 22:20 |
| mwhudson | cherylj: still at least a reproduction case makes actually fixing the bug feasible | 22:20 |
| mwhudson | cherylj: when did the bug start? | 22:21 |
| cherylj | mwhudson: I need to look at the CI logs to see when we started hitting it | 22:22 |
| cherylj | give me a few | 22:22 |
| mwhudson | last openssh upload was about three weeks ago | 22:22 |
| === mnepton is now known as mneptok | ||
| === stokachu_ is now known as stokachu | ||
| rcj | slangasek, I have asked if they can stop diverting around the real mountall but that may not be possible in the current environment | 22:23 |
| slangasek | :/ | 22:23 |
| rcj | I'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 mountall | 22:26 |
| nacc | slangasek: ok, i'm on my last 3 packages1 | 22:29 |
| nacc | s/1/!/ ;) | 22:29 |
| nacc | slangasek: need some help/advice on one of them, if you have a second, though | 22:29 |
| slangasek | nacc: hit me | 22:29 |
| slangasek | rcj: so I believe it is possible and the devil is in the details | 22:30 |
| === pitti` is now known as pitti | ||
| nacc | slangasek: 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-bridge | 22:33 |
| === pitti is now known as Guest3706 | ||
| nacc | slangasek: oh ... i wonder if i could have two version of the binary package in the ocntrol file, toggled by Build-Profiles? | 22:34 |
| slangasek | nacc: profile qualifiers can be applied to hard-coded dependencies listed in debian/control, not just to build-dependencies | 22:35 |
| nacc | slangasek: oh! that's not mentioned on the wiki page :) | 22:35 |
| nacc | easy enough then | 22:35 |
| slangasek | nacc: I don't know that you can toggle the whole stanza, but it should work for the evaluation of the binary control files | 22:36 |
| nacc | ok, i'll test that now | 22:36 |
| slangasek | nacc: obviously, test this to make sure I'm not blowing smoke :) | 22:36 |
| nacc | slangasek: :) | 22:37 |
| slangasek | nacc: 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 manner | 22:39 |
| rcj | slangasek, I'll pursue the details through a bug rather than IRC. Thanks. | 22:45 |
| === Guest3706 is now known as pitti | ||
| nacc | slangasek: 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 |
| slangasek | nacc: for stage1, hack it any way you like that gets you the proper result ;) | 22:56 |
| nacc | slangasek: heh | 22:56 |
| slangasek | nacc: 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 |
| mwhudson | infinity: how's the paperwork? | 23:01 |
| mwhudson | infinity: i'm going to disappear in 2.5 hours or so and i need to do some afk stuff before then | 23:19 |
| nacc | slangasek: 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 |
| nacc | full list = 400+ packages, that is | 23:22 |
| infinity | mwhudson: I'm aroundish now. | 23:25 |
| mwhudson | infinity: \o/ | 23:25 |
| mwhudson | infinity: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1536882 https://wiki.ubuntu.com/MichaelHudsonDoyle/Go15InTrusty | 23:26 |
| ubottu | Launchpad bug 1536882 in golang (Ubuntu) "upload golang1.5 package for trusty" [Undecided,New] | 23:26 |
| infinity | mwhudson: Right. Want to mumble or something? | 23:27 |
| mwhudson | infinity: sure, although i don't think i actually have mumble installed | 23:27 |
| infinity | mwhudson: Or a hangout... | 23:27 |
| mwhudson | would be easier | 23:27 |
| infinity | mwhudson: Not picky. | 23:28 |
| mwhudson | hangout then | 23:28 |
| * mwhudson can't remember how to start a hangout | 23:29 | |
| mwhudson | oh there | 23:29 |
| mwhudson | infinity: i've invited the canonical you, i think | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
