[00:40] slangasek: ugh, upstream php7.0.4 does not show the problem. very confused right now, will debug it tmrw [00:40] slangasek: could be a configure option we're passing [00:42] nacc: because of course a language should behave differently depending on the configure options you pass at build time ;) [00:42] slangasek: i'm hopeful that's not it, but then i'm not sure what it is [00:51] 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:53] 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 [01:11] 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:12] nacc: I'll go ahead and upload that change onw [01:12] now [01:14] slangasek: ah thanks! yep, that makes sense [01:14] slangasek: sorry, first time i'd encountered that, appreciate your uhelp [01:15] 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:16] hahahaha [01:19] 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] slangasek: so i'm 99% sure it's the configure [01:28] 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:35] nacc: php-common also breaks: the version of php-mongodb we have [01:35] not sure why that is when there's no php-mongodb package yet anywhere in Debian; ohwell [01:36] slangasek: that is odd; do you want me to spin up a debdiff? [01:36] nacc: nah I'll sort it out, just giving you a headsup [01:36] slangasek: thanks, i appreciate it [01:42] nacc: stupid dependency boolean tricks: https://launchpad.net/ubuntu/+source/php-monolog/1.17.2-1ubuntu2 [01:43] slangasek: ah ok, thanks! [01:48] 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:49] slangasek: that will resolve the two failures i see in the logs, i think [01:50] slangasek: nm, i was looking at an old log! :/ [01:50] nacc: oh, the monster... [01:53] slangasek: i *think* we'll want to bump or cherry-pick from 2.7.10 [01:54] slangasek: but i will need to look at the diff, etc [01:55] alternatively, like you suggested before, we could look to sync from experimental [01:55] that would need a FFe, of course [01:59] but based upon upstream changelog, all of 2.7.10 is bugfixes [01:59] so that might be the safest course [02:01] nacc: why not just save yourself the trouble and sync to 2.7.10? [02:01] Latest Upstreams are _always_ the Best Available And Has No Bugs[tm] :) [02:01] 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] ™ [02:01] heh [02:02] ugh [02:02] okay [02:02] well, using 2.7.10 means that it’ll be easier to cherrypick from 2.8 later on, when you have to [02:03] 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:04] 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] 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:05] just because the company I work for practically depends on it, doesn’t mean I like mucking around in it [02:05] I’ve learned way too many terrible things in my quest to figure out how much stuff breaks with php7 [02:05] find . -type f -exec sed -i 's/2.7/2.8/g' {}\; #YOLO [02:06] sarnold: the saddest part about it is that it didn’t work :( [02:06] at the end of it all, the application was busted [02:06] damn people and their lack of foresight [02:07] Son_Goku: aww :( that's frustrating [02:07] 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:08] because no tolerance in your software A Good Thing(TM) [02:08] the situation got bad enough in Fedora land that we had to walk back from our policy of blocking bundling by default [02:09] ow :/ [02:10] 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] I’m lucky enough to work on packages where I don’t have upstreams like that [02:10] but man, the worst examples of this are chromium and owncloud [02:10] 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:11] the biggest irony of owncloud is that they’re run by former SUSE/openSUSE engineers [02:11] and SUSE themselves don’t allow ownCloud into their core repos [02:12] 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] I’m all for using a nice build system and all, but their attitude is terrible [02:13] this is one of the big reasons I don’t like Docker [02:13] note that Docker != containers [02:14] maybe I’m an old fogie, but I remember when all the distros were burned because of zlib [02:14] that one was -painful- [02:14] you’re telling me [02:15] to this day, I’m *still* not sure if all of that is gone [02:15] I’m only 24, but I remember when it happened [02:15] and holy crap the fallout was horrible [02:15] heh I bet you're right.. [02:16] 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] the bullshit about Alpine Linux only encourages it [02:16] because guess what you have to do when there’s nothing in your container rootfs? [02:17] vendorize! [02:17] * Son_Goku sighs [02:17] it’s not helping that all the enterprise distros are gunning for this weird space [02:18] Red Hat with Atomic, Canonical with Ubuntu Snappy, SUSE with JeOS, Docker with Alpine Linux, etc [02:18] and yes, I’m counting Docker as a distro vendor now [02:18] because they effectively took over stewardship of Alpine [02:19] oh joy [02:19] netsplit hell [02:20] sarnold: I think that like OpenStack, people are going to hit the gas pedal too hard [02:20] and then when they realize they landed in some disgusting stuff, the pendulum will swing again [02:21] I barely give a pass on Chromium for the bundling thing because they have some semi-legit reasons for it [02:22] but holy hell, look at how many bundled() Provides it has: https://spot.fedorapeople.org/chromium.spec [02:22] 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:23] like… WHY do you need your own GTK+3?! [02:23] and then… zlib [02:23] sarnold: I have spent two months trying to properly set up OpenStack [02:24] 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] # Bundled bits (I'm sure I've missed some) [02:24] but every time I try, more of me dies inside because of the sheer overengineered complexity that’s in it [02:25] I just use oVirt now [02:25] my own personal sandbox where I do all my crazy stuff is an oVirt system [02:25] it’s ~15 minutes to set up, and It Just Works(TM) [02:25] something that the world likes to forget about, these days [02:26] most of my php7.0 package dev work and testing has been on the oVirt system [02:27] 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] I’ll probably throw in openSUSE Tumbleweed and Mageia Cauldron to round out my testing [02:28] sarnold: but yeah, if you’re looking to make a nice little ESXi-like VM environment, I highly recommend oVirt [02:28] it works great, it’s FOSS, and it’s not complicated! [02:29] actually, does Ubuntu have an equivalent to Fedora’s bundled() Provides? [02:29] not that I know of [02:29] hmm [02:30] it comes in handy for my automated auditing with a shitty shell script [02:30] the debian security team has a bundled listing somewhere, but it's not particularly easy to updae [02:30] eck [02:31] I once tried to make virtual Provides like the ones I’m used to when I make RPMs for Fedora/Mageia [02:31] on Ubuntu [02:31] I’ve never seen apt blow up in such strange ways [02:31] apparently, it’s a really stupid idea to load up on virtual Provides [02:32] oh my :) yeah, I think the easiest way out of that is to start over.. === juliank_ is now known as juliank [02:33] 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] then I tried it and found out why [02:34] sarnold: also, apparently you can break the apt db and the repo metadata by doing stuff like that [02:34] it doesn’t handle it very well :P [02:34] hehe yeah, apt assumes everyone doing packaging has learned the debian secret handshakes [02:35] I don’t think I’ll ever learn those [02:35] I’ve been doing packaging for almost 8 years [02:36] when I first started using Ubuntu back in 2005, I was surprised to see that it chose a Debian base [02:36] I found out that Mark Shuttleworth was a former Debian maintainer a few years later, and the pieces fell into place :) [02:45] sarnold: I feel old when I think about stuff like this [02:45] I’ve witnessed the rise of Linux [02:45] and I had a (very) small hand in some of that [02:45] Son_Goku: heh, I was around for the very end of the a.out -> ELF transition.. [02:45] I came in just after that, I think [02:46] I was there for the transition from LinuxThreads to NPTL, though [02:47] woot :) not bad for 24, hehe [02:47] the COFF->ELF transition was one I was glad to miss though [02:51] but yeah [02:52] 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] the LSB attempted it, but with how little distros followed it, it didn’t matter [02:53] today, the closest we’re getting is with systemd, which is forcing distros to stop being special snowflakes in some respects [02:53] making it easier to make portable applications that don’t require vendoring [02:55] the LSB never understood that double-dipping by charging both OSVs and distro vendors for certification was a failed funding model [02:56] and there's just no denying that insserv was annoying :) [02:56] insserv was never a required LSB interface [02:58] that was -optional- and people opted into it? oof :) [03:00] 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:01] interesting [03:04] 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:05] nacc: alright, php-aws-sdk is still uninstallable, because php-guzzle was removed (LP: #1543808) [03:05] Launchpad bug 1543808 in php-guzzle (Ubuntu) "Please consider dropping php-guzzle from Ubuntu Xenial" [Wishlist,Fix released] https://launchpad.net/bugs/1543808 [03:06] 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:07] 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] didn't lennart already do that? :) [03:07] 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] sarnold: he capitulated way too much early on [03:07] pitti: a link showing the proper way to ask 'please reboot with the 'cgroup_enable=memory' boot argument' ? [03:08] systemd actually has a lot of things to deal with debianisms, suseisms, etc. [03:09] 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] the Upstart->systemd move was quite painful in Fedora 15 [03:09] of course, you guys got all the benefit of that pain, many years later :) [03:10] * hallyn does the dance of joy [03:10] * hallyn brushes away some of the copious sarcasm [03:12] 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:13] single database, handling all the package types, repos, etc. [03:13] yikes that sounds terrible [03:13] well, it’s the rpm5 project [03:13] the guy is of the firm belief that having a division in packaging systems only hurts the community [03:13] so he made it his goal to introduce support for both packaging systems in RPM5 [03:13] which he did [03:14] he’s employed by the Yocto Project, who uses his fork of rpm for their stuff [03:15] I'm reminded of https://xkcd.com/927/ [03:15] yep [03:15] I can’t say I disagree with Jeff on his belief [03:15] 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] because he managed to alienate everyone in the process of that [03:16] there was even LWN articles about his project :P [03:16] hallyn :) [03:17] the most annoying part is that he took over the project page for RPM on launchpad [03:17] so now it’s chock full of bugs and discussions that are completely non-relevant to the project that actually controls that page [03:18] rpm5 webpage tells me it's ~relaunched~ [03:18] I know [03:18] he did that on purpose [03:18] when Red Hat let him go, he did that [03:20] but it’s aggravating because rpm5 controls https://launchpad.net/rpm despite everything [03:20] people file bugs about the rpm in ubuntu, but no one deals with it, because the rpm5 people don’t give a damn [03:23] hallyn: the rpm5 project is geared towards merging the capabilities of apt/yum, rpm, and dpkg into a unified rpm [03:23] it can even replace reprepro, createrepo, etc. [03:23] what about ebuild :) [03:23] it has rudimentary capabilities for that too [03:23] Hi! [03:23] it can download sources and compile them automatically in chroots and stuff like that [03:24] it’s got a lot more capabilities than the main rpm [03:24] 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:25] hallyn: of course, now it has mongodb integration, so I don’t know what to think anymore [03:25] Only thing I want to ask about is a translation that I'm doing for Xenial. [03:26] I can use #launchpad if that's preferred, but I just want to hear what you guys think. [03:26] Pidgin Internet messenger [03:27] The part of Internet Messenger, should that be translated into my language? [03:27] It's a bit tricky to get it accurate. [03:28] isn’t it an “Instant messenger”? [03:28] Yeah, but in Swedish that's a bit hard to translate. [03:28] That's why I'm asking. [03:28] And YES, I'm Swedish. [03:28] Umeaboy: I think I’ve met you before [03:28] Yeah. [03:29] You have. [03:29] in #Mageia, right? [03:29] Yeah. [03:29] you probably shouldn’t translate the “internet messenger” bit [03:29] because it’s part of Pidgin’s title [03:30] Right. [03:30] My thought as well. [03:30] I was thinking about translating into "Meddelandeklienten" [03:31] 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:32] Likewise, on my system, the menu icon says "Firefox Web Browser", but the name of the application upstream is just Firefox. [03:33] rlaager: Yeah, that's just plain irritating. [03:34] Umeaboy: What's irritating? The extra words in the Ubuntu menus? [03:34] rlaager: Yeah. [03:34] I know WHY, but............ [03:35] It's like I in Swedish say That brown ball of meat to a Meatball. [03:35] It's like you're talking to a 2 year old. [03:35] Simple can be TO simple as well. [03:36] I wish we had a choice during the installation how we want our menus. [03:36] Just like you can do in Android [03:36] Regular touch desktop or Simple Touchwiz. [03:36] Simplified Touchwiz that is. [03:38] I'll just leave it then I guess. [03:56] rlaager and Son_Goku: What about the part for ubiquity-slideshow-ubuntu: Bienvenue! [03:56] ? [03:57] I know it's in French, but am I supposed to translate thoose sentances or words? [03:57] I have a feeling as to what they are used for, but I want to be sure. [03:57] Umeaboy: I don't have any guidance there. I'm not an Ubuntu developer and I'm not familiar with that application. [03:57] OK. [03:58] i have a vague memory of the slideshow saying 'welcome' in many languages [03:58] sarnold: Everyone loves copying Apple, don't they? ;) [03:59] rlaager: it's entirely possible that that's what I'm remembering :) === shuduo-afk is now known as shuduo [04:38] sarnold: Are you sure you didn't copy the thought of that from someone else? [04:38] ;) [06:26] 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:48] good morning [07:34] good morning [08:14] Good morning [08:18] 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:19] 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:20] wgrant: meh, since yesterday our scalingstack instances are one big "timed out waiting for ssh" sorryness [08:20] and "INFO: task sshd:659 blocked for more than 120 seconds." [08:20] known? [08:23] pitti: lgw01 is undergoing maintenance; lcy01 doesn't seem too awful [08:23] this affects all three clouds [08:23] pitti: though there was an incident yesterday that took it down [08:24] (lcy01 that is) [08:24] pitti: I think you'll need to check directly with IS then; LP builders are not broken across the board [08:24] cjwatson: ack, thanks [08:24] (I think) [08:24] just wanted to check before as there's no vanguard ATM [08:25] right, lgw doesn't respond, so if that's known, I won't report that again [08:27] it's having surgery done on its mysql [08:29] * pitti blames the vivid backported 3.19.0-57-generic kernel [08:32] apw: the vivid 3.19.0-57.63 kernel update is completely broken :( [08:36] apw: http://paste.ubuntu.com/15406752/ [08:42] 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] ta, thanks [08:42] lamont, I just copied your bind over to a ppa of mine to add isc-dhcp later [08:42] kewl [08:43] * lamont had some things come up that kept him from sleeping tonight, so he fought the battle to the conclusion. [08:43] otoh, too sleepy to be confident in my testing, nor do I have a trivially easy test setup for dhcp [08:43] Mirv, libinput needs a merge, xserver-xorg-input-libinput is dep-wait [08:43] Does not sound that good [08:44] pitti: lgw01 is back. [08:44] After some mysql hackery. [08:44] 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] I did [08:44] that one built locally (needed a new lib for 9.10) [08:45] I see (just reading the changelog) [08:45] smb: thanks for that work, btw [08:45] n.b., all I did was make it not ftbfs. [08:46] but Ihave every reason to believe that it by damn well better fix the bugs [08:46] lamont, yw. Heh, yeah, unfortunately that was not obvious before :) [08:46] doko: you might mean that to tjaalton? [08:46] 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] Mirv, ohh, crap, I do ... :-/ [08:47] wgrant: yay, thanks for notifying; reenabling [08:47] pitti: I misread LP logs, it may not actually be working yet. [08:47] But if it's not working then you may be able to get more details as to why. [08:47] 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] (we don't have logs from lgw01 because lgw01 is entertaining) [08:47] 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] Right. [08:47] doko: oh right [08:48] Let me know if you can/can't start instancecs. [08:48] smb: :D [08:50] tjaalton, and a 1.2.2 seems to be out [08:50] smb: I took a really really big hammer and just beat the living hell out of that square peg until it fit. [08:50] doko: yes updating it atm [08:51] wgrant: right, "server building" is hanging, it's stuck in scheduling/NOSTATE [08:52] 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:53] apw: I purged all linux-meta test requests from the vivid queues FYI, so they'll stay in "MISS" forever on your side [08:54] pitti, ahh did we lose the vivid hosts ... damn [08:54] smb it's a configure run, followed by a pair of for looped sed commands with a patch run in between... [08:55] tbf, I could have moved the patch run, but ... HAMMER [08:55] lamont, yay! (half-hearted) :) At least good you did not use grep [08:55] smb: it didn't make it into the script. :p [08:56] So we do not need a Claymore on top of the hammer [08:56] heh [08:57] smb: not as long as the dhcp bugs are fixe [08:57] d [08:57] also, thanks isc for dropping the --enable-exportlib code [08:58] and yes, I'll be grumbling at my isc contacts [08:58] but not until next week [09:00] smb: doko isc-dhcp is built, waiting for publication [09:01] lamont, ack [09:01] and sleep for me.!! [09:02] Heh, I think that you better do on your own for yourself [09:13] 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] Hm... to my testing 1 of 2 problems solved [09:14] dholbach, also I would have guided flexiondotorg to do it the proper way so next requests can be more easily handled :p [09:14] seb128, I have been so guided :-) [09:15] flexiondotorg, sorry but those diff + tarball sponsoring requests are just not easy to reconstruct/sponsor [09:15] you should better add the dsc/diff|debian.tar.gz/orig [09:16] seb128, Understodd and future sponsoring requests will be more sponsor friendly. [09:16] thanks [09:22] 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:24] seb128, very easy: downloaded old package and debdiff, applied it [09:25] seb128, but I said to flexiondotorg that a link to a .dsc file in a ppa would maybe be more straight-forward [09:25] 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:26] oh well, I guess they can fix fallover from that workflow if there are some [09:26] next time, ppa upload :) [09:26] or dsc/diff.gz to the bug [09:26] that works as well [09:35] 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] cjwatson, Sure, what is the correct project name? [09:36] flexiondotorg: the ubiquity package in Ubuntu, as I said [09:36] flexiondotorg: as in, "also affects distribution/package", not "also affects project", etc. [09:37] Thanks, that's the clue I needed. [09:37] cheers [09:41] 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] 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:42] ta [09:43] lamont, Hm, we will see how much that is but have a good night (had hoped you may already have) [09:43] there was driving involved. [09:43] and the "huh, let me try to punt this to foundations" thought brought me back.. now I'm off to actual sleep. [09:44] heh [09:55] pitti: Should be fixed for real now. [10:17] wgrant: yay, works indeed, thanks [10:17] queues will appreciate the horsepower [11:00] 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:47] pitti, autopackagetest ENOQUOTA [11:47] xnox: it should be much better now that lgw01 is back, queues are catching up fast [11:47] they were broken since last night for various reasons [11:48] right, but i see adt logs having errors "30 out of 30 cpus used" and thus failing everything. [11:48] xnox: that's mostly harmless, they'll auto-retry [11:48] ok [11:48] xnox: that happens if there are several "big" tests running which use an m1.large instead of the normal small [11:48] thus they block more cores [11:49] (linux, binutils) [11:49] plus, lcy01's db is off again and claiming that I use more resources than I actually do === _salem is now known as salem_ [12:49] /win 13 === roaksoax is now known as roaksoax-afk [12:53] pitti, i have (at least) one more question. [12:54] 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] heres what i'm interested in doing. [12:54] juliank: iz migrated now. [12:55] infinity: oh dear [12:55] we haven't had time to re-sign PPAs yet [12:55] a.) add event fires a rule in place by cloud-init that runs cloud-init-name-device via import [12:56] I guess we're about to get a support firestorm [12:56] that blocks until i've found information on what devices should be named [12:57] 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:58] so i'm going to end up with some language for saying "ID_NET_NAME_PATH=enp0s25 NAME=foo0" [12:59] 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. [13:00] ie, i'd like for cloud-init-local to write /etc/udev/rules.d/70-persistent-net.rules [13:02] cjwatson: Oh. A blocking bug might have been nice. If only the guy who wrote that feature was an LP dev. [13:02] infinity: I didn't realise it was going to start happening quite so soon :P [13:03] juliank: bug 1558331 - looks like synaptic's handling of warnings causes confusion [13:03] 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] (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] 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:04] (Thankfully, sbuild's just noisy, it doesn't fail) [13:04] infinity: there was some debate about that in a bug somewhere, I forget the details [13:04] cjwatson: Yeah, the warning system is somewhat confusing. [13:04] With 1.2.8 it gets better [13:05] As it then shows the actual errors as E: [13:05] 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] infinity: sure, I get that, but signing with --digest-algo SHA512 might be an easier temporary fix [13:05] cjwatson: Oh, true. [13:06] that should work even with prettyarchaic gpg [13:06] cjwatson: Could a rebuild of all PPAs be triggered after your digest algo change is in? Is that possible? [13:07] Anything's possible, but I bet republishing all active PPAs would take a few days. [13:07] 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] (rough order of magnitude guess) [13:07] It won't hurt not to do it, though, then users might notice some inactive PPAs [13:07] this is a pretty strict definition of "inactive" [13:07] juliank: "inactive" doesn't imply "bad". [13:08] Well, if they add a xenial repo after the patch is done, they won't have an issue. [13:08] it should be possible to just go through and run the Release step on everything [13:08] they = the PPA owners [13:08] but I need to work out the details [13:08] I don't think there's a huge amount of xenial PPAs for end users yet [13:09] You underestimate how popular PPAs are. :) [13:11] I even have PPAs on my Debian system! [13:11] works OKish [13:12] if my query isn't completely wrong there are at least 1440 PPAs with xenial publications [13:12] we definitely want to do something in bulk [13:14] 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:34] 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] Which is the same time frame the web browsers have. [13:34] (one stable update for xenial, one for xenial+1; and an upload to xenial + 2) [13:35] On the other hand, I could also make the code a time bomb that automatically knocks it off on Jan 1 [13:37] timebombs are terrible, you then get to deal with mis-set clocks etc. [13:37] Also a package bump with a changelog entry is less surprising as an explanation of changed behaviour. [13:38] Yeah. It's also declarative now, a timebomb wouldn't... [13:38] * juliank has a table digest id => (trust state, name) [13:39]