[01:24] <nacc> slangasek: Pharaoh_Atem: fyi: https://3v4l.org/uMrcs
[01:24] <nacc> shows that the issue with zeta-console-tools test is an upstream thing, and probably something that is "expected", but shoudl be adjusted in their output
[01:30] <Pharaoh_Atem> nacc: cool
[01:59] <cherylj> hey cjwatson, I'm seeing a failure when doing an apt-get update for ppa:juju/devel on xenial (weak digest error).  I found bug #1556666  and wondered if we had to push a new package to get InRelease resigned in that ppa?
[02:00] <cherylj> infinity ^^?
[02:38] <infinity> cherylj: It needs fixing on the LP end, nothing you can do about it.
[02:40] <cherylj> thanks, infinity
[05:51] <cpaelzer> good morning
[06:52] <kickinz1> Morning!
[07:31] <pitti> Good morning
[07:31] <pitti> Mirv: landing-036 does not exist any more, I suppose this was taken care of already?
[07:34] <pitti> slangasek: there have been no testbed config changes on my side; in theory it could be that the QEMU config on the nova-compute side got changed somehow
[07:34] <pitti> slangasek: but if you can reproduce it locally, that error doesn't seem to be too specific to the qemu params in scalingstack
[07:34] <Mirv> pitti: yes, we just forced QA:ing and publishing of it. no problem!
[07:35] <pitti> cjwatson: will look into it, this is tracked in bug 1558823
[07:37] <pitti> xnox: seems Stephane already approved your FFE
[07:58] <pitti> slangasek: ah, I get the same thing in apport now apparently
[07:58] <pitti> Failed to connect to Mir: Failed to connect to server socket: No such file or directory
[07:58] <pitti> ^ that?
[08:19] <dholbach> good morning
[08:34] <jamespage> morning all
[11:30] <cjwatson> cherylj: there may be a period (which is not the case yet) in which pushing a new package is enough to get the PPA re-signed; but we're planning to do it in bulk
[11:31] <cjwatson> pitti: thanks
[11:31] <cjwatson> cherylj: Note that it's technically a warning, not an error
[11:54] <dasjoe> cking: #1527727 - I think Ned will release 0.6.5.6 early this week, the LLNL guys don't seem to work on weekends
[11:55] <cking> dasjoe, yep, I emailed Ned for some clarification, but I will try and sync with 0.6.5.6 if it comes out this week for sure
[11:59] <dasjoe> cking: behlendorf asked me whether I was aware of any ZFS issues from Ubuntu which concerned the upstream ZFS on Linux project, neither rlaager nor me could name anything relevant
[12:00] <cking> dasjoe, cool, thanks for that
[12:04] <dasjoe> cking: one thing I've noticed, which may not be ZFS related, is grub-pc's installation fails when given multiple disks. I had to work around this for my installation: http://paste.debian.net/hidden/24d104e9/ - see line 173
[12:07] <dasjoe> I didn't copy the error message, if I remember correctly grub-pc's normal installation process works for the first disk, then fails with "can't find /dev/disk/by-id/ata-xyz,", I assume the , breaks it
[12:14] <Sharcho> FYI: There doesn't seem to be any patches for GIT for CVE-2016-2324, CVE-2016‑2315 on Ubuntu 14.04 LTS
[12:14] <mdeslaur> Sharcho: It's being worked on
[12:15] <Sharcho> mdeslaur: thanks
[12:27] <doko> Laney: any idea about https://launchpadlibrarian.net/249221907/buildlog_ubuntu-xenial-amd64.gnubg_1.05.000-6_BUILDING.txt.gz ? seems to be introduced with the recent glib
[12:34] <Laney> doko: It's probably that de-duplicating thing
[12:34] <Laney> doko: Copy glib-gettext.m4 from glib or remove the local copy
[12:47] <flexiondotorg> Which team should I direct towards this bug? https://bugs.launchpad.net/ubuntu-mate/+bug/1559243
[12:48] <cjwatson> flexiondotorg: installer team.  I'll have a look, I think I still remember how to do that
[12:48] <flexiondotorg> cjwatson, Thank you :-)
[12:52] <Mirv> this signatures problem probably affects interaction with Debian too? meaning LP doesn't get updated information from Debian, so syncing of latest packages and such isn't possible.
[12:53] <Mirv> "has not been picked up by LP yet"
[12:53] <smoser> pitti, http://paste.ubuntu.com/15401586/ <-- were you going to upload that ?
[12:55] <pitti> smoser: no, as I said it's the wrong way around; the Wants= should be added to units that want to run before the network is up
[12:55] <pitti> i. e. cloud-init in that case (according to systemd.special(7))
[12:55] <smoser> oh.
[12:55] <smoser> hm.. that was the second part of my question.
[12:56] <smoser> i dont necessarily think its the wrong way around though.
[12:56] <pitti> I didn't read that properly when we talked about this
[12:56] <smoser> networking.service should want the network-pre.target to have been reached.
[12:56] <smoser> i'm sorry, i must have just misunderstood then. i can add Wants network-pre.target to cloud-init-local.service
[12:57] <pitti> no worries, it wasn't clear last week when we talked about it
[12:57] <smoser> one other question.
[12:58] <smoser> you can have multple 'Wants=' in a service
[12:58] <smoser> i think.
[12:58] <smoser> Wants=other-thing1
[12:58] <smoser> Wants=other-thing2
[12:58] <smoser> that multiline syntax does work, rigth?
[12:59] <smoser> is 'Wants=other-thing1 other-thing2' preferred for any reason ?
[13:00] <pitti> smoser: they are exactly identical
[13:01] <pitti> so just a matter of stylistic preference I guess
[13:01] <pitti> multi-line is nicer for patching or adding comments, but a bit more verbose
[13:02] <smoser> thats what i thought.
[13:02] <smoser> thanks.
[13:05] <caribou> xnox: FYI - LP: #1560024
[13:10] <cjwatson> Mirv: I explained that on ubuntu-devel recently.
[13:18]  * Mirv reads
[13:22] <cjwatson> flexiondotorg: Done; will require another upload to actually include localisations, so please remind us in a couple of weeks.
[13:29] <flexiondotorg> cjwatson, Thanks. But I can point translators at it now?
[13:36] <cjwatson> flexiondotorg: It'll probably take a little while before it's available for translation on LP.  Check first
[13:38] <cjwatson> flexiondotorg: (https://translations.launchpad.net/ubuntu/xenial/+source/gfxboot-theme-ubuntu/+pots/bootloader, pick random language, search for mate)
[14:06] <slangasek> pitti: yeah, wasn't a testbed change, turns out it was a genuine regression between glibc and mesa due to use of swrast on single-CPU VM guests (LP: #1559842) - thanks for looking though
[14:08] <pitti> slangasek: ah, thanks for the pointer! that means now that mesa is in it's worth retrying the failures?
[14:08] <pitti> slangasek: although the glibc task of the above bug is still open, does this need a glibc fix too?
[14:08] <pitti> slangasek: I tried to locally run apport against all of -proposed, and it seemed to work
[14:08] <pitti> (some 3 hours ago maybe)
[14:09] <pitti> cjwatson: I suppose it's ok to use syncpackage --no-lp for the time being?
[14:09] <slangasek> pitti: yes, any of the autopkgtests that have regressed with glibc on amd64+i386 should be retried
[14:09] <pitti> slangasek: ack, doing
[14:10] <slangasek> pitti: and the glibc task can be closed, I didn't clean that up before I went to bed
[14:10] <pitti> in fact, I retried a few already, and so did infinity
[14:10] <slangasek> yep
[14:10] <slangasek> pitti: hopefully not with --all-proposed though ;)
[14:11] <pitti> I might have done apport
[14:11] <pitti> but *shrug*, whatever makes them pass :)
[14:12] <cjwatson> pitti: Yes, though I just requested a deployment with the gina fix so if I can twist a webops' arm then it should hopefully be sorted out today
[14:13] <cjwatson> pitti: i.e. if it's not urgent it would be preferable to wait
[14:13] <pitti> cjwatson: no, it's not; thanks
[14:28] <infinity> pitti: So, the apport test still fails, for slightly different reasons.  The rest seem to have been fixed by Steve's mesa.
[14:30] <pitti> infinity: indeed, a lot less red on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#glibc now; I'll look at apport, but this indeed looks unrelated now
[14:31] <infinity> pitti: Well, it's unrelated to the thing Steve fixed, but if you previously expected xvfb to exit and now it doesn't, either your assumption was silly or something is still a bit goofy.
[14:31] <pitti> AssertionError: 'no debug symbol package found for coreutils\n' != ''
[14:31] <pitti> infinity: no, the only two failures are in backend_apt_dpkg
[14:31] <pitti> search for [14:32] <pitti> the xvfb message at the end is normal (just for debugging)
[14:32] <pitti> not sure what's up with coreutils' ddebs
[14:33] <infinity> pitti: Oh.
[14:33] <infinity> pitti: Tests with ddebs are busted because you need to re-sign ddebs.u.c with a less crap key, IIRC.
[14:34] <pitti> infinity: I did this morning
[14:34] <infinity> pitti: Oh, so we should retry crash and see how it likes it?
[14:34] <pitti> see bug 1558823
[14:34] <pitti> infinity: I didn't look at crash's regression yet, but if that was it it's worth retrying indeed
[14:35] <infinity> pitti: crash was much whining from apt, followed by "E: some indexes not updated", so yeah.  Pretty sure your new key will fix that, if apt now loves i.
[14:35] <infinity> s/i./it./
[14:42] <pitti> infinity: hmm, http://keyserver.ubuntu.com/pks/lookup?op=get&fingerprint=on&search=0xC8CAB6595FDFF622 exists now, but I can't say for how long already
[14:50] <flexiondotorg> I will be filling a needs packaging FFe in a bit. Can some just confirm I've got the version numbering correct?
[14:50] <flexiondotorg> http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/topmenu-qt/view/head:/debian/changelog
[14:50] <flexiondotorg> I realise the ~xenial1.0 suffix needs to be dropped.
[14:50] <flexiondotorg> This package is not going into Debian, so I want the confirm I've got the -0ubuntu1 bit right.
[14:53] <infinity> flexiondotorg: -0ubuntu1 is correct for something where our upstream is ahead of Debian, yes.
[14:53] <flexiondotorg> infinity, Thanks. This package will be entirely absent from Debian.
[14:55] <infinity> pitti: crash's tests might be statically configured to pull the old key or something.
[14:55]  * infinity looks.
[14:56] <infinity> pitti: Yeah, it is.
[14:56] <pitti> infinity: hm, perhaps this should pull http://ddebs.ubuntu.com/dbgsym-release-key.asc instead?
[14:57] <infinity> pitti: Maybe.  What's the recommended way for people to get the key on live systems?
[14:57] <infinity> pitti: Should it perhaps be packaged instead, so there's a trusty path?
[14:57] <infinity> s/trusty/trust/
[14:57] <pitti> I updated the key ID on https://wiki.ubuntu.com/DebuggingProgramCrash this morning
[14:58] <pitti> but that won't magically fix people's scripts indeed
[14:58] <pitti> infinity: hmm, we could put it into ubuntu-keyring
[14:59] <infinity> pitti: Yeah, in a split file, perhaps, the way debian-archive-keyring is now laid out.
[14:59] <pitti> does merely adding it to /usr/share/keyrings/ actually helps? I thought apt would expect them in /etc/apt/trusted.gpg.d
[14:59] <nacc> slangasek: i'm going to file a bug upstream for that php-zeta-console-tools failure, I think. Let me see if I can patch the testrunner to skip that error
[15:00] <infinity> pitti: apt wants them either added to the master keyring or in a trusted.d keyring, yes.
[15:00] <infinity> pitti: ubuntu-keyring adds its own keys to the master keyring.  But shipping a snippet in trusted.d (like debian-archive-keyring does) might be better for ddebs.
[15:01] <infinity> pitti: Anyhow, I'm going to "fix" crash the naive and simple way for now, but I think shipping a proper keyring would be smart.  And we'll need to look at fixing stables too. :/
[15:01] <infinity> pitti: Or you could double-sign ddebs with old and new key, so the old one still works on stables.
[15:01] <infinity> pitti: Which might not be awful.
[15:03] <infinity> pitti: double-signing seems less evil than telling everyone to fix their stable machines that they manually configured.
[15:03] <infinity> pitti: And no risk of regression (ie: falling back to the old key) on >= xenial, since apt will outright reject the old key anyway.
[15:04] <infinity> pitti: Then we can work on doing it "right" in xenial, by shipping a key in the archive.
[15:06] <pitti> ok, that needs some reenginering (going from "just call gpg" to "call it with multiple configurable keys")
[15:07] <flexiondotorg> Wht has replaced libqt4-private-dev in Xenial?
[15:07] <flexiondotorg> I need some headers that package typically provides.
[15:13] <bdmurray> mpt: Do you have a moment to discuss that user page in the error tracker?
[15:17] <nacc> flexiondotorg: per the changelog, debian 4:4.8.7+dfsg-1
[15:18] <nacc> flexiondotorg: "  * Remove libqt4-private-dev. The only package using it is gammaray (#763852)
[15:18] <nacc>     which at the moment of this writing has it fixed in it's repo."
[15:18] <flexiondotorg> nacc, Thanks. Well, that's dissapointing :-(
[15:21] <bdmurray> mpt: Well, I'm happy to change labels of columns and reorder them - just let me know.
[15:22] <mpt> bdmurray, sure
[15:22] <mpt> bdmurray, what did you mean by “Recorded”?
[15:22] <bdmurray> " I took "Recorded" to mean the time that the server received them and "Occurred" to mean when the crash actually happened on the client."
[15:23] <bdmurray> mpt: so recorded in the database
[15:24] <mpt> Ah, I see
[15:24] <mpt> So you were thinking in terms of the database, I was thinking in terms of the client
[15:24] <cking> pitti, i've got another update of stress-ng i'd like to sync to Xenial under a FFe,  bug 1560065,  I was wondering if you could eyeball it
[15:24] <cjwatson> pitti: It's hopefully easily reinventable, but just in case, lp:ubuntu-archive-publishing's code for doing this isn't too impenetrable
[15:24] <pitti> cking: I have zero concern about getting new stress-ng versions
[15:24] <cjwatson> (Since it doesn't bother with the "configurable" bit)
[15:25] <pitti> cking: responded for the records
[15:25] <mpt> bdmurray, so how about “Occurred” and “Sent”? Would that be less ambiguous?
[15:25] <cking> ppisati, ok, shall I just sync it in then? ;-)
[15:26] <cking> done
[15:26] <bdmurray> mpt: my issue with sent was the report could be sent multiple times and if something was wrong with the database it wouldn't get recorded / received.
[15:27] <mpt> bdmurray, ok, “Occurred” and “Received”? :-)
[15:27] <bdmurray> mpt: also thinking about it the not occurred time is in UTC which really wouldn't be the sent time.
[15:27] <mpt> understood
[15:27] <mpt> I noticed the different time zones
[15:28] <bdmurray> mpt: sure, Occurred and Received, in which order and with which as a link?
[15:30] <mpt> bdmurray, chronological order of occurrence I think — that way, the one at the top will nearly always correspond to the last time the user clicked “Send” (unless the DB is read-only or something weird like that)
[15:31] <mpt> (the last time they clicked “Continue” with sending agreed to, I mean)
[15:33] <bdmurray> mpt: okay, thanks!
[15:33] <mpt> you’re welcome, thanks for indulging me :-)
[15:42] <mpt> bdmurray, …I just noticed that I had previously written “Error reports should be listed in the order they were received”, but I can’t remember why I did
[15:43] <mpt> bdmurray, what would happen if your system clock was accidentally set to the year 2028 when you submitted an error report? Would it sit at the top of the list for 12 years?
[15:48] <nacc> slangasek: LP: #1560092 filed, with debdiff that passes the testsuite here
[15:48] <bdmurray> mpt: I have it sorting by received in the database so the system clock being wrong wouldn't matter.
[15:50] <mpt> Ok, so I was wrong about “chronological order of occurrence” above. I’ll leave that sentence untouched. :-)
[15:57] <nacc> Pharaoh_Atem: https://bugs.php.net/bug.php?id=71870, just got fixed yesterday :)
[16:00] <infinity> Odd_Bloke: Have you tried a powerpc cloud image with the -14 kernel yet?
[16:00] <Odd_Bloke> infinity: Not yet, no.
[16:00] <infinity> Odd_Bloke: Were those manual builds, or automated?
[16:01] <infinity> Odd_Bloke: If the latter, can I get a pointer to one that might work, if the former, want to spin a fresh one?
[16:06] <Odd_Bloke> infinity: Manual; I'll (probably) have to rebase my livecd-rootfs changes on top of what's in place now (which has had a bit of a refactor); I'll try to have something for (your) tomorrow morning.
[16:08] <infinity> Odd_Bloke: Sure.  No huge rush.  Would just love to have this resolved by xenial release, so we can drop the P7 machines off a cliff.
[16:08] <infinity> (or mail them back to IBM)
[16:38] <pitti> meh, it seems I somehow broke ddebs.u.c. :(
[16:39]  * pitti files an RT, perhaps we happen to have a backup
[16:40] <infinity> pitti: ...?
[16:40] <infinity> pitti: Did you wipe out your archive?
[16:40] <pitti> it seems trusty's indexes only have those packages which have the same version in xenial
[16:40] <infinity> Ouch.
[16:40] <pitti> Laney | pitti: laney@nightingale> for r in trusty xenial; do echo -n "${r}: "; GET http://ddebs.ubuntu.com/dists/${r}/main/binary-amd64/Packages | grep-dctrl -c .; done
[16:40] <pitti> Laney | trusty: 121
[16:40] <pitti> Laney | xenial: 3021
[16:40] <infinity> That seems ungood.
[16:40] <pitti> doubleplusso
[16:41] <infinity> Is the pool also empty, or just the indexes?
[16:41] <pitti> the pool (otehrwise it would not be a big problem)
[16:41] <infinity> Ugh.
[16:41] <infinity> Not sure if IS backs that up.  I guess you'll find out. :(
[16:41] <Laney> :(
[16:42] <infinity> We can reconstruct anything post-ddebs-in-librarian, but you may be SOL for history.
[16:42] <infinity> I hope I'm wrong.
[16:42] <infinity> But it was only a matter of time before the bubblegum slipped off that shoestring.
[16:44] <cjwatson> Unfortunately ddebs in librarian postdates trusty release.
[16:44] <infinity> cjwatson: Indeed.
[16:45] <infinity> But, hey, new LTS is upon us, if there's no backup, we can just fling our hands in the air, scream a collective "meh" and carry on knowing that xenial is debuggable. :P
[16:45] <infinity> It also presents an elegant solution to the "what do we do about all these loose ddebs with no strong relation to build records?" problem.
[16:46] <infinity> Which is, well.  Nothing.  Cause they're gone.
[16:46] <infinity> (silver lining anyone?)
[16:46] <dobey> hmm, what happened to gccgo on ppc archs in xenial?
[16:46] <cjwatson> "elegant"
[16:46] <infinity> cjwatson: :)
[16:47] <cjwatson> http://paste.ubuntu.com/15465001/ <- that looks promising to me though.
[16:48] <cjwatson> suggests that that whole tree is backed up.
[16:48] <infinity> Ah-ha.  It does indeed.
[16:48] <pitti> wow
[16:48] <cjwatson> so a full recovery should be possible
[16:48] <infinity> pitti: Hit #is-outage and get them to freeze the backups in time ASAFP.
[16:48] <infinity> pitti: Cause if that's backing up with --delete, it's only a matter of time before the backup also goes poof.
[16:49] <infinity> (note "snapshot_mode: none")
[16:49] <nacc> dobey: i believe it's just go now?
[16:49] <infinity> pitti: This is too urgent for a ticket.
[16:49] <nacc> mwhudson: --^ do you have the answer to dobey's question?
[16:50] <dobey> nacc: https://launchpadlibrarian.net/249463768/buildlog_ubuntu-xenial-ppc64el.pay-service_15.10+16.04.20160321-0ubuntu1_BUILDING.txt.gz
[16:50] <cjwatson> turku defaults to retaining five days, I believe
[16:50] <dobey> nacc: "go: not found" doesn't sound like "it's just go now" :)
[16:50] <nacc> dobey: i meant based upon my reading of the logs of the channel from last week :)
[16:50] <cjwatson> ah, yes, but maybe not with snapshot_mode none
[16:50] <nacc> dobey: it's "supposed" to be ? :)
[16:51] <pitti> apparently I triggered a but when I told it to regenerate all indexes for the new gpg key
[16:51] <nacc> dobey: looking at my logs, either stgraber or mwhudson might have the context ...
[16:51] <pitti> s/but/bug/
[16:52] <infinity> cjwatson: I'm not sure how that key is interpreted, to be fair, but the naive interpretation would be "oh shit".
[16:52] <infinity> cjwatson: (And a perfectly reasonable default for a backup of a deb archive...)
[16:52] <cjwatson> Quite.
[16:54] <nacc> slangasek: i believe we talked about this previously, but if Debian has/will be releasing a new 7.0.4-X, are you ok with merging to that (as it includes the backports of a few bugfixes), or would you rather i backport those directly to our current -X in ubuntu?
[17:00] <zequence> We're having some problems with our seeds (Ubuntu Studio). We've blacklisted a few unity packages, such as unity-control-center, as you can see here http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.xenial/view/head:/blacklist.
[17:01] <zequence> ..but, we are still getting them on our ISO
[17:01] <cjwatson> Blacklisting isn't generally what you want.
[17:01] <zequence> Ok
[17:01] <cjwatson> Stop trying to use it. :-)
[17:02] <cjwatson> You need to arrange for apt to resolve alternative dependencies the way you want.
[17:02] <cjwatson> This normally involves ensuring that suitable alternatives are in the innermost possible seed whose expansion contains any of the packages with the alternative dependencies.
[17:02] <cjwatson> This can be a bit subtle and usually requires poring over germinate output in some detail.
[17:03] <zequence> cjwatson: Does it have to do with the order of seeds in the STRUCTURE file?
[17:03] <cjwatson> Yes.
[17:03] <cjwatson> Well, sort of.
[17:03] <cjwatson> It has more to do with their inheritance structure.
[17:03] <zequence> Right
[17:04] <cjwatson> The reason seed-level blacklisting isn't what you want is that apt doesn't know anything about it.  At best it might cause an image build to fail or something as a circuit-breaker.
[17:14] <zequence> cjwatson: Thanks. Seems I have a lead. lighdm pulls in unity-greeter, which we have an alternative for
[18:24] <barry> @pilot in
[18:25] <infinity> pitti: Do you backport postgresql-common to old releases ever, or if I change it for xenial, can I just not worry about <= xenial legacy codepaths?
[18:26] <pitti> infinity: yes, it regularly gets auto-backported on apt.postgresql.org
[18:27] <infinity> pitti: Right, lecagy codepath it is, then.  That's easy enough anyway.
[18:27] <pitti> infinity: and we keep it in sync, so if you change it for xenial we'll have to make that compatible with other D/U releases somehow
[18:27] <showaz> bug in mlmmj deb (package) "/usr/bin/mlmmj-recieve" and "/usr/bin/mlmmj-recieve" (no manual entry for mlmmj-receive)
[18:27] <showaz> bin dublicate filename bug.
[18:27] <infinity> pitti: Already in hand.  Don't worry about it.
[18:28] <infinity> pitti: If it supports precise trusty vivid wily xenial, is that good enough, or do you backport for EOL releases too?
[18:30] <pitti> infinity: nope, p/t/w/x is fine
[18:30] <pitti> (and jessie/stretch/unstable of course)
[18:31]  * pitti waves good night
[18:33] <nacc> caribou: would you be able to review LP: #1552983 ? fairly trivial merge for logwatch
[18:33] <infinity> pitti: Sec, don't run away yet.
[18:38] <infinity> pitti: Still there? :P
[18:38]  * infinity guesses he ran fast.
[18:38]  * flexiondotorg sees dust.
[18:38] <ogra_> he didnt run .. he waved away :)
[18:39] <cjwatson> showaz: as far as I can see mlmmj-recieve is the one without a manual entry, not mlmmj-receive, and since "recieve" is a misspelling that seems OK
[18:40] <cjwatson> showaz: though this is version-dependent.  anyway, reporting bugs on IRC is not useful, bug reports go to Launchpad
[18:40] <showaz> cjwatson:  docs only "mlmmj-receive" http://mlmmj.org/documentation/
[18:40] <cjwatson> showaz: good!  ignore mlmmj-recieve, looks like it's just there for backward compat
[18:40] <cjwatson> no doubt a historical mistake
[19:23] <momken> nickserv identify digitsm
[19:23] <Snow-Man> …
[19:23] <Snow-Man> try again
[19:23] <sarnold> momken: oops :)
[19:23] <Snow-Man> and change your pw
[19:23] <sarnold> preferably something a bit stronger, too
[19:24] <dobey> like 12345
[19:24] <momken> it's not my password
[19:24] <Snow-Man> maybe Vu~W-f]zvOzY|57GGSMLe<c;0
[19:24] <Snow-Man> :D
[19:27] <dobey> your password must be between 8-24 characters, and match the regex [A-Za-z0-9]+
[19:32] <Snow-Man> it's the websites where the 'change password' page will accept nearly anything, but the 'login' page doesn't work with certain characters that kills me
[19:37] <flexiondotorg> cjwatson, Just interested in how your wrangling is going with apt changes is going?
[19:47] <rcj> arges, Do you have time to review a pending upload for SRU in bug #1559307
[19:48] <arges> rcj: in a bit
[19:48] <rcj> arges, thank you
[19:52] <slangasek> pitti: gdnsd's i386 autopkgtest failure is curious; it's failing to install the package because it wants to start a systemd unit, which will fail if e.g. there's already a dns server installed and running on the system.  Why do we not mask systemd services as part of autopkgtests (policy-rc.d)?
[19:54] <arges> rcj: is the xenial task for walinuxagent is fixed?
[19:55] <arges> removing the second is
[19:55] <rcj> arges, it's in xenial already
[19:55] <rcj> been there for a bit
[19:55] <rcj> sorry
[20:08] <pitti> infinity: back for a bit
[20:09] <infinity> pitti: Too late, I uploaded. :)
[20:09] <doko> infinity, fyi, https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=2.23;users=debian-glibc@lists.debian.org
[20:09] <infinity> pitti: But do check the postgresql-common diff and grab it for Debian.
[20:09] <pitti> slangasek: err no, that would be entirely wrong -- the point of autopkgtests is to check that a package works, so not starting their services would certainly (for some packages)/hopefully (for many) break their tests
[20:10] <slangasek> pitti: hmm, well, ok.  what do you think we should do with gdnsd, then?  Should the package conflict with e.g. dnsmasq?
[20:11] <infinity> doko: Pretty much all of those seem to be fallout from https://sourceware.org/bugzilla/show_bug.cgi?id=19439
[20:11] <infinity> doko: And I think they probably all point to their upstreams being wrong, not glibc.  But will have to go through and fix them all.
[20:11] <pitti> slangasek: if that's what it's conflicting with, yes; but I suppose that should rather be some C/R/P: dhcp-server virtual package or so?
[20:11] <slangasek> pitti: dns server, not dhcp server
[20:12] <pitti> right, a simple apt-get install gdnsd fails in that manner
[20:12] <pitti> so, this spotted a packaging bug
[20:12] <pitti> gdnsd[1745]: Failed to bind() TCP DNS socket to 0.0.
[20:12] <pitti> question is why -- dnsmasq isn't even installed
[20:13] <pitti> (and we don't install it by default, only -base)
[20:13] <infinity> pitti: The follow-up question is why anything's bound to that on your adt VM.
[20:13] <slangasek> we don't, as a rule, require packages to conflict with one another due to trying to provide services on the same port
[20:13] <slangasek> oh, you see that failure even without dnsmasq?
[20:13] <pitti> tcp        0      0 10.0.3.1:53             0.0.0.0:*               LISTEN      901/dnsmasq
[20:13] <pitti> hm, what's that
[20:13] <infinity> lsof -i TCP
[20:14] <pitti> ah, dnsmasq is running, owned by lxc-dns
[20:14] <pitti> ah, of course! we install lxc by default now
[20:14] <pitti> lxc-common in particualr
[20:14] <infinity> "we" do?
[20:14] <pitti> cloud images do
[20:14] <infinity> Only in cloud-image/server.
[20:14] <pitti> they ship all sorts of ... unnecessary stuff these days
[20:14] <infinity> Yeah, don't you already remove a bunch of cloud-image stuff we don't want in adt images? :)
[20:15] <pitti> yeah, I do
[20:15] <pitti> except on lcy01
[20:15] <pitti> as building images is broken there
[20:15] <pitti> and it recently started failing on lgw01 as well (which is in some sort of semi-broken state)
[20:15] <infinity> I find "apt-get purge server^ && apt-get --purge autoremove" works well.
[20:15] <pitti> so before, depending on whether you ran on a minimal adt image or a standard cloud iamge it would pass or fail
[20:16] <slangasek> infinity: pro tip, 'apt autoremove --purge server^'
[20:16] <infinity> Or that.
[20:16] <pitti> so I guess I'll add the purging of lxc/lxd to the setup commands again
[20:16] <pitti> it'll slow down every test, but avoid this
[20:16] <pitti> however, this just papers over the fact that the package still fails to install on a default server/cloud install
[20:17] <infinity> Any dns server will.
[20:17] <slangasek> pitti: again, policy doesn't expect packages to conflict with other implementors of a network service just because they might want to share the same port
[20:17] <slangasek> this definitely isn't gdnsd-specific
[20:17] <infinity> I'm inclined to think it's a bit of a bug that our default cloud/server install now binds to that port.
[20:17] <infinity> I hear people like to run DNS servers on servers.
[20:17] <pitti> well, it can be fixed either way (not make postinst fail if the port is taken, or conflict to other dns servers)
[20:18] <nacc> infinity: pitti: i can take it as an action to talk to the server team about it :)
[20:18] <infinity> nacc: Please do.
[20:18] <nacc> yep
[20:18] <infinity> pitti: I don't think packaging needs to be sorted for force conflicts all over, but I think cloud/server images binding to TCP:53 out of the box is a massive bug.
[20:19] <pitti> well, if you want lxc-net to work out of the box, you have to install a DHCP server
[20:19] <infinity> DNS, you mean.
[20:20] <pitti> but indeed it sucks a bit that you have to choose between "run a DNS server" and "use LXC"
[20:20] <pitti> infinity: henceforth I'll just call it D* :)
[20:20] <infinity> Surely, the solution is to only bind to TCP:53 on the lxc bridge.
[20:20] <infinity> Which shouldn't conflict with running a real DNS server on the host.
[20:20] <pitti> NMICT
[20:20] <pitti> infinity: unless that tries to bind on all interfaces?
[20:22] <pitti> hmm, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/g/gdnsd/20160320_184317@/log.gz actually *did* run on an adt image
[20:22] <pitti> ah, so apparently apt-get purge --auto-remove lxc does not remove lxc-common any more?!
[20:23] <slangasek> yes, if lxc-net's dnsmasq was bound to the lxc bridge, another server coming along and binding to 0.0.0.0 should DTRT
[20:23] <pitti> ah, lxc1 now also depends on that, I guess I need to add  to my ever-increasing purge list :)
[20:23] <pitti> slangasek: that sounds good
[20:24] <slangasek> though I'm not sure if the lxc dnsmasq running only on the bridge IP is what's expected?  questions of resolvconf integration
[20:24] <slangasek> infinity: fwiw building valgrind from svn trunk doesn't get me anything that works any better
[20:24] <smoser> slangasek, so http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/view/head:/cloud-image
[20:24] <infinity> slangasek: Fun.
[20:24] <smoser> has ubuntu-snappy
[20:24] <pitti> slangasek: oh, how does that integrate with resolvconf?
[20:24] <slangasek> now going to double-check whether this is a toolchain problem (rebuild current glibc with xenial)
[20:25] <smoser> why is that not installed in image ?
[20:25] <dobey> mwhudson: around?
[20:25] <infinity> smoser: Because ubuntu-snappy is in universe.
[20:25] <pitti> ok, purging lxc-common does the trick
[20:25] <infinity> smoser: So germinate will cull it out of the results as an unknown package.
[20:25] <smoser> i figured it would go in and create a component mismatch
[20:25] <smoser> ok.
[20:26] <smoser> :-(
[20:26] <slangasek> smoser: it's listed in component-mismatches
[20:26] <slangasek> but until it's in main it doesn't go on the image
[20:26] <slangasek> I've been picking away at the MIR from the archive side over the past couple of days; ubuntu-snappy itself might be ready to go in now, I can look at that today
[20:26] <smoser> i expected the component mismatch, but thought it let it in and warn rather than ignore it.
[20:26] <pitti> smoser: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg has a nice graph of it, FYI
[20:26] <smoser> ok. thank you all. so the other question related then, pitti hinted at
[20:27] <smoser> should we put 'ubuntu-server' into each of those seeds (cloud-image and server)
[20:27] <infinity> No.
[20:27] <infinity> Well, I put it in server already.
[20:27] <infinity> Didn't I?
[20:27] <infinity> Yeah, I did.
[20:27] <hallyn> pitti: havne't read the whole backlog, but fwiw this week or next lxc-net should be removed from the seed again i think;
[20:28] <hallyn> lxd will stop depending on it, and so it should get dropped automatically
[20:28] <hallyn> at least that's my understanding
[20:28] <pitti> hallyn: lxc-common you mean?
[20:28] <smoser> infinity, yeah, you did.
[20:28] <smoser> i will add it now to cloud-image as it is desired ther also
[20:29] <hallyn> pitti: that i'm not sure
[20:29] <hallyn> pitti: but lxc1
[20:29] <hallyn> which has the lxc-net init job
[20:29] <pitti> hallyn: but I figure lxc and lxd actually do need lxc-net (i. e. a bridge with DHCP server) to work reasonably
[20:29] <hallyn> lxd will stop using lxcbr0 so it won't be needed any more
[20:29] <hallyn> no, lxd will not.
[20:30] <pitti> hallyn: oh, will the lxd-daemon have some builtin DHCP/DNS server then?
[20:31] <hallyn> i think ipv6 only by default
[20:32] <slangasek> nacc: rather than passing lots of flags to apt-cache rdepends, I bet you want to learn about grep-dctrl which has much more powerful filtering capabilities
[20:35] <pitti> slangasek, hallyn: hmm, lxc-net already uses --interface=lxcbr0 and listens on 10.0.3.1:53 only
[20:36] <pitti> so this doesn't help for things that bind on 0.0.0.0
[20:37] <slangasek> pitti: ah, you're right - I was looking at the wrong column in netstat before
[20:37] <nacc> slangasek: yep, sorry, what i meant wsa that `reverse-depends` does a (albeit slower) more accurate job of what i need
[20:38] <nacc> slangasek: but yeah, grep-dctrl is also going to be handy as i trim this down
[20:38] <slangasek> pitti: and if I compare with bind9, bind9 binds to each available IP individually, so that tells us nothing ;)
[20:40] <pitti> so, tomorrow's auto-built adt images should not have lxc1 any more
[20:41] <pitti> which should make that test work again (but it's still kinda papering over)
[20:44] <hallyn> and why does lxc1 make the test fail?
[20:45] <infinity> hallyn: It's a test for a dns server that fails to start because lxc depends on dnsmasq, which binds to a port the dns server kinda wants.
[20:50] <TJ-> shouldn't dnsmasq be using "--bind-interfaces" to 'drop' those interfaces it isn't interested in?
[20:50] <doko> xnox, pitti: ping on cmake
[20:50] <doko> see email
[20:51] <stgraber> note that the plan is to transition to lxdbr0 over the next week or so, that bridge will be ipv6 link-local only and will not have a dnsmasq server running against it
[20:51] <infinity> stgraber: Okay, that's promising.
[20:51] <stgraber> TJ-: the LXC dnsmasq absolutely does that, it only binds port 53 on the lxcbr0 interface, the problem is that all the other DNS servers in the archive assume they can bind port 53 on all interfaces which doesn't quite work when you have something bind one of the others
[20:51] <pitti> hallyn: it's an actual problem with the package -- apt-get install gdnsd on a cloud image fails; it's less clear whose fault that is
[20:52] <infinity> stgraber: How do guests get IPv4 connectivity?
[20:52] <stgraber> infinity: the guest won't have any connectivity by default except http through a minimal proxy
[20:52] <stgraber> infinity: it will then be up to the local admin to run "dpkg-reconfigure lxd" to configure lxdbr0 with some proper connectivity
[20:52] <infinity> Fair enough.
[20:52] <TJ-> stgraber: Ahhh, the inverse issue. Although I thought binds to 0.0.0.0 would only bind the 'free' interfaces for the port
[20:53] <stgraber> TJ-: sure doesn't, bind to 0.0.0.0 requires that the port is free on all interfaces :)
[20:53] <infinity> TJ-: slangasek and I thought the same thing.  Apparently we're wrong. :P
[20:53] <slangasek> I'm guessing that's a kernel configurable thing
[20:53] <slangasek> and/or a socket configurable thing
[20:53] <TJ-> I'm sure I did just that earlier today with multiple ncat instances on the same port on different interfaces.... goes off to check
[20:53] <infinity> Maybe.  Though, the current behaviour is certainly more deterministic.
[20:54] <infinity> "maybe-bind()" isn't exactly debuggable.
[20:54] <nacc> slangasek: i'm going through the deps for the pkgs mentioned in 1547183, looking to rebuild them as best i can. I'm trying to figure out if maybe for some that we don't run tests for, we could now (at least as autopkgtests, mabye during build too)
[20:54] <hallyn> pitti: ...  i thought we had it so that installing lxc did not require full dnsmasq.
[20:55] <pitti> stgraber: hm, that sounds like a step backwards for "just works"?
[20:55] <pitti> hallyn: it only installs/uses dnsmasq-base, so dnsmasq's own service doesn't start indeed; but lxc-net still launches lxc-net
[20:55] <hallyn> which only listens on lxcbr0's port 53.
[20:56] <hallyn> so if anyone wants to listen on that, it's the bad actor
[20:56] <pitti> and this is correct from LXC's perspective, just as listening on all interface is reasonably plausible from gdnsd's perspective -- these just don't work togethe r:/
[20:56] <hallyn> why is htat reasonable for gdnsd?
[20:56] <pitti> hallyn: yeah, I tend to agree and blame gdnsd too
[20:56] <TJ-> yes; i have multiple processes on the same port on different interfaces.
[20:56] <pitti> it shoudl be content to bind on "some" interfaces in the default install
[20:56] <hallyn> i agree i'm worried about lxdbr0 becoming more work for ppl,
[20:56] <doko> TJ-, are you still working on the openjdk backports?
[20:57] <pitti> or not fail package install even if it can't bind on any, cf. slangasek's "not required by policy to have packages conflicting on port resources"
[20:57] <hallyn> maybe we'll push more ppl to setting up ipv6 :)
[20:57] <TJ-> ahhh, no, the script is pulling out specific IP address to bind on, not 0.0.0.0
[20:57] <pitti> hallyn: well, ipv4, ipv6, you still need a DNS server, no?
[20:57] <TJ-> doko: I've not touched it since we last talked as in, I didn't find any regression for my use cases with Eclipse, Tomcat
[20:58] <pitti> and dropping ipv4 in containers still seems a bit premature
[20:58] <pitti> as much as I like/use IPv6, it doesn't fully replace ipv4 yet
[20:58] <TJ-> makes routing a lot easier though :)
[20:59] <stgraber> pitti: it is a step backward in usability, yes
[20:59] <stgraber> pitti: unfortunately it's the only way we can fix the installation of other DNS servers and prevent accidental subnet masking issues when LXD is installed by default everywhere
[20:59] <TJ-> doko: but I've been on 16.04/15.10 for a while now so not used that build recently
[21:00] <pitti> stgraber: hm, a shame -- I'd rather make the .services conflict..
[21:00] <stgraber> pitti: I really wish we'd made that change early in the cycle but unfortunately it took quite a while to get all images to work when on a link-local only kind of network... anyway, it's the last thing on my todo for this cycle but it's something we do need to sort out before the LTS
[21:01] <stgraber> pitti: yeah, for the DNS part we could have done something like that, though even then there are a whole bunch of packages using dnsmasq-base that will screw us over as they don't use systemd units. But ulitmately the main reason behind the change we're working on now is the subnet masking issue
[21:02] <pitti> doko: cmake> well, aren't you the first one to complain if new stuff causes massive FTBFS? :-)
[21:02] <mwhudson> dobey: am no
[21:02] <mwhudson> w
[21:02] <stgraber> pitti: that is, we do have logic to use a subnet which your machine itself isn't using, but that's not to say that the subnet we're picking isn't the one that your DNS server or some other network service is using
[21:02] <pitti> doko: I have no idea how prone it is to cause problems, but I guess if someone wants to update it they should at least do a rebuildl test
[21:02] <stgraber> pitti: and since we can only inspect what's directly attached to your system (routing table) and not what's behind your default gateway, we're kinda stuck
[21:03] <pitti> stgraber: hard to believe that after all this years of virtualization one can't use some "private routing namespace" or something such :)
[21:03] <stgraber> pitti: so that's why sabdfl asked us to not have any IP configuration by default, just use IPv6 link-local and get as good an experience as we can with that until the user provides chooses something sane
[21:04] <dobey> mwhudson: hi! i'm having some trouble with go on xenial powerpc/ppc64el now
[21:04] <pitti> stgraber: well, I guess as long as there's some simple way to enable it (call /usr/share/lxc/enable-bridge or whatever), it's still not too bad
[21:04] <mwhudson> dobey: oh right, you are being hit by the move to coinstallable go versions being half done i think
[21:04] <mwhudson> dobey: ppc64el?
[21:04] <pitti> stgraber: or installing a package like lxc1 indeed
[21:04] <dobey> mwhudson: yeah
[21:04] <dobey> mwhudson: https://launchpadlibrarian.net/249488485/buildlog_ubuntu-xenial-ppc64el.pay-service_15.10+16.04.20160321.1-0ubuntu1_BUILDING.txt.gz
[21:04] <dobey> "go: not found"
[21:04] <mwhudson> blargh
[21:04] <stgraber> pitti: lxc1 will ship lxcbr0 as it always had, we won't be changing it. lxd will no longer use lxcbr0 but instead lxdbr0 which will be configured through debconf
[21:05] <mwhudson> dobey: does this build-depend on gccgo [ppc64el] or something?
[21:05] <stgraber> pitti: by default it'll come up as a link-local only bridge with a proxy running against it, but you can run dpkg-reconfigure to set its ipv4 and ipv6 config
[21:05] <dobey> mwhudson: but all the other archs where we use gccgo are still fine
[21:05] <pitti> stgraber: ah, which means that you can also enable dnsmasq in a config file
[21:05] <dobey> mwhudson: yes
[21:05] <mwhudson> dobey: er, we only use gccgo by default on powerpc now
[21:06] <mwhudson> dobey: change the package to b-d on all arches
[21:06] <mwhudson> errr
[21:06] <mwhudson> dobey: change the package to b-d on golang-go all arches
[21:06] <mwhudson> it'll ftbfs on powerpc for a while
[21:06] <dobey> mwhudson: won't that break on vivid though?
[21:06] <stgraber> pitti: yeah, our default will be to start dnsmasq only if an ipv4 or ipv6 subnet is set on the bridge, so that's why this whole thing won't be an issue once my change lands since default lxdbr0 will not have a running dnsmasq
[21:07] <mwhudson> dobey: are you telling me you actually care about the status of this package on ppc64el on vivid?
[21:07] <mwhudson> i mean, yes it will
[21:07] <infinity> dobey: The goal in debian/control shouldn't be to make a package build on every release ever.
[21:07] <mwhudson> but progress has to be possible
[21:07] <infinity> dobey: Surely, you have a mechanism to fork the packaging.
[21:08] <dobey> mwhudson: i'm telling you this is a package that we ship on the phone and yes the ubuntu "has to build on archs where it previously built successfully" policy
[21:08] <dobey> infinity: yes but i don't hate myseful enough to want to do that
[21:09] <infinity> dobey: As mwhudson says, progress must be possible.  We've made go stuff much less crap in xenial, but the result is you might have to fork packaging for backports.
[21:09] <mwhudson> dobey: maybe golang-go on vivid should depend on gccgo on ppc64el
[21:09] <mwhudson> which would be a change, of course
[21:09] <dobey> infinity: well it's not like this works on ppc even if it did build successfully; i can happily just make it not build there any more
[21:10] <mwhudson> dobey: that sounds like a pretty good solution tbh
[21:10] <infinity> dobey: You might be able to fudge it with something like "golang-go (>> xenial-version) [ppc64el] | gccgo [ppc64el]"
[21:10] <infinity> dobey: Er, drop it in xenial or vivid?
[21:10] <dobey> infinity: but that requires me to convince someone like you that we should remove the existing binaries from xenial and the phone overlay, for the archs where this doesn't work anyway
[21:10] <infinity> dobey: Really don't care about ppc64el in the vivid PPA.
[21:10] <dobey> infinity: well in the phone overlay, we don't care about actual vivid obviously
[21:11] <infinity> dobey: But "go is improved in xenial, let's drop the arch in xenial" would be silly.
[21:11] <dobey> infinity: well, people who can block my stuff landing there will complain
[21:12] <dobey> infinity: well, trying to support complining stuff on archs that it doesn't really work at runtime on anyway is probably more silly
[21:12] <infinity> dobey: Try "golang-go (>= 1.6) [ppc64el] | gccgo [ppc64el]" to keep the current state of affairs and make it backportable.
[21:13] <infinity> dobey: How do you know it doesn't work at runtime?
[21:13] <dobey> infinity: because a whole boatload of runtime dependencies aren't built on these archs
[21:14] <infinity> If that were true, it would never migrate.
[21:14] <dobey> it would only fail to migrate if something were trying to actually use it on those archs
[21:14] <infinity> ...?
[21:15] <infinity> No, if the package deps are unsatisfiable, britney will tell you to eff off.
[21:15] <dobey> there are no autopkgtests in anything that tries to perform the runtime work that fails
[21:15] <dobey> yeah, that's why the package deps are tweaked to not depend on the thing that isn't available, on those archs
[21:17] <dobey> ok, well i have to go now. i guess i'll try to hack around the golang-go/gccgo thing then too
[21:17] <dobey> so this will build again
[21:18] <dobey> later
[21:42] <slangasek> smoser: so the deal with ubuntu-snappy is that it has a direct build-dependency on golang-websocket, which has an incomplete MIR (LP: #1520689).  If I promote ubuntu-snappy now to get it on the images, the tradeoff is that the snappy team can no longer upload it
[21:43] <slangasek> I can pre-promote golang-websocket to main, but then it becomes a problem of tracking the outstanding MIR when it isn't on component-mismatches anymore
[21:43] <slangasek> or I can wait until the archive reorg changes land, which may be this week or it might be next week; then ubuntu-snappy will still be buildable without golang-websocket getting promoted
[21:43] <slangasek> or I can wait until the build-dep is sorted before promoting
[21:44] <slangasek> or I can promote it now and leave it unbuildable
[21:44] <slangasek> smoser: ^^ those are the options; option 1 is least-preferred from my POV, maybe you can discuss with the snappy team and decide which of the others is acceptable
[21:59] <cjwatson> flexiondotorg: for Debian imports, changes awaiting deployment and my expectation is that that'll be done within a day; for PPA signing, the change to make it work for newly-published archives is likewise pending deployment, and part of the change to let us bulk-re-sign existing PPAs is pending code review
[22:01] <cyphermox> nacc: I'm looking at bug 1544352 but it doesn't look like some of these packages can just get no-change rebuilds and php5->php
[22:08] <juliank> cjwatson: That sounds great :)
[22:09] <infinity> slangasek: Of course, regarding the snappy versus golang-foo thing above, it occurs to me that in static linking cases, germinate really should follow Built-Using and force us to support the thing we statically linked in.
[22:09] <infinity> slangasek: (ie: "wait for archive reorg" is a bit of a cop-out there)
[22:09] <infinity> slangasek: In that if we refuse to support golang-foo, I can't see how we can claim we support a package that statically links it.
[22:11] <slangasek> infinity: the germinate patch does implement support for Built-Using
[22:11] <infinity> slangasek: Kay.  In that case, archive reorg wouldn't fix the issue (assuming Built-Using is supported as I think it should be)
[22:11] <slangasek> which means the package would be buildable but there would still be a record in component-mismatches, which is what I care about
[22:12] <infinity> Ahh, fair.
[22:21] <flexiondotorg> cjwatson, Thanks for the update. Interesting stuff.
[22:29] <barry> @pilot out
[22:37] <nacc> cyphermox: you're probably right, some will need installation checking and such; although if they have tests, that list passed their tetss
[22:37] <nacc> tests, rather
[22:38] <nacc> cyphermox: oh, you didn't see the description
[22:38] <nacc> cyphermox: several seds need to be run
[22:39] <nacc> it's *almost* automatic :)
[22:39] <cyphermox> yes, several sed commands, and ideally it would probbly be best if the command was provided
[22:39] <cyphermox> tbh to me it looks very not automatic
[22:40] <nacc> cyphermox: it was provided, well, the regex i used were. I can provide a complete `find` line
[22:40] <nacc> cyphermox: i mean, i scripted it here :)
[22:40] <cyphermox> where?
[22:40] <nacc> on my machine, running an adt run against each
[22:40] <nacc> that's about all i can do w/o upload rights
[22:40] <cyphermox> well, almost all; you could file bugs and ask for sponsoring if the work is already done
[22:41] <cyphermox> but I'm looking at adminer, it needs changes in a couple places, and in some others it should *not* be a sed because then you'll have redundancies in debian/control Depends fields, for example
[22:41] <nacc> cyphermox: slangasek and i agreed filing many (~400) bugs was not necessary for the ones that are roughly automateable; but i can do that for this list if you think it's preferable
[22:42] <nacc> cyphermox: what redundancies?
[22:42] <slangasek> nacc: fwiw cyphermox and I were discussing this - I don't mind not filing separate bugs for each of them, but if you want automated conversion of these packages, please provide us the automation code you want run + details of any testing of the results
[22:42] <cyphermox> php | php, for instance
[22:42] <nacc> slangasek: yep, I can do that
[22:42] <cyphermox> because some packages mention php5 | php
[22:43] <nacc> cyphermox: i don't see how that will ahppen to adminer
[22:43] <slangasek> nacc: otherwise, if the "automation" is incomplete and should be captured as a debdiff, then there should be separate bugs for each
[22:43] <nacc> the result of the sed is
[22:43] <nacc> lite | php-pgsql
[22:43] <nacc> gah
[22:43] <cyphermox> nacc: this isn't adminer but I did see one instance
[22:43] <slangasek> cyphermox: well, dpkg-buildpackage is awfully smart these days, so php | php will be reduced :)
[22:43] <nacc> cyphermox: i'm happy to clean those up as i encounter them ... they didn't lead to an error, per se
[22:43] <cyphermox> slangasek: but it won't change the actual debian/control file uploaded
[22:44] <nacc> cyphermox: i am taking what you say to heart
[22:44] <nacc> slangasek: i can provide debdiffs for these that needed the sed
[22:44] <slangasek> cyphermox: true, it won't, but at runtime it'll be fine
[22:44] <nacc> it will be a better review anyways, as a result
[22:44] <cyphermox> I mean, the list looks otherwise pretty good, and the work isn't complicated; it just takes a bit to go through it and upload each
[22:44] <nacc> cyphermox: admittedly, it's just a matter of time
[22:44] <cyphermox> (I already download all the source)
[22:44] <cyphermox> *downloaded
[22:45] <nacc> and there's still about ~100 or so packages after that that did build w/ some tweaking to the sed and then another ~100 that need manual remediation
[22:45] <nacc> we package a lot of *old* php stuff :)
[22:45] <nacc> it's unfortunate, what with composer being the upstream-prescribed (and only approved) way to install things, often
[22:46] <cyphermox> a couple things also ship apache config, we'll need to make sure those get changed too
[22:46] <slangasek> reminder, old and crufty stuff can also be removed if we don't think it's worth fixing
[22:46] <nacc> cyphermox: yep, that's one thing i needed to manually go back and fix in some packages
[22:46] <nacc> slangasek: agreed, and several of them have been superseded int eh archive already, we just carry two versions
[22:47] <nacc> one of whcih might be EOL at this point :)
[22:47] <nacc> cyphermox: slangasek: thanks for the feedback. I'll try to be clearer in the bugs (that one in particular, I filed when I first started looking at PHP7, so I should have amended it since then).
[22:47] <cyphermox> I fixed up a simple tracker config for this, I'll push my code
[22:49] <nacc> cyphermox: is a tracker like what debian has for following the php7 migration? there's a page that reports any package that right now depends on a src:php5 package?
[22:50] <cyphermox> yes
[22:50] <nacc> awesome, thanks! i was going to ask if we had something similar, but had forgotten :)
[22:51] <cyphermox> it's kind of naive; just checking if it Depends or Build-Depends on something called php5.*
[22:51] <nacc> cyphermox: i mean, that's basically what my scripting is doing :) i'm ok with naive for now
[22:52] <nacc> slangasek: sigh, i don't know why php-zeta-console-tools failed. It didn't emit any output that indicates what actually failed?
[22:53] <nacc> slangasek: and it passed all tests during the build and in my systems' autopkgtests (running it again now to be sure)
[22:53] <nacc> slangasek: confirmed, in my adt-virt-lxc run, all 744 tests passed
[22:54] <nacc> slangasek: something seems off with the log: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/php-zeta-console-tools/20160321_202400@/log.gz
[22:55] <nacc> i think you should see "test phpunit: [----
[22:55] <nacc> followed by a patching line
[22:55] <nacc> then PHPUnit output
[22:55] <nacc> then another patching line (as the patch is reverted)
[22:55] <nacc> then "test phpunit -----]
[23:21] <slangasek> nacc: I can reproduce the php-zeta-console-tools autopkgtest failure here
[23:22] <slangasek> nacc: in fact, phpunit does nothing but exit 255 for me here
[23:23] <nacc> slangasek: so confused. i literally just ran it here; and it clearly ran succesfully during the build
[23:23] <nacc> slangasek: from which directory location are you running it?
[23:24] <slangasek> nacc: what is supposed to provide ezc/ConsoleTools/autoload.php?  Because I don't see that file under /usr/share/php/ on my system.  Is this from a newer version of some package which is currently only in xenial-proposed?
[23:25] <slangasek> oh, maybe it comes from php-zeta-console-tools itself, and I should actually install the xenial-proposed version of the package I'm trying to test?
[23:25] <nacc> yeah, i htink that's the case
[23:26] <nacc> slangasek: and that's probably the issue, the d/t/control doesn't depend on itself?
[23:26] <slangasek> nacc: no, that's not the problem
[23:26] <slangasek> that's just the first error I hit locally, not necessarily the real problem on the autopkgtest infra
[23:27] <cyphermox> you could get a console in the autopkgtest environment to check exactly what fails in the infra
[23:27] <nacc> slangasek: ok, so if i don't build during my autopkgtest run, i see the same error now; but if i build, i don't.
[23:27] <nacc> let me see if i can see why
[23:28] <slangasek> nacc: ok, it's looking for /usr/share/php/ezc/Base/autoload.php, but there's no versioned dep on php-zeta-base
[23:28] <slangasek> well... there is a versioned dep, but the versioned dep doesn't ensure that file's existence
[23:28] <Umeaboy> In Xenial I see no menus when moving the cursor to the top bar.
[23:29] <Umeaboy> Is that expected?
[23:29] <Umeaboy> I know that it's a testing version of Ubuntu so no need to tell me that again.
[23:29] <Umeaboy> Just wondering how I can get it back without having to downgrade Ubuntu.
[23:29] <slangasek> nacc: upgrading php-zeta-base fixes it; so php-zeta-console-tools *should* have a versioned dep on php-zeta-base, I think?
[23:30] <nacc> slangasek: it does, though? on php-zeta-base >= 1.9-2~
[23:30] <cyphermox> Umeaboy: I know some apps didn't show me menus in unity; best is probably that you file a bug.
[23:30] <nacc> slangasek: or do you mean only certain version of php-zeta-base have the file?
[23:30] <slangasek> nacc: depends, not build-depends. the depends is on php-zeta-base (>= 1.8), php-zeta-base (<< 2~~) which is insufficiently strict
[23:30] <Umeaboy> And also...... when you translate "Add to Dash", do you also translate the name Dash?
[23:30] <Umeaboy> Just making sure.
[23:31] <cyphermox> I don't know
[23:31] <nacc> slangasek: ah! sorry
[23:31] <slangasek> nacc: 1.9-1 doesn't have it, maybe it only shows up when rebuilt with the php7 package toolchain?
[23:31] <Umeaboy> Anyone else that knows?
[23:31] <Umeaboy>  ../launcher/ApplicationLauncherIcon.cpp:717
[23:31] <cyphermox> Umeaboy: it might be better to ask about this on #ubuntu-unity
[23:31] <Umeaboy> is the location of it.
[23:31] <Umeaboy> OK.
[23:32] <cyphermox> Umeaboy: and/or compare with other languages
[23:33] <nacc> slangasek: so there should be a versioned dep on php-zeta-base, maybe on >= 1.9 ?
[23:33] <slangasek> nacc: no, >= 1.9 is *not* sufficiently strict.  The php-zeta-base in xenial is 1.9-1, and that package doesn't have the file we're after
[23:34] <slangasek> nacc: so if ezc/Base/autoload.php needs to be there for the package to work, it needs to be >= 1.9-2build1
[23:36] <slangasek> nacc: or possibly just 1.9-2 - it's not clear to me if this was a packaging change or a tooling change
[23:38] <slangasek> nacc: of course, 1.9-2 never built in Ubuntu, so either of those works the same for us - but it definitely needs to be >> 1.9-1
[23:38] <doko> nacc, slangasek: the last test rebuild showed up a lot of php related build failures. are these now resolved with the recent 7 changes?
[23:38] <slangasek> doko: they still need worked through; we're basically mid rebuild transition
[23:39] <slangasek> doko: things that build-depend on the standard php tooling, but depend on other extensions that are currently built for php5, probably FTBFS
[23:39] <doko> slangasek, ok, would like to start one more test rebuild once glibc migrates + outstanding debian syncs
[23:39] <slangasek> nacc: does my explanation for php-zeta-console-tools make sense? would you like me to plunk it in here, or do you want to send me a debdiff?
[23:41] <nacc> slangasek: yes, it makes sense, thank you for clarifying
[23:41] <nacc> slangasek: feel free to plunk :)
[23:43] <slangasek> nacc: done
[23:44] <nacc> slangasek: thanks! fwiw, i just got icinga to run (mostly) its own tests. The errors it's tripping now are because i don't have mysql setup in my container, but no syntax errors
[23:46] <slangasek> nacc: ok.  and I think I left questions for you on php-opencloud
[23:46] <nacc> slangasek: fyi, also, it's a packing chagne, i just tried building php-zeta-base 1.9-1 and 1.9-2 and only the latter has the file where expected
[23:47] <nacc> slangasek: yep, getting to that one too