[01:03] <nacc> slangasek: quick general question for you, SRU related; there's an open bug for php5-apcu (LP: #1374892), and even the upstream maintainer says we shouldn't be shipping 4.0.2 (provided a +1 to update in the bug, c13). Debian ships 4.0.7-1 in stable for similar issues, afaict.
[01:04] <nacc> slangasek: we have 4.0.7-ish in backports, but this bug is specifically about updating the official one
[01:04] <sarnold> (upstream maintainers always say that :)
[01:04] <nacc> sarnold: at least in this case, i think the extension crashes/hangs pretty easily
[01:04] <nacc> sarnold: but that is a fair point
[01:04] <sarnold> sometimes they're right :) but still
[01:05] <nacc> sarnold: right, so i'd like to understand what i can do to figure it out
[01:07] <slangasek> nacc: general process is https://wiki.ubuntu.com/StableReleaseUpdates; if you're asking about upgrading wholesale to 4.0.7, "current version is completely broken" is a good argument, but the update would still need to be regression tested for an SRU
[01:09] <nacc> slangasek: yep, i was reviewing that; I will see what kind of testing I can do / ask the community to do
[01:10] <infinity> nacc: I'm not at all against accepting an SRU on the "it's broken" grounds.
[01:11] <infinity> If the one in backports has no dependencies in backports, we could just copy it over.
[01:11] <nacc> infinity: yeah, i'm trying to get some clarity on if it fixes all the issues or not; there is one reporter who says some things are still broken
[01:11] <nacc> infinity: most say it's better, at least (meaning it's usable)
[01:12] <nacc> infinity: afaict, it has no deps in backports, but i'm trusting `reverse-depends -r trusty -c backports src:php-apcu` to tell me that, is that correct?
[01:13] <infinity> nacc: Err, no, I meant the binary itself shouldn't have backports deps.
[01:14] <infinity> nacc: As in, backports build-deps on backports, and can thus pull in deps that wouldn't be satisfiable in -updates (which would then mean we need a fresh build in -updates)
[01:14] <infinity> Which is fine, but if we can use the backports binary, people have already tested that one and claimed it's not crap.
[01:15] <nacc> infinity: oh i see
[01:16] <nacc> infinity: i don't believe that's the case here; I will dig into it a bit tmrw
[06:13] <pitti> Good morning
[06:16] <alkisg> Good morning
[06:21] <alkisg> It appears that Ubuntu's network-manager patches have something to do with the nbd-client's cyclic dependencies... (LP: #1487679)
[06:26] <alkisg> I.e. that any sysvinit service that has "Required-Start: $network" is causing loops in Ubuntu, but not in Debian
[06:27] <slangasek> nacc: php-horde-db tests regress with mysql-5.7
[06:31] <seb128> cyphermox, did we get anywhere with the n-m 1.2 update?
[06:46] <slangasek> nacc: php-sabredav also fails with an incompatibility between php-sabredav and some dependency
[07:20] <pitti> alkisg: not "any" sysvinit service, but rcS ones; we've seen that happen in Debian too
[07:20] <pitti> alkisg: most prominently with nfs-utils, as Debian's package still uses the single sysv script instead of the units
[07:20] <pitti> this comes up on (Debian) IRC every so often
[07:21] <pitti> slangasek: ^ speaking of which, do you plan to merge Ubuntu's nfs-utils changes to Debian? Or is that fodder for an NMU?
[07:49] <slangasek> pitti: have the patches been sent to the BTS?  I haven't looked at nfs-utils at all recently
[07:49] <alkisg> pitti: I don't think I can help there; it's way over my head! We'll just dpkg-divert nbd-client service until some fix is made available... :)
[07:51] <pitti> slangasek: no, I don't think so; it's essentially the changes from 1:1.2.8-9ubuntu2 to ubuntu12, but as this keeps changing, patches are bitrotting quite fast
[07:52] <slangasek> pitti:
[07:52] <pitti> slangasek: i. e. if you plan to update Debian at all, I'm fine with massaging those for Debian (changelog cleanup, etc.)
[07:52] <pitti> slangasek: and send them to some appropriate debian bug
[07:52] <slangasek> pitti: I don't have any near-term plans, but a patch to the BTS would be helpful; there are comaintainers
[07:53] <pitti> we don't want the upstart changes in Debian supposedly, as upstart is gone there
[07:54] <slangasek> they don't hurt anything, and if it reduces the delta then I'd be for them
[07:54] <pitti> ok; might use debian bug 765731, but I guess it's better to file a new one and refer to that and some others
[07:56] <pitti> slangasek: well, I suppose we won't keep them much longer either, do we? ubuntu touch won't need NFS
[07:57] <pitti> maybe there's a new upstream version by now which incorporates these patches
[07:57] <pitti> ah, 1.3.3
[07:58] <pitti> so, updating to that would get rid of 90% of the patches already
[11:01] <pitti> doko: new vim seems to break vim-addon-manager (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#vim)
[11:01] <pitti> currently checking if that's a real regression, or fallout from some ruby change
[11:01] <pitti> E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/universe/source/Sources  Writing more data than expected (9699328 > 9651713)
[11:01] <pitti> le what?
[11:03] <ansgar> pitti: I think that error happens when apt gets a new InRelease, but old Packages/Sources (or the other way around).
[11:04] <pitti> I consistently get it in my containers now, might be some fallout wrt. the recent "by-hash" enablement and apt-cacher-ng
[11:05] <pitti> hm, still the same thing after cleaning /var/cache/apt-cacher-ng/uburep
[11:15] <pitti> meh, this happens with a *completely clean* /var/lib/apt/lists and /var/cache/apt-cacher-ng/
[11:15] <pitti> it's like something in the metadata contradicts with each other
[11:21] <cjwatson> pitti: by-hash isn't advertised yet.  I suspect the contrary: your problem will go away once we advertise it :)
[11:21] <cjwatson> pitti: Try with 'deb [by-hash=force] http://...' for the relevant sources.list line; I bet that fixes it
[11:22] <cjwatson> pitti: Also, if you're running pre-xenial or non-Ubuntu apt-cacher-ng, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819852 for a config workaround you'll need to support by-hash
[11:22] <pitti> cjwatson: no, I have current xenial version with your patch
[11:22] <cjwatson> pitti: OK, good, just try [by-hash=force] then
[11:23] <cjwatson> apt-cacher-ng might have just decided to cache a stale Sources, or perhaps some other proxy in the way
[11:23] <pitti> yay, works wonders
[11:23] <pitti> cjwatson: well, I suspected that too, but if I stop acng, completely empty /var/cache/apt-cacher-ng/ and restart it, that shouldn't be the case any more
[11:24] <cjwatson> pitti: could be something else on the network path between you and a.u.c
[11:24] <pitti> cjwatson: thanks for the hint with [by-hash=force]!
[11:24] <cjwatson> pitti: planning to turn it on by default today; I just want to check that deletion is working
[11:24] <pitti> cjwatson: ah, I'm on the VPN, maybe there's some transparent proxy in between indeed
[11:24] <pitti> doko: so, vim-addon-manager tests still succeed on current xenial and fail in that way in xenial-proposed, so this looks real
[11:26] <alkisg> (10:20:01 πμ) pitti: alkisg: not "any" sysvinit service, but rcS ones; we've seen that happen in Debian too ==> I tried *without* the S stage and got the issue... I.e. with a single "Required-Start: $network" and without a Default-Start (or with 2 3 4 5)
[11:28] <alkisg> I had only the required-start: $network part with no other headers at all...
[11:36] <doko> pitti, yes, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820313
[12:07] <zyga> re
[12:07] <zyga> jdstrand: IT WORKS :-)
[12:13] <rbasak> xnox: are you working on the rsyslog s390x FTBFS?
[12:18] <xnox> rbasak, did not see that.
[12:18] <xnox> rbasak, is there a bug number?
[12:19] <doko> xnox, see the test rebuild
[12:19] <rbasak> xnox: no, it's just in http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160401-xenial.html
[12:20] <xnox> doko, rbasak - did not go through s390x only ftbfs yet
[12:27] <pitti> doko: ah, so that was fixed in vim itself
[12:27] <doko> pitti, package in unapproved
[12:34] <pitti> doko: no, it's not :-)
[12:34] <pitti> doko: (i. e. accepted, thank you!)
[12:35] <pitti> xnox: is it actually part of the specification that just about every tool and acronym on s390x is utterly unpronouncible? :-)
[12:36] <xnox> pitti, yes Ram is Storage and etc.
[12:36] <pitti> dasdfmt, fdasd, lpar, chzdev, this all sounds much more like "cat jumped on the keyboard" :-)
[12:36] <xnox> pitti, do we need a guidelines of acronyms?
[12:37] <xnox> pitti, dasdfmt -> DASD drive low level formatting for linux; fdasd - format dasd partition table on a dasd drive; LPAR - logical parition, e.g. a portion of a mainframe viewed as a single baremetal machine
[12:37] <pitti> xnox: I figure zSeries' guidelines are "must contain at least 80% consonants and have a non-memorizable name"
[12:37] <pitti> xnox: (no worries, j/k -- it's Friday afternoon)
[12:37] <pitti> just spotted some more of this during unapproved review
[12:38] <xnox> chzdev - CHange z device -> bring CCW (their unique bus, all devices are on CCW bus) devices online/offline (e.g. on/off switch for network cards, drives of all types)
[12:38] <cjwatson> pitti: all right, can we do this by-hash thing?
[12:38] <cjwatson> pitti: lp-shell production devel, then xenial = lp.load('/ubuntu/xenial'); xenial.advertise_by_hash = True; xenial.lp_save()
[12:38] <pitti> cjwatson: I haven't heard of any problems
[12:38] <pitti> cjwatson: Fri afternoon is the perfect time :)
[12:38] <xnox> pitti, [ls|ch]*foo is quite common within s390-tools... and that's the thing to fiddle with stuff in /sys/ without going brain dead =)
[12:38] <xnox> on all linuxes.
[12:38] <cjwatson> totally :)  we have an easy circuit breaker to turn it off if it causes problems (i.e. just revert the above flag)
[12:39]  * pitti pushes the button and sticks fingers in ears
[12:39] <cjwatson> yay
[12:43] <pitti> cjwatson: thanks and congrats, this is an amazingly nice feature
[12:44] <pitti> "hash sum mismatch"-b-gone!
[12:44] <cjwatson> fingers crossed.  there will be an assortment of problems with mirror scripts, but they should be no worse than previous behaviour
[12:57] <jdstrand> zyga: woohoo! :)
[12:58]  * jdstrand hugs zyga :)
[12:58] <zyga> jdstrand: I'll ping you with two or three branches shortly
[12:58]  * zyga just wasted 30 minutes debugging telepathy to see why irc is broken
[12:58] <zyga> it seems that irc password is saved as a dbus type signature instead, some missing function call somewhere :P
[12:59] <zyga> anyway...
[12:59] <zyga> jdstrand: one critical thing is to get the template in line
[12:59] <zyga> jdstrand: we have two options
[12:59] <zyga> jdstrand: but I think for 16.04 we should just get rid of all unused variables
[12:59] <zyga> jdstrand: and use "modern" names everyhwere
[12:59] <zyga> jdstrand: I'll explain details in a sec, I have to go to a meeting
[13:03] <jdstrand> zyga: (see my response in #snappy-- I'm not going to be available for several hours (many meetings, need prep, etc)
[13:03] <jdstrand> )
[13:08] <doko> xnox, should we kick out the separate boost-mpi source?
[13:08] <xnox> doko, if universe got enabled, yes.
[13:09] <xnox> doko, e.g. no-follow-build-depends
[13:09] <xnox> but i'm not sure what the status there is.
[13:09] <doko> hmm, true. currently only seen in component-mismatches
[13:12] <cjwatson> xnox: it's done
[13:13] <xnox> Set no-follow-build-depends feature, so packages in universe aren't pulled into main just because they are build-depends.
[13:13] <xnox> yeay
[13:15] <xnox> wow
[13:15] <xnox> just wow
[13:15] <xnox> i can't even believe we managed to do this =)
[13:15] <xnox> i mean when i first used linux, archive reorg was an "acient thing that never got implemented"
[13:19] <xnox> doko, so new boost needs to be uploaded that builds both main & universe packages, and then it should still correctly ship "mpi" bits into universe, and then we can purge boost-mpi package.
[13:20] <pitti> mvo, juliank: I can't make much sense of bug 1560797 -- it seems after unpacking libgcrypt20, apt decides to try and configure systemd instead of configuring libgcrypt20 first
[13:20] <pitti> but all of libgcrypt20's deps are already configured, so there should be nothign that prevents libgcrypt20 configuration
[13:21] <pitti> do you have any idea how to debug this further?
[13:21] <pitti> (I wasn't able to reproduce this)
[13:21] <pitti> oh, this uses libgcrypt20:amd64 *and* libgcrypt20:i386, maybe that will help to reproduce it
[14:21] <pitti> slangasek, cyphermox, jibel: *phew*, we nailed bug 1554266; thanks to nuclearbob for being remote hands
[14:22] <cyphermox> what was it?
[14:22] <pitti> see the last two bug comments
[14:22] <pitti> TL;DR: installing a package while the boot was still going on
[14:22] <cyphermox> oh, interesting
[14:22] <pitti> which is highly timing dependent on how fast your network/disks are, i. e. whether booting finishes  first, or download/unpack
[14:23] <pitti> i. e. time bomb :)
[14:23] <cyphermox> well, not just boot..
[14:23] <pitti> and allegedy the CI lab was moved to a faster network recently
[14:23] <cyphermox> this would be running after boot, towards the end (or at least the middle) of installation
[14:23] <cyphermox> so if systemd thinks it's still in a boot phase, we have something wrong in the ubiquity-dm service
[14:23] <pitti> cyphermox: Max will put it back into the OS install, in late_command
[14:24] <cyphermox> ok
[14:24] <pitti> cyphermox: but right now rc.local calls apt-get install
[14:24] <pitti> which is *during* boot
[14:24] <cyphermox> mmkay
[14:24] <cyphermox> well, that's not fixing the bug
[14:24] <pitti> (I suggested an alternative approach with waiting until the boot is finished, but Max knows this stuff better)
[14:24] <pitti> so installing openssh-server as part  of installing the OS instead of during first boot sounds fine
[14:25] <pitti> and apparently it used to be that way, but it was changed some time ago
[14:25] <cyphermox> pitti: installing openssh was already being part of the install, and that was not working
[14:25] <pitti> anyway, we have an explanation and two proposals now
[14:25] <cyphermox> well, we'll see, I'm not holding my breath
[14:31] <cjwatson> Laney: is there some way to get appstream to say what it actually means when it says "AppStream cache update completed, but some metadata was ignored due to errors" ?
[14:34] <Laney> cjwatson: Ummmmmmmmmmmmm
[14:34] <Laney> I think there's an appstreamcli subcommand for that
[14:37] <gQuigs> cjwatson: interesting - http://pastebin.ubuntu.com/15688945/
[14:38] <cjwatson> OK, so it actually means errors inside the metadata tarball?
[14:38] <Laney> I don't see it here
[14:38] <cjwatson> Yeah, seems so here
[14:39] <cjwatson> In that case I don't care - I just wanted to make sure it wasn't a problem prompted by by-hash
[14:39] <Laney> but it sounds like it comes from appstreamcli refresh-index
[14:39] <Laney> ah I probably don't have the new appstream from yesterday
[14:39] <cjwatson> https://paste.ubuntu.com/15688991/ here
[14:40] <cjwatson> also worth noting there that it's downloading both from my local mirror and from the archive
[14:40] <cjwatson> so perhaps that's the cause of colliding ids?
[14:40] <Laney> Yeah, don't think that particularly matters
[14:41] <Laney> I would guess it's the warning
[14:41] <Laney> I'll look into it, thanks for the report
[14:46] <gQuigs> cjwatson: so apt-get update hangs for me.. new problem as of today...
[14:46] <gQuigs> http://pastebin.ubuntu.com/15689150/
[14:47] <gQuigs> but I can browse to the archive website fine...
[14:51] <gQuigs> cjwatson: and it's my fault, nevermind
[14:59] <nacc> slangasek: ok, will investigate those
[15:04] <morphis_> does anybody know if I can tell launchpad to not truncate diffs on a merge proposal?
[15:14] <teward> morphis_: #launchpad may be able to answer that better
[15:15] <dobey> morphis_: you cannot
[15:15] <teward> or that
[15:15] <morphis_> dobey, teward: thanks .. that somehow makes reviews superflous with MPs if people can't really comment on the whole thing in line
[15:16] <nacc> rbasak: might need your help on these php regressions, too; default mysql permissions seem to be denying root@localhost
[15:16] <dobey> morphis_: e-mail works fine. the e-mail has the whole diff
[15:16] <rbasak> nacc: there are two possibilities for that.
[15:16] <morphis_> dobey: sure
[15:16] <dobey> but yeah, not nice for in-line replies on the web site
[15:17] <rbasak> nacc: first is that you're setting an empty root password, possibly by installing non-interactively. In this case login as MySQL root by a non-root Unix user is no longer permitted. I can understand this might impact testing.
[15:18] <nacc> rbasak: ok, i can update the tests; that's almost certainly what this module does (presumably the default?)
[15:18] <rbasak> nacc: second is that there's currently a bug that prevents dpkg-reconfigure from setting a root password later if it is originally unset. We'll have a fix for that early next week.
[15:18] <nacc> rbasak: ok, i'll reproduce locally and let you know
[15:18] <nacc> rbasak: thanks for the quick response!
[15:19] <rbasak> nacc: one final thing. Another bug: if ~/.my.cnf or ~root/.my.cnf exists at the time the mysql postinst is run, it interferes with the initial configuration of the database. We should have a fix for that early next week too.
[15:19] <nacc> rbasak: yeah i saw that yesterday; for the first case is there a config option i can tweak or is that permanently disabled?
[15:20] <rbasak> nacc: no config option currently. Perhaps there should be one You could work around by tweaking the config as root before going non-root, but I'm not sure if that'll stay when the postinst runs again.
[15:20] <nacc> rbasak: right, will just verify if that's the issue, at least
[15:21] <nacc> rbasak: this is in an autopkgtest, fwiw
[15:22] <rbasak> nacc: does it run as root or non-root? Ie. does it have a Restrictions: needs-root?
[15:22] <nacc> rbasak: it has needs-root
[15:23] <rbasak> nacc: then you might be able to work around in the autopkgtest by switching the auth type back to password for the root user
[15:23] <rbasak> It's OK for a test to have an empty password I guess.
[15:24] <Skuggen> If it's run as root it'll log in successfully even if you specify a password that's not valid (if the auth_socket is set)
[15:25] <nacc> it could easily be some bug in the php-mysql implementation relative to mysql 5.7, so want to eliminate one thing at a time :)
[15:25] <nacc> rbasak: quick reference on how to do that?
[15:27] <Skuggen> nacc: Switching auth back to password?
[15:27] <nacc> Skuggen: yep
[15:28] <Skuggen> Can you log in as root at the start of the test?
[15:29] <Skuggen> To switch it back, right now you have to log in and run "ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' IDENTIFIED BY 'somepassword'";
[15:30] <nacc> Skuggen: let me see
[15:31] <Skuggen> If you've installed in noninteractive so password was blank, any attempt to log in as mysql-root as unix-root should succeed
[15:31] <nacc> rbasak: ah i see, the test runs as root to set up the db, then drops to www-data :/
[15:31] <nacc> Skuggen: yes, logging in as root w/o password does work by default
[15:31] <nacc> so i think it's something elese
[15:31] <Skuggen> For ruby-mysql we used that setup to create a separate user to use for the rest of the tests
[15:32] <Skuggen> Could you just put up the test setup on pastebin or something (I'm not at a worky-computer)
[15:33] <nacc> Skuggen: http://paste.ubuntu.com/15690307/
[15:33] <nacc> Skuggen: i think that it's the exported CONFIGs
[15:33] <nacc> that specify to use root w/o password
[15:33] <nacc> for the www-data user (given --preserve-environment)
[15:34] <Skuggen> "mysql -e 'create database IF NOT EXISTS test;' -uroot" If you just add the query I pasted above after ;, I think it should work
[15:35] <Skuggen> Though erase somepassword
[15:35] <nacc> Skuggen: ok, let me try
[15:38] <nacc> Skuggen: putting IDENTIFIED BY '' threw an error: "You have an error in your SQL syntax"
[15:38] <Skuggen> Are you using the same quotes you put around the entire query?
[15:39] <nacc> Skuggen: http://paste.ubuntu.com/15690484/ ?
[15:40] <Skuggen> Hm, maybe it needs the ; at the end
[15:40] <Skuggen> i.e. after identified by ''
[15:41] <nacc> nope
[15:41] <nacc> :)
[15:41] <Skuggen> Does it give a syntax error if you have an actual password?
[15:41] <nacc> yeah, the same one, i think
[15:42] <nacc> Skuggen: no second IDENTIIFIED
[15:42] <nacc> Skuggen: IDENTIFIED WITH ... BY ...
[15:43] <Skuggen> Aah
[15:43] <nacc> Skuggen: great, tests pass now, thanks!
[15:43] <Skuggen> \o/
[15:47]  * mvo hugs cjwatson for landing by-hash in LP
[15:51] <cjwatson> mvo: thanks for the apt side!  that reminds me, meant to credit you in my blog post
[15:52] <cjwatson> mvo: oh, thanks for merging my apt-ddtp-tools branch.  did you see my request for a ddtp-translations upload with that?
[15:53] <mvo> cjwatson: I was just importing the latest debian translations and will upload in  a bit
[15:53] <mvo> cjwatson: its a bit slow (the generation of the files)
[15:54] <cjwatson> ah, ok, cool
[15:55] <mvo> cjwatson: thank you for the branch :) i18n back in xenial.
[16:08] <nacc> slangasek: i think i figured out the sabredav failure as well; it might have been relying on a buggy php behavior with the default include path, testing now
[16:17] <cyphermox> pitti: is there a way to tell systemd to not  try to automatically activate swap for a period of time?
[16:31] <nacc> Pharaoh_Atem: is it possible to build a pear extension with debug symbols as part of `pear/pecl install` ?
[16:36] <nacc> ha! faked it with export CFLAGS= :)
[16:53] <pitti> cyphermox: several, but the simplest one is certainly to comment it out from /etc/fstab or add "noauto" to iit
[16:53] <pitti> cyphermox: or systemctl mask your-swap-unit.swap (check systemctl --all -t swap)
[16:53] <cyphermox> it wouldn't be in /etc/fstab
[16:53] <cyphermox> it's detected swap in the live session
[16:55] <pitti> cyphermox: oh, GPT?
[16:55] <cyphermox> err, maybe, I don't know?
[16:55] <pitti> systemd-gpt-auto-generator(8) runs at boot and autodetects swap partitions
[16:55] <pitti> there's no auto-detection that I know of for MBR
[16:56] <pitti> cyphermox: can you describe this in some more details in a bug report or mail or so, and I'll look at it next week? sorry, gotta run now
[16:56] <cyphermox> pitti: there's a bug already, I'll send you the link by email
[16:58] <Pharaoh_Atem> nacc: I've not been able to myself
[16:59] <Pharaoh_Atem> afaik, pear stuff explicitly is pure-php, so there's no debug stuff to get
[16:59] <nacc> Pharaoh_Atem: ok, it did work for me, trying to debug a php5 sigill with redis
[16:59] <Pharaoh_Atem> hmm
[16:59] <nacc> Pharaoh_Atem: ok, this was pecl
[16:59] <Pharaoh_Atem> ah
[16:59] <pitti> cyphermox: ah, just subscribe me, I get that bug mail into the right folder
[16:59] <nacc> Pharaoh_Atem: which `pear` wraps if you do an 'upgrade-all'
[16:59]  * pitti runs, good weekend everyone!
[16:59] <Pharaoh_Atem> ohh
[17:00] <Pharaoh_Atem> I've had trouble getting the debug stuff to register when trying to do it myself with libvirt-php stuff
[17:02] <nacc> Pharaoh_Atem: export CFLAGS seems to work for php-redis, at least
[17:02] <nacc> Pharaoh_Atem: what's the status on libvirt-php, btw?
[17:02] <Pharaoh_Atem> I got a colleague to write up a good number of unit tests, eclipsing the current set from before
[17:03] <Pharaoh_Atem> and I'm preparing to push that work to my GitLab and send a patch series to the libvirt mailing list
[17:04] <nacc> Pharaoh_Atem: great!
[17:04] <Pharaoh_Atem> from what I can tell, it works fine in php5 and php7
[17:04] <Pharaoh_Atem> so at least nothing is *more* broken than before
[17:05] <nacc> Pharaoh_Atem: which is something :)
[17:06] <slangasek> nacc: https://launchpad.net/ubuntu/+source/php-horde-db/2.3.1-1ubuntu2/+build/9552276
[17:06] <nacc> slangasek: "chroot problem"?
[17:07] <slangasek> nacc: oops that's a chroot problem, nevermind
[17:07] <nacc> slangasek: also, i got a couple of emails with hash sum mismatches for php-sabredav
[17:07] <slangasek> oh?
[17:07] <nacc> https://launchpad.net/ubuntu/+source/php-horde-db/2.3.1-1ubuntu2/+build/9552276/+files/buildlog_ubuntu-xenial-amd64.php-horde-db_2.3.1-1ubuntu2_BUILDING.txt.gz
[17:07] <slangasek> maybe somebody else tried to sponsor you in parallel
[17:07] <slangasek> for the chroot problem, that's obviously the chroot's problem, not yours :-)
[17:07] <nacc> slangasek: sorry, in the repo itself, looks to be the translations
[17:08]  * Pharaoh_Atem double checks to make sure libvirt is new enough
[17:08] <Pharaoh_Atem> yep, we're good on xenial libvirt
[17:08] <Pharaoh_Atem> I found out the hard way that trusty's libvirt is too old
[18:02] <cjwatson> nacc,slangasek: oh, heh, I see why this is still happening even after deploying by-hash
[18:02] <cjwatson> the xenial chroots are still copies of the wily ones, and wily's apt is too old to support by-hash
[18:02] <cjwatson> so until the initial upgrade runs, the buildd's apt doesn't support by-hash yet
[18:02] <slangasek> hah
[18:03] <cjwatson> infinity: please could you update the xenial chroots sometime *before* we release? :)
[18:03] <juliank> pitti: This APT ordering thing looks awful, but I don't know what to do about it. Maybe there's a complicated pre-depends or conflicts/breaks cycle somewhere?
[18:03] <cjwatson> (the above is with the exception of s390x, which has been updated rather more recently and of course didn't exist in wily)
[18:04] <juliank> And yes, the ordering code is somewhat suboptimal
[18:14] <slangasek> juliank: systemd-sysv Pre-Depends: systemd which probably has to do with it, but I don't see any cycles that would force apt to configure this before libgcrypt20
[18:16] <juliank> There probably is no sane-ish reason to do that, ordering is just somewhat broken in some places.
[18:17] <slangasek> heh
[18:17] <slangasek> APT, Approximate Package Tool? ;)
[18:30] <nacc> cjwatson: oh i see
[19:17]  * elbrus wonders if Debian bug 820475 applies to Ubuntu's php7.0 as well (which would mean a regression)
[19:17] <elbrus> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820475
[19:17]  * elbrus has no Ubuntu system to check...
[19:26] <slangasek> elbrus: it is a "regression" in the sense that the packaging of php7.0 deliberately moves the xml module into a separate binary package instead of carrying it as a builtin.  It looks like cacti needs to add a dep on php-xml now, which I don't see was done yet in Ubuntu - nacc can probably help make that happen
[19:27] <elbrus> slangasek: good to know...
[19:27] <elbrus> and thanks for looking into it.
[19:28]  * elbrus will close the Debian bug than as well
[19:28] <slangasek> no problem, sadly I have a visual trigger on php at the moment ;)
[19:28] <elbrus> sadly for you, great for me in this case
[19:28] <elbrus> (and for cacti in Ubuntu)
[19:30]  * elbrus confirms that installing php-xml does the trick in Debian/unstable
[19:31]  * elbrus is adding an autopkgtest to cacti, that is how I found out
[19:34] <slangasek> wahoo, +1 for autopkgtest
[19:49] <elbrus> slangasek: do you recognize "Call to undefined function mb_strlen"? is that also in an other package now, or is that just deprecated?
[19:50] <slangasek> elbrus: yes, also split out - php-mbstring if I remember the name
[19:53] <elbrus> slangasek: great thanks... nacc: will you pick up these dependencies for cacti in Ubuntu?
[20:10] <elbrus> hmm, installing php-mbstring didn't seem to solve it, but than again, installing the php package doesn't trigger apache to reload/restart... is that a bug or a feature?
[20:11] <sarnold> imho seems like a feature; there's dozens of ways php can be used and not all of thm even require a web server
[20:11] <elbrus> sarnold: I feared that...
[20:12] <Unit193> I have php but not apache.
[20:12] <elbrus> aha, I guess as a dependency, it is resolved of course in postinst.
[20:13] <elbrus> when doing stuff for apache...
[20:13] <elbrus> yeah... php7.0 and cacti now work (on Debian)
[20:14] <elbrus> at least according to my wget call...
[20:41] <nacc> elbrus: what's up? cacti depends on mbstring and xml?
[20:46] <nacc> elbrus: slangasek: debdiff attached to LP: #1568136
[20:52] <nacc> elbrus: thanks for the report, i had tested the basic functionality you had mentioned in the other bug but nothing else (I rarely know how to test php applications unless they have autopkgtests :)
[20:52] <nacc> slangasek: so i think (based upon my reading of excuses) php7.0 should be a valid candidate now?
[20:54] <slangasek> nacc: IFF it says 'Valid candidate' at the bottom of the stanza :)
[20:54] <slangasek> I still see the php-sabredav, php-horde-db failures
[20:55] <nacc> slangasek: they haven't been rerun w/ the current version?
[20:55] <slangasek> nacc: that *may* be because I tripped over syntax and only retriggered for ppc64el
[20:55] <nacc> slangasek: as php-sabredav already migrated, and php-horde-db is a valid candidated
[20:56] <nacc> slangasek: ah could be, i see it doesn't indicate ppc64el failed anymore
[20:56] <slangasek> nacc: yes, that only means that new php-sabredav and new php-horde-db passed their tests with current php-defaults in xenial; now it's the cross-test that's needed, triggered now
[22:07] <nacc> cjwatson: just did an `apt-get update` at home, and got some DEP-11 hash sum mismatches from my local mirror. Is that a case of propogation taking some time, or do i need to clear my local cache for the by-hash change?
[22:09] <infinity> (base)adconrad@nosferatu:~$ grep Acquire /var/lib/apt/lists/*Release
[22:09] <infinity> /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial_InRelease:Acquire-By-Hash: yes
[22:09] <infinity> nacc: You have that?
[22:10] <infinity> cjwatson: Erm, is it intentional or a bug that the post-release pockets don't have A-B-H set?
[22:12] <infinity> cjwatson: Or is there some clever plan to flip state when we go from pre-release states to released states, and turn off by-hash on the release pocket and turn it on on post-release pockets?  (which would actually make sense, the hashes are useless on a frozen pocket, just wasted space)
[22:12] <nacc> infinity: hrm, no, not set, nm
[22:13] <infinity> nacc: Right, if it's not set, then your mirror is out of date.
[22:13] <nacc> infinity: yep, makes sense
[22:13] <infinity> (base)adconrad@nosferatu:~$ grep ^Date /var/lib/apt/lists/*Release
[22:13] <infinity> /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial_InRelease:Date: Fri, 08 Apr 2016 21:02:46 UTC
[22:13] <infinity> /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-security_InRelease:Date: Wed, 03 Feb 2016 15:23:44 UTC
[22:13] <infinity> /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-updates_InRelease:Date: Wed, 03 Feb 2016 15:23:44 UTC
[22:13] <infinity> cjwatson: Oh, I see.  Not so much bug as feature, since the post-release xenial pockets haven't been dirty (and thus, not republished) since Feb 03. :P
[22:14]  * infinity wonders what made them republish in February...
[22:15] <nacc> infinity: yep (note needed `grep -r`, as it's partial here, maybe due to the mismatch?) but mine is at 8 Apr 3:00 UTC, quite out of date
[22:15] <infinity> nacc: Yeah, partial/ is where temp files go, and move to .. when they're validated to be good and shiny and true.
[22:16] <nacc> infinity: makes sense!
[22:16] <nacc> infinity: thanks!
[22:17] <infinity> nacc: So yeah, if your mirror is on a 24h sync schedule (not uncommon), you'll likely see it all happy tomorrow.
[22:18] <nacc> infinity: yep
[22:18] <Pharaoh_Atem> nacc: https://www.redhat.com/archives/libvir-list/2016-April/msg00402.html :P
[22:18] <infinity> nacc: And this, incidentally, is why we always include security.ubuntu.com in the default sources.list.  So your local mirror can be wildly out of date, and you still get 99% of packages from it, but you don't end up lagging on security updates.
[22:20] <nacc> infinity: yep, that makes total sense and is obvious now :)
[22:20] <nacc> infinity: good policy :)
[22:21] <nacc> Pharaoh_Atem: nice! i look forward to seeing that get rolled out :)
[22:24] <Pharaoh_Atem> nacc: welp, you can pull it in if you want :P
[22:25] <nacc> Pharaoh_Atem: well, i'd rather wait til it's at least in the libvirt repo
[22:25] <Pharaoh_Atem> :/
[22:25] <Pharaoh_Atem> I hope they review it quickly, then
[22:26] <nacc> Pharaoh_Atem: mostly because i don't want churn or if they reject it
[22:26] <Pharaoh_Atem> yeah, I get it
[22:26] <nacc> Pharaoh_Atem: it's one of our known-broken cases, i'd rather we fix it right when we do fix it
[22:26] <Pharaoh_Atem> okay
[22:26] <Pharaoh_Atem> but at least you can notate that a fix IS coming
[22:27] <nacc> true, i'll update the pad with that link :)
[22:27] <Pharaoh_Atem> I have a newfound disgust for the internals of php
[22:28] <Pharaoh_Atem> the sheer amount of weirdness involved in php has been staggering
[22:31] <nacc> Pharaoh_Atem: ack
[22:31] <nacc> Pharaoh_Atem: pad updated with links for the three outstanding packages
[22:37] <cjwatson> infinity: Yeah, it'll happen when they're republished.  Not really worth the effort to forth it.
[22:38] <cjwatson> *force (where did that come from?)
[22:38] <infinity> cjwatson: Lithp?
[22:38] <infinity> cjwatson: Right, I sorted that out from my looking at Release file timestamps.
[22:39] <infinity> cjwatson: But then that leads to the other question, would there be value in un-hashing release pockets on state change, so we're not carrying a bunch of pointless redundant versions of all the Packages/Sources/etc files?
[22:40] <cjwatson> infinity: No - we'll end up rerunning just the Release file pass a couple of times post-release to reap old by-hash files.
[22:40] <cjwatson> infinity: Not necessarily immediately after xenial, but in the not too distant future in order to enable Valid-Until.
[22:40] <infinity> cjwatson: Okay, so we'll have the "pointless" copies of the final files, but not the pointless history.
[22:41] <cjwatson> I'd rather have everything ultimately end up being by-hash for consistency.
[22:41] <infinity> Yeah, that's fair.
[22:41] <infinity> The copies of the shallow revision aren't too bad, it's the history frozen in time that would be icky.
[22:41] <slangasek> oh, Valid-Until
[22:42] <cjwatson> infinity: They're also hardlinks rather than copies, at least on the master.
[22:42] <infinity> cjwatson: Ahh, right.
[22:42] <cjwatson> Probably not on mirrors though because rsync -H is fairly expensive
[22:42] <infinity> cjwatson: Indeed, we've had that conversation.
[22:42] <infinity> cjwatson: But at least on master, wacking the history is enough to reclaim waste.
[22:43] <infinity> On mirrors, meh.  It's a ton of space, but not relative to the archive size.
[22:43] <cjwatson> Quite.
[22:44] <infinity> cjwatson: I'm going to assume you had to submit some fun patches to magicmirror to make the arch split not vomit?
[22:44] <infinity> Actually, how would that even work?  Since magicmirror's whole thing is "delete if not referenced", and all but the latest hash aren't referenced by anything...
[22:45] <cjwatson> infinity: No, for a change it didn't need any changes.  The by-hash directories are all immediately alongside the by-name versions, so you have dists/xenial/main/binary-amd64/by-hash/...
[22:45] <infinity> Stay of execution on by-hash/* I guess.
[22:45] <cjwatson> Dunno but it totally has a ton of them.
[22:45] <infinity> Oh, maybe the reference magic is only for pool/
[22:46] <infinity> And dists is just assumed correct and synced wholesale (except for the /$arch/ filter)
[22:46] <cjwatson> Yeah, looking that way to me.
[22:46] <cjwatson> The timestamp magic can all go away, and I submitted an MP for that a while back that hasn't been reviewed yet, but it doesn't matter for by-hash.
[22:47]  * infinity nods.
[22:50] <infinity> cjwatson: Oh, and I'll update the chroots.  I kinda forgot to care after you wrote bootstrap-package, and then I almost saw it as a feature, since the base system dist-upgrade helped me catch and fix a couple of bugs during the cycle. :P
[22:52] <cjwatson> Heh.  Thanks.
[22:52] <infinity> If I can find a spare moment to breathe, I'll automate chroot building in LP/+livefs for 16.10
[22:52] <infinity> With some sort of post-build validation magic, so I can upload them without fear.
[23:20] <tkamppeter> infinity, hi
[23:21] <infinity> tkamppeter: Hey.
[23:21] <tkamppeter> infinity, did you already look into the LSB printer driver problem?
[23:21] <infinity> tkamppeter: Not yet, but it's on my list before release.
[23:22] <tkamppeter> infinity, OK.
[23:28] <nacc> slangasek: started working (or was going to) on my dev application, but the wiki seems to hate me :)
[23:28] <nacc> slangasek: will work on it next week, so hopefully will have to pester you a lot less at some point