| 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:03 |
|---|---|---|
| ubottu | 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:03 |
| 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:04 |
| nacc | sarnold: right, so i'd like to understand what i can do to figure it out | 01:05 |
| 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:07 |
| nacc | slangasek: yep, i was reviewing that; I will see what kind of testing I can do / ask the community to do | 01:09 |
| infinity | nacc: I'm not at all against accepting an SRU on the "it's broken" grounds. | 01:10 |
| 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:11 |
| 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:12 |
| infinity | nacc: Err, no, I meant the binary itself shouldn't have backports deps. | 01:13 |
| 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:14 |
| nacc | infinity: oh i see | 01:15 |
| nacc | infinity: i don't believe that's the case here; I will dig into it a bit tmrw | 01:16 |
| === alkisg_away is now known as alkisg | ||
| pitti | Good morning | 06:13 |
| alkisg | Good morning | 06:16 |
| alkisg | It appears that Ubuntu's network-manager patches have something to do with the nbd-client's cyclic dependencies... (LP: #1487679) | 06:21 |
| ubottu | Launchpad bug 1487679 in nbd (Ubuntu) "Breaking ordering cycle by deleting job nbd-client.service/start" [Undecided,Triaged] https://launchpad.net/bugs/1487679 | 06:21 |
| alkisg | I.e. that any sysvinit service that has "Required-Start: $network" is causing loops in Ubuntu, but not in Debian | 06:26 |
| slangasek | nacc: php-horde-db tests regress with mysql-5.7 | 06:27 |
| === athairus is now known as afkthairus | ||
| seb128 | cyphermox, did we get anywhere with the n-m 1.2 update? | 06:31 |
| slangasek | nacc: php-sabredav also fails with an incompatibility between php-sabredav and some dependency | 06:46 |
| 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:20 |
| 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:21 |
| 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:49 |
| 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:51 |
| 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:52 |
| pitti | we don't want the upstart changes in Debian supposedly, as upstart is gone there | 07:53 |
| 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:54 |
| ubottu | Debian bug 765731 in nfs-kernel-server "nfs-kernel-server: Service ordering cycle under systemd" [Normal,Open] http://bugs.debian.org/765731 | 07:54 |
| pitti | slangasek: well, I suppose we won't keep them much longer either, do we? ubuntu touch won't need NFS | 07:56 |
| pitti | maybe there's a new upstream version by now which incorporates these patches | 07:57 |
| pitti | ah, 1.3.3 | 07:57 |
| pitti | so, updating to that would get rid of 90% of the patches already | 07:58 |
| === hikiko is now known as hikiko|ln | ||
| 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:01 |
| ansgar | pitti: I think that error happens when apt gets a new InRelease, but old Packages/Sources (or the other way around). | 11:03 |
| pitti | I consistently get it in my containers now, might be some fallout wrt. the recent "by-hash" enablement and apt-cacher-ng | 11:04 |
| pitti | hm, still the same thing after cleaning /var/cache/apt-cacher-ng/uburep | 11:05 |
| === darkxst_ is now known as darkxst | ||
| 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:15 |
| 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:21 |
| 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 |
| ubottu | Debian bug 819852 in apt-cacher-ng "apt-cacher-ng: support by-hash index files" [Normal,Open] | 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:22 |
| 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:23 |
| 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:24 |
| 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:26 |
| alkisg | I had only the required-start: $network part with no other headers at all... | 11:28 |
| === hikiko|ln is now known as hikiko | ||
| doko | pitti, yes, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820313 | 11:36 |
| ubottu | Debian bug 820313 in vim-common "vim-addon-manager ftbfs (tests are failing)" [Serious,Fixed] | 11:36 |
| zyga | re | 12:07 |
| zyga | jdstrand: IT WORKS :-) | 12:07 |
| rbasak | xnox: are you working on the rsyslog s390x FTBFS? | 12:13 |
| xnox | rbasak, did not see that. | 12:18 |
| xnox | rbasak, is there a bug number? | 12:18 |
| 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:19 |
| xnox | doko, rbasak - did not go through s390x only ftbfs yet | 12:20 |
| pitti | doko: ah, so that was fixed in vim itself | 12:27 |
| doko | pitti, package in unapproved | 12:27 |
| === _salem is now known as salem_ | ||
| pitti | doko: no, it's not :-) | 12:34 |
| pitti | doko: (i. e. accepted, thank you!) | 12:34 |
| pitti | xnox: is it actually part of the specification that just about every tool and acronym on s390x is utterly unpronouncible? :-) | 12:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| * pitti pushes the button and sticks fingers in ears | 12:39 | |
| cjwatson | yay | 12:39 |
| pitti | cjwatson: thanks and congrats, this is an amazingly nice feature | 12:43 |
| 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:44 |
| jdstrand | zyga: woohoo! :) | 12:57 |
| * 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:58 |
| 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 | 12:59 |
| 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:03 |
| doko | xnox, should we kick out the separate boost-mpi source? | 13:08 |
| xnox | doko, if universe got enabled, yes. | 13:08 |
| 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:09 |
| cjwatson | xnox: it's done | 13:12 |
| 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:13 |
| 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:15 |
| 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:19 |
| 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 |
| ubottu | 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 |
| pitti | but all of libgcrypt20's deps are already configured, so there should be nothign that prevents libgcrypt20 configuration | 13:20 |
| 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 | 13:21 |
| pitti | slangasek, cyphermox, jibel: *phew*, we nailed bug 1554266; thanks to nuclearbob for being remote hands | 14:21 |
| ubottu | bug 1554266 in UTAH "sshd does not start on newly installed desktop system" [Undecided,Triaged] https://launchpad.net/bugs/1554266 | 14:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:31 |
| Laney | cjwatson: Ummmmmmmmmmmmm | 14:34 |
| Laney | I think there's an appstreamcli subcommand for that | 14:34 |
| gQuigs | cjwatson: interesting - http://pastebin.ubuntu.com/15688945/ | 14:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| Laney | I would guess it's the warning | 14:41 |
| Laney | I'll look into it, thanks for the report | 14:41 |
| gQuigs | cjwatson: so apt-get update hangs for me.. new problem as of today... | 14:46 |
| gQuigs | http://pastebin.ubuntu.com/15689150/ | 14:46 |
| gQuigs | but I can browse to the archive website fine... | 14:47 |
| gQuigs | cjwatson: and it's my fault, nevermind | 14:51 |
| === fginther` is now known as fginther | ||
| nacc | slangasek: ok, will investigate those | 14:59 |
| morphis_ | does anybody know if I can tell launchpad to not truncate diffs on a merge proposal? | 15:04 |
| teward | morphis_: #launchpad may be able to answer that better | 15:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| nacc | rbasak: this is in an autopkgtest, fwiw | 15:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| Skuggen | nacc: Switching auth back to password? | 15:27 |
| nacc | Skuggen: yep | 15:27 |
| Skuggen | Can you log in as root at the start of the test? | 15:28 |
| 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:29 |
| nacc | Skuggen: let me see | 15:30 |
| 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:31 |
| Skuggen | Could you just put up the test setup on pastebin or something (I'm not at a worky-computer) | 15:32 |
| 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:33 |
| 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:34 |
| === afkthairus is now known as athairus | ||
| Skuggen | Though erase somepassword | 15:35 |
| nacc | Skuggen: ok, let me try | 15:35 |
| 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:38 |
| nacc | Skuggen: http://paste.ubuntu.com/15690484/ ? | 15:39 |
| Skuggen | Hm, maybe it needs the ; at the end | 15:40 |
| Skuggen | i.e. after identified by '' | 15:40 |
| 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:41 |
| nacc | Skuggen: no second IDENTIIFIED | 15:42 |
| nacc | Skuggen: IDENTIFIED WITH ... BY ... | 15:42 |
| Skuggen | Aah | 15:43 |
| nacc | Skuggen: great, tests pass now, thanks! | 15:43 |
| Skuggen | \o/ | 15:43 |
| * mvo hugs cjwatson for landing by-hash in LP | 15:47 | |
| cjwatson | mvo: thanks for the apt side! that reminds me, meant to credit you in my blog post | 15:51 |
| cjwatson | mvo: oh, thanks for merging my apt-ddtp-tools branch. did you see my request for a ddtp-translations upload with that? | 15:52 |
| 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:53 |
| cjwatson | ah, ok, cool | 15:54 |
| mvo | cjwatson: thank you for the branch :) i18n back in xenial. | 15:55 |
| 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:08 |
| cyphermox | pitti: is there a way to tell systemd to not try to automatically activate swap for a period of time? | 16:17 |
| nacc | Pharaoh_Atem: is it possible to build a pear extension with debug symbols as part of `pear/pecl install` ? | 16:31 |
| nacc | ha! faked it with export CFLAGS= :) | 16:36 |
| 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:53 |
| 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:55 |
| 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:56 |
| Pharaoh_Atem | nacc: I've not been able to myself | 16:58 |
| 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 | 16:59 |
| Pharaoh_Atem | I've had trouble getting the debug stuff to register when trying to do it myself with libvirt-php stuff | 17:00 |
| 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:02 |
| Pharaoh_Atem | and I'm preparing to push that work to my GitLab and send a patch series to the libvirt mailing list | 17:03 |
| 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:04 |
| nacc | Pharaoh_Atem: which is something :) | 17:05 |
| slangasek | nacc: https://launchpad.net/ubuntu/+source/php-horde-db/2.3.1-1ubuntu2/+build/9552276 | 17:06 |
| nacc | slangasek: "chroot problem"? | 17:06 |
| 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:07 |
| * 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 | 17:08 |
| 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:02 |
| 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:03 |
| juliank | And yes, the ordering code is somewhat suboptimal | 18:04 |
| 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:14 |
| juliank | There probably is no sane-ish reason to do that, ordering is just somewhat broken in some places. | 18:16 |
| slangasek | heh | 18:17 |
| slangasek | APT, Approximate Package Tool? ;) | 18:17 |
| nacc | cjwatson: oh i see | 18:30 |
| * elbrus wonders if Debian bug 820475 applies to Ubuntu's php7.0 as well (which would mean a regression) | 19:17 | |
| ubottu | 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 |
| elbrus | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820475 | 19:17 |
| * elbrus has no Ubuntu system to check... | 19:17 | |
| 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:26 |
| elbrus | slangasek: good to know... | 19:27 |
| elbrus | and thanks for looking into it. | 19:27 |
| * 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:28 |
| * elbrus confirms that installing php-xml does the trick in Debian/unstable | 19:30 | |
| * elbrus is adding an autopkgtest to cacti, that is how I found out | 19:31 | |
| slangasek | wahoo, +1 for autopkgtest | 19:34 |
| 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:49 |
| slangasek | elbrus: yes, also split out - php-mbstring if I remember the name | 19:50 |
| elbrus | slangasek: great thanks... nacc: will you pick up these dependencies for cacti in Ubuntu? | 19:53 |
| === AndyTechGuy_ is now known as AndyTechGuy | ||
| 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:10 |
| 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:11 |
| Unit193 | I have php but not apache. | 20:12 |
| elbrus | aha, I guess as a dependency, it is resolved of course in postinst. | 20:12 |
| elbrus | when doing stuff for apache... | 20:13 |
| elbrus | yeah... php7.0 and cacti now work (on Debian) | 20:13 |
| elbrus | at least according to my wget call... | 20:14 |
| nacc | elbrus: what's up? cacti depends on mbstring and xml? | 20:41 |
| nacc | elbrus: slangasek: debdiff attached to LP: #1568136 | 20:46 |
| ubottu | Launchpad bug 1568136 in cacti (Ubuntu) "cacti depends on xml and mbstring extensions at runtime" [Undecided,New] https://launchpad.net/bugs/1568136 | 20:46 |
| 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:52 |
| 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:54 |
| 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:55 |
| 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 | 20:56 |
| 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:07 |
| 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:09 |
| infinity | cjwatson: Erm, is it intentional or a bug that the post-release pockets don't have A-B-H set? | 22:10 |
| 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:12 |
| 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:13 |
| * infinity wonders what made them republish in February... | 22:14 | |
| 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:15 |
| nacc | infinity: makes sense! | 22:16 |
| nacc | infinity: thanks! | 22:16 |
| infinity | nacc: So yeah, if your mirror is on a 24h sync schedule (not uncommon), you'll likely see it all happy tomorrow. | 22:17 |
| 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:18 |
| nacc | infinity: yep, that makes total sense and is obvious now :) | 22:20 |
| nacc | infinity: good policy :) | 22:20 |
| nacc | Pharaoh_Atem: nice! i look forward to seeing that get rolled out :) | 22:21 |
| Pharaoh_Atem | nacc: welp, you can pull it in if you want :P | 22:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| Pharaoh_Atem | the sheer amount of weirdness involved in php has been staggering | 22:28 |
| nacc | Pharaoh_Atem: ack | 22:31 |
| nacc | Pharaoh_Atem: pad updated with links for the three outstanding packages | 22:31 |
| === salem_ is now known as _salem | ||
| cjwatson | infinity: Yeah, it'll happen when they're republished. Not really worth the effort to forth it. | 22:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| infinity | On mirrors, meh. It's a ton of space, but not relative to the archive size. | 22:43 |
| cjwatson | Quite. | 22:43 |
| === jgrimm is now known as jgrimm-afk | ||
| 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:44 |
| 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:45 |
| 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:46 |
| * infinity nods. | 22:47 | |
| 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:50 |
| 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. | 22:52 |
| tkamppeter | infinity, hi | 23:20 |
| 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:21 |
| tkamppeter | infinity, OK. | 23:22 |
| 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 | 23:28 |
| === darkness is now known as darkxst | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!