/srv/irclogs.ubuntu.com/2016/03/21/#ubuntu-devel.txt

naccslangasek: Pharaoh_Atem: fyi: https://3v4l.org/uMrcs01:24
naccshows that the issue with zeta-console-tools test is an upstream thing, and probably something that is "expected", but shoudl be adjusted in their output01:24
Pharaoh_Atemnacc: cool01:30
cheryljhey 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?01:59
ubottubug 1556666 in Launchpad itself "PPA (In)Release files use SHA1 digests for GPG signature" [High,Fix committed] https://launchpad.net/bugs/155666601:59
cheryljinfinity ^^?02:00
=== juliank is now known as Guest79559
=== juliank_ is now known as juliank
infinitycherylj: It needs fixing on the LP end, nothing you can do about it.02:38
cheryljthanks, infinity02:40
cpaelzergood morning05:51
kickinz1Morning!06:52
pittiGood morning07:31
pittiMirv: landing-036 does not exist any more, I suppose this was taken care of already?07:31
pittislangasek: 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 somehow07:34
pittislangasek: but if you can reproduce it locally, that error doesn't seem to be too specific to the qemu params in scalingstack07:34
Mirvpitti: yes, we just forced QA:ing and publishing of it. no problem!07:34
pitticjwatson: will look into it, this is tracked in bug 155882307:35
ubottubug 1558823 in Ubuntu "ddebs.ubuntu.com gpg signatures use sha-1" [Undecided,New] https://launchpad.net/bugs/155882307:35
pittixnox: seems Stephane already approved your FFE07:37
pittislangasek: ah, I get the same thing in apport now apparently07:58
pittiFailed to connect to Mir: Failed to connect to server socket: No such file or directory07:58
pitti^ that?07:58
dholbachgood morning08:19
jamespagemorning all08:34
=== rhuddie_ is now known as rhuddie
cjwatsoncherylj: 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 bulk11:30
cjwatsonpitti: thanks11:31
cjwatsoncherylj: Note that it's technically a warning, not an error11:31
dasjoecking: #1527727 - I think Ned will release 0.6.5.6 early this week, the LLNL guys don't seem to work on weekends11:54
ckingdasjoe, 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 sure11:55
dasjoecking: 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 relevant11:59
ckingdasjoe, cool, thanks for that12:00
=== xavigarcia is now known as xavigarcia_lunch
dasjoecking: 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 17312:04
dasjoeI 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 it12:07
SharchoFYI: There doesn't seem to be any patches for GIT for CVE-2016-2324, CVE-2016‑2315 on Ubuntu 14.04 LTS12:14
ubottu** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2324)12:14
mdeslaurSharcho: It's being worked on12:14
Sharchomdeslaur: thanks12:15
dokoLaney: 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 glib12:27
Laneydoko: It's probably that de-duplicating thing12:34
Laneydoko: Copy glib-gettext.m4 from glib or remove the local copy12:34
flexiondotorgWhich team should I direct towards this bug? https://bugs.launchpad.net/ubuntu-mate/+bug/155924312:47
ubottuLaunchpad bug 1559243 in ubuntu-mate "Missing string translations for Ubuntu MATE flavour." [High,Triaged]12:47
cjwatsonflexiondotorg: installer team.  I'll have a look, I think I still remember how to do that12:48
flexiondotorgcjwatson, Thank you :-)12:48
Mirvthis 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:52
Mirv"has not been picked up by LP yet"12:53
smoserpitti, http://paste.ubuntu.com/15401586/ <-- were you going to upload that ?12:53
pittismoser: 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 up12:55
pittii. e. cloud-init in that case (according to systemd.special(7))12:55
smoseroh.12:55
smoserhm.. that was the second part of my question.12:55
smoseri dont necessarily think its the wrong way around though.12:56
pittiI didn't read that properly when we talked about this12:56
smosernetworking.service should want the network-pre.target to have been reached.12:56
smoseri'm sorry, i must have just misunderstood then. i can add Wants network-pre.target to cloud-init-local.service12:56
pittino worries, it wasn't clear last week when we talked about it12:57
smoserone other question.12:57
smoseryou can have multple 'Wants=' in a service12:58
smoseri think.12:58
smoserWants=other-thing112:58
smoserWants=other-thing212:58
smoserthat multiline syntax does work, rigth?12:58
smoseris 'Wants=other-thing1 other-thing2' preferred for any reason ?12:59
pittismoser: they are exactly identical13:00
pittiso just a matter of stylistic preference I guess13:01
pittimulti-line is nicer for patching or adding comments, but a bit more verbose13:01
smoserthats what i thought.13:02
smoserthanks.13:02
caribouxnox: FYI - LP: #156002413:05
ubottuLaunchpad bug 1560024 in s390-tools (Ubuntu) "/etc/kernel/postrm.d/zz-zipl fails when removing an old kernel" [Undecided,New] https://launchpad.net/bugs/156002413:05
=== xavigarcia_lunch is now known as xavigarcia
cjwatsonMirv: I explained that on ubuntu-devel recently.13:10
* Mirv reads13:18
cjwatsonflexiondotorg: Done; will require another upload to actually include localisations, so please remind us in a couple of weeks.13:22
flexiondotorgcjwatson, Thanks. But I can point translators at it now?13:29
cjwatsonflexiondotorg: It'll probably take a little while before it's available for translation on LP.  Check first13:36
cjwatsonflexiondotorg: (https://translations.launchpad.net/ubuntu/xenial/+source/gfxboot-theme-ubuntu/+pots/bootloader, pick random language, search for mate)13:38
slangasekpitti: 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 though14:06
ubottuLaunchpad bug 1559842 in glibc (Ubuntu Xenial) "SIGFPE in pthread_barrier_destroy in glibc 2.23" [Critical,Triaged] https://launchpad.net/bugs/155984214:06
pittislangasek: ah, thanks for the pointer! that means now that mesa is in it's worth retrying the failures?14:08
pittislangasek: although the glibc task of the above bug is still open, does this need a glibc fix too?14:08
pittislangasek: I tried to locally run apport against all of -proposed, and it seemed to work14:08
pitti(some 3 hours ago maybe)14:08
pitticjwatson: I suppose it's ok to use syncpackage --no-lp for the time being?14:09
slangasekpitti: yes, any of the autopkgtests that have regressed with glibc on amd64+i386 should be retried14:09
pittislangasek: ack, doing14:09
slangasekpitti: and the glibc task can be closed, I didn't clean that up before I went to bed14:10
pittiin fact, I retried a few already, and so did infinity14:10
slangasekyep14:10
slangasekpitti: hopefully not with --all-proposed though ;)14:10
pittiI might have done apport14:11
pittibut *shrug*, whatever makes them pass :)14:11
cjwatsonpitti: 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 today14:12
cjwatsonpitti: i.e. if it's not urgent it would be preferable to wait14:13
pitticjwatson: no, it's not; thanks14:13
infinitypitti: So, the apport test still fails, for slightly different reasons.  The rest seem to have been fixed by Steve's mesa.14:28
pittiinfinity: 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 now14:30
infinitypitti: 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
pittiAssertionError: 'no debug symbol package found for coreutils\n' != ''14:31
pittiinfinity: no, the only two failures are in backend_apt_dpkg14:31
pittisearch for ======14:31
pittithe xvfb message at the end is normal (just for debugging)14:32
pittinot sure what's up with coreutils' ddebs14:32
infinitypitti: Oh.14:33
infinitypitti: Tests with ddebs are busted because you need to re-sign ddebs.u.c with a less crap key, IIRC.14:33
pittiinfinity: I did this morning14:34
infinitypitti: Oh, so we should retry crash and see how it likes it?14:34
pittisee bug 155882314:34
ubottubug 1558823 in ddeb-retriever "ddebs.ubuntu.com gpg signatures use sha-1" [Medium,Fix released] https://launchpad.net/bugs/155882314:34
pittiinfinity: I didn't look at crash's regression yet, but if that was it it's worth retrying indeed14:34
infinitypitti: 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
infinitys/i./it./14:35
pittiinfinity: hmm, http://keyserver.ubuntu.com/pks/lookup?op=get&fingerprint=on&search=0xC8CAB6595FDFF622 exists now, but I can't say for how long already14:42
flexiondotorgI will be filling a needs packaging FFe in a bit. Can some just confirm I've got the version numbering correct?14:50
flexiondotorghttp://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/topmenu-qt/view/head:/debian/changelog14:50
flexiondotorgI realise the ~xenial1.0 suffix needs to be dropped.14:50
flexiondotorgThis package is not going into Debian, so I want the confirm I've got the -0ubuntu1 bit right.14:50
infinityflexiondotorg: -0ubuntu1 is correct for something where our upstream is ahead of Debian, yes.14:53
flexiondotorginfinity, Thanks. This package will be entirely absent from Debian.14:53
infinitypitti: crash's tests might be statically configured to pull the old key or something.14:55
* infinity looks.14:55
infinitypitti: Yeah, it is.14:56
pittiinfinity: hm, perhaps this should pull http://ddebs.ubuntu.com/dbgsym-release-key.asc instead?14:56
infinitypitti: Maybe.  What's the recommended way for people to get the key on live systems?14:57
infinitypitti: Should it perhaps be packaged instead, so there's a trusty path?14:57
infinitys/trusty/trust/14:57
pittiI updated the key ID on https://wiki.ubuntu.com/DebuggingProgramCrash this morning14:57
pittibut that won't magically fix people's scripts indeed14:58
pittiinfinity: hmm, we could put it into ubuntu-keyring14:58
infinitypitti: Yeah, in a split file, perhaps, the way debian-archive-keyring is now laid out.14:59
pittidoes merely adding it to /usr/share/keyrings/ actually helps? I thought apt would expect them in /etc/apt/trusted.gpg.d14:59
naccslangasek: 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 error14:59
infinitypitti: apt wants them either added to the master keyring or in a trusted.d keyring, yes.15:00
infinitypitti: 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:00
infinitypitti: 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
infinitypitti: Or you could double-sign ddebs with old and new key, so the old one still works on stables.15:01
infinitypitti: Which might not be awful.15:01
infinitypitti: double-signing seems less evil than telling everyone to fix their stable machines that they manually configured.15:03
infinitypitti: And no risk of regression (ie: falling back to the old key) on >= xenial, since apt will outright reject the old key anyway.15:03
infinitypitti: Then we can work on doing it "right" in xenial, by shipping a key in the archive.15:04
pittiok, that needs some reenginering (going from "just call gpg" to "call it with multiple configurable keys")15:06
flexiondotorgWht has replaced libqt4-private-dev in Xenial?15:07
flexiondotorgI need some headers that package typically provides.15:07
bdmurraympt: Do you have a moment to discuss that user page in the error tracker?15:13
naccflexiondotorg: per the changelog, debian 4:4.8.7+dfsg-115:17
naccflexiondotorg: "  * 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
flexiondotorgnacc, Thanks. Well, that's dissapointing :-(15:18
bdmurraympt: Well, I'm happy to change labels of columns and reorder them - just let me know.15:21
mptbdmurray, sure15:22
mptbdmurray, 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:22
bdmurraympt: so recorded in the database15:23
mptAh, I see15:24
mptSo you were thinking in terms of the database, I was thinking in terms of the client15:24
ckingpitti, 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 it15:24
ubottubug 1560065 in stress-ng (Ubuntu) "[FFE]: stress-ng: sync to 0.05.21 form 0.05.19" [Medium,In progress] https://launchpad.net/bugs/156006515:24
cjwatsonpitti: It's hopefully easily reinventable, but just in case, lp:ubuntu-archive-publishing's code for doing this isn't too impenetrable15:24
pitticking: I have zero concern about getting new stress-ng versions15:24
cjwatson(Since it doesn't bother with the "configurable" bit)15:24
pitticking: responded for the records15:25
mptbdmurray, so how about “Occurred” and “Sent”? Would that be less ambiguous?15:25
ckingppisati, ok, shall I just sync it in then? ;-)15:25
ckingdone15:26
bdmurraympt: 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:26
mptbdmurray, ok, “Occurred” and “Received”? :-)15:27
bdmurraympt: also thinking about it the not occurred time is in UTC which really wouldn't be the sent time.15:27
mptunderstood15:27
mptI noticed the different time zones15:27
bdmurraympt: sure, Occurred and Received, in which order and with which as a link?15:28
mptbdmurray, 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:30
mpt(the last time they clicked “Continue” with sending agreed to, I mean)15:31
bdmurraympt: okay, thanks!15:33
mptyou’re welcome, thanks for indulging me :-)15:33
mptbdmurray, …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 did15:42
mptbdmurray, 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:43
naccslangasek: LP: #1560092 filed, with debdiff that passes the testsuite here15:48
ubottuLaunchpad bug 1560092 in php-zeta-console-tools (Ubuntu) "Workaround PHP bug #71870" [Low,In progress] https://launchpad.net/bugs/156009215:48
bdmurraympt: I have it sorting by received in the database so the system clock being wrong wouldn't matter.15:48
mptOk, so I was wrong about “chronological order of occurrence” above. I’ll leave that sentence untouched. :-)15:50
=== roaksoax-afk is now known as roaksoax
naccPharaoh_Atem: https://bugs.php.net/bug.php?id=71870, just got fixed yesterday :)15:57
infinityOdd_Bloke: Have you tried a powerpc cloud image with the -14 kernel yet?16:00
Odd_Blokeinfinity: Not yet, no.16:00
infinityOdd_Bloke: Were those manual builds, or automated?16:00
infinityOdd_Bloke: If the latter, can I get a pointer to one that might work, if the former, want to spin a fresh one?16:01
Odd_Blokeinfinity: 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:06
infinityOdd_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:08
pittimeh, it seems I somehow broke ddebs.u.c. :(16:38
* pitti files an RT, perhaps we happen to have a backup16:39
infinitypitti: ...?16:40
infinitypitti: Did you wipe out your archive?16:40
pittiit seems trusty's indexes only have those packages which have the same version in xenial16:40
infinityOuch.16:40
pittiLaney | 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 .; done16:40
pittiLaney | trusty: 12116:40
pittiLaney | xenial: 302116:40
infinityThat seems ungood.16:40
pittidoubleplusso16:40
infinityIs the pool also empty, or just the indexes?16:41
pittithe pool (otehrwise it would not be a big problem)16:41
infinityUgh.16:41
infinityNot sure if IS backs that up.  I guess you'll find out. :(16:41
Laney:(16:41
infinityWe can reconstruct anything post-ddebs-in-librarian, but you may be SOL for history.16:42
infinityI hope I'm wrong.16:42
infinityBut it was only a matter of time before the bubblegum slipped off that shoestring.16:42
cjwatsonUnfortunately ddebs in librarian postdates trusty release.16:44
infinitycjwatson: Indeed.16:44
infinityBut, 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. :P16:45
infinityIt 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:45
infinityWhich is, well.  Nothing.  Cause they're gone.16:46
infinity(silver lining anyone?)16:46
dobeyhmm, what happened to gccgo on ppc archs in xenial?16:46
cjwatson"elegant"16:46
infinitycjwatson: :)16:46
cjwatsonhttp://paste.ubuntu.com/15465001/ <- that looks promising to me though.16:47
cjwatsonsuggests that that whole tree is backed up.16:48
infinityAh-ha.  It does indeed.16:48
pittiwow16:48
cjwatsonso a full recovery should be possible16:48
infinitypitti: Hit #is-outage and get them to freeze the backups in time ASAFP.16:48
infinitypitti: Cause if that's backing up with --delete, it's only a matter of time before the backup also goes poof.16:48
infinity(note "snapshot_mode: none")16:49
naccdobey: i believe it's just go now?16:49
infinitypitti: This is too urgent for a ticket.16:49
naccmwhudson: --^ do you have the answer to dobey's question?16:49
dobeynacc: https://launchpadlibrarian.net/249463768/buildlog_ubuntu-xenial-ppc64el.pay-service_15.10+16.04.20160321-0ubuntu1_BUILDING.txt.gz16:50
cjwatsonturku defaults to retaining five days, I believe16:50
dobeynacc: "go: not found" doesn't sound like "it's just go now" :)16:50
naccdobey: i meant based upon my reading of the logs of the channel from last week :)16:50
cjwatsonah, yes, but maybe not with snapshot_mode none16:50
naccdobey: it's "supposed" to be ? :)16:50
pittiapparently I triggered a but when I told it to regenerate all indexes for the new gpg key16:51
naccdobey: looking at my logs, either stgraber or mwhudson might have the context ...16:51
pittis/but/bug/16:51
infinitycjwatson: I'm not sure how that key is interpreted, to be fair, but the naive interpretation would be "oh shit".16:52
infinitycjwatson: (And a perfectly reasonable default for a backup of a deb archive...)16:52
cjwatsonQuite.16:52
naccslangasek: 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?16:54
zequenceWe'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:00
zequence..but, we are still getting them on our ISO17:01
cjwatsonBlacklisting isn't generally what you want.17:01
zequenceOk17:01
cjwatsonStop trying to use it. :-)17:01
cjwatsonYou need to arrange for apt to resolve alternative dependencies the way you want.17:02
cjwatsonThis 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
cjwatsonThis can be a bit subtle and usually requires poring over germinate output in some detail.17:02
zequencecjwatson: Does it have to do with the order of seeds in the STRUCTURE file?17:03
cjwatsonYes.17:03
cjwatsonWell, sort of.17:03
cjwatsonIt has more to do with their inheritance structure.17:03
zequenceRight17:03
cjwatsonThe 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:04
zequencecjwatson: Thanks. Seems I have a lead. lighdm pulls in unity-greeter, which we have an alternative for17:14
=== muktupavels_ is now known as muktupavels
barry@pilot in18:24
=== udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
infinitypitti: 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:25
pittiinfinity: yes, it regularly gets auto-backported on apt.postgresql.org18:26
infinitypitti: Right, lecagy codepath it is, then.  That's easy enough anyway.18:27
pittiinfinity: 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 somehow18:27
showazbug in mlmmj deb (package) "/usr/bin/mlmmj-recieve" and "/usr/bin/mlmmj-recieve" (no manual entry for mlmmj-receive)18:27
showazbin dublicate filename bug.18:27
infinitypitti: Already in hand.  Don't worry about it.18:27
infinitypitti: If it supports precise trusty vivid wily xenial, is that good enough, or do you backport for EOL releases too?18:28
pittiinfinity: nope, p/t/w/x is fine18:30
pitti(and jessie/stretch/unstable of course)18:30
* pitti waves good night18:31
nacccaribou: would you be able to review LP: #1552983 ? fairly trivial merge for logwatch18:33
ubottuLaunchpad bug 1552983 in logwatch (Ubuntu) "Please merge logwatch 7.4.2-1 from Debian" [Low,New] https://launchpad.net/bugs/155298318:33
infinitypitti: Sec, don't run away yet.18:33
infinitypitti: Still there? :P18:38
* infinity guesses he ran fast.18:38
* flexiondotorg sees dust.18:38
ogra_he didnt run .. he waved away :)18:38
cjwatsonshowaz: 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 OK18:39
cjwatsonshowaz: though this is version-dependent.  anyway, reporting bugs on IRC is not useful, bug reports go to Launchpad18:40
showazcjwatson:  docs only "mlmmj-receive" http://mlmmj.org/documentation/18:40
cjwatsonshowaz: good!  ignore mlmmj-recieve, looks like it's just there for backward compat18:40
cjwatsonno doubt a historical mistake18:40
momkennickserv identify digitsm19:23
Snow-Man19:23
Snow-Mantry again19:23
sarnoldmomken: oops :)19:23
Snow-Manand change your pw19:23
sarnoldpreferably something a bit stronger, too19:23
dobeylike 1234519:24
momkenit's not my password19:24
Snow-Manmaybe Vu~W-f]zvOzY|57GGSMLe<c;019:24
Snow-Man:D19:24
=== momken is now known as digitsm
dobeyyour password must be between 8-24 characters, and match the regex [A-Za-z0-9]+19:27
Snow-Manit's the websites where the 'change password' page will accept nearly anything, but the 'login' page doesn't work with certain characters that kills me19:32
flexiondotorgcjwatson, Just interested in how your wrangling is going with apt changes is going?19:37
rcjarges, Do you have time to review a pending upload for SRU in bug #155930719:47
ubottubug 1559307 in walinuxagent (Ubuntu) "[SRU] update walinuxagent to 2.1.3 in Wily" [Critical,In progress] https://launchpad.net/bugs/155930719:47
argesrcj: in a bit19:48
rcjarges, thank you19:48
slangasekpitti: 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:52
argesrcj: is the xenial task for walinuxagent is fixed?19:54
argesremoving the second is19:55
rcjarges, it's in xenial already19:55
rcjbeen there for a bit19:55
rcjsorry19:55
pittiinfinity: back for a bit20:08
infinitypitti: Too late, I uploaded. :)20:09
dokoinfinity, fyi, https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=2.23;users=debian-glibc@lists.debian.org20:09
infinitypitti: But do check the postgresql-common diff and grab it for Debian.20:09
pittislangasek: 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 tests20:09
slangasekpitti: hmm, well, ok.  what do you think we should do with gdnsd, then?  Should the package conflict with e.g. dnsmasq?20:10
infinitydoko: Pretty much all of those seem to be fallout from https://sourceware.org/bugzilla/show_bug.cgi?id=1943920:11
ubottusourceware.org bug 19439 in math "Unix98 isinf and isnan functions conflict with C++11" [Normal,Resolved: fixed]20:11
infinitydoko: 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
pittislangasek: 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
slangasekpitti: dns server, not dhcp server20:11
pittiright, a simple apt-get install gdnsd fails in that manner20:12
pittiso, this spotted a packaging bug20:12
pittigdnsd[1745]: Failed to bind() TCP DNS socket to 0.0.20:12
pittiquestion is why -- dnsmasq isn't even installed20:12
pitti(and we don't install it by default, only -base)20:13
infinitypitti: The follow-up question is why anything's bound to that on your adt VM.20:13
slangasekwe don't, as a rule, require packages to conflict with one another due to trying to provide services on the same port20:13
slangasekoh, you see that failure even without dnsmasq?20:13
pittitcp        0      0 10.0.3.1:53             0.0.0.0:*               LISTEN      901/dnsmasq20:13
pittihm, what's that20:13
infinitylsof -i TCP20:13
pittiah, dnsmasq is running, owned by lxc-dns20:14
pittiah, of course! we install lxc by default now20:14
pittilxc-common in particualr20:14
infinity"we" do?20:14
pitticloud images do20:14
infinityOnly in cloud-image/server.20:14
pittithey ship all sorts of ... unnecessary stuff these days20:14
infinityYeah, don't you already remove a bunch of cloud-image stuff we don't want in adt images? :)20:14
pittiyeah, I do20:15
pittiexcept on lcy0120:15
pittias building images is broken there20:15
pittiand it recently started failing on lgw01 as well (which is in some sort of semi-broken state)20:15
infinityI find "apt-get purge server^ && apt-get --purge autoremove" works well.20:15
pittiso before, depending on whether you ran on a minimal adt image or a standard cloud iamge it would pass or fail20:15
slangasekinfinity: pro tip, 'apt autoremove --purge server^'20:16
infinityOr that.20:16
pittiso I guess I'll add the purging of lxc/lxd to the setup commands again20:16
pittiit'll slow down every test, but avoid this20:16
pittihowever, this just papers over the fact that the package still fails to install on a default server/cloud install20:16
infinityAny dns server will.20:17
slangasekpitti: again, policy doesn't expect packages to conflict with other implementors of a network service just because they might want to share the same port20:17
slangasekthis definitely isn't gdnsd-specific20:17
infinityI'm inclined to think it's a bit of a bug that our default cloud/server install now binds to that port.20:17
infinityI hear people like to run DNS servers on servers.20:17
pittiwell, it can be fixed either way (not make postinst fail if the port is taken, or conflict to other dns servers)20:17
naccinfinity: pitti: i can take it as an action to talk to the server team about it :)20:18
infinitynacc: Please do.20:18
naccyep20:18
infinitypitti: 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:18
pittiwell, if you want lxc-net to work out of the box, you have to install a DHCP server20:19
infinityDNS, you mean.20:19
pittibut indeed it sucks a bit that you have to choose between "run a DNS server" and "use LXC"20:20
pittiinfinity: henceforth I'll just call it D* :)20:20
infinitySurely, the solution is to only bind to TCP:53 on the lxc bridge.20:20
infinityWhich shouldn't conflict with running a real DNS server on the host.20:20
pittiNMICT20:20
pittiinfinity: unless that tries to bind on all interfaces?20:20
pittihmm, 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 image20:22
pittiah, so apparently apt-get purge --auto-remove lxc does not remove lxc-common any more?!20:22
slangasekyes, if lxc-net's dnsmasq was bound to the lxc bridge, another server coming along and binding to 0.0.0.0 should DTRT20:23
pittiah, lxc1 now also depends on that, I guess I need to add  to my ever-increasing purge list :)20:23
pittislangasek: that sounds good20:23
slangasekthough I'm not sure if the lxc dnsmasq running only on the bridge IP is what's expected?  questions of resolvconf integration20:24
slangasekinfinity: fwiw building valgrind from svn trunk doesn't get me anything that works any better20:24
smoserslangasek, so http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/view/head:/cloud-image20:24
infinityslangasek: Fun.20:24
smoserhas ubuntu-snappy20:24
pittislangasek: oh, how does that integrate with resolvconf?20:24
slangaseknow going to double-check whether this is a toolchain problem (rebuild current glibc with xenial)20:24
smoserwhy is that not installed in image ?20:25
dobeymwhudson: around?20:25
infinitysmoser: Because ubuntu-snappy is in universe.20:25
pittiok, purging lxc-common does the trick20:25
infinitysmoser: So germinate will cull it out of the results as an unknown package.20:25
smoseri figured it would go in and create a component mismatch20:25
smoserok.20:25
smoser:-(20:26
slangaseksmoser: it's listed in component-mismatches20:26
slangasekbut until it's in main it doesn't go on the image20:26
slangasekI'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 today20:26
smoseri expected the component mismatch, but thought it let it in and warn rather than ignore it.20:26
pittismoser: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg has a nice graph of it, FYI20:26
smoserok. thank you all. so the other question related then, pitti hinted at20:26
smosershould we put 'ubuntu-server' into each of those seeds (cloud-image and server)20:27
infinityNo.20:27
infinityWell, I put it in server already.20:27
infinityDidn't I?20:27
infinityYeah, I did.20:27
hallynpitti: havne't read the whole backlog, but fwiw this week or next lxc-net should be removed from the seed again i think;20:27
hallynlxd will stop depending on it, and so it should get dropped automatically20:28
hallynat least that's my understanding20:28
pittihallyn: lxc-common you mean?20:28
smoserinfinity, yeah, you did.20:28
smoseri will add it now to cloud-image as it is desired ther also20:28
hallynpitti: that i'm not sure20:29
hallynpitti: but lxc120:29
hallynwhich has the lxc-net init job20:29
pittihallyn: but I figure lxc and lxd actually do need lxc-net (i. e. a bridge with DHCP server) to work reasonably20:29
hallynlxd will stop using lxcbr0 so it won't be needed any more20:29
hallynno, lxd will not.20:29
pittihallyn: oh, will the lxd-daemon have some builtin DHCP/DNS server then?20:30
hallyni think ipv6 only by default20:31
slangaseknacc: 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 capabilities20:32
pittislangasek, hallyn: hmm, lxc-net already uses --interface=lxcbr0 and listens on 10.0.3.1:53 only20:35
pittiso this doesn't help for things that bind on 0.0.0.020:36
slangasekpitti: ah, you're right - I was looking at the wrong column in netstat before20:37
naccslangasek: yep, sorry, what i meant wsa that `reverse-depends` does a (albeit slower) more accurate job of what i need20:37
naccslangasek: but yeah, grep-dctrl is also going to be handy as i trim this down20:38
slangasekpitti: and if I compare with bind9, bind9 binds to each available IP individually, so that tells us nothing ;)20:38
pittiso, tomorrow's auto-built adt images should not have lxc1 any more20:40
pittiwhich should make that test work again (but it's still kinda papering over)20:41
hallynand why does lxc1 make the test fail?20:44
infinityhallyn: 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:45
TJ-shouldn't dnsmasq be using "--bind-interfaces" to 'drop' those interfaces it isn't interested in?20:50
dokoxnox, pitti: ping on cmake20:50
dokosee email20:50
stgrabernote 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 it20:51
infinitystgraber: Okay, that's promising.20:51
stgraberTJ-: 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 others20:51
pittihallyn: it's an actual problem with the package -- apt-get install gdnsd on a cloud image fails; it's less clear whose fault that is20:51
infinitystgraber: How do guests get IPv4 connectivity?20:52
stgraberinfinity: the guest won't have any connectivity by default except http through a minimal proxy20:52
stgraberinfinity: it will then be up to the local admin to run "dpkg-reconfigure lxd" to configure lxdbr0 with some proper connectivity20:52
infinityFair 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 port20:52
stgraberTJ-: sure doesn't, bind to 0.0.0.0 requires that the port is free on all interfaces :)20:53
infinityTJ-: slangasek and I thought the same thing.  Apparently we're wrong. :P20:53
slangasekI'm guessing that's a kernel configurable thing20:53
slangasekand/or a socket configurable thing20: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 check20:53
infinityMaybe.  Though, the current behaviour is certainly more deterministic.20:53
infinity"maybe-bind()" isn't exactly debuggable.20:54
naccslangasek: 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
hallynpitti: ...  i thought we had it so that installing lxc did not require full dnsmasq.20:54
pittistgraber: hm, that sounds like a step backwards for "just works"?20:55
pittihallyn: it only installs/uses dnsmasq-base, so dnsmasq's own service doesn't start indeed; but lxc-net still launches lxc-net20:55
hallynwhich only listens on lxcbr0's port 53.20:55
hallynso if anyone wants to listen on that, it's the bad actor20:56
pittiand 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
hallynwhy is htat reasonable for gdnsd?20:56
pittihallyn: yeah, I tend to agree and blame gdnsd too20:56
TJ-yes; i have multiple processes on the same port on different interfaces.20:56
pittiit shoudl be content to bind on "some" interfaces in the default install20:56
hallyni agree i'm worried about lxdbr0 becoming more work for ppl,20:56
dokoTJ-, are you still working on the openjdk backports?20:56
pittior 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
hallynmaybe 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.020:57
pittihallyn: 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, Tomcat20:57
pittiand dropping ipv4 in containers still seems a bit premature20:58
pittias much as I like/use IPv6, it doesn't fully replace ipv4 yet20:58
TJ-makes routing a lot easier though :)20:58
stgraberpitti: it is a step backward in usability, yes20:59
stgraberpitti: 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 everywhere20:59
TJ-doko: but I've been on 16.04/15.10 for a while now so not used that build recently20:59
pittistgraber: hm, a shame -- I'd rather make the .services conflict..21:00
stgraberpitti: 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 LTS21:00
stgraberpitti: 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 issue21:01
pittidoko: cmake> well, aren't you the first one to complain if new stuff causes massive FTBFS? :-)21:02
mwhudsondobey: am no21:02
mwhudsonw21:02
stgraberpitti: 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 using21:02
pittidoko: 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 test21:02
stgraberpitti: 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 stuck21:02
pittistgraber: hard to believe that after all this years of virtualization one can't use some "private routing namespace" or something such :)21:03
stgraberpitti: 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 sane21:03
dobeymwhudson: hi! i'm having some trouble with go on xenial powerpc/ppc64el now21:04
pittistgraber: 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 bad21:04
mwhudsondobey: oh right, you are being hit by the move to coinstallable go versions being half done i think21:04
mwhudsondobey: ppc64el?21:04
pittistgraber: or installing a package like lxc1 indeed21:04
dobeymwhudson: yeah21:04
dobeymwhudson: https://launchpadlibrarian.net/249488485/buildlog_ubuntu-xenial-ppc64el.pay-service_15.10+16.04.20160321.1-0ubuntu1_BUILDING.txt.gz21:04
dobey"go: not found"21:04
mwhudsonblargh21:04
stgraberpitti: 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 debconf21:04
mwhudsondobey: does this build-depend on gccgo [ppc64el] or something?21:05
stgraberpitti: 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 config21:05
dobeymwhudson: but all the other archs where we use gccgo are still fine21:05
pittistgraber: ah, which means that you can also enable dnsmasq in a config file21:05
dobeymwhudson: yes21:05
mwhudsondobey: er, we only use gccgo by default on powerpc now21:05
mwhudsondobey: change the package to b-d on all arches21:06
mwhudsonerrr21:06
mwhudsondobey: change the package to b-d on golang-go all arches21:06
mwhudsonit'll ftbfs on powerpc for a while21:06
dobeymwhudson: won't that break on vivid though?21:06
stgraberpitti: 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 dnsmasq21:06
mwhudsondobey: are you telling me you actually care about the status of this package on ppc64el on vivid?21:07
mwhudsoni mean, yes it will21:07
infinitydobey: The goal in debian/control shouldn't be to make a package build on every release ever.21:07
mwhudsonbut progress has to be possible21:07
infinitydobey: Surely, you have a mechanism to fork the packaging.21:07
dobeymwhudson: 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" policy21:08
dobeyinfinity: yes but i don't hate myseful enough to want to do that21:08
infinitydobey: 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
mwhudsondobey: maybe golang-go on vivid should depend on gccgo on ppc64el21:09
mwhudsonwhich would be a change, of course21:09
dobeyinfinity: 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 more21:09
mwhudsondobey: that sounds like a pretty good solution tbh21:10
infinitydobey: You might be able to fudge it with something like "golang-go (>> xenial-version) [ppc64el] | gccgo [ppc64el]"21:10
infinitydobey: Er, drop it in xenial or vivid?21:10
dobeyinfinity: 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 anyway21:10
infinitydobey: Really don't care about ppc64el in the vivid PPA.21:10
dobeyinfinity: well in the phone overlay, we don't care about actual vivid obviously21:10
infinitydobey: But "go is improved in xenial, let's drop the arch in xenial" would be silly.21:11
dobeyinfinity: well, people who can block my stuff landing there will complain21:11
dobeyinfinity: well, trying to support complining stuff on archs that it doesn't really work at runtime on anyway is probably more silly21:12
infinitydobey: Try "golang-go (>= 1.6) [ppc64el] | gccgo [ppc64el]" to keep the current state of affairs and make it backportable.21:12
infinitydobey: How do you know it doesn't work at runtime?21:13
dobeyinfinity: because a whole boatload of runtime dependencies aren't built on these archs21:13
infinityIf that were true, it would never migrate.21:14
dobeyit would only fail to migrate if something were trying to actually use it on those archs21:14
infinity...?21:14
infinityNo, if the package deps are unsatisfiable, britney will tell you to eff off.21:15
dobeythere are no autopkgtests in anything that tries to perform the runtime work that fails21:15
dobeyyeah, that's why the package deps are tweaked to not depend on the thing that isn't available, on those archs21:15
dobeyok, well i have to go now. i guess i'll try to hack around the golang-go/gccgo thing then too21:17
dobeyso this will build again21:17
dobeylater21:18
slangaseksmoser: 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 it21:42
ubottuLaunchpad bug 1520689 in golang-websocket (Ubuntu) "[MIR] golang-websocket-dev" [High,Incomplete] https://launchpad.net/bugs/152068921:42
slangasekI 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 anymore21:43
slangasekor 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 promoted21:43
slangasekor I can wait until the build-dep is sorted before promoting21:43
slangasekor I can promote it now and leave it unbuildable21:44
slangaseksmoser: ^^ 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 acceptable21:44
cjwatsonflexiondotorg: 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 review21:59
cyphermoxnacc: I'm looking at bug 1544352 but it doesn't look like some of these packages can just get no-change rebuilds and php5->php22:01
ubottubug 1544352 in Ubuntu "[PHP7] After bootstrapping, these PHP packages can automatically be rebuilt" [Wishlist,Incomplete] https://launchpad.net/bugs/154435222:01
juliankcjwatson: That sounds great :)22:08
infinityslangasek: 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
infinityslangasek: (ie: "wait for archive reorg" is a bit of a cop-out there)22:09
infinityslangasek: 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:09
slangasekinfinity: the germinate patch does implement support for Built-Using22:11
infinityslangasek: Kay.  In that case, archive reorg wouldn't fix the issue (assuming Built-Using is supported as I think it should be)22:11
slangasekwhich means the package would be buildable but there would still be a record in component-mismatches, which is what I care about22:11
infinityAhh, fair.22:12
flexiondotorgcjwatson, Thanks for the update. Interesting stuff.22:21
barry@pilot out22:29
=== udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
nacccyphermox: you're probably right, some will need installation checking and such; although if they have tests, that list passed their tetss22:37
nacctests, rather22:37
nacccyphermox: oh, you didn't see the description22:38
nacccyphermox: several seds need to be run22:38
naccit's *almost* automatic :)22:39
cyphermoxyes, several sed commands, and ideally it would probbly be best if the command was provided22:39
cyphermoxtbh to me it looks very not automatic22:39
nacccyphermox: it was provided, well, the regex i used were. I can provide a complete `find` line22:40
nacccyphermox: i mean, i scripted it here :)22:40
cyphermoxwhere?22:40
naccon my machine, running an adt run against each22:40
naccthat's about all i can do w/o upload rights22:40
cyphermoxwell, almost all; you could file bugs and ask for sponsoring if the work is already done22:40
cyphermoxbut 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 example22:41
nacccyphermox: 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 preferable22:41
nacccyphermox: what redundancies?22:42
slangaseknacc: 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 results22:42
cyphermoxphp | php, for instance22:42
naccslangasek: yep, I can do that22:42
cyphermoxbecause some packages mention php5 | php22:42
nacccyphermox: i don't see how that will ahppen to adminer22:43
slangaseknacc: otherwise, if the "automation" is incomplete and should be captured as a debdiff, then there should be separate bugs for each22:43
naccthe result of the sed is22:43
nacclite | php-pgsql22:43
naccgah22:43
cyphermoxnacc: this isn't adminer but I did see one instance22:43
slangasekcyphermox: well, dpkg-buildpackage is awfully smart these days, so php | php will be reduced :)22:43
nacccyphermox: i'm happy to clean those up as i encounter them ... they didn't lead to an error, per se22:43
cyphermoxslangasek: but it won't change the actual debian/control file uploaded22:43
nacccyphermox: i am taking what you say to heart22:44
naccslangasek: i can provide debdiffs for these that needed the sed22:44
slangasekcyphermox: true, it won't, but at runtime it'll be fine22:44
naccit will be a better review anyways, as a result22:44
cyphermoxI mean, the list looks otherwise pretty good, and the work isn't complicated; it just takes a bit to go through it and upload each22:44
nacccyphermox: admittedly, it's just a matter of time22:44
cyphermox(I already download all the source)22:44
cyphermox*downloaded22:44
naccand 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 remediation22:45
naccwe package a lot of *old* php stuff :)22:45
naccit's unfortunate, what with composer being the upstream-prescribed (and only approved) way to install things, often22:45
cyphermoxa couple things also ship apache config, we'll need to make sure those get changed too22:46
slangasekreminder, old and crufty stuff can also be removed if we don't think it's worth fixing22:46
nacccyphermox: yep, that's one thing i needed to manually go back and fix in some packages22:46
naccslangasek: agreed, and several of them have been superseded int eh archive already, we just carry two versions22:46
naccone of whcih might be EOL at this point :)22:47
nacccyphermox: 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
cyphermoxI fixed up a simple tracker config for this, I'll push my code22:47
nacccyphermox: 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:49
cyphermoxyes22:50
naccawesome, thanks! i was going to ask if we had something similar, but had forgotten :)22:50
cyphermoxit's kind of naive; just checking if it Depends or Build-Depends on something called php5.*22:51
nacccyphermox: i mean, that's basically what my scripting is doing :) i'm ok with naive for now22:51
naccslangasek: sigh, i don't know why php-zeta-console-tools failed. It didn't emit any output that indicates what actually failed?22:52
naccslangasek: and it passed all tests during the build and in my systems' autopkgtests (running it again now to be sure)22:53
naccslangasek: confirmed, in my adt-virt-lxc run, all 744 tests passed22:53
naccslangasek: 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.gz22:54
nacci think you should see "test phpunit: [----22:55
naccfollowed by a patching line22:55
naccthen PHPUnit output22:55
naccthen another patching line (as the patch is reverted)22:55
naccthen "test phpunit -----]22:55
slangaseknacc: I can reproduce the php-zeta-console-tools autopkgtest failure here23:21
slangaseknacc: in fact, phpunit does nothing but exit 255 for me here23:22
naccslangasek: so confused. i literally just ran it here; and it clearly ran succesfully during the build23:23
naccslangasek: from which directory location are you running it?23:23
slangaseknacc: 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:24
slangasekoh, 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
naccyeah, i htink that's the case23:25
naccslangasek: and that's probably the issue, the d/t/control doesn't depend on itself?23:26
slangaseknacc: no, that's not the problem23:26
slangasekthat's just the first error I hit locally, not necessarily the real problem on the autopkgtest infra23:26
cyphermoxyou could get a console in the autopkgtest environment to check exactly what fails in the infra23:27
naccslangasek: 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
nacclet me see if i can see why23:27
slangaseknacc: ok, it's looking for /usr/share/php/ezc/Base/autoload.php, but there's no versioned dep on php-zeta-base23:28
slangasekwell... there is a versioned dep, but the versioned dep doesn't ensure that file's existence23:28
UmeaboyIn Xenial I see no menus when moving the cursor to the top bar.23:28
UmeaboyIs that expected?23:29
UmeaboyI know that it's a testing version of Ubuntu so no need to tell me that again.23:29
UmeaboyJust wondering how I can get it back without having to downgrade Ubuntu.23:29
slangaseknacc: upgrading php-zeta-base fixes it; so php-zeta-console-tools *should* have a versioned dep on php-zeta-base, I think?23:29
naccslangasek: it does, though? on php-zeta-base >= 1.9-2~23:30
cyphermoxUmeaboy: I know some apps didn't show me menus in unity; best is probably that you file a bug.23:30
naccslangasek: or do you mean only certain version of php-zeta-base have the file?23:30
slangaseknacc: depends, not build-depends. the depends is on php-zeta-base (>= 1.8), php-zeta-base (<< 2~~) which is insufficiently strict23:30
UmeaboyAnd also...... when you translate "Add to Dash", do you also translate the name Dash?23:30
UmeaboyJust making sure.23:30
cyphermoxI don't know23:31
naccslangasek: ah! sorry23:31
slangaseknacc: 1.9-1 doesn't have it, maybe it only shows up when rebuilt with the php7 package toolchain?23:31
UmeaboyAnyone else that knows?23:31
Umeaboy ../launcher/ApplicationLauncherIcon.cpp:71723:31
cyphermoxUmeaboy: it might be better to ask about this on #ubuntu-unity23:31
Umeaboyis the location of it.23:31
UmeaboyOK.23:31
cyphermoxUmeaboy: and/or compare with other languages23:32
naccslangasek: so there should be a versioned dep on php-zeta-base, maybe on >= 1.9 ?23:33
slangaseknacc: 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 after23:33
slangaseknacc: so if ezc/Base/autoload.php needs to be there for the package to work, it needs to be >= 1.9-2build123:34
slangaseknacc: or possibly just 1.9-2 - it's not clear to me if this was a packaging change or a tooling change23:36
slangaseknacc: 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-123:38
dokonacc, 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
slangasekdoko: they still need worked through; we're basically mid rebuild transition23:38
slangasekdoko: things that build-depend on the standard php tooling, but depend on other extensions that are currently built for php5, probably FTBFS23:39
dokoslangasek, ok, would like to start one more test rebuild once glibc migrates + outstanding debian syncs23:39
slangaseknacc: 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:39
naccslangasek: yes, it makes sense, thank you for clarifying23:41
naccslangasek: feel free to plunk :)23:41
slangaseknacc: done23:43
naccslangasek: 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 errors23:44
slangaseknacc: ok.  and I think I left questions for you on php-opencloud23:46
naccslangasek: 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 expected23:46
naccslangasek: yep, getting to that one too23:47

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