| nacc | slangasek: ugh, upstream php7.0.4 does not show the problem. very confused right now, will debug it tmrw | 00:40 |
|---|---|---|
| nacc | slangasek: could be a configure option we're passing | 00:40 |
| slangasek | nacc: because of course a language should behave differently depending on the configure options you pass at build time ;) | 00:42 |
| nacc | slangasek: i'm hopeful that's not it, but then i'm not sure what it is | 00:42 |
| slangasek | nacc: slight adjustment to the versioning, it should actually be 3.15.1.is.really.2.8.27-0ubuntu1 (you had 3.15.1-1.is.really.2.8.27-1ubuntu1) | 00:51 |
| slangasek | nacc: actually I'm going to make this 3.15.1.is.really.2.8.27-1~build1 to declare that there is no delta and it's ok to autosync later from Debian | 00:53 |
| slangasek | nacc: php-monolog will need an upload to adjust its versioned build-dep; the new package is compatible but will have a version that sorts >> 3, since version numbers in the archive only go up | 01:11 |
| slangasek | nacc: I'll go ahead and upload that change onw | 01:12 |
| slangasek | now | 01:12 |
| nacc | slangasek: ah thanks! yep, that makes sense | 01:14 |
| nacc | slangasek: sorry, first time i'd encountered that, appreciate your uhelp | 01:14 |
| nacc | slangasek: and i think it is a configure-time bug in our php :/ ... i just ran ./configure w/o any options and it didn't show the bug | 01:15 |
| slangasek | hahahaha | 01:16 |
| nacc | slangasek: it *could* theoretically point at something in a library, i guess, but upstream php-zeta-console-tools dev tested with 7.0.3/7.0.4 and 7.1.0-dev and they all passed | 01:19 |
| nacc | slangasek: so i'm 99% sure it's the configure | 01:19 |
| nacc | slangasek: ah maybe not as bad, running `./debian/rules dh_auto_configure; make install` also did not show the error. So maybe it's some compile time option we're passing in debian/rules ... will pick it up tmrw | 01:28 |
| slangasek | nacc: php-common also breaks: the version of php-mongodb we have | 01:35 |
| slangasek | not sure why that is when there's no php-mongodb package yet anywhere in Debian; ohwell | 01:35 |
| nacc | slangasek: that is odd; do you want me to spin up a debdiff? | 01:36 |
| slangasek | nacc: nah I'll sort it out, just giving you a headsup | 01:36 |
| nacc | slangasek: thanks, i appreciate it | 01:36 |
| slangasek | nacc: stupid dependency boolean tricks: https://launchpad.net/ubuntu/+source/php-monolog/1.17.2-1ubuntu2 | 01:42 |
| nacc | slangasek: ah ok, thanks! | 01:43 |
| nacc | slangasek: i think the issue for symfony (at least the first one) is that it needs to not run the same tests (online,network,tty,benchmark,intl-data) that the build avoids | 01:48 |
| nacc | slangasek: that will resolve the two failures i see in the logs, i think | 01:49 |
| nacc | slangasek: nm, i was looking at an old log! :/ | 01:50 |
| Son_Goku | nacc: oh, the monster... | 01:50 |
| nacc | slangasek: i *think* we'll want to bump or cherry-pick from 2.7.10 | 01:53 |
| nacc | slangasek: but i will need to look at the diff, etc | 01:54 |
| nacc | alternatively, like you suggested before, we could look to sync from experimental | 01:55 |
| nacc | that would need a FFe, of course | 01:55 |
| nacc | but based upon upstream changelog, all of 2.7.10 is bugfixes | 01:59 |
| nacc | so that might be the safest course | 01:59 |
| Son_Goku | nacc: why not just save yourself the trouble and sync to 2.7.10? | 02:01 |
| sarnold | Latest Upstreams are _always_ the Best Available And Has No Bugs[tm] :) | 02:01 |
| nacc | Son_Goku: it's not a sync, it's a merge, so it's a bit more work; and because i have to do a ffe and verify all the changes are not going to break something :) | 02:01 |
| Unit193 | ™ | 02:01 |
| nacc | heh | 02:01 |
| Son_Goku | ugh | 02:02 |
| Son_Goku | okay | 02:02 |
| Son_Goku | well, using 2.7.10 means that it’ll be easier to cherrypick from 2.8 later on, when you have to | 02:02 |
| nacc | Son_Goku: agreed, and i think that's probably our best course of action, as it will unstick symfony's dependencies in the archive ... but would rather consider that at the beginnign of my day rather than the end :) | 02:03 |
| Son_Goku | the only reason I’m not advocating for symfony 2.8 is because it breaks too many people’s projects simply because of the version number bump | 02:04 |
| Son_Goku | I spent way too much time fixing composer files and direct file require references trying to use 2.8 than I ever should have | 02:04 |
| Son_Goku | just because the company I work for practically depends on it, doesn’t mean I like mucking around in it | 02:05 |
| Son_Goku | I’ve learned way too many terrible things in my quest to figure out how much stuff breaks with php7 | 02:05 |
| sarnold | find . -type f -exec sed -i 's/2.7/2.8/g' {}\; #YOLO | 02:05 |
| Son_Goku | sarnold: the saddest part about it is that it didn’t work :( | 02:06 |
| Son_Goku | at the end of it all, the application was busted | 02:06 |
| Son_Goku | damn people and their lack of foresight | 02:06 |
| sarnold | Son_Goku: aww :( that's frustrating | 02:07 |
| Son_Goku | one of the terrible, terrible downsides to every language having their own package manager is that now people are coding strictly to specific versions or git commits | 02:07 |
| Son_Goku | because no tolerance in your software A Good Thing(TM) | 02:08 |
| Son_Goku | the situation got bad enough in Fedora land that we had to walk back from our policy of blocking bundling by default | 02:08 |
| sarnold | ow :/ | 02:09 |
| Son_Goku | patches to improve system integration or work with newer versions of software were rejected by upstreams repeatedly, simply because they “don’t care” and that new versions are “Fedora’s problem” | 02:10 |
| Son_Goku | I’m lucky enough to work on packages where I don’t have upstreams like that | 02:10 |
| Son_Goku | but man, the worst examples of this are chromium and owncloud | 02:10 |
| sarnold | vendorizing all the things is probably going to be on some visionary genius's slidedeck in five years when the future realizes that the amount of technical debt that has been built into every service ever is too large to overcome | 02:10 |
| Son_Goku | the biggest irony of owncloud is that they’re run by former SUSE/openSUSE engineers | 02:11 |
| Son_Goku | and SUSE themselves don’t allow ownCloud into their core repos | 02:11 |
| Son_Goku | every time the system integration issue is brought up, they want people to spin up OBS appliances and interconnect to manage their flavor’s packaging | 02:12 |
| Son_Goku | I’m all for using a nice build system and all, but their attitude is terrible | 02:12 |
| Son_Goku | this is one of the big reasons I don’t like Docker | 02:13 |
| Son_Goku | note that Docker != containers | 02:13 |
| Son_Goku | maybe I’m an old fogie, but I remember when all the distros were burned because of zlib | 02:14 |
| sarnold | that one was -painful- | 02:14 |
| Son_Goku | you’re telling me | 02:14 |
| Son_Goku | to this day, I’m *still* not sure if all of that is gone | 02:15 |
| Son_Goku | I’m only 24, but I remember when it happened | 02:15 |
| Son_Goku | and holy crap the fallout was horrible | 02:15 |
| sarnold | heh I bet you're right.. | 02:15 |
| sarnold | heartbleed made front page of newspapers and yet something like 1/3 of the docker images in the world still don't have that one fixed | 02:16 |
| Son_Goku | the bullshit about Alpine Linux only encourages it | 02:16 |
| Son_Goku | because guess what you have to do when there’s nothing in your container rootfs? | 02:16 |
| sarnold | vendorize! | 02:17 |
| * Son_Goku sighs | 02:17 | |
| Son_Goku | it’s not helping that all the enterprise distros are gunning for this weird space | 02:17 |
| Son_Goku | Red Hat with Atomic, Canonical with Ubuntu Snappy, SUSE with JeOS, Docker with Alpine Linux, etc | 02:18 |
| Son_Goku | and yes, I’m counting Docker as a distro vendor now | 02:18 |
| Son_Goku | because they effectively took over stewardship of Alpine | 02:18 |
| Son_Goku | oh joy | 02:19 |
| Son_Goku | netsplit hell | 02:19 |
| Son_Goku | sarnold: I think that like OpenStack, people are going to hit the gas pedal too hard | 02:20 |
| Son_Goku | and then when they realize they landed in some disgusting stuff, the pendulum will swing again | 02:20 |
| Son_Goku | I barely give a pass on Chromium for the bundling thing because they have some semi-legit reasons for it | 02:21 |
| Son_Goku | but holy hell, look at how many bundled() Provides it has: https://spot.fedorapeople.org/chromium.spec | 02:22 |
| sarnold | yeah.. I just recently bought a decent machine that I intend to use for vms (among other things), and I just can't bring myself to contemplate installing openstack on the thing. I'd rather have a dozen small shell scripts than a dozen privileged daemons with gross apis and on and on.. | 02:22 |
| Son_Goku | like… WHY do you need your own GTK+3?! | 02:23 |
| Son_Goku | and then… zlib | 02:23 |
| Son_Goku | sarnold: I have spent two months trying to properly set up OpenStack | 02:23 |
| Son_Goku | not only can I not get it working (and I like to think I’m reasonably competent as a Linux user/admin/developer/etc) | 02:24 |
| sarnold | # Bundled bits (I'm sure I've missed some) | 02:24 |
| Son_Goku | but every time I try, more of me dies inside because of the sheer overengineered complexity that’s in it | 02:24 |
| Son_Goku | I just use oVirt now | 02:25 |
| Son_Goku | my own personal sandbox where I do all my crazy stuff is an oVirt system | 02:25 |
| Son_Goku | it’s ~15 minutes to set up, and It Just Works(TM) | 02:25 |
| Son_Goku | something that the world likes to forget about, these days | 02:25 |
| Son_Goku | most of my php7.0 package dev work and testing has been on the oVirt system | 02:26 |
| Son_Goku | I have Ubuntu 16.04-dev, Fedora 23 (with remi php70 scl), and CentOS 7 (with remi php70 scl) for testing and development | 02:27 |
| Son_Goku | I’ll probably throw in openSUSE Tumbleweed and Mageia Cauldron to round out my testing | 02:27 |
| Son_Goku | sarnold: but yeah, if you’re looking to make a nice little ESXi-like VM environment, I highly recommend oVirt | 02:28 |
| Son_Goku | it works great, it’s FOSS, and it’s not complicated! | 02:28 |
| Son_Goku | actually, does Ubuntu have an equivalent to Fedora’s bundled() Provides? | 02:29 |
| sarnold | not that I know of | 02:29 |
| Son_Goku | hmm | 02:29 |
| Son_Goku | it comes in handy for my automated auditing with a shitty shell script | 02:30 |
| sarnold | the debian security team has a bundled listing somewhere, but it's not particularly easy to updae | 02:30 |
| Son_Goku | eck | 02:30 |
| Son_Goku | I once tried to make virtual Provides like the ones I’m used to when I make RPMs for Fedora/Mageia | 02:31 |
| Son_Goku | on Ubuntu | 02:31 |
| Son_Goku | I’ve never seen apt blow up in such strange ways | 02:31 |
| Son_Goku | apparently, it’s a really stupid idea to load up on virtual Provides | 02:31 |
| sarnold | oh my :) yeah, I think the easiest way out of that is to start over.. | 02:32 |
| === juliank_ is now known as juliank | ||
| Son_Goku | I always wondered why there weren’t things like “libgcc_s.so.1()(64bit)” as Provides and Requires (names independent of package names) | 02:33 |
| Son_Goku | then I tried it and found out why | 02:33 |
| Son_Goku | sarnold: also, apparently you can break the apt db and the repo metadata by doing stuff like that | 02:34 |
| Son_Goku | it doesn’t handle it very well :P | 02:34 |
| sarnold | hehe yeah, apt assumes everyone doing packaging has learned the debian secret handshakes | 02:34 |
| Son_Goku | I don’t think I’ll ever learn those | 02:35 |
| Son_Goku | I’ve been doing packaging for almost 8 years | 02:35 |
| Son_Goku | when I first started using Ubuntu back in 2005, I was surprised to see that it chose a Debian base | 02:36 |
| Son_Goku | I found out that Mark Shuttleworth was a former Debian maintainer a few years later, and the pieces fell into place :) | 02:36 |
| Son_Goku | sarnold: I feel old when I think about stuff like this | 02:45 |
| Son_Goku | I’ve witnessed the rise of Linux | 02:45 |
| Son_Goku | and I had a (very) small hand in some of that | 02:45 |
| sarnold | Son_Goku: heh, I was around for the very end of the a.out -> ELF transition.. | 02:45 |
| Son_Goku | I came in just after that, I think | 02:45 |
| Son_Goku | I was there for the transition from LinuxThreads to NPTL, though | 02:46 |
| sarnold | woot :) not bad for 24, hehe | 02:47 |
| Son_Goku | the COFF->ELF transition was one I was glad to miss though | 02:47 |
| Son_Goku | but yeah | 02:51 |
| Son_Goku | I think in some ways the biggest disappointment was that the Linux communities never made it so have common tools across all distributions | 02:52 |
| Son_Goku | the LSB attempted it, but with how little distros followed it, it didn’t matter | 02:52 |
| Son_Goku | today, the closest we’re getting is with systemd, which is forcing distros to stop being special snowflakes in some respects | 02:53 |
| Son_Goku | making it easier to make portable applications that don’t require vendoring | 02:53 |
| slangasek | the LSB never understood that double-dipping by charging both OSVs and distro vendors for certification was a failed funding model | 02:55 |
| sarnold | and there's just no denying that insserv was annoying :) | 02:56 |
| slangasek | insserv was never a required LSB interface | 02:56 |
| sarnold | that was -optional- and people opted into it? oof :) | 02:58 |
| slangasek | applications were required to support the various LSB pseudoheaders in their init scripts in order to be compliant; OS implementors could freely ignore that | 03:00 |
| sarnold | interesting | 03:01 |
| Son_Goku | ironically, it might be easier for me now to come up with a baseline for compatibility than it would have been for the LSB a decade ago | 03:04 |
| slangasek | nacc: alright, php-aws-sdk is still uninstallable, because php-guzzle was removed (LP: #1543808) | 03:05 |
| ubottu | Launchpad bug 1543808 in php-guzzle (Ubuntu) "Please consider dropping php-guzzle from Ubuntu Xenial" [Wishlist,Fix released] https://launchpad.net/bugs/1543808 | 03:05 |
| Son_Goku | sarnold: if I were to sit down for a month (or rather, be allowed to do that and not work), I could probably put together a basic definition of what a Linux system is supposed to have to be compatible | 03:06 |
| Son_Goku | but really, what actually has to happen is that the distros themselves need to stop making “special snowflake” decisions and actually do some unifying on their own | 03:07 |
| sarnold | didn't lennart already do that? :) | 03:07 |
| hallyn | pitti: so on http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.41-1.dsc the testcases fail in debian bc they rely on the memory cgroup which is not enabled there by default; is there | 03:07 |
| Son_Goku | sarnold: he capitulated way too much early on | 03:07 |
| hallyn | pitti: a link showing the proper way to ask 'please reboot with the 'cgroup_enable=memory' boot argument' ? | 03:07 |
| Son_Goku | systemd actually has a lot of things to deal with debianisms, suseisms, etc. | 03:08 |
| Son_Goku | the only distros I know of that got rid of their “isms” to adopt it was Fedora, Mageia, Arch, and a few “newbie” distros | 03:09 |
| Son_Goku | the Upstart->systemd move was quite painful in Fedora 15 | 03:09 |
| Son_Goku | of course, you guys got all the benefit of that pain, many years later :) | 03:09 |
| * hallyn does the dance of joy | 03:10 | |
| * hallyn brushes away some of the copious sarcasm | 03:10 | |
| Son_Goku | sarnold: I don’t know if you know this, but there was actually an attempt to make a package manager that supported both rpms and debs on a single system | 03:12 |
| Son_Goku | single database, handling all the package types, repos, etc. | 03:13 |
| sarnold | yikes that sounds terrible | 03:13 |
| Son_Goku | well, it’s the rpm5 project | 03:13 |
| Son_Goku | the guy is of the firm belief that having a division in packaging systems only hurts the community | 03:13 |
| Son_Goku | so he made it his goal to introduce support for both packaging systems in RPM5 | 03:13 |
| Son_Goku | which he did | 03:13 |
| Son_Goku | he’s employed by the Yocto Project, who uses his fork of rpm for their stuff | 03:14 |
| sarnold | I'm reminded of https://xkcd.com/927/ | 03:15 |
| Son_Goku | yep | 03:15 |
| Son_Goku | I can’t say I disagree with Jeff on his belief | 03:15 |
| Son_Goku | but I think his approach was wrong | 03:15 |
| * hallyn didn't even have to load that xkcd to know what it was gonna be | 03:15 | |
| Son_Goku | because he managed to alienate everyone in the process of that | 03:15 |
| Son_Goku | there was even LWN articles about his project :P | 03:16 |
| sarnold | hallyn :) | 03:16 |
| Son_Goku | the most annoying part is that he took over the project page for RPM on launchpad | 03:17 |
| Son_Goku | so now it’s chock full of bugs and discussions that are completely non-relevant to the project that actually controls that page | 03:17 |
| hallyn | rpm5 webpage tells me it's ~relaunched~ | 03:18 |
| Son_Goku | I know | 03:18 |
| Son_Goku | he did that on purpose | 03:18 |
| Son_Goku | when Red Hat let him go, he did that | 03:18 |
| Son_Goku | but it’s aggravating because rpm5 controls https://launchpad.net/rpm despite everything | 03:20 |
| Son_Goku | people file bugs about the rpm in ubuntu, but no one deals with it, because the rpm5 people don’t give a damn | 03:20 |
| Son_Goku | hallyn: the rpm5 project is geared towards merging the capabilities of apt/yum, rpm, and dpkg into a unified rpm | 03:23 |
| Son_Goku | it can even replace reprepro, createrepo, etc. | 03:23 |
| hallyn | what about ebuild :) | 03:23 |
| Son_Goku | it has rudimentary capabilities for that too | 03:23 |
| Umeaboy | Hi! | 03:23 |
| Son_Goku | it can download sources and compile them automatically in chroots and stuff like that | 03:23 |
| Son_Goku | it’s got a lot more capabilities than the main rpm | 03:24 |
| Umeaboy | I've just installed Xenial in my laptop and besides having no Swedish keyboard activated in the keyboard settings (both in the installation and in the booted system) everything runs just fine. No crash so far. | 03:24 |
| Son_Goku | hallyn: of course, now it has mongodb integration, so I don’t know what to think anymore | 03:25 |
| Umeaboy | Only thing I want to ask about is a translation that I'm doing for Xenial. | 03:25 |
| Umeaboy | I can use #launchpad if that's preferred, but I just want to hear what you guys think. | 03:26 |
| Umeaboy | <strong>Pidgin</strong> <span>Internet messenger</span> | 03:26 |
| Umeaboy | The part of Internet Messenger, should that be translated into my language? | 03:27 |
| Umeaboy | It's a bit tricky to get it accurate. | 03:27 |
| Son_Goku | isn’t it an “Instant messenger”? | 03:28 |
| Umeaboy | Yeah, but in Swedish that's a bit hard to translate. | 03:28 |
| Umeaboy | That's why I'm asking. | 03:28 |
| Umeaboy | And YES, I'm Swedish. | 03:28 |
| Son_Goku | Umeaboy: I think I’ve met you before | 03:28 |
| Umeaboy | Yeah. | 03:28 |
| Umeaboy | You have. | 03:29 |
| Son_Goku | in #Mageia, right? | 03:29 |
| Umeaboy | Yeah. | 03:29 |
| Son_Goku | you probably shouldn’t translate the “internet messenger” bit | 03:29 |
| Son_Goku | because it’s part of Pidgin’s title | 03:29 |
| Umeaboy | Right. | 03:30 |
| Umeaboy | My thought as well. | 03:30 |
| Umeaboy | I was thinking about translating into "Meddelandeklienten" | 03:30 |
| rlaager | Son_Goku: The name of the application (upstream) is just Pidgin. I believe it's Ubuntu that's adding "Internet messenger". I don't think we use that name upstream at all. I assume Ubuntu used "Internet" instead of "instant" for legal reasons. | 03:31 |
| rlaager | Likewise, on my system, the menu icon says "Firefox Web Browser", but the name of the application upstream is just Firefox. | 03:32 |
| Umeaboy | rlaager: Yeah, that's just plain irritating. | 03:33 |
| rlaager | Umeaboy: What's irritating? The extra words in the Ubuntu menus? | 03:34 |
| Umeaboy | rlaager: Yeah. | 03:34 |
| Umeaboy | I know WHY, but............ | 03:34 |
| Umeaboy | It's like I in Swedish say That brown ball of meat to a Meatball. | 03:35 |
| Umeaboy | It's like you're talking to a 2 year old. | 03:35 |
| Umeaboy | Simple can be TO simple as well. | 03:35 |
| Umeaboy | I wish we had a choice during the installation how we want our menus. | 03:36 |
| Umeaboy | Just like you can do in Android | 03:36 |
| Umeaboy | Regular touch desktop or Simple Touchwiz. | 03:36 |
| Umeaboy | Simplified Touchwiz that is. | 03:36 |
| Umeaboy | I'll just leave it then I guess. | 03:38 |
| Umeaboy | rlaager and Son_Goku: What about the part for ubiquity-slideshow-ubuntu: Bienvenue! | 03:56 |
| Umeaboy | ? | 03:56 |
| Umeaboy | I know it's in French, but am I supposed to translate thoose sentances or words? | 03:57 |
| Umeaboy | I have a feeling as to what they are used for, but I want to be sure. | 03:57 |
| rlaager | Umeaboy: I don't have any guidance there. I'm not an Ubuntu developer and I'm not familiar with that application. | 03:57 |
| Umeaboy | OK. | 03:57 |
| sarnold | i have a vague memory of the slideshow saying 'welcome' in many languages | 03:58 |
| rlaager | sarnold: Everyone loves copying Apple, don't they? ;) | 03:58 |
| sarnold | rlaager: it's entirely possible that that's what I'm remembering :) | 03:59 |
| === shuduo-afk is now known as shuduo | ||
| Umeaboy | sarnold: Are you sure you didn't copy the thought of that from someone else? | 04:38 |
| Umeaboy | ;) | 04:38 |
| bipul | Can anyone help me to get the output: for ((;;)); do tail -f /var/log/kern.log | a=$(grep -E "wlan0: authenticated" | tail -c21) | echo $a ; done | 06:26 |
| cpaelzer | good morning | 06:48 |
| dholbach | good morning | 07:34 |
| pitti | Good morning | 08:14 |
| pitti | hallyn: sorry, I'm missing context here -- buliding the .dsc fails because debian's buildds don't enable the memory cgroup? this would be either the arch specific porter lists (https://lists.debian.org/ports.html) or perhaps https://lists.debian.org/debian-dak/ | 08:18 |
| pitti | hallyn: or is that for autopkgtests? in Debian they currently run in a container, but at least enabling some kernel option there is much simpler/less contentious | 08:19 |
| pitti | wgrant: meh, since yesterday our scalingstack instances are one big "timed out waiting for ssh" sorryness | 08:20 |
| pitti | and "INFO: task sshd:659 blocked for more than 120 seconds." | 08:20 |
| pitti | known? | 08:20 |
| cjwatson | pitti: lgw01 is undergoing maintenance; lcy01 doesn't seem too awful | 08:23 |
| pitti | this affects all three clouds | 08:23 |
| cjwatson | pitti: though there was an incident yesterday that took it down | 08:23 |
| cjwatson | (lcy01 that is) | 08:24 |
| cjwatson | pitti: I think you'll need to check directly with IS then; LP builders are not broken across the board | 08:24 |
| pitti | cjwatson: ack, thanks | 08:24 |
| cjwatson | (I think) | 08:24 |
| pitti | just wanted to check before as there's no vanguard ATM | 08:24 |
| pitti | right, lgw doesn't respond, so if that's known, I won't report that again | 08:25 |
| cjwatson | it's having surgery done on its mysql | 08:27 |
| * pitti blames the vivid backported 3.19.0-57-generic kernel | 08:29 | |
| pitti | apw: the vivid 3.19.0-57.63 kernel update is completely broken :( | 08:32 |
| pitti | apw: http://paste.ubuntu.com/15406752/ | 08:36 |
| lamont | doko: smb ppa:lamont/ppa for your isc-dhcp testing fun, if you would be so kind. Once I wake up, I'll bump versions and upload to xenial | 08:42 |
| doko | ta, thanks | 08:42 |
| smb | lamont, I just copied your bind over to a ppa of mine to add isc-dhcp later | 08:42 |
| lamont | kewl | 08:42 |
| * lamont had some things come up that kept him from sleeping tonight, so he fought the battle to the conclusion. | 08:43 | |
| lamont | otoh, too sleepy to be confident in my testing, nor do I have a trivially easy test setup for dhcp | 08:43 |
| doko | Mirv, libinput needs a merge, xserver-xorg-input-libinput is dep-wait | 08:43 |
| smb | Does not sound that good | 08:43 |
| wgrant | pitti: lgw01 is back. | 08:44 |
| wgrant | After some mysql hackery. | 08:44 |
| smb | lamont, Oh I saw you actually just uploaded a new version of isc-dhcp of yours. I was not sure you would be awake to do so | 08:44 |
| lamont | I did | 08:44 |
| lamont | that one built locally (needed a new lib for 9.10) | 08:44 |
| smb | I see (just reading the changelog) | 08:45 |
| lamont | smb: thanks for that work, btw | 08:45 |
| lamont | n.b., all I did was make it not ftbfs. | 08:45 |
| lamont | but Ihave every reason to believe that it by damn well better fix the bugs | 08:46 |
| smb | lamont, yw. Heh, yeah, unfortunately that was not obvious before :) | 08:46 |
| Mirv | doko: you might mean that to tjaalton? | 08:46 |
| lamont | smb: do not, if you value your keyboard or sanity, read debian/apply-export-patch in the bind9 tree.. you have been warned | 08:46 |
| doko | Mirv, ohh, crap, I do ... :-/ | 08:46 |
| pitti | wgrant: yay, thanks for notifying; reenabling | 08:47 |
| wgrant | pitti: I misread LP logs, it may not actually be working yet. | 08:47 |
| wgrant | But if it's not working then you may be able to get more details as to why. | 08:47 |
| pitti | wgrant: well, I can talk to it; absolute-limits is still as wrong as before, but at least it's back alive somehow | 08:47 |
| wgrant | (we don't have logs from lgw01 because lgw01 is entertaining) | 08:47 |
| smb | lamont, Bah, thats the kind of "warning" to lure people of just doing that... :-P I try to don a tin foil hat before doing so ... | 08:47 |
| wgrant | Right. | 08:47 |
| tjaalton | doko: oh right | 08:47 |
| wgrant | Let me know if you can/can't start instancecs. | 08:48 |
| lamont | smb: :D | 08:48 |
| doko | tjaalton, and a 1.2.2 seems to be out | 08:50 |
| lamont | smb: I took a really really big hammer and just beat the living hell out of that square peg until it fit. | 08:50 |
| tjaalton | doko: yes updating it atm | 08:50 |
| pitti | wgrant: right, "server building" is hanging, it's stuck in scheduling/NOSTATE | 08:51 |
| smb | lamont, ugh... Looking forward to see what I avoided to do... Also sounds a bit like you should forward a bill to isc for fixing what they wanted to be paid a year ago... | 08:52 |
| pitti | apw: I purged all linux-meta test requests from the vivid queues FYI, so they'll stay in "MISS" forever on your side | 08:53 |
| apw | pitti, ahh did we lose the vivid hosts ... damn | 08:54 |
| lamont | smb it's a configure run, followed by a pair of for looped sed commands with a patch run in between... | 08:54 |
| lamont | tbf, I could have moved the patch run, but ... HAMMER | 08:55 |
| smb | lamont, yay! (half-hearted) :) At least good you did not use grep | 08:55 |
| lamont | smb: it didn't make it into the script. :p | 08:55 |
| smb | So we do not need a Claymore on top of the hammer | 08:56 |
| lamont | heh | 08:56 |
| lamont | smb: not as long as the dhcp bugs are fixe | 08:57 |
| lamont | d | 08:57 |
| lamont | also, thanks isc for dropping the --enable-exportlib code | 08:57 |
| lamont | and yes, I'll be grumbling at my isc contacts | 08:58 |
| lamont | but not until next week | 08:58 |
| lamont | smb: doko isc-dhcp is built, waiting for publication | 09:00 |
| smb | lamont, ack | 09:01 |
| lamont | and sleep for me.!! | 09:01 |
| smb | Heh, I think that you better do on your own for yourself | 09:02 |
| seb128 | dholbach, just curious, that u-m-w update, how did you reconstruct the update package? patched the old version and renamed the dir? or unpackaged the new tarball and moved the debian dir over? | 09:13 |
| smb | Hm... to my testing 1 of 2 problems solved | 09:13 |
| seb128 | dholbach, also I would have guided flexiondotorg to do it the proper way so next requests can be more easily handled :p | 09:14 |
| flexiondotorg | seb128, I have been so guided :-) | 09:14 |
| seb128 | flexiondotorg, sorry but those diff + tarball sponsoring requests are just not easy to reconstruct/sponsor | 09:15 |
| seb128 | you should better add the dsc/diff|debian.tar.gz/orig | 09:15 |
| flexiondotorg | seb128, Understodd and future sponsoring requests will be more sponsor friendly. | 09:16 |
| seb128 | thanks | 09:16 |
| smb | doko, So it looks like dhcp lease renewal works now, but I think the signal handling still is an issue. I see the normal kill being noticed (strace attached) but looks like it still refuses to do something ... | 09:22 |
| dholbach | seb128, very easy: downloaded old package and debdiff, applied it | 09:24 |
| dholbach | seb128, but I said to flexiondotorg that a link to a .dsc file in a ppa would maybe be more straight-forward | 09:25 |
| seb128 | dholbach, right, I did that, but then you can't really review the packaging diff and there is no garanty there is no cruft over what a proper tarball unpack + diff would have done | 09:25 |
| seb128 | oh well, I guess they can fix fallover from that workflow if there are some | 09:26 |
| dholbach | next time, ppa upload :) | 09:26 |
| seb128 | or dsc/diff.gz to the bug | 09:26 |
| seb128 | that works as well | 09:26 |
| cjwatson | flexiondotorg: when you're reassigning bugs to ubiquity, please could you reassign them to the ubiquity package in Ubuntu, not to the ubiquity project in Launchpad (which we use for code hosting, but not for bug tracking)? I've been reassigning them on but it gets tedious | 09:35 |
| flexiondotorg | cjwatson, Sure, what is the correct project name? | 09:35 |
| cjwatson | flexiondotorg: the ubiquity package in Ubuntu, as I said | 09:36 |
| cjwatson | flexiondotorg: as in, "also affects distribution/package", not "also affects project", etc. | 09:36 |
| flexiondotorg | Thanks, that's the clue I needed. | 09:37 |
| cjwatson | cheers | 09:37 |
| lamont | smb: as for delving deeper into the crazy, I suspect that y'all are as familiar with the relevant code as I am... I'd prefer to let foundations go crazy with it :( | 09:41 |
| lamont | smb: anyway, I'll be back to waking status in about 5 hours, will upload the non ~foo versions then, hopefully with whatever fixes you come up with in the mean time... | 09:41 |
| lamont | ta | 09:42 |
| smb | lamont, Hm, we will see how much that is but have a good night (had hoped you may already have) | 09:43 |
| lamont | there was driving involved. | 09:43 |
| lamont | and the "huh, let me try to punt this to foundations" thought brought me back.. now I'm off to actual sleep. | 09:43 |
| smb | heh | 09:44 |
| wgrant | pitti: Should be fixed for real now. | 09:55 |
| pitti | wgrant: yay, works indeed, thanks | 10:17 |
| pitti | queues will appreciate the horsepower | 10:17 |
| juliank | The test failure of apt on i386 was flakyness again, and should be ignored. I just made the test a bit less flaky, we'll see how well that works in the next upload. | 11:00 |
| xnox | pitti, autopackagetest ENOQUOTA | 11:47 |
| pitti | xnox: it should be much better now that lgw01 is back, queues are catching up fast | 11:47 |
| pitti | they were broken since last night for various reasons | 11:47 |
| xnox | right, but i see adt logs having errors "30 out of 30 cpus used" and thus failing everything. | 11:48 |
| pitti | xnox: that's mostly harmless, they'll auto-retry | 11:48 |
| xnox | ok | 11:48 |
| pitti | xnox: that happens if there are several "big" tests running which use an m1.large instead of the normal small | 11:48 |
| pitti | thus they block more cores | 11:48 |
| pitti | (linux, binutils) | 11:49 |
| pitti | plus, lcy01's db is off again and claiming that I use more resources than I actually do | 11:49 |
| === _salem is now known as salem_ | ||
| roaksoax | /win 13 | 12:49 |
| === roaksoax is now known as roaksoax-afk | ||
| smoser | pitti, i have (at least) one more question. | 12:53 |
| smoser | i suspect that if i'm running on an add event, that even in an import i cannot update rules that would be executed later. | 12:54 |
| smoser | heres what i'm interested in doing. | 12:54 |
| infinity | juliank: iz migrated now. | 12:54 |
| cjwatson | infinity: oh dear | 12:55 |
| cjwatson | we haven't had time to re-sign PPAs yet | 12:55 |
| smoser | a.) add event fires a rule in place by cloud-init that runs cloud-init-name-device via import | 12:55 |
| cjwatson | I guess we're about to get a support firestorm | 12:56 |
| smoser | that blocks until i've found information on what devices should be named | 12:56 |
| smoser | b.) i want to allow nic device name assignment based on something other than MAC (for example 'ID_NET_NAME_PATH' might be something) | 12:57 |
| smoser | so i'm going to end up with some language for saying "ID_NET_NAME_PATH=enp0s25 NAME=foo0" | 12:58 |
| smoser | which looks a lot like udev rules. so rather than using writing another parser, i'd like to re-use udev rules. but in order to do that i'd have to create or update a rules file that [possibly] did not exist when this event started. | 12:59 |
| smoser | ie, i'd like for cloud-init-local to write /etc/udev/rules.d/70-persistent-net.rules | 13:00 |
| infinity | cjwatson: Oh. A blocking bug might have been nice. If only the guy who wrote that feature was an LP dev. | 13:02 |
| cjwatson | infinity: I didn't realise it was going to start happening quite so soon :P | 13:02 |
| cjwatson | juliank: bug 1558331 - looks like synaptic's handling of warnings causes confusion | 13:03 |
| ubottu | bug 1558331 in apt (Ubuntu) "After upgrading to apt 1.2.7 in Xenial, PPAs and most other third-party repositories become unusable with "The repository is insufficiently signed by key (weak digest)"" [Undecided,Confirmed] https://launchpad.net/bugs/1558331 | 13:03 |
| cjwatson | (if you read the bug log closely, it looks as though PPAs aren't actually unusable, but synaptic displays warnings as errors and makes it look as though they will be) | 13:03 |
| infinity | cjwatson: I've noticed sbuild's temp repo is also goofycakes with the new apt. Should we just switch that to [trusted=yes] for apt >> XX and be done with it? | 13:03 |
| infinity | (Thankfully, sbuild's just noisy, it doesn't fail) | 13:04 |
| cjwatson | infinity: there was some debate about that in a bug somewhere, I forget the details | 13:04 |
| juliank | cjwatson: Yeah, the warning system is somewhat confusing. | 13:04 |
| juliank | With 1.2.8 it gets better | 13:04 |
| juliank | As it then shows the actual errors as E: | 13:05 |
| infinity | cjwatson: Well, signing on the same system that turns around and reads the archive is snakeoil at best. trusted=yes is obviously smarter in that case, but needs to be branched based on the version of apt in the target chroot until we no longer care about old apt. | 13:05 |
| cjwatson | infinity: sure, I get that, but signing with --digest-algo SHA512 might be an easier temporary fix | 13:05 |
| infinity | cjwatson: Oh, true. | 13:05 |
| cjwatson | that should work even with prettyarchaic gpg | 13:06 |
| juliank | cjwatson: Could a rebuild of all PPAs be triggered after your digest algo change is in? Is that possible? | 13:06 |
| infinity | Anything's possible, but I bet republishing all active PPAs would take a few days. | 13:07 |
| cjwatson | juliank: still need to work that out, a full rerun of everything would be extremely slow but it may be possible to have a job that just re-signs everything | 13:07 |
| infinity | (rough order of magnitude guess) | 13:07 |
| juliank | It won't hurt not to do it, though, then users might notice some inactive PPAs | 13:07 |
| cjwatson | this is a pretty strict definition of "inactive" | 13:07 |
| infinity | juliank: "inactive" doesn't imply "bad". | 13:07 |
| juliank | Well, if they add a xenial repo after the patch is done, they won't have an issue. | 13:08 |
| cjwatson | it should be possible to just go through and run the Release step on everything | 13:08 |
| juliank | they = the PPA owners | 13:08 |
| cjwatson | but I need to work out the details | 13:08 |
| juliank | I don't think there's a huge amount of xenial PPAs for end users yet | 13:08 |
| infinity | You underestimate how popular PPAs are. :) | 13:09 |
| juliank | I even have PPAs on my Debian system! | 13:11 |
| juliank | works OKish | 13:11 |
| cjwatson | if my query isn't completely wrong there are at least 1440 PPAs with xenial publications | 13:12 |
| cjwatson | we definitely want to do something in bulk | 13:12 |
| juliank | Oh, and the Chrome repository generator is fixed on Google's side now; so that should start working with the next Chrome (pre-)release | 13:14 |
| juliank | I also think now that we have warnings for the SHA1 signed release files, there's no need to turn them into errors for 16.10, we can just turn them into errors everywhere on January 1. | 13:34 |
| juliank | Which is the same time frame the web browsers have. | 13:34 |
| juliank | (one stable update for xenial, one for xenial+1; and an upload to xenial + 2) | 13:34 |
| juliank | On the other hand, I could also make the code a time bomb that automatically knocks it off on Jan 1 | 13:35 |
| cjwatson | timebombs are terrible, you then get to deal with mis-set clocks etc. | 13:37 |
| rbasak | Also a package bump with a changelog entry is less surprising as an explanation of changed behaviour. | 13:37 |
| juliank | Yeah. It's also declarative now, a timebomb wouldn't... | 13:38 |
| * juliank has a table digest id => (trust state, name) | 13:38 | |
| juliank | APT does not trust any digest in the private/implementation-defined range | 13:39 |
| juliank | only the SHA2 ones and the reserved ones in the official range | 13:40 |
| juliank | starting with 1.2.8 | 13:40 |
| juliank | (1.2.7 would have also accepted digest algorithms in the private range) | 13:40 |
| xnox | pitti, is it possible to ignore spl-linux "regressions"? as far as I can see linux package builtin module is loaded, instead of the dkms module and then test fails. | 13:51 |
| xnox | it's an automatic dkms test or some such. | 13:51 |
| pitti | xnox: ah, we had this case with another package already indeed | 13:51 |
| pitti | yeah, http://autopkgtest.ubuntu.com/packages/s/spl-linux/xenial/amd64 doesn't look very good | 13:52 |
| pitti | xnox: will hint | 13:52 |
| pitti | xnox: in fact we already have a hint, it just needs its version bumped :) | 13:52 |
| xnox | pitti, thank you. And were is the test comming from? i guess we should be able to force use the dkms module, over the built-in one to make the tests test the dkms.... | 13:52 |
| pitti | xnox: from /usr/lib/dkms/dkms-autopkgtest | 13:53 |
| xnox | pitti, tah. | 13:53 |
| xnox | pitti, so dkms-autopkgtest can setup a wrapper script around dkms to call `dkms --force "$@"`, or e.g. dkms script could be modified to accept environment variable DKMS_FORCE= or some such. what would you prefer? | 14:16 |
| xnox | (then modules will be "force" installed by dkms, and we can test that they actually succeed) | 14:16 |
| pitti | xnox: maybe | 14:18 |
| pitti | xnox: but maybe the better thing would be to remove the dkms packages for which we already ship the modules in our kernel? | 14:18 |
| xnox | pitti, we will not. | 14:18 |
| xnox | =) | 14:18 |
| xnox | pitti, e.g. dkms package is arch:all, and in case of spl we pre-compile it only for some arches, not all. | 14:18 |
| pitti | ok | 14:19 |
| pitti | xnox: env variable sounds a bit difficult as that's called via apt -> dpkg -> postinst | 14:22 |
| pitti | xnox: so I guess dkms-autopkgtest would need to drop a config file somewhere? | 14:22 |
| pitti | wrapping sounds ok too, but then we don't really test dkms | 14:22 |
| pitti | we want to see what these packages actually *do* on installation | 14:22 |
| pitti | smoser: this language (map some properties to a name) is pretty much what .link files are, no? | 14:26 |
| pitti | smoser: /lib/systemd/network/99-default.link is the default if there are no more specific rules, but anything earlier than that can define its own name based on properties, and will then be handled by 80-net-setup-link.rules | 14:27 |
| xnox | pitti, yeah i'm not sure what should happen when a person does an active choice to install spl-dkms, e.g. whether or not it should or shouldn't shadow kernel built-in spl.ko. | 14:28 |
| smoser | pitti, yeah. that might work. | 14:28 |
| smoser | pitti, i like it. the only thing i dont like is that it ties me even more to systemd | 14:30 |
| pitti | smoser: this is udev stuff, so it'll work under upstart or sysv all the same | 14:32 |
| pitti | but it does tie you to >= vivid (or so) | 14:32 |
| pitti | smoser: anyway, you can equally well use udev rules for that, it's not a big difference | 14:32 |
| pitti | in both cases you need to have the rules in place before the network device gets detected | 14:33 |
| smoser | are you sure ? | 14:33 |
| pitti | well, once a network device appears you need to name it somehow, and once the event is processed that name i s set | 14:33 |
| pitti | you can change it on the next boot of course, but one must not start using the name in any configuration by then | 14:34 |
| smoser | pitti, right. but i think with systemd.link via /lib/udev/rules.d/80-net-setup-link.rules i can probably manage to populate that directory *during* the event, just prior to 80 | 14:35 |
| smoser | as it uses IMPORT. as long as 'builtin' reads the directory when the rule is processed (the same way it seems to for IMPORT{program} | 14:36 |
| pitti | yeah, that could work | 14:36 |
| pitti | adding rules while a rule is being processed most probably doesn't | 14:36 |
| smoser | yeah, i'm pretty sure it doesnt. | 14:36 |
| smoser | pitti, not a huge deal i dont think, but i'm almost certain that 'wait_for_interface' in /lib/udev/ifupdown-hotplug is completely bogus. | 14:44 |
| smoser | read state /sys/class/net/$interface/operstate | 14:45 |
| smoser | does not populate 'state' variable from the contents of read state /sys/class/net/$interface/operstate | 14:45 |
| smoser | that *should* say | 14:45 |
| smoser | read state < /sys/class/net/$interface/operstate | 14:45 |
| smoser | the former just does a read from stdin and returns error, never setting 'state' | 14:45 |
| pitti | smoser: maybe; this isn't being used for anything except lo under !systemd, so I doubt it's being tested | 14:51 |
| smoser | yeah, i dont think its a big deal in reality | 14:51 |
| smoser | but its completely broken if anyone ever expected it to work | 14:51 |
| pitti | right | 14:52 |
| pitti | smoser: actually, the only reason to even have this wrapper is the systemd-escape --template for ifnames with funny chars | 14:52 |
| pitti | otherwise the udev rule could just directly say ENV{SYSTEMD_WANTS}+=ifup%<something>.service | 14:53 |
| smoser | well, you said the wrapper would be needed to avoid dead ifup@non-auto-interface | 14:53 |
| pitti | right, that too | 14:54 |
| smoser | what funny names are there ? | 14:54 |
| pitti | well, someone might decide that they want an interface with / or @ or a space in the name | 14:56 |
| pitti | (which arguably is just making your life hard, but we at least shoudln't crash on it) | 14:57 |
| xnox | it will get systemd-encoded no? | 15:00 |
| xnox | ah right, mentioned above. | 15:00 |
| xnox | one can name interface names using UTF-8 characters and it totally works. | 15:00 |
| xnox | kernel is totally happy with network interface called 好 | 15:01 |
| xnox | very good name | 15:01 |
| nacc | slangasek: right, i'll work on that next -- i remember that now | 15:02 |
| blake_r | lamont: isc-dhcp is doing something wierd it keeps losing connection to its failover peer | 15:04 |
| blake_r | lamont: it didnt use to do this | 15:05 |
| nacc | tjaalton: did that fix to commons-lang-java also unbreak pki? | 15:05 |
| tjaalton | nacc: yes | 15:06 |
| nacc | tjaalton: great! | 15:06 |
| tjaalton | thanks | 15:06 |
| nacc | slangasek: it looks like, possibly, the zeta-console-tools is because we've disabled some normally built-in extension in the debian/ubuntu builds. I've got the list from ondrej and am now debugging | 15:07 |
| blake_r | lamont: also stop using SIGTERM is still broken | 15:26 |
| blake_r | lamont: I have to do SIGKILL which is nasty for the failover | 15:26 |
| infinity | blake_r: This is known. | 15:47 |
| infinity | blake_r: And being worked on. | 15:47 |
| blake_r | infinity: yeah lamont was working on it and wanted me to test | 15:50 |
| blake_r | infinity: is someone else working on it | 15:50 |
| infinity | blake_r: Ahh, you're testing a PPA or something? Nevermind, then. | 15:53 |
| slangasek | xnox: do you name your interfaces 好 and 不好? | 15:53 |
| lamont | infinity: ppa in prep for xenial upload... it's less broken, but I was hoping smb or doko or cyphermox would have more info for us | 15:54 |
| smb | lamont, if you wait a little maybe I have | 15:54 |
| infinity | lamont: "Less broken" instills such amazing confidence. | 15:55 |
| xnox | slangasek, i have had a double decoding bug, renaming my interfaces like that. And i was like "it can't be, and it totally is working" | 15:55 |
| smb | lamont, I am currently doing local test builds | 15:55 |
| xnox | slangasek, 好 and 不好 are awesome names for e.g. veth pair for a container =) | 15:55 |
| smb | infinity, at least it did do some work while only still not stop doing it when you wanted to | 15:56 |
| lamont | infinity: the first report was that 1 of 2 bugs appeared fixed. :/ | 15:56 |
| infinity | lamont: The bug I care about is the kill/term one. Though, if there are others, I'm all for them all being fixed. :P | 15:56 |
| lamont | infinity: the other one had to do with not handing out leases, iirc | 15:57 |
| smb | infinity, unfortunately that was the one not fixed | 15:57 |
| * smb wonders whether he talks to a different room | 15:57 | |
| infinity | If we fail to fix that one, we're going to have to hack around it with a late shutdown job that does killall dhclient. Which is vile. So let's not. | 15:57 |
| infinity | smb: I'm seeing you. :P | 15:58 |
| smb | infinity, thank deity! :-P | 15:58 |
| lamont | smb: and we're getting into the area where I'm not fully up to speed on the code that dhcp is using, so I'm kinda leaning on y'all here... | 15:58 |
| lamont | not just because I'm a touch sleep deprived atm | 15:58 |
| smb | lamont, I am suspecting some code in bind lib/isc/unix/app.c | 15:59 |
| lamont | smb: this would not surprise me | 15:59 |
| smb | lamont, but let me finish the test builds and then I could ask you to confirm I am not completely crazy (only half) | 15:59 |
| lamont | ta | 15:59 |
| lamont | poke me if I can help with any of it | 15:59 |
| * lamont goes to his meeting | 16:00 | |
| infinity | smb: Given your size, is your half crazy the same volume as my full crazy? | 16:00 |
| blake_r | lamont: the failover connection also seems to be going in and out, something that I saw before these issues occurred | 16:00 |
| smb | infinity, guess it depends on the square of distance or so | 16:00 |
| infinity | smb: Well, the question is if relative crazy or absolute crazy is the more interesting measure. | 16:01 |
| lamont | blake_r: I suspect that's related to the signals, but yeah | 16:01 |
| smb | infinity, that kindo of gets us into half-a-bee territory :-P | 16:02 |
| infinity | Bzzzzzzz! | 16:02 |
| maswan | smb: but half infinity is still infinity | 16:03 |
| infinity | maswan: I think you've just solved all my time management issues. Fetch me a saw. | 16:03 |
| smb | but then on the other hand there is no more crazy than inifinite crazy... So half of mine never can not be anywhere near (no matter of size) | 16:05 |
| nacc | slangasek: ugh, i'm super frustrated by this, but the maze of dependencies (and really old versions of various components) means i think the simplest answer is to put php-guzzle back in. is that feasible? | 16:21 |
| nacc | slangasek: i think the only reason we will need it is for this runtime dependency for aws-sdk-for-php | 16:21 |
| nacc | slangasek: as php-opencloud 2.0 uses php-guzzlehttp | 16:22 |
| nacc | slangasek: LP: #1543807 | 16:22 |
| ubottu | Launchpad bug 1543807 in php-opencloud (Ubuntu) "[FFe] upgrade to php-opencloud 2.0.0" [Wishlist,New] https://launchpad.net/bugs/1543807 | 16:22 |
| nacc | slangasek: then again, we could *not* move php-opencloud up, if php-guzzle is around | 16:22 |
| nacc | i hate carrying around a fully deprecated and unmaintained package, but these packages are a nightmare to untangle | 16:23 |
| smb | infinity, do you happen do remember to number of the dhclient is ignoring me part of the problem | 16:27 |
| infinity | smb: That sentence no English. | 16:28 |
| smb | infinity, at least those are English words. :-P | 16:29 |
| infinity | smb: There were many English words, yes. | 16:29 |
| smb | infinity, what I meant there is the dhclient does not terminate problem | 16:29 |
| infinity | smb: They just didn't sentence correctly. | 16:29 |
| smb | infinity, the one you are interested in getting fixed. I just cannot remember which bug number that was | 16:29 |
| infinity | https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1556175 | 16:30 |
| ubottu | Launchpad bug 1556175 in isc-dhcp (Ubuntu) "networking.service hangs on shutdown -- killing dhclient has no effect any more" [High,Triaged] | 16:30 |
| smb | infinity, coold thanks | 16:30 |
| smb | So I can add the correct closing codes to the changelog | 16:30 |
| infinity | smb: Does that mean you've fixed it? | 16:31 |
| slangasek | nacc: do you have a php7-compatible php-guzzle? the lack of compatibility was why it was removed | 16:31 |
| slangasek | nacc: my handwavy guess was that it was going to be better to port php-aws-sdk to php-guzzlehttp | 16:31 |
| smb | infinity, I think I have. Though I will let lamont have double check the change | 16:31 |
| nacc | slangasek: well ... we *could* port. that's why we were updating php-aws-sdk :) | 16:31 |
| nacc | slangasek: and it's almost impossilbe to figure out what to backport | 16:32 |
| infinity | smb: \o/ | 16:32 |
| nacc | slangasek: as i think we'd be backporting basically all of v3 of the SDK (lots of changes upstream) | 16:32 |
| smb | infinity, seems slightly crazy to fix signal processing not working by removing parts that install signal handlers | 16:32 |
| nacc | slangasek: but let me keep digging | 16:32 |
| infinity | smb: That does sound potentially sketchy. | 16:34 |
| smb | infinity, though effectively that is exactly how things where before upstream tried magics with the lib. | 16:36 |
| infinity | smb: Right, sounds sketchy on both counts. Removing a signal handler is often a sign your doing something wrong, but I'd argue that adding one to a client library is also a sign you've done something wrong. :P | 16:37 |
| infinity | smb: (Unless you've taught all the applications that link to it how to deal with the new world order) | 16:37 |
| smb | infinity, Right, which seems to be the little detail upstream did not care (enough)... | 16:38 |
| infinity | smb: The question is if removing the handler for dhcp's sake then breaks bind. | 16:39 |
| infinity | smb: Unless you're doing this in a dhcp-only build of the library. | 16:39 |
| smb | infinity, Oh I basically added a if (!isc_bind9) -> don't care about that | 16:39 |
| smb | right | 16:40 |
| infinity | smb: Right, that seems potentially reasonable then. | 16:40 |
| nacc | slangasek: as to symfony, i do think we'll want to update to 2.7.10, that will pick up several bugfixes, and allow for compat with php-proxy-manager 2.0 | 16:44 |
| lamont | smb: looking now | 16:51 |
| smb | lamont, I need 1 more minutes , sorry | 16:51 |
| lamont | np | 16:51 |
| hallyn | pitti: for autopkgtests, yes. | 17:19 |
| === mhall119 is now known as mhall119_canonic | ||
| === mhall119_canonic is now known as mhall119_cct | ||
| === mhall119_cct is now known as mhall119_CC | ||
| === mhall119_CC is now known as mhall119_CCT | ||
| === mhall119_CCT is now known as mhall119 | ||
| flexiondotorg | Is there something "wrong" with the xenial archive? | 18:10 |
| flexiondotorg | I can see new version of packages actually in the directory structure. | 18:10 |
| flexiondotorg | But apt-get update and apt-cache show is not finding these newer versions. | 18:10 |
| mitya57 | flexiondotorg, be more precise? which package? | 18:11 |
| flexiondotorg | ubuntu-mate-welcome was one I was interested in. | 18:11 |
| flexiondotorg | 16.04.4 is in published, but only 16.04.3 is discoverable. | 18:11 |
| flexiondotorg | gstreamer-plugins-1.0-bad is uninstallable as weel. | 18:12 |
| mitya57 | flexiondotorg, ubuntu-mate-welcome was published today, maybe your mirror is not yet updated… | 18:12 |
| infinity | flexiondotorg: ubuntu-mate-welcome looks there to... What mitya57 said. | 18:12 |
| infinity | flexiondotorg: Are you using a Canonical mirror, or a downstream, or a proxy? | 18:12 |
| flexiondotorg | OK, I'll check what mirror I'm using. | 18:13 |
| mitya57 | And gst-plugins-bad1.0 was published *only* 25 minutes ago, and not even migrated to release yet. | 18:14 |
| nacc | slangasek: ok, i can confirm that, based upon my testing, php-guzzle really is incompatible with php7 (curl issues, minimally) | 18:15 |
| nacc | slangasek: i'm going to ask the monolog maintainer about their dep | 18:15 |
| slangasek | nacc: ok. fwiw I'm context switching out the php stuff at this point since I don't see anything for me to do on it without diving into upstream code; but as soon as you have anything that wants sponsoring (or just review), just poke me | 18:18 |
| nacc | slangasek: yep, will do, thanks! | 18:18 |
| nacc | slangasek: have a (relatively) quick question for you, if you're available | 18:50 |
| nacc | slangasek: I *think* I have a way forward for php-monolog, but would like to understand if it's acceptable. It sounds like the only reason there is a build-dep on php-aws-sdk is to run the tests. So we *could* skip the tests, or intentionally fail those tests (the runtime throws an error) and catch that error appropriately. | 18:53 |
| slangasek | nacc: shoot | 18:53 |
| nacc | slangasek: if we could keep the previously sync'd version of php-aws-sdk :/ | 18:53 |
| nacc | slangasek: so much churn, i'm really sorry | 18:53 |
| slangasek | nacc: ok, we can certainly restore it (with a funky version number now), but that version was also not viable - you have fixes now for it? | 18:55 |
| nacc | slangasek: ok, so my understadning of why php-aws-sdk didn't work was strictly this php-monolog issue | 18:55 |
| nacc | as it's the only dependency in the archive on it | 18:55 |
| slangasek | nacc: do you believe php-monolog will be compatible with the new php-aws-sdk package? | 18:56 |
| nacc | slangasek: oh i see what you're asking | 18:56 |
| nacc | slangasek: so no, php-monolog is not compatible (afaict) with v3 of the API. But an upstream contributor basically says that "versioned dependency" in the composer.json is only there so the tests run. The runtime will leverage AWS if you want it to, but it's no a key part of the functionality, if that makes sense? | 18:58 |
| nacc | slangasek: i'm asking upstream for more clarity on what they'd recommend here | 18:58 |
| nacc | slangasek: v2 of the SDK is explicitly not PHP7 compatible (due to php-guzzle not being PHP7 compatible) | 18:59 |
| slangasek | nacc: right. so before we re-uplift php-aws-sdk, I want to make sure we have a solution for php-monolog, whatever it is - because downgrading aws-sdk a second time would be exceptionally painful :) | 19:00 |
| nacc | slangasek: yep, understood, i just wanted to clarify what is possible or not | 19:00 |
| nacc | slangasek: i'm not going to suggest antyhing until i get clarity from upstream | 19:00 |
| slangasek | ok | 19:00 |
| superm1 | cyphermox: slangasek, any intentions on moving to mokutil 0.3 instead of 0.2? it looked like it's changed now to use system efivar rather than an old embedded library along with tons of fixing on issues | 19:07 |
| nacc | slangasek: can you explain to my why php-mongodb hasn't proceeded to release? | 19:09 |
| === pavlushka_ is now known as pavlushka | ||
| slangasek | nacc: because of the php-defaults breaks, I think | 19:14 |
| slangasek | nacc: so new php-defaults needs to go in first | 19:14 |
| slangasek | superm1: hadn't made any plans around it; are there specific issues that are fixed that you're concerned about? | 19:15 |
| nacc | slangasek: ok, my current tentative suggestion is: re-uplift php-aws-sdk; remove build-dep in php-monolog which will skip tests. Not ideal, but from interacting with upstream, the AWS usecase is quite small (for monolog) | 19:16 |
| nacc | slangasek: hrm, i can chdist install both? | 19:16 |
| slangasek | nacc: the php-common from xenial, plus the php-mongodb from xenial-proposed? | 19:16 |
| cyphermox | superm1: does 0.3 better handle non-interactiveness | 19:17 |
| superm1 | slangasek: there's been a variety of odd issues that got fixed directly in efivar the past few months related to how it built up and parsed efi variables. they've affected both fwupdate and efibootmgr directly. i haven't directly seen any issues with mokutil myself that mirrored the type of stuff that happened in efivar | 19:17 |
| nacc | slangasek: ah ha! that's it, sorry, i was using the php-common from proposed as well, which is waiting right now | 19:18 |
| cyphermox | superm1: sounds worth checking out, I've noticed some issues with setting validation | 19:18 |
| superm1 | cyphermox: it does have some different import mechanisms | 19:18 |
| teward | is anyone else having issues editing things on the wiki? | 19:26 |
| * teward can't even edit his own page | 19:27 | |
| teward | nevermind, i just had to logout and login again :) | 19:29 |
| sarnold | teward: the details are that you were added to the new group that is required for editing privilegs, but the wiki doesn't notice until you logout and in again | 19:31 |
| teward | sarnold: indeed. | 19:32 |
| teward | weird that this didn't present yesterday | 19:32 |
| teward | and only today | 19:32 |
| * teward shrugs | 19:32 | |
| sarnold | odd indeed, I needed tio be added to the group several days ago | 19:33 |
| superm1 | cyphermox: https://launchpad.net/~superm1/+archive/ubuntu/uefi/+build/9364737 mokutil 0.3.0 if you want to see if it helps your validation issues. if you decide to go with it, there are some compile warnings that cause FTBFS on i386 with current toolchain, so might need to be more closely investigated | 20:20 |
| cyphermox | superm1: cool, thanks | 20:21 |
| teward | I had a poke from someone wondering if the 'unified ping' (ping / ping6) changes from Debian were incorporated into Ubuntu for Xenial, does anyone know offhand? | 20:49 |
| * teward isn't sure how to answer it | 20:49 | |
| teward | ooo, I see, Debian made that change in iputils to unify the ping and ping6 items, and uploaded after featurefreeze | 20:54 |
| teward | makes sense :P | 20:54 |
| superm1 | cyphermox: pretty sure this will fix the FTBFS on i386 too: https://github.com/lcp/mokutil/commit/cdb4b6f3bfd6ada6558ddfb889e27150f0841b28 | 20:54 |
| nacc | slangasek: i don't have much experience with importing new upstrema versions, and am ahving some trouble with symfony 2.7.10 and importing it. I'm following the instructions in debian/README.source but I'm not sure how I regenerate the license information for the images; and then I'm getting a dh_php failure afterwards; would you be able to help me understand what is needed? | 21:12 |
| slangasek | nacc: you want 2.7.10 specifically? I see 2.8.3 is available | 21:18 |
| slangasek | nacc: if you were going to 2.8.3, you would just run 'uscan && uupdate' | 21:18 |
| slangasek | nacc: for 2.7.10, you want to download the tarball manually, and then use uupdate | 21:18 |
| slangasek | oh, but the watch file doesn't handle source mangling for us? | 21:19 |
| slangasek | haaaaate | 21:19 |
| nacc | slangasek: i *think* 2.7.10 is a safer upgrade ... 2.8.3 introduces some functional changes, afaict, and 2.7.10 will get us proxy-manager 2.0 compliance | 21:20 |
| nacc | slangasek: not only that, the watch file is syntactically wrong | 21:20 |
| nacc | it uses \d | 21:20 |
| nacc | rather than \d+ :) | 21:20 |
| nacc | so it doesn't even see 2.7.10 | 21:20 |
| slangasek | ah, heh | 21:20 |
| slangasek | nacc: escape hatch, because Debian already has 2.8.2 in experimental we probably will never have a 2.7.10 tarball in Debian so we don't have to worry about checksum mismatches. So we assume that we can create our own orig.tar.gz with impunity. as for licensing, I only know what I read in that same debian/README.source | 21:21 |
| slangasek | nacc: I would try the script that they provide, and cross-reference with licensecheck | 21:21 |
| nacc | slangasek: ok, good to know, let me try with uupdate | 21:21 |
| nacc | slangasek: Pharaoh_Atem also indicate the version chagne for symfony breaks lots of tools (2.7 -> 2.8), so i think we'd rather avoid it if we can | 21:22 |
| * slangasek nods | 21:24 | |
| lamont | doko: http://bugs.debian.org/818541 :p | 21:30 |
| ubottu | Debian bug 818541 in libbind-dev "libbind-dev: arch-dependent files in "Multi-Arch: same" package" [Important,Open] | 21:31 |
| nacc | slangasek: can you confirm something for me? does symfony fail to build for you with dh-php in the archive? | 22:30 |
| slangasek | nacc: the current symfony and dh-php packages in the archive? | 22:31 |
| nacc | slangasek: yeah -- i have a log locally of it working with dh-php 0.5, but with dh-php 0.10, i'm getting an error | 22:32 |
| sarnold | pitti: can you please take a look at 1558823? thanks ;) | 22:36 |
| nacc | slangasek: so i think 0.10 removed "auto-configuration" and ... so symfony won't build | 22:40 |
| slangasek | nacc: I see it failing to build with test failures | 22:45 |
| slangasek | nacc: http://paste.ubuntu.com/15410975/ | 22:46 |
| slangasek | not sure if that's related to the auto-configuration you mention | 22:46 |
| nacc | slangasek: hrm, with dh_php 0.10? I get: "dh_php: .php configuration file is needed for dh_php" | 22:46 |
| slangasek | yes | 22:46 |
| slangasek | it is, however, building without xenial-proposed enabled | 22:46 |
| slangasek | should I try that? | 22:46 |
| nacc | slangasek: ah ambye that's the differnce | 22:47 |
| nacc | yeah i'm using proposed | 22:47 |
| slangasek | ok, checking | 22:47 |
| nacc | slangasek: hrm, I got a failure without proposed too | 22:49 |
| nacc | weird! | 22:49 |
| slangasek | nacc: ah, interesting. And this is symfony 2.7.9+dfsg-1ubuntu2 ? | 22:50 |
| slangasek | nacc: I see the same failure with either xenial or xenial-proposed | 22:51 |
| nacc | slangasek: the testcase failure you pasted above? | 22:51 |
| slangasek | nacc: yes | 22:51 |
| nacc | slangasek: i'm pulling down the source again to be sure i'm not carrying osme bad state somehow | 22:53 |
| nacc | slangasek: ugh, i apologize, it must have been something stale in my repository ... will debug it | 22:53 |
| nacc | s/repository/system | 22:53 |
| slangasek | ok :) | 22:53 |
| nacc | slangasek: ah ha! i see why now | 23:07 |
| nacc | slangasek: ok, so in my case, i'm still trying to figure out how to update the licenses | 23:07 |
| nacc | so i passed DEB_BUILD_OPTIONS=nocheck to skip the license check for now | 23:07 |
| nacc | slangasek: but that also skips the tests :) | 23:07 |
| slangasek | ah ;) | 23:07 |
| nacc | slangasek: ah, but symfony 2.8.2 in experimental does have the fix for your testcase failure | 23:10 |
| nacc | slangasek: ok,i'll need to spend more time on this to figure out wehther we hsould just go to symfony 2.8.2 like you said earlier; but that adds a new source & binary requiremeint, php-symfony-polyfill (although I think our version can be trimmed down significantly since we aren't going to support php5) | 23:21 |
| slangasek | I think php-symfony-polyfill is already in Ubuntu, but stuck in -proposed? | 23:22 |
| nacc | slangasek: ah i see, probably needs some updates to use the right deps | 23:23 |
| Logan | doko: looks like gmp-gcc4 is failing to rebuild due to the new inclusion of -Wdate-time in dpkg-buildflags (which GCC 4.7 doesn't support, apparently) | 23:28 |
| slangasek | Logan: adjust the package to filter it out of the buildflags? | 23:30 |
| slangasek | (or drop the package, because gcc4?) | 23:30 |
| Logan | I didn't want to touch it without doko's approval since he created the split for Xenial | 23:30 |
| Logan | I guess it has some legacy rdeps | 23:30 |
| slangasek | the worst that can happen is that you're permanently TIL ;) | 23:31 |
| Logan | the horror! | 23:31 |
| nacc | slangasek: ok, debdiff posted in LP: #1558848 for polyfill | 23:32 |
| ubottu | Launchpad bug 1558848 in symfony (Ubuntu) "symfony: failing autopkgtests" [Undecided,New] https://launchpad.net/bugs/1558848 | 23:32 |
| nacc | builds & passes test here | 23:33 |
| nacc | with that in, i'll look at testing the debian version of symfony, i think | 23:33 |
| nacc | slangasek: could you possibly kick php-symfony-security-acl's build? I think it should build now | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!