[01:03] 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:03] Launchpad bug 1374892 in php-apcu (Ubuntu) "Please backport php5-apcu version 4.0.6 to Ubuntu 14.04 LTS" [Undecided,Confirmed] https://launchpad.net/bugs/1374892 [01:04] slangasek: we have 4.0.7-ish in backports, but this bug is specifically about updating the official one [01:04] (upstream maintainers always say that :) [01:04] sarnold: at least in this case, i think the extension crashes/hangs pretty easily [01:04] sarnold: but that is a fair point [01:04] sometimes they're right :) but still [01:05] sarnold: right, so i'd like to understand what i can do to figure it out [01:07] 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] slangasek: yep, i was reviewing that; I will see what kind of testing I can do / ask the community to do [01:10] nacc: I'm not at all against accepting an SRU on the "it's broken" grounds. [01:11] If the one in backports has no dependencies in backports, we could just copy it over. [01:11] 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] infinity: most say it's better, at least (meaning it's usable) [01:12] 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] nacc: Err, no, I meant the binary itself shouldn't have backports deps. [01:14] 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] 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] infinity: oh i see [01:16] infinity: i don't believe that's the case here; I will dig into it a bit tmrw === alkisg_away is now known as alkisg [06:13] Good morning [06:16] Good morning [06:21] It appears that Ubuntu's network-manager patches have something to do with the nbd-client's cyclic dependencies... (LP: #1487679) [06:21] Launchpad bug 1487679 in nbd (Ubuntu) "Breaking ordering cycle by deleting job nbd-client.service/start" [Undecided,Triaged] https://launchpad.net/bugs/1487679 [06:26] I.e. that any sysvinit service that has "Required-Start: $network" is causing loops in Ubuntu, but not in Debian [06:27] nacc: php-horde-db tests regress with mysql-5.7 === athairus is now known as afkthairus [06:31] cyphermox, did we get anywhere with the n-m 1.2 update? [06:46] nacc: php-sabredav also fails with an incompatibility between php-sabredav and some dependency [07:20] alkisg: not "any" sysvinit service, but rcS ones; we've seen that happen in Debian too [07:20] alkisg: most prominently with nfs-utils, as Debian's package still uses the single sysv script instead of the units [07:20] this comes up on (Debian) IRC every so often [07:21] 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] pitti: have the patches been sent to the BTS? I haven't looked at nfs-utils at all recently [07:49] 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] 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] pitti: [07:52] slangasek: i. e. if you plan to update Debian at all, I'm fine with massaging those for Debian (changelog cleanup, etc.) [07:52] slangasek: and send them to some appropriate debian bug [07:52] pitti: I don't have any near-term plans, but a patch to the BTS would be helpful; there are comaintainers [07:53] we don't want the upstart changes in Debian supposedly, as upstart is gone there [07:54] they don't hurt anything, and if it reduces the delta then I'd be for them [07:54] 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:54] Debian bug 765731 in nfs-kernel-server "nfs-kernel-server: Service ordering cycle under systemd" [Normal,Open] http://bugs.debian.org/765731 [07:56] slangasek: well, I suppose we won't keep them much longer either, do we? ubuntu touch won't need NFS [07:57] maybe there's a new upstream version by now which incorporates these patches [07:57] ah, 1.3.3 [07:58] so, updating to that would get rid of 90% of the patches already === hikiko is now known as hikiko|ln [11:01] doko: new vim seems to break vim-addon-manager (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#vim) [11:01] currently checking if that's a real regression, or fallout from some ruby change [11:01] E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/universe/source/Sources Writing more data than expected (9699328 > 9651713) [11:01] le what? [11:03] pitti: I think that error happens when apt gets a new InRelease, but old Packages/Sources (or the other way around). [11:04] I consistently get it in my containers now, might be some fallout wrt. the recent "by-hash" enablement and apt-cacher-ng [11:05] hm, still the same thing after cleaning /var/cache/apt-cacher-ng/uburep === darkxst_ is now known as darkxst [11:15] meh, this happens with a *completely clean* /var/lib/apt/lists and /var/cache/apt-cacher-ng/ [11:15] it's like something in the metadata contradicts with each other [11:21] pitti: by-hash isn't advertised yet. I suspect the contrary: your problem will go away once we advertise it :) [11:21] pitti: Try with 'deb [by-hash=force] http://...' for the relevant sources.list line; I bet that fixes it [11:22] 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] Debian bug 819852 in apt-cacher-ng "apt-cacher-ng: support by-hash index files" [Normal,Open] [11:22] cjwatson: no, I have current xenial version with your patch [11:22] pitti: OK, good, just try [by-hash=force] then [11:23] apt-cacher-ng might have just decided to cache a stale Sources, or perhaps some other proxy in the way [11:23] yay, works wonders [11:23] 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] pitti: could be something else on the network path between you and a.u.c [11:24] cjwatson: thanks for the hint with [by-hash=force]! [11:24] pitti: planning to turn it on by default today; I just want to check that deletion is working [11:24] cjwatson: ah, I'm on the VPN, maybe there's some transparent proxy in between indeed [11:24] 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] (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] I had only the required-start: $network part with no other headers at all... === hikiko|ln is now known as hikiko [11:36] pitti, yes, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820313 [11:36] Debian bug 820313 in vim-common "vim-addon-manager ftbfs (tests are failing)" [Serious,Fixed] [12:07] re [12:07] jdstrand: IT WORKS :-) [12:13] xnox: are you working on the rsyslog s390x FTBFS? [12:18] rbasak, did not see that. [12:18] rbasak, is there a bug number? [12:19] xnox, see the test rebuild [12:19] xnox: no, it's just in http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160401-xenial.html [12:20] doko, rbasak - did not go through s390x only ftbfs yet [12:27] doko: ah, so that was fixed in vim itself [12:27] pitti, package in unapproved === _salem is now known as salem_ [12:34] doko: no, it's not :-) [12:34] doko: (i. e. accepted, thank you!) [12:35] xnox: is it actually part of the specification that just about every tool and acronym on s390x is utterly unpronouncible? :-) [12:36] pitti, yes Ram is Storage and etc. [12:36] dasdfmt, fdasd, lpar, chzdev, this all sounds much more like "cat jumped on the keyboard" :-) [12:36] pitti, do we need a guidelines of acronyms? [12:37] 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] xnox: I figure zSeries' guidelines are "must contain at least 80% consonants and have a non-memorizable name" [12:37] xnox: (no worries, j/k -- it's Friday afternoon) [12:37] just spotted some more of this during unapproved review [12:38] 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] pitti: all right, can we do this by-hash thing? [12:38] pitti: lp-shell production devel, then xenial = lp.load('/ubuntu/xenial'); xenial.advertise_by_hash = True; xenial.lp_save() [12:38] cjwatson: I haven't heard of any problems [12:38] cjwatson: Fri afternoon is the perfect time :) [12:38] 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] on all linuxes. [12:38] 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] yay [12:43] cjwatson: thanks and congrats, this is an amazingly nice feature [12:44] "hash sum mismatch"-b-gone! [12:44] fingers crossed. there will be an assortment of problems with mirror scripts, but they should be no worse than previous behaviour [12:57] zyga: woohoo! :) [12:58] * jdstrand hugs zyga :) [12:58] 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] it seems that irc password is saved as a dbus type signature instead, some missing function call somewhere :P [12:59] anyway... [12:59] jdstrand: one critical thing is to get the template in line [12:59] jdstrand: we have two options [12:59] jdstrand: but I think for 16.04 we should just get rid of all unused variables [12:59] jdstrand: and use "modern" names everyhwere [12:59] jdstrand: I'll explain details in a sec, I have to go to a meeting [13:03] zyga: (see my response in #snappy-- I'm not going to be available for several hours (many meetings, need prep, etc) [13:03] ) [13:08] xnox, should we kick out the separate boost-mpi source? [13:08] doko, if universe got enabled, yes. [13:09] doko, e.g. no-follow-build-depends [13:09] but i'm not sure what the status there is. [13:09] hmm, true. currently only seen in component-mismatches [13:12] xnox: it's done [13:13] Set no-follow-build-depends feature, so packages in universe aren't pulled into main just because they are build-depends. [13:13] yeay [13:15] wow [13:15] just wow [13:15] i can't even believe we managed to do this =) [13:15] i mean when i first used linux, archive reorg was an "acient thing that never got implemented" [13:19] 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] 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] bug 1560797 in systemd (Ubuntu) "package systemd-sysv 225-1ubuntu9.1 failed to install/upgrade: libgcrypt20 was unconfigured" [Undecided,Confirmed] https://launchpad.net/bugs/1560797 [13:20] but all of libgcrypt20's deps are already configured, so there should be nothign that prevents libgcrypt20 configuration [13:21] do you have any idea how to debug this further? [13:21] (I wasn't able to reproduce this) [13:21] oh, this uses libgcrypt20:amd64 *and* libgcrypt20:i386, maybe that will help to reproduce it [14:21] slangasek, cyphermox, jibel: *phew*, we nailed bug 1554266; thanks to nuclearbob for being remote hands [14:21] bug 1554266 in UTAH "sshd does not start on newly installed desktop system" [Undecided,Triaged] https://launchpad.net/bugs/1554266 [14:22] what was it? [14:22] see the last two bug comments [14:22] TL;DR: installing a package while the boot was still going on [14:22] oh, interesting [14:22] which is highly timing dependent on how fast your network/disks are, i. e. whether booting finishes first, or download/unpack [14:23] i. e. time bomb :) [14:23] well, not just boot.. [14:23] and allegedy the CI lab was moved to a faster network recently [14:23] this would be running after boot, towards the end (or at least the middle) of installation [14:23] so if systemd thinks it's still in a boot phase, we have something wrong in the ubiquity-dm service [14:23] cyphermox: Max will put it back into the OS install, in late_command [14:24] ok [14:24] cyphermox: but right now rc.local calls apt-get install [14:24] which is *during* boot [14:24] mmkay [14:24] well, that's not fixing the bug [14:24] (I suggested an alternative approach with waiting until the boot is finished, but Max knows this stuff better) [14:24] so installing openssh-server as part of installing the OS instead of during first boot sounds fine [14:25] and apparently it used to be that way, but it was changed some time ago [14:25] pitti: installing openssh was already being part of the install, and that was not working [14:25] anyway, we have an explanation and two proposals now [14:25] well, we'll see, I'm not holding my breath [14:31] 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] cjwatson: Ummmmmmmmmmmmm [14:34] I think there's an appstreamcli subcommand for that [14:37] cjwatson: interesting - http://pastebin.ubuntu.com/15688945/ [14:38] OK, so it actually means errors inside the metadata tarball? [14:38] I don't see it here [14:38] Yeah, seems so here [14:39] In that case I don't care - I just wanted to make sure it wasn't a problem prompted by by-hash [14:39] but it sounds like it comes from appstreamcli refresh-index [14:39] ah I probably don't have the new appstream from yesterday [14:39] https://paste.ubuntu.com/15688991/ here [14:40] also worth noting there that it's downloading both from my local mirror and from the archive [14:40] so perhaps that's the cause of colliding ids? [14:40] Yeah, don't think that particularly matters [14:41] I would guess it's the warning [14:41] I'll look into it, thanks for the report [14:46] cjwatson: so apt-get update hangs for me.. new problem as of today... [14:46] http://pastebin.ubuntu.com/15689150/ [14:47] but I can browse to the archive website fine... [14:51] cjwatson: and it's my fault, nevermind === fginther` is now known as fginther [14:59] slangasek: ok, will investigate those [15:04] does anybody know if I can tell launchpad to not truncate diffs on a merge proposal? [15:14] morphis_: #launchpad may be able to answer that better [15:15] morphis_: you cannot [15:15] or that [15:15] dobey, teward: thanks .. that somehow makes reviews superflous with MPs if people can't really comment on the whole thing in line [15:16] rbasak: might need your help on these php regressions, too; default mysql permissions seem to be denying root@localhost [15:16] morphis_: e-mail works fine. the e-mail has the whole diff [15:16] nacc: there are two possibilities for that. [15:16] dobey: sure [15:16] but yeah, not nice for in-line replies on the web site [15:17] 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] rbasak: ok, i can update the tests; that's almost certainly what this module does (presumably the default?) [15:18] 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] rbasak: ok, i'll reproduce locally and let you know [15:18] rbasak: thanks for the quick response! [15:19] 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] 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] 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] rbasak: right, will just verify if that's the issue, at least [15:21] rbasak: this is in an autopkgtest, fwiw [15:22] nacc: does it run as root or non-root? Ie. does it have a Restrictions: needs-root? [15:22] rbasak: it has needs-root [15:23] 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] It's OK for a test to have an empty password I guess. [15:24] 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] 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] rbasak: quick reference on how to do that? [15:27] nacc: Switching auth back to password? [15:27] Skuggen: yep [15:28] Can you log in as root at the start of the test? [15:29] 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] Skuggen: let me see [15:31] 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] rbasak: ah i see, the test runs as root to set up the db, then drops to www-data :/ [15:31] Skuggen: yes, logging in as root w/o password does work by default [15:31] so i think it's something elese [15:31] For ruby-mysql we used that setup to create a separate user to use for the rest of the tests [15:32] Could you just put up the test setup on pastebin or something (I'm not at a worky-computer) [15:33] Skuggen: http://paste.ubuntu.com/15690307/ [15:33] Skuggen: i think that it's the exported CONFIGs [15:33] that specify to use root w/o password [15:33] for the www-data user (given --preserve-environment) [15:34] "mysql -e 'create database IF NOT EXISTS test;' -uroot" If you just add the query I pasted above after ;, I think it should work === afkthairus is now known as athairus [15:35] Though erase somepassword [15:35] Skuggen: ok, let me try [15:38] Skuggen: putting IDENTIFIED BY '' threw an error: "You have an error in your SQL syntax" [15:38] Are you using the same quotes you put around the entire query? [15:39] Skuggen: http://paste.ubuntu.com/15690484/ ? [15:40] Hm, maybe it needs the ; at the end [15:40] i.e. after identified by '' [15:41] nope [15:41] :) [15:41] Does it give a syntax error if you have an actual password? [15:41] yeah, the same one, i think [15:42] Skuggen: no second IDENTIIFIED [15:42] Skuggen: IDENTIFIED WITH ... BY ... [15:43] Aah [15:43] Skuggen: great, tests pass now, thanks! [15:43] \o/ [15:47] * mvo hugs cjwatson for landing by-hash in LP [15:51] mvo: thanks for the apt side! that reminds me, meant to credit you in my blog post [15:52] mvo: oh, thanks for merging my apt-ddtp-tools branch. did you see my request for a ddtp-translations upload with that? [15:53] cjwatson: I was just importing the latest debian translations and will upload in a bit [15:53] cjwatson: its a bit slow (the generation of the files) [15:54] ah, ok, cool [15:55] cjwatson: thank you for the branch :) i18n back in xenial. [16:08] 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] pitti: is there a way to tell systemd to not try to automatically activate swap for a period of time? [16:31] Pharaoh_Atem: is it possible to build a pear extension with debug symbols as part of `pear/pecl install` ? [16:36] ha! faked it with export CFLAGS= :) [16:53] cyphermox: several, but the simplest one is certainly to comment it out from /etc/fstab or add "noauto" to iit [16:53] cyphermox: or systemctl mask your-swap-unit.swap (check systemctl --all -t swap) [16:53] it wouldn't be in /etc/fstab [16:53] it's detected swap in the live session [16:55] cyphermox: oh, GPT? [16:55] err, maybe, I don't know? [16:55] systemd-gpt-auto-generator(8) runs at boot and autodetects swap partitions [16:55] there's no auto-detection that I know of for MBR [16:56] 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] pitti: there's a bug already, I'll send you the link by email [16:58] nacc: I've not been able to myself [16:59] afaik, pear stuff explicitly is pure-php, so there's no debug stuff to get [16:59] Pharaoh_Atem: ok, it did work for me, trying to debug a php5 sigill with redis [16:59] hmm [16:59] Pharaoh_Atem: ok, this was pecl [16:59] ah [16:59] cyphermox: ah, just subscribe me, I get that bug mail into the right folder [16:59] Pharaoh_Atem: which `pear` wraps if you do an 'upgrade-all' [16:59] * pitti runs, good weekend everyone! [16:59] ohh [17:00] I've had trouble getting the debug stuff to register when trying to do it myself with libvirt-php stuff [17:02] Pharaoh_Atem: export CFLAGS seems to work for php-redis, at least [17:02] Pharaoh_Atem: what's the status on libvirt-php, btw? [17:02] I got a colleague to write up a good number of unit tests, eclipsing the current set from before [17:03] and I'm preparing to push that work to my GitLab and send a patch series to the libvirt mailing list [17:04] Pharaoh_Atem: great! [17:04] from what I can tell, it works fine in php5 and php7 [17:04] so at least nothing is *more* broken than before [17:05] Pharaoh_Atem: which is something :) [17:06] nacc: https://launchpad.net/ubuntu/+source/php-horde-db/2.3.1-1ubuntu2/+build/9552276 [17:06] slangasek: "chroot problem"? [17:07] nacc: oops that's a chroot problem, nevermind [17:07] slangasek: also, i got a couple of emails with hash sum mismatches for php-sabredav [17:07] oh? [17:07] 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] maybe somebody else tried to sponsor you in parallel [17:07] for the chroot problem, that's obviously the chroot's problem, not yours :-) [17:07] 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] yep, we're good on xenial libvirt [17:08] I found out the hard way that trusty's libvirt is too old [18:02] nacc,slangasek: oh, heh, I see why this is still happening even after deploying by-hash [18:02] the xenial chroots are still copies of the wily ones, and wily's apt is too old to support by-hash [18:02] so until the initial upgrade runs, the buildd's apt doesn't support by-hash yet [18:02] hah [18:03] infinity: please could you update the xenial chroots sometime *before* we release? :) [18:03] 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] (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] And yes, the ordering code is somewhat suboptimal [18:14] 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] There probably is no sane-ish reason to do that, ordering is just somewhat broken in some places. [18:17] heh [18:17] APT, Approximate Package Tool? ;) [18:30] 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] Debian bug 820475 in php7.0 "php7.0: php5 to php7.0 regression: undefined function xml_parser_create()" [Normal,Open] http://bugs.debian.org/820475 [19:17] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820475 [19:17] * elbrus has no Ubuntu system to check... [19:26] 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] slangasek: good to know... [19:27] and thanks for looking into it. [19:28] * elbrus will close the Debian bug than as well [19:28] no problem, sadly I have a visual trigger on php at the moment ;) [19:28] sadly for you, great for me in this case [19:28] (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] wahoo, +1 for autopkgtest [19:49] 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] elbrus: yes, also split out - php-mbstring if I remember the name [19:53] slangasek: great thanks... nacc: will you pick up these dependencies for cacti in Ubuntu? === AndyTechGuy_ is now known as AndyTechGuy [20:10] 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] 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] sarnold: I feared that... [20:12] I have php but not apache. [20:12] aha, I guess as a dependency, it is resolved of course in postinst. [20:13] when doing stuff for apache... [20:13] yeah... php7.0 and cacti now work (on Debian) [20:14] at least according to my wget call... [20:41] elbrus: what's up? cacti depends on mbstring and xml? [20:46] elbrus: slangasek: debdiff attached to LP: #1568136 [20:46] Launchpad bug 1568136 in cacti (Ubuntu) "cacti depends on xml and mbstring extensions at runtime" [Undecided,New] https://launchpad.net/bugs/1568136 [20:52] 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] slangasek: so i think (based upon my reading of excuses) php7.0 should be a valid candidate now? [20:54] nacc: IFF it says 'Valid candidate' at the bottom of the stanza :) [20:54] I still see the php-sabredav, php-horde-db failures [20:55] slangasek: they haven't been rerun w/ the current version? [20:55] nacc: that *may* be because I tripped over syntax and only retriggered for ppc64el [20:55] slangasek: as php-sabredav already migrated, and php-horde-db is a valid candidated [20:56] slangasek: ah could be, i see it doesn't indicate ppc64el failed anymore [20:56] 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] 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] (base)adconrad@nosferatu:~$ grep Acquire /var/lib/apt/lists/*Release [22:09] /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial_InRelease:Acquire-By-Hash: yes [22:09] nacc: You have that? [22:10] cjwatson: Erm, is it intentional or a bug that the post-release pockets don't have A-B-H set? [22:12] 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] infinity: hrm, no, not set, nm [22:13] nacc: Right, if it's not set, then your mirror is out of date. [22:13] infinity: yep, makes sense [22:13] (base)adconrad@nosferatu:~$ grep ^Date /var/lib/apt/lists/*Release [22:13] /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial_InRelease:Date: Fri, 08 Apr 2016 21:02:46 UTC [22:13] /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-security_InRelease:Date: Wed, 03 Feb 2016 15:23:44 UTC [22:13] /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-updates_InRelease:Date: Wed, 03 Feb 2016 15:23:44 UTC [22:13] 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] 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] nacc: Yeah, partial/ is where temp files go, and move to .. when they're validated to be good and shiny and true. [22:16] infinity: makes sense! [22:16] infinity: thanks! [22:17] nacc: So yeah, if your mirror is on a 24h sync schedule (not uncommon), you'll likely see it all happy tomorrow. [22:18] infinity: yep [22:18] nacc: https://www.redhat.com/archives/libvir-list/2016-April/msg00402.html :P [22:18] 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] infinity: yep, that makes total sense and is obvious now :) [22:20] infinity: good policy :) [22:21] Pharaoh_Atem: nice! i look forward to seeing that get rolled out :) [22:24] nacc: welp, you can pull it in if you want :P [22:25] Pharaoh_Atem: well, i'd rather wait til it's at least in the libvirt repo [22:25] :/ [22:25] I hope they review it quickly, then [22:26] Pharaoh_Atem: mostly because i don't want churn or if they reject it [22:26] yeah, I get it [22:26] Pharaoh_Atem: it's one of our known-broken cases, i'd rather we fix it right when we do fix it [22:26] okay [22:26] but at least you can notate that a fix IS coming [22:27] true, i'll update the pad with that link :) [22:27] I have a newfound disgust for the internals of php [22:28] the sheer amount of weirdness involved in php has been staggering [22:31] Pharaoh_Atem: ack [22:31] Pharaoh_Atem: pad updated with links for the three outstanding packages === salem_ is now known as _salem [22:37] infinity: Yeah, it'll happen when they're republished. Not really worth the effort to forth it. [22:38] *force (where did that come from?) [22:38] cjwatson: Lithp? [22:38] cjwatson: Right, I sorted that out from my looking at Release file timestamps. [22:39] 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] 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] infinity: Not necessarily immediately after xenial, but in the not too distant future in order to enable Valid-Until. [22:40] cjwatson: Okay, so we'll have the "pointless" copies of the final files, but not the pointless history. [22:41] I'd rather have everything ultimately end up being by-hash for consistency. [22:41] Yeah, that's fair. [22:41] The copies of the shallow revision aren't too bad, it's the history frozen in time that would be icky. [22:41] oh, Valid-Until [22:42] infinity: They're also hardlinks rather than copies, at least on the master. [22:42] cjwatson: Ahh, right. [22:42] Probably not on mirrors though because rsync -H is fairly expensive [22:42] cjwatson: Indeed, we've had that conversation. [22:42] cjwatson: But at least on master, wacking the history is enough to reclaim waste. [22:43] On mirrors, meh. It's a ton of space, but not relative to the archive size. [22:43] Quite. === jgrimm is now known as jgrimm-afk [22:44] cjwatson: I'm going to assume you had to submit some fun patches to magicmirror to make the arch split not vomit? [22:44] 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] 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] Stay of execution on by-hash/* I guess. [22:45] Dunno but it totally has a ton of them. [22:45] Oh, maybe the reference magic is only for pool/ [22:46] And dists is just assumed correct and synced wholesale (except for the /$arch/ filter) [22:46] Yeah, looking that way to me. [22:46]