| teward | did the perl 5.22 transition finish already? | 00:24 |
|---|---|---|
| Unit193 | teward: https://launchpad.net/ubuntu/+source/perl | 00:25 |
| Bluefoxicy | Transition to what? An expanded list providing duplicate keys in a hash? | 00:25 |
| teward | that answers the question xD | 00:26 |
| teward | Unit193: thanks (the transition tracker shows one thing still failing, hence the question) | 00:26 |
| Bluefoxicy | no docker 1.9 in next LTS? | 00:27 |
| Bluefoxicy | the new docker-compose allows setting ulimits in the compose file, which is a pretty major feature | 00:27 |
| Unit193 | Just means I can do my perl5.22 rebuilds now too. | 00:30 |
| cjwatson | teward: the tracker is only a guide, and in this case that's only failing because I hadn't yet done NBS removals following the transition (doing now) | 00:35 |
| teward | cjwatson: ah, OK, i should've known when nginx 1.9.6-2ubuntu2 landed that the perl migration finished :P | 00:36 |
| teward | thanks though | 00:37 |
| Bluefoxicy | nginx 1.9! | 00:37 |
| Bluefoxicy | Ubuntu 16.04 LTS will have http2 capability | 00:37 |
| teward | um | 00:37 |
| teward | maybe at some point | 00:37 |
| teward | but not right now | 00:37 |
| Bluefoxicy | ... as if that matters. Running nginx out of a docker container is easy. | 00:37 |
| teward | (talk to the Security Team) | 00:37 |
| cjwatson | ECHAN? | 00:37 |
| Bluefoxicy | teward: http2 is part of nginx 1.9 | 00:37 |
| teward | Bluefoxicy: optional module, has to explicitly be enabled | 00:38 |
| Bluefoxicy | ah | 00:38 |
| teward | you may be interested to read the merge bug | 00:38 |
| cjwatson | oh right | 00:38 |
| Bluefoxicy | so it's in the docker container for official, but not enabled in nginx on Ubuntu ok | 00:38 |
| teward | https://launchpad.net/bugs/1510096 | 00:38 |
| ubottu | Launchpad bug 1510096 in nginx (Ubuntu) "Please merge 1.9.6-2 (main) from Debian Unstable (main)" [Wishlist,Fix released] | 00:38 |
| teward | Bluefoxicy: the PPA has it though | 00:38 |
| teward | also managed by yours truly :) | 00:38 |
| teward | cjwatson: ? | 00:39 |
| Bluefoxicy | that's ... odd. | 00:39 |
| Bluefoxicy | does http2 add anything to the execution path if you don't explicitly set listen ssl http2? | 00:39 |
| teward | Bluefoxicy: as I said, talk to the sec team | 00:39 |
| jrwren | "security team" | 00:39 |
| teward | ^ they overrule things :P | 00:40 |
| Bluefoxicy | I mean I understand the point; I'm just curious if the code is even executed (thus, capable of bringing security problems) if the user doesn't use it explicitly | 00:40 |
| * teward shrugs | 00:40 | |
| teward | whether I believe it's stable or not, not my call | 00:40 |
| Bluefoxicy | (I'm also annoyed nginx doesn't package modules as DSO, but that's a long-standing conversation between nginx developers and entire world) | 00:40 |
| teward | Bluefoxicy: for those of us on the tail end of a long day beating an ancient Dovecot into submission to migrate it to a newer dovecot, mind expanding DSO to full words? | 00:41 |
| teward | please :) | 00:41 |
| Bluefoxicy | teward: Dynamic Shared Object | 00:41 |
| teward | Bluefoxicy: i think they just want the HTTP/2 protocol to have more exposure in the real world :) | 00:41 |
| teward | ahhh, yeah, i think dynamic modules are planned | 00:41 |
| teward | where'd I see that email... | 00:42 |
| * teward digs up the message from rbasak he saw recently... | 00:42 | |
| Bluefoxicy | there was experimental dynamic loading support 10 years ago :P | 00:42 |
| teward | https://lists.ubuntu.com/archives/ubuntu-release/2016-January/003499.html is relevant | 00:43 |
| teward | (for the HTTP2 in Xenial thing) | 00:43 |
| Bluefoxicy | ah | 00:44 |
| cjwatson | teward: never mind | 00:45 |
| teward | cjwatson: ok :) | 00:45 |
| teward | wheee, ftbfs in sbuild schroots >.> | 00:45 |
| === _salem is now known as salem_ | ||
| * psusi remembers when dynamic loading was the fancy new thing both to the kernel and user space... circa 1997 or so... | 01:16 | |
| psusi | had a lot of fun playing with the new shared objects and dynamically loading them in eggdrop 1.3.x irc bot | 01:17 |
| psusi | can't believe it's 2016 already | 01:18 |
| teward | psusi: heheh | 01:25 |
| sarnold | pitti: could you please give some feedback on 1503762? It feels to me like Felipe's suggestion for an apparmor systemd service file is just about right but it'd be nice to have your opinion before we get too far ahead of ourselves :) thanks | 01:40 |
| === salem_ is now known as _salem | ||
| === jincreator is now known as jincreator_ | ||
| === jincreator is now known as jincreator_ | ||
| Mirv | is it known Ubuntu Installer e-mail notes lag by up to a month? every now and then I still keep getting notices from my December's Qt landing. yesterday I got a notice for this https://launchpad.net/ubuntu/+source/gammaray/2.3.0-3build1 that landed to release pocket 2015-12-10 | 06:17 |
| Mirv | and I had e-mail about this https://launchpad.net/ubuntu/+source/gcin/2.8.4+dfsg1-1ubuntu1 on 2015-12-28.. | 06:19 |
| infinity | Mirv: Sounds more like a mail server hitching up somewhere. | 06:20 |
| infinity | Mirv: LP just spits the mail out to an MTA managed by IS, after that it's a blackhole to us. | 06:21 |
| infinity | Mirv: Oh. Or no. | 06:23 |
| infinity | Mirv: It's s390x catching up, probably. | 06:23 |
| infinity | https://launchpad.net/ubuntu/+source/gammaray/2.3.0-3build1/+build/8387977 | 06:24 |
| infinity | https://launchpad.net/ubuntu/+source/gcin/2.8.4+dfsg1-1ubuntu1/+build/8387979 | 06:24 |
| infinity | Note those builds happened fairly recently. | 06:24 |
| infinity | And when proposed-migration decides they're good to copy, it recopies the source+binaries, since that's easier than figuring out how to just copy a binary. :P | 06:24 |
| infinity | That should probably happen silently for those cases, but it doesn't currently. | 06:25 |
| infinity | cjwatson: In the step where britney generates the list of archive actions required, does it know at that point (I imagine it does) if a copy is binary-only? | 06:27 |
| infinity | cjwatson: If so, it might be nice to flag those as silent, so people don't get a confusing second mail when an arch is catching up. | 06:27 |
| infinity | cjwatson: Though, a bit late now that s390x is mostly done. :P | 06:27 |
| Mirv | infinity: ah, a logical explanation! thanks! | 06:30 |
| === jincreator is now known as jincreator_ | ||
| === jfh is now known as jfh_away | ||
| pitti | Good morning | 07:17 |
| dholbach | good morning | 08:20 |
| sladen | Morgen | 08:23 |
| Odd_Bloke | I'm seeing a "The following packages have unmet dependencies:\n perl-base : Breaks: perl-modules (< 5.22.1~)\n perl-modules-5.22 : Breaks: perl-modules" error when trying to build a xenial livefs; I saw some discussion yesterday about a Perl migration, but don't know how to work out when I can expect my builds to return to a working state. | 09:16 |
| pitti | Odd_Bloke: it actually should work, the perl transition is complete | 09:17 |
| Odd_Bloke | Ah, OK. | 09:17 |
| Odd_Bloke | Well, it isn't: https://launchpadlibrarian.net/233282042/buildlog_ubuntu_xenial_amd64_cpc_BUILDING.txt.gz ^_^ | 09:17 |
| pitti | Odd_Bloke: so of course you need the current perl-base with the current perl-modules | 09:18 |
| pitti | hm, I built containers this morning | 09:18 |
| Odd_Bloke | The "Get"s are perl-modules-5.22 all 5.22.1-3, perl amd64 5.22.1-3, and perl-base amd64 5.22.1-3. | 09:19 |
| pitti | the gets look alright to me | 09:19 |
| pitti | just not sure why dist-upgrade croaks about the breaks: | 09:20 |
| Odd_Bloke | "dpkg: perl-modules: dependency problems, but removing anyway as you requested: perl depends on perl-modules (>= 5.20.2-6)." | 09:21 |
| Odd_Bloke | Wait, maybe that's in the host rather than the chroot. | 09:22 |
| pitti | perl-modules should be removed, that's right (replaced by p-m-5.22) | 09:22 |
| === ejat_ is now known as ejat | ||
| infinity | Odd_Bloke: Fixing. | 09:31 |
| Odd_Bloke | infinity: <3 | 09:32 |
| infinity | pitti: It's because perl-modules is NBS and still present in seeds as a result of still being in the archive, so his attempt to install a task that includes it will explode. | 09:32 |
| * infinity removes it. | 09:32 | |
| pitti | infinity: why on earth do we seed perl-modules? | 09:32 |
| infinity | pitti: We don't, but things depend on it. | 09:32 |
| infinity | pitti: Which lands it in tasks. | 09:33 |
| pitti | ah | 09:33 |
| infinity | Oh. And also explicitly seeded in samba-server. | 09:33 |
| infinity | Which is obsolete not. | 09:34 |
| infinity | s/not/now/ | 09:34 |
| infinity | There, fixed even harder. | 09:35 |
| infinity | Odd_Bloke: Should be slightly less sad in an hour or so. | 09:35 |
| Odd_Bloke | infinity: Great, thanks! Will I be able to tell that it's good once perl-modules disappears from http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.xenial/cloud-image? | 09:37 |
| infinity | Odd_Bloke: That would be a reasonable indicator, yeah. | 09:41 |
| LocutusOfBorg1 | hi folks, stupid question: what does "unapproved" means? (wrt queue) | 09:48 |
| LocutusOfBorg1 | I'm a recent MOTU, I uploaded an SRU for wily, and a backport for precise,trusty,utopic, wily and all of them ended in unapproved queue | 09:50 |
| pitti | LocutusOfBorg1: that's the queue for pockets that require archive admins or the release team to review and approve uploads | 09:50 |
| LocutusOfBorg1 | oh I found it | 09:50 |
| LocutusOfBorg1 | https://wiki.ubuntu.com/ArchiveAdministration#Diffs_for_unapproved_uploads | 09:50 |
| pitti | LocutusOfBorg1: i. e. all stable releases, and the devel series when it's "frozen" | 09:50 |
| LocutusOfBorg1 | google was pointing to the queues not to the means | 09:50 |
| LocutusOfBorg1 | yes sure, thanks | 09:51 |
| LocutusOfBorg1 | for debian backports needs approval the first time (because they are new), not anymore after that I think | 09:51 |
| LocutusOfBorg1 | so even after the first backport there is still need to go in the queue, fine :) | 09:51 |
| LocutusOfBorg1 | thanks | 09:52 |
| LocutusOfBorg1 | "virtual memory exhausted: Cannot allocate memory" | 10:08 |
| LocutusOfBorg1 | this happens on arm64, how can I fix it? | 10:08 |
| LocutusOfBorg1 | maybe I can upload and force -j1 | 10:08 |
| infinity | LocutusOfBorg1: Which build? | 10:10 |
| LocutusOfBorg1 | arrayfire/arm64 | 10:13 |
| LocutusOfBorg1 | I tried to give it back twice | 10:13 |
| LocutusOfBorg1 | no help | 10:13 |
| LocutusOfBorg1 | I'm going to upload an ubuntu1 without --parallel build | 10:13 |
| infinity | LocutusOfBorg1: Sec. | 10:13 |
| infinity | LocutusOfBorg1: Please don't. | 10:13 |
| LocutusOfBorg1 | ack | 10:13 |
| LocutusOfBorg1 | no problem | 10:14 |
| infinity | LocutusOfBorg1: I'm going to retry it on a machine that (probably) sucks less. | 10:15 |
| LocutusOfBorg1 | thanks :) | 10:15 |
| seb128 | there seems to be a blueman/bluez issue on xenial, looking at e.u.c ... Noskcaj_ could you check if that's due to your blueman update? | 10:15 |
| infinity | LocutusOfBorg1: Okay, if the current build on auburn fails in the same way, feel free to experiment. | 10:17 |
| infinity | LocutusOfBorg1: If it doesn't, it probably just means we need to fix our VM configs a bit for the bos* nodes. | 10:17 |
| LocutusOfBorg1 | infinity, BTW assuming it will build there, it won't migrate because of missing powerpc build, I asked to remove it on Debian, should I file a bug in Ubuntu too? | 10:18 |
| LocutusOfBorg1 | infinity, I have no problems in disabling parallel builds in Debian, maybe -j4 is too much for arm64? | 10:18 |
| LocutusOfBorg1 | I don't want to have the same issues on the next debian upload, even if now it is fixed :) | 10:18 |
| infinity | LocutusOfBorg1: We select the -j, not you. :P | 10:18 |
| infinity | LocutusOfBorg1: And if we're selecting too high, we need to fix our setup. | 10:19 |
| LocutusOfBorg1 | infinity, exactly I know, but I can disable it at all, or even force it :) | 10:19 |
| infinity | (or, rather, if we're memory starving ourselves) | 10:19 |
| infinity | LocutusOfBorg1: We'll see how it goes first. | 10:19 |
| LocutusOfBorg1 | debian defaults arm64 with -j8, right? | 10:20 |
| infinity | LocutusOfBorg1: Well, it's -j8 on the builder I just put you on too. | 10:20 |
| infinity | LocutusOfBorg1: Generally, people do -j$(nproc) | 10:20 |
| infinity | And nproc on a Mustang is 8. | 10:21 |
| infinity | One our VMs, it's 4. | 10:21 |
| LocutusOfBorg1 | ok so it wasn't a real hw | 10:21 |
| infinity | LocutusOfBorg1: Also, uhm, please don't remove on an arch for one failing test. Fix the bug instead? | 10:22 |
| infinity | LocutusOfBorg1: It's obviously an endian bug. Same failure on all big-endian arches. | 10:23 |
| seb128 | pitti, did you see https://errors.ubuntu.com/problem/03377c894de2d08604cdabf066893d99c348d84f ? | 10:23 |
| seb128 | "udev.prerm called with unknown argument 'deconfigure' dpkg ( error processing archive /var/cache/apt/archives/ifupdown_0.8.5ubuntu1_amd64.deb (--unpack))" | 10:23 |
| pitti | seb128: actually I did, it's debian bug 809744 and debian bug 809743 | 10:24 |
| ubottu | Debian bug 809744 in udev "/var/lib/dpkg/info/udev.prerm called with unknown argument 'deconfigure'" [Serious,Fixed] http://bugs.debian.org/809744 | 10:24 |
| ubottu | Debian bug 809743 in ifupdown "/var/lib/dpkg/info/udev.prerm called with unknown argument 'deconfigure'" [Normal,Fixed] http://bugs.debian.org/809743 | 10:24 |
| seb128 | pitti, danke | 10:25 |
| seb128 | pitti, I'm just looking at the e.u.c xenial top reports and it's in it | 10:25 |
| seb128 | good to see it's handled | 10:25 |
| pitti | seb128: unfortunately a broken prerm can't be retroactively fixed, so we'll work around it in ifupdown | 10:25 |
| * seb128 clicks bug opening and add the debian watch | 10:25 | |
| LocutusOfBorg1 | infinity, I agree, but the package is rather complicate, my endianness knowledge is stuck in the "headache" step, it isn't a package I personally maintain / care about | 10:25 |
| pitti | I can't reproduce it in my dist-upgrades though, but apparently some people do | 10:25 |
| seb128 | hum | 10:25 |
| seb128 | e.u.c "create" fails | 10:25 |
| LocutusOfBorg1 | but maybe knowing it is a big-little endian issue will make me try to patch | 10:26 |
| infinity | LocutusOfBorg1: Given all the BE arches failing on buildd.debian.org, it's pretty clearly that. | 10:27 |
| LocutusOfBorg1 | infinity, I'm not too much a porter guy to remember just by looking at architectures list which are big and which are little :) sorry | 10:29 |
| infinity | LocutusOfBorg1: Anyhow, it's also a leaf package, so I won't whine too hard about removing the PPC binaries. Tomorrow, after we've figured our arm64. | 10:30 |
| infinity | LocutusOfBorg1: Bug fixing the endian bug would be lovely too. :P | 10:30 |
| LocutusOfBorg1 | I'm already trying that :) | 10:31 |
| LocutusOfBorg1 | you gave me the best hint I could get | 10:31 |
| LocutusOfBorg1 | unfortunately upstream doesn't care too much about the porting, so maintaining the code aligned for other archs might be difficult for the Debian Maintainer | 10:32 |
| LocutusOfBorg1 | and I don't think science packages are used too much on arm* or powerpc | 10:33 |
| pitti | seb128: I'll merge it ASAP | 10:34 |
| seb128 | pitti, danke | 10:34 |
| pitti | seb128: it's bug 1531685 | 10:40 |
| ubottu | bug 1531685 in ifupdown (Ubuntu) "package ifupdown 0.8.5ubuntu1 failed to install/upgrade: Unterprozess installiertes pre-removal-Skript gab den Fehlerwert 1 zurück" [Undecided,New] https://launchpad.net/bugs/1531685 | 10:40 |
| seb128 | k | 10:40 |
| infinity | LocutusOfBorg1: I suppose that depends on how sciency they are. | 10:43 |
| infinity | LocutusOfBorg1: Some very large machines run ppc64 and sparc64 and then, well, there's s390x. | 10:43 |
| LocutusOfBorg1 | infinity, the build seems to have passed the problematic build step | 11:02 |
| infinity | LocutusOfBorg1: Yeahp, when it completes successfully, I'll remove the powerpc binaries for you. | 11:05 |
| infinity | LocutusOfBorg1: And if someone wants to fix the BE bug later, yay. | 11:05 |
| LocutusOfBorg1 | infinity, upstream fixed i386 in this upload, so I'm going to point them to the "BE issue" thanks | 11:06 |
| Odd_Bloke | infinity: No sign of an update to the germinate output yet (I was even a good boy and waited 90 minutes to nag you ^_^). | 11:06 |
| infinity | Odd_Bloke: Give the build a whirl anyway, that germinate output on people isn't updated often. | 11:10 |
| Odd_Bloke | Whirling now. | 11:10 |
| infinity | LocutusOfBorg1: Okay, arm64 uploading, PPC binaries scheduled for deletion. | 11:15 |
| Odd_Bloke | infinity: Aha, the new builds look like they're succeeding; thanks! | 11:16 |
| infinity | Odd_Bloke: You might want to diff manifests between yesterday and today to make sure the seed/perl changes didn't do something nasty, but it should be fine. | 11:16 |
| LocutusOfBorg1 | infinity, upstream is now aware of the BE issue :) | 11:20 |
| LocutusOfBorg1 | BTW I don't think it will migrate because of an armhf regression | 11:21 |
| LocutusOfBorg1 | but I'll see | 11:21 |
| infinity | LocutusOfBorg1: Given the stellar history on http://autopkgtest.ubuntu.com/packages/a/arrayfire/xenial/armhf/ it seems like a fluke that it ever passed. | 11:25 |
| infinity | LocutusOfBorg1: But I'll retry it. | 11:26 |
| rbasak | mvo_: around? do you know if there is any way I can get apt to keep around the file after a Hash Sum mismatch? Got some odd behaviour behind a (mandatory) proxy with a mismatch on some debs. Which, AFAICT, are being served accurately and match the Packages file, so I need to dig deeper somehow. | 11:36 |
| rbasak | Confusingly my failure happens reproducibly with sbuild (a handful of mismatches on debs, but not all) but then if I don't purge the session then I can install using apt-get manually without a problem. | 11:46 |
| rbasak | Whatever sbuild does to invoke apt doesn't seem to end up in /var/log/apt/history.log :-/ | 11:47 |
| cjwatson | infinity: I think it possibly could, but it doesn't pass it through at the moment, and it's a bit buried :-/ | 12:29 |
| === _salem is now known as salem_ | ||
| cjwatson | infinity: (arch-specific copies) | 12:31 |
| doko | apw, please could you have a look at merging schroot? | 12:38 |
| infinity | Odd_Bloke: Bootloader->kernel bits work on the latest powerpc test image. | 12:43 |
| infinity | Someother bits seem broken, but progress. :) | 12:43 |
| === popey_ is now known as popey | ||
| sil2100 | Hey! Does anyone know if there are plans of merging the new ppp from Debian to Ubuntu? If yes, is there anyone working on that? | 13:00 |
| LocutusOfBorg1 | the last uploader was ScottK ^^^ | 13:02 |
| * ScottK is not. | 13:14 | |
| LocutusOfBorg1 | I'm working on it | 13:15 |
| sil2100 | LocutusOfBorg1: on ppp? | 13:15 |
| sil2100 | LocutusOfBorg1: I'm working on some network-manager merges right now and I can only merge the new -pptp if we merge ppp, which is a bit of a bigger story | 13:16 |
| LocutusOfBorg1 | yes, http://paste.ubuntu.com/14429758/ | 13:16 |
| LocutusOfBorg1 | feel free to test and upload | 13:16 |
| LocutusOfBorg1 | I can't :) | 13:16 |
| sil2100 | LocutusOfBorg1: ok, will check, I'm actually building a quick test build of a ppp merge already, but you probably put more attention when prepping this than I did ;) | 13:20 |
| sil2100 | (since I just did minimal changes) | 13:20 |
| sil2100 | LocutusOfBorg1: thanks! | 13:23 |
| LocutusOfBorg1 | yw! | 13:24 |
| Odd_Bloke | infinity: http://paste.ubuntu.com/14429904/ is the package diff between pre- and post-seed change; that looks like a lot of removed Perl packages to me, but I don't know if that's what is expected. | 13:48 |
| Odd_Bloke | (For all I know, the whole point of the migration was to not pull in all of these unnecessary packages :p) | 13:48 |
| cjwatson | That's a familiar-looking set of removals. | 13:52 |
| cjwatson | I haven't tracked down why, but wouldn't get too sad about it. | 13:53 |
| cjwatson | Might be things moving into core or something. | 13:54 |
| Odd_Bloke | OK, cool. | 13:56 |
| pitti | sarnold: I replied to the bug, and subscribed (so I'll see responses timely) | 14:14 |
| seb128 | pitti, did you see that the ifupdown update hit a regression on i386 autopkg | 14:16 |
| pitti | seb128: ah, upstart's tests have been flaky for a while; I'll retry, and ignore it if it keeps failing | 14:16 |
| seb128 | k | 14:17 |
| mvo_ | rbasak: sorry for the delay, the files should be in /var/cache/apt/archives/partial, if you have more info please let me know I can also try to reproduce. this sounds worth digging into | 14:23 |
| rbasak | xnox: I'm working with kickinz1 on a freeipmi merge. We're looking at 1.1.5-3ubuntu3 that you uploaded with "Fix dso linking on the convenience library." Your patch was http://paste.ubuntu.com/14430242/ | 14:36 |
| rbasak | xnox: was this for an --as-needed type thing or some other FTBFS or something else? | 14:36 |
| rbasak | xnox: we're not sure if this is still needed. It doesn't appear needed, but I don't understand why you needed it. | 14:37 |
| Odd_Bloke | infinity: cjwatson: I'm seeing a lot of "Unknown symbol mcount (err 0)" in the powerpc boot log, which looks like it's always the last message for a module (where ppc64el has many more for each module/driver, and actually boots). Any ideas? | 14:37 |
| Odd_Bloke | http://paste.ubuntu.com/14430284/ is the full log. | 14:40 |
| Odd_Bloke | Googling around, this normally shows up when a DKMS module hasn't been compiled against the current kernel. | 14:40 |
| Odd_Bloke | But that seems... unlikely. | 14:40 |
| rbasak | mvo_: hmm. They're all truncated at exactly 2986 bytes. | 14:43 |
| rbasak | 2896 bytes sorry. | 14:43 |
| xnox | rbasak, it's been more than two years for that one... i have no idea =) if not needed, and it builds everywhere drop it, i guess... | 14:45 |
| cjwatson | Odd_Bloke: no idea, sorry! | 14:48 |
| arges | pitti: for bug 1531768, are you running arm64 instances on top of amd64? (emulated) | 14:48 |
| ubottu | bug 1531768 in linux (Ubuntu) "arm64 kernel and multiple CPUs is unusably slow" [Undecided,Confirmed] https://launchpad.net/bugs/1531768 | 14:48 |
| === lool- is now known as lool | ||
| pitti | arges: no, the host should be proper arm64 | 14:48 |
| pitti | arges: the bug report isn't that useful yet, it's mostly for collecting data | 14:48 |
| arges | pitti: ok, and in a single CPU variation you don't experience all the stalls? | 14:49 |
| pitti | arges: so it seems the more CPUs the instance gets, the faster it falls into that trap (whatever it is) | 14:49 |
| pitti | arges: I can't even boot an 8-CPU machine half of the time, and with 4 it at least survives a bbit | 14:49 |
| arges | pitti: which hardware is it exactly? | 14:49 |
| pitti | arges: I haven't tested single-CPU yet (it would be completely useless to me, but it'd be interesting for this bug report indeed) -- still on my list | 14:50 |
| pitti | arges: good question, whatever we have in Scalingstack; but I don't know about the hosts there | 14:50 |
| arges | ok | 14:50 |
| arges | pitti: i'll put the questions in the bug. | 14:53 |
| apw | doko, schroot ack, will put it on the list | 14:54 |
| rbasak | xnox: OK, thanks. I think it was needed to fix an FTBFS, and we seem to build OK without it now, so we'll drop the patch. For next time, could you try to document the reason for an upload in the changelog, please? | 14:57 |
| === jfh is now known as jfh_away | ||
| gpiccoli | nacc: ping | 16:44 |
| nacc | gpiccoli: pong | 16:47 |
| gpiccoli | Hello nacc, how are you doing? | 16:47 |
| gpiccoli | Sorry to bother you, can I pm? | 16:47 |
| nacc | gpiccoli: doing well, thanks! and yes, sure | 16:48 |
| gpiccoli | nice, ty | 16:48 |
| juliank | APT will soon start depending on liblz4, that needs to be promoted from universe to main (mvo_ et al) | 16:56 |
| juliank | Unless it is already | 16:57 |
| juliank | No it is not | 16:57 |
| juliank | I'll do an MIR now | 16:59 |
| juliank | Filed as bug #1531923 | 17:03 |
| ubottu | bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New] https://launchpad.net/bugs/1531923 | 17:03 |
| juliank | Someone needs to figure out who's going to be responsible for it. | 17:05 |
| juliank | Feel free to update the bug accordingly | 17:06 |
| juliank | The package is tiny though, and has always been synced. | 17:07 |
| bdmurray | xnox: How would you expect an updated app-install-data-partner package to change software-center? I don't see anything when I filter by "Canonical Partners". | 18:05 |
| xnox | bdmurray, horum. | 18:07 |
| hallyn | xnox: hey, you still have some upstart insight, right? | 18:08 |
| hallyn | <grin> | 18:08 |
| xnox | hallyn, i guess so... | 18:08 |
| hallyn | we have this really really weird bug going on involving upstart killing tasks in a container when uevents happen | 18:09 |
| hallyn | (i thought it was a fuse related bug, sforshee made the connection to uevents) | 18:09 |
| hallyn | (trying to find the bug#, one sec) | 18:09 |
| hallyn | bug 1530617 | 18:10 |
| ubottu | bug 1530617 in lxc (Ubuntu) "FUSE in wily image with upstart installed causes chaos" [High,Confirmed] https://launchpad.net/bugs/1530617 | 18:10 |
| hallyn | it's quite fascinating | 18:10 |
| xnox | bdmurray, well, i guess we simply need to rebuild the package. And if i remember correctly, iff one has partner enabled, and the app-install-data-partner is up to date, and one doesn't have e.g. skype installed, the icon and channel discription should still be visible in the software centre and/or some such. | 18:10 |
| xnox | hallyn, i don't think we actually support upstart in 15.10... do we? | 18:12 |
| xnox | hallyn, this is crazy =) | 18:13 |
| hallyn | wait, we don't? | 18:13 |
| xnox | hallyn, not without systemd as pid 1 removed.... | 18:14 |
| hallyn | it's not the default but i thought we supported it at least though 16.04 | 18:14 |
| hallyn | ^ without systemd as pid 1 removed - not quite parsing, | 18:14 |
| xnox | hallyn, we support it as running as part of the upgrade. | 18:14 |
| xnox | not as anything else. | 18:14 |
| xnox | hallyn, e.g. if one is running 14.04, one can upgrade to 16.04 and still be running upstart until reboot. | 18:15 |
| hallyn | i thought bc of phone users that wasn't an option | 18:15 |
| xnox | hallyn, but e.g. 15.10 cannot be doing that.... as the only upgrade path to 15.10 is from 15.04 which is running systemd by default. | 18:16 |
| xnox | none the less. container should not be able to see udev events. and there shouldn't be udev running in the container. | 18:16 |
| xnox | if that is the case, it's a resource leak no? and e.g. container can affect the host.... | 18:16 |
| hallyn | that's a huge discussion upstream, and no right now uevents cannot be filtered to not go to containres | 18:19 |
| hallyn | it's wise not to run udev in container, but the solution is just to prevent udev in container from writing to sys | 18:20 |
| hallyn | mind you containers used to not run udev, not quite sur when that changed. | 18:22 |
| hallyn | (for upstart) | 18:22 |
| hallyn | still curious what is sending SIGKILL though. | 18:24 |
| bdmurray | mvo_: I've updated the app-install-data-partner info for xenial but still don't see anything in software-center. Any ideas? | 18:27 |
| === cpaelzer is now known as cpaelzer_afk | ||
| mvo_ | bdmurray: hm, you updated and installed it and nothing is in there. nothing at all? or nothing from the new set? | 19:37 |
| === Saviq_ is now known as Saviq | ||
| === neunon_ is now known as neunon | ||
| === plars_ is now known as plars | ||
| === dkessel_ is now known as dkessel | ||
| mterry | Laney, hey... so I'm reminded of some patches I put into accountsservice to enable libpam-pin years ago. At the time, I thought we might use them for Touch, but we went a different way. The upstream bug hasn't seen any movement, so they don't seem likely to be integrated upstream. No one seems to use the module. It might be good to drop the patch now, before 16.04? | 19:45 |
| mterry | Just checking on thoughts / confirmation no one uses it before dropping it | 19:45 |
| barry | mterry: LP: #1531033 is fix committed, but it's still in universe and we're depwaiting on it. do i need to do something to actually get the package in main? | 19:50 |
| ubottu | Launchpad bug 1531033 in lazy-object-proxy (Ubuntu) "[MIR] lazy-object-proxy is new dep for main package pylint" [Undecided,Fix committed] https://launchpad.net/bugs/1531033 | 19:50 |
| mterry | barry, not typically, but you can poke an archive admin to speed things up | 19:50 |
| barry | mterry: ack, thx | 19:50 |
| === josepht` is now known as josepht | ||
| TJ- | bdmurray_: re app-install-data-partner - I have no idea what its supposed to point to - I only found it in a roundabout way due to reading the man-page of apturl and investigating the repo path examples it gives | 20:06 |
| === cpaelzer is now known as cpaelzer_afk | ||
| bdmurray_ | TJ-: alright | 20:29 |
| === bdmurray_ is now known as bdmurray | ||
| === nobuto_ is now known as nobuto | ||
| === bschaefer_ is now known as bschaefer | ||
| === alexisb is now known as alexisb-afk | ||
| sarnold | pitti: thanks so much for your feedback on 1503762! :) | 22:42 |
| Laney | mterry: No objections from me, feel free to upload it and make it be removed on upgrade | 22:53 |
| mterry | Laney, cool | 22:56 |
| hallyn | xnox: hm, so if we're going to say upstart is not supported, should it be dropped from main? (I'm looking for some authorotative statement about it not being supported; that woudl qualify) | 23:55 |
| rbasak | hallyn: AIUI, upstart is still supported when used for user sessions on the phone, so it must remain in main. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!