| === MrBIOS_ is now known as MrBIOS | ||
| === waspinator_ is now known as waspinator | ||
| tsg | micahg, kitterman: submitted backport request again as suggested - https://bugs.launchpad.net/trusty-backports/+bug/1517713 | 04:00 |
|---|---|---|
| ubottu | Launchpad bug 1517713 in trusty-backports "Please backport liberasurecode 1.1.0-2 (main) from xenial" [Undecided,New] | 04:00 |
| tsg | ScottK: ^^ | 04:00 |
| pitti | Good morning | 06:13 |
| didrocks | good morning pitti | 06:14 |
| pitti | bonjour didrocks ! | 06:14 |
| RAOF | Aloha didrocks, pitti! | 06:15 |
| didrocks | hey RAOF! | 06:15 |
| === cpaelzer_ is now known as cpaelzer | ||
| Mirv | lpotter: only Qt packaging is in git, and mostly it's as a branch of Debian's packagings like irssi http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/log/?h=ubuntu | 07:10 |
| Mirv | lpotter: for in-use package you'd do dget file.dsc by finding the .dsc file from for example https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?batch=75&memo=150&start=150 | 07:10 |
| Mirv | s/irssi// :) | 07:13 |
| lpotter | hmmm | 07:33 |
| dholbach | good morning | 07:36 |
| lpotter | Mirv: so how does the bzr repo fit in? it doesn't seem to be used at all | 07:39 |
| Mirv | lpotter: depends which bzr. the old packaging bzr:s have been emptied and declared obsolete, but there are also the automatic Ubuntu branches that are not that useful at the moment since the vivid overlay is PPA separate from Ubuntu archives, and 5.5 is not yet in xenial archives either. | 07:44 |
| lpotter | specifically qtbase | 07:44 |
| lpotter | https://code.launchpad.net/ubuntu/+source/qtbase-opensource-src is what I am looking at | 07:45 |
| lpotter | https://code.launchpad.net/~ubuntu-branches/ubuntu/wily/qtbase-opensource-src/wily this seems to contain 5.0.2 | 07:48 |
| Mirv | lpotter: right, you're correct, they are completely obsolete. I haven't had an explanation though why some of them are totally stalled and some seem to import the latest package. | 07:58 |
| Mirv | lpotter: as another example, https://code.launchpad.net/~ubuntu-branches/ubuntu/wily/qtdeclarative-opensource-src/wily seems to be just correct | 07:59 |
| Mirv | the good thing about /ubuntu/ branches is that they include the whole source, so they're easier to work with. I've local bzr:s of those 5.4.1/5.4.2 branches that need updates (usually just qtbase/qtdeclarative) so that I can cleanly use bzr builddeb with them | 08:00 |
| Mirv | I create them with dget <url.dsc> ; bzr init ; quilt pop (repeat so that all are popped) ; bzr add * .qmake.conf ; bzr commit -m import | 08:01 |
| rkuska | Hello, regarding your latest decision of making Python3 the default interpreter in Ubuntu 16.04, whats your plan with Samba? | 08:41 |
| === pete-woods1 is now known as pete-woods | ||
| seb128 | hum, is https://errors.ubuntu.com stucked on "loading..." for others as well? | 09:19 |
| seb128 | ah, loaded now | 09:20 |
| seb128 | so maybe just slow | 09:20 |
| pitti | wgrant: can we open https://translations.launchpad.net/ubuntu/xenial/+language-packs ? | 09:41 |
| seb128 | pitti, cjwatson opened xenial translations some weeks back | 09:42 |
| seb128 | aren't the langpack automatically enabled when a serie opens? | 09:42 |
| pitti | I figure LP needs to adjust the cronjobs for the exports | 09:42 |
| pitti | wgrant: export on Sunday/build on my side on Monday seems to be a free slot? | 09:43 |
| === greyback__ is now known as greyback | ||
| cjwatson | seb128,pitti: I didn't completely open it, I did part of the steps and then handed over to ubuntu-translations-coordinators@, and got no response: http://paste.ubuntu.com/13344194/ | 11:15 |
| pitti | cjwatson: ah, thanks | 11:15 |
| pitti | dpm: ^ what is the next step there? | 11:17 |
| dpm | cjwatson, pitti, the ubuntu-translations-coordinators is not really active anymore. However, I generally look at the e-mail. For some reason I missed this one, though :/ | 11:20 |
| dpm | the e-mail seems to list all steps already, but let me double-check | 11:20 |
| * xnox waves hi | 11:21 | |
| pitti | hey xnox | 11:21 |
| === _salem is now known as salem_ | ||
| dpm | cjwatson, pitti, I think the next steps are simply to make the translations visible in LP and setting the focus to Xenial. I can do that now. | 11:23 |
| cjwatson | dpm: our master list says that should be after cron jobs are set up, though I suppose it doesn't matter *too* much | 11:27 |
| cjwatson | dpm: https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings | 11:27 |
| dpm | yeah, I think it's fine. Translators can start doing their jobs before the cron jobs are set up | 11:28 |
| dpm | I've just approved a couple of templates in the imports queue and going through the rest quickly | 11:28 |
| dpm | I think after that I can just open them in LP | 11:28 |
| cjwatson | pitti,wgrant: I agree that the Sunday export slot seems clear. Is "30 10 * * 0 nice -16 $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/language-pack-exporter.py ubuntu xenial --force-utf8-encoding -q --log-file=INFO:/srv/launchpad.net/production-logs/rosetta/language-pack-exporter.log" OK for you then? | 11:43 |
| pitti | cjwatson: Sunday export is fine for me (can't speak about the rest, but I suppose that's c&p) | 11:49 |
| cjwatson | Yeah | 11:49 |
| dpm | cjwatson, pitti, translations are now visible and focus is set to xenial. cjwatson, one last thing: could we add a cron job to export translations for xenial? IIRC, it's a matter of enabling it in a cron job, similarly to https://code.launchpad.net/~dpm/lp-production-crontabs/add-wily-l10n-stats/+merge/266073 | 11:51 |
| cjwatson | dpm: see immediately above | 11:51 |
| cjwatson | dpm: oh, you mean stats, not translations | 11:52 |
| cjwatson | dpm: sure, I can include that in the same ticket | 11:52 |
| dpm | cjwatson, I think we're talking of a different type of export: I mean the .json export for translation stats | 11:52 |
| dpm | yeah, that'd be great, thanks | 11:52 |
| cjwatson | *mutter* that's such an evil job | 11:52 |
| cjwatson | I must have another go at those webservice exports at some point | 11:53 |
| cjwatson | dpm: I'm just waiting for webops to get the crontab back in sync with reality after the last change before I propose this | 11:53 |
| dpm | ok, thanks! | 11:54 |
| Laney | tyhicks: hey, I'm just merging dbus and I'm reminded of https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1489489 - do you think we can get dropping this method targetted for this cycle? | 12:06 |
| ubottu | Launchpad bug 1489489 in dbus (Ubuntu) "The org.freedesktop.DBus.GetConnectionAppArmorSecurityContext() method is deprecated" [Medium,Triaged] | 12:06 |
| Laney | It'd be good to not have to carry the patch into the release | 12:07 |
| cjwatson | marcoceppi: can you see what's going on with the CI failures on https://code.launchpad.net/~cjwatson/charms/trusty/ubuntu-repository-cache/xz-indexes/+merge/277880 ? they look like testbed issues to me ... | 12:49 |
| cjwatson | (but I'm not sure) | 12:49 |
| * popey hugs xnox | 12:50 | |
| === davidcalle_ is now known as davidcalle | ||
| cjwatson | pitti,dpm: OK, this is RT#86504 now | 13:25 |
| kenvandine | pitti, ubuntu-system-settings is blocked on some autopkgtests that say they're in progress but the tests aren't actually running | 13:43 |
| Laney | kenvandine: that means they're in the queue | 13:43 |
| pitti | kenvandine: yes, the queues are still very long | 13:43 |
| kenvandine | ah... is there a way to view the queue? | 13:43 |
| kenvandine | it's been more than 24 hours, figured it would have been done by now :) | 13:43 |
| pitti | I now added some capacity (let's see how long it'll hold), but lots of xenial uploads + lots of them being KDE (long tests) plus lots of kernel tests from stables plus troubles with cloud -> taking ages :( | 13:44 |
| kenvandine | i'd imagine | 13:44 |
| pitti | kenvandine: queue view> yes, but not publicly yet; I'm working on it | 13:44 |
| kenvandine | ok, thx for the info | 13:44 |
| kenvandine | pitti, ok, cool | 13:44 |
| Laney | really? | 13:44 |
| Laney | with that management plugin or something? | 13:44 |
| seb128 | unsure what to do about such issues, is that dpkg bugs? | 13:46 |
| dpm | thanks cjwatson | 13:46 |
| seb128 | https://errors.ubuntu.com/problem/a00c6c70c46827e0854c65da57937aa7bd2d14b1 | 13:46 |
| seb128 | " | 13:47 |
| seb128 | Processing triggers for mime-support (3.59ubuntu1) ... | 13:47 |
| seb128 | dpkg: error processing package libbsd0:i386 (--configure): | 13:47 |
| seb128 | package libbsd0:i386 is already installed and configured" | 13:47 |
| seb128 | same with https://errors.ubuntu.com/problem/923088c36748eaa801974b5e87dd89022f3f12b8 " triggers looping, abandoned?" | 13:48 |
| pitti | Laney: you know how to get the queue count; I think queue contents can be done with the mgmt plugin | 13:49 |
| pitti | Laney: or that trick to read the entire queue without ack'ing (I'll see if that scrambles the order; if not, that's fine) | 13:50 |
| Laney | pitti: ah, yeah, I thought you meant you had a prototype of contents | 13:52 |
| === nudtrobert1 is now known as nudtrobert | ||
| === dpm is now known as dpm-afk | ||
| matsubara | psivaa, hi, do you know what happened to https://code.launchpad.net/~psivaa/ubuntu-test-cases/lvm-grub-preseed-fix/+merge/258620? | 15:22 |
| === sconklin_ is now known as sconklin | ||
| tyhicks | Laney: hello - I think it is doable | 15:24 |
| psivaa | matsubara: that was waiting for a little too long for merging i suppose, and was pinged a couple of times regarding that in #ubuntu-ci-eng by those cleaning up Ubuntu sponsoring queue. I had to delete that | 15:31 |
| matsubara | psivaa, hmm ok, rbasak was ready to review it... | 15:32 |
| psivaa | matsubara: https://code.launchpad.net/~psivaa/ubuntu-test-cases/lvm-grub-preseed-fix is the personal branch for that. please feel free to fork it | 15:33 |
| rbasak | matsubara: the other one was https://code.launchpad.net/~om26er/ubuntu-test-cases/fix_minimal_image_size_test/+merge/235298 which also 404s. | 15:43 |
| rbasak | psivaa: do you want anything merging right now? | 15:44 |
| matsubara | rbasak, right, likely it was deleted in the same way. I can't find om26er around here, so I'd ask him | 15:45 |
| teward | need some guidance on a bug fix... https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1517865 indicates there is an fd leak in a package, yet to fix it the only way we can really 'fix' it is to update the corresponding included third-party module in the package, is that SRU-qualified or do I have to hunt and peck for a specific upstream patch that only fixes the issue? | 15:54 |
| ubottu | Launchpad bug 1517865 in nginx (Ubuntu) "nginx-extras push module fd leak" [Undecided,New] | 15:54 |
| rbasak | teward: generally a cherry-pick is what is required for an SRU. | 15:59 |
| === tdaitx_ is now known as tdaitx | ||
| rbasak | teward: that doesn't mean you have to do it. If only one person has been affected in 18 months since release, it seems pretty low priority to me. You could ask the reporter to identify the cherry-pick. | 16:00 |
| teward | (I already know the cherrypick, there's a Debian bug on it) | 16:01 |
| teward | but Debian's solution was to just update the module | 16:01 |
| psivaa | rbasak: not at the moment | 16:05 |
| rbasak | OK, thank.s | 16:05 |
| hallyn | stgraber: if there is a security update on package foo, do init scripts in foo which are marked as no-restart-on-upgrade get restarted in that case? | 17:45 |
| stgraber | hallyn: no | 17:45 |
| stgraber | hallyn: standard behavior is to write to /run/reboot-required and /run/reboot-required.pkgs | 17:45 |
| stgraber | hallyn: which will show the reboot warning in MOTD and if on desktop, the matching notification | 17:46 |
| stgraber | that's what e.g. network-manager does | 17:46 |
| stgraber | and those packages' postinst typically write to reboot-required for every update, so not trying to be clever and do it only for security (because you can be sure someone will forget about it) | 17:46 |
| hallyn | i thought maybe th epackaging would look at the priority or pocket... | 17:47 |
| hallyn | hope springs eternal | 17:47 |
| stgraber | hallyn: it could but I don't believe we have any precedent for doing so and it wouldn't trigger on backports, PPA builds and uploads to the dev release | 17:55 |
| hallyn | yeah tha's no good | 17:56 |
| hallyn | obvoiusly foo=lxcfs. so i'm thinking that we need to have a hook triggered from the host to the container to re-mount. anyway, still testing | 17:56 |
| stgraber | hallyn: since we're stateless the best really would be to have a way to re-exec without dropping the fuse connection, but that'd likely need a bit of fixing in libfuse | 17:57 |
| stgraber | security updates upstart-style | 17:57 |
| hallyn | where's jodh when you need him | 17:58 |
| stgraber | well, I hear we got xnox back :) | 17:59 |
| xnox | hallyn, hello. | 18:01 |
| stgraber | hallyn: an alternative would be to split 99% of lxcfs into a library that we dlopen into a tiny bit of code which is the daemon. On update we can signal the daemon to reload the library and use it. Limiting the amount of stuff we can't update without breaking all containers. | 18:01 |
| hallyn | yeah | 18:05 |
| hallyn | i know, a dbus service :) | 18:08 |
| stgraber | how about, no? :) | 18:08 |
| xnox | if one is stateless, re-exec whilst keeping sockets open and passing them across should be trivial, no?! | 18:09 |
| xnox | without even a library split. | 18:09 |
| xnox | with extra magic systemd unit restart commands. | 18:10 |
| xnox | hallyn, ^ | 18:10 |
| stgraber | yeah, I'm just not sure of how that'd affect fuse | 18:10 |
| stgraber | our code wouldn't mind for sure, libfuse might | 18:10 |
| xnox | one can totally reuse systemd socket activation for that, to serialise opened sockets to keep them for re-exec. | 18:10 |
| xnox | stgraber, well, true. | 18:10 |
| hallyn | the dlopen might be complicated by our now threaded nature... | 18:15 |
| hallyn | xnox: lxcfs is not completely stateless. in particular fuse keeps pointers on directory entries to cached data (for open files/dirs) in our memory | 18:16 |
| hallyn | so if we go the dlopen way we could perhaps add a version # to those structs and invalidate any versions older than our curren tone (bump version # on every dlopen) | 18:17 |
| hallyn | i suppose dlopen must be process-wide, so just doing it once under a global mutex should suffice | 18:18 |
| stgraber | Looks like some folks published a re-fuse paper back in 2010 or so where they describe how to allow respawning a fuse fs on crash without affecting existing users. I'm not finding any code for that though... | 18:18 |
| hallyn | simpler way would be to have containers bind-mount a ms_slave directory from host which has lxcfs mounted under it; have lxcfs register a start hook that prints the container's name into a file; have lxcfs on start trigger a hook in each contaner named in that file to re-set the mountpoints | 18:31 |
| hallyn | not has elegant | 18:31 |
| stgraber | and from past experience, very tricky to get right, wrt running random binary in the container from the host in a safe way :) | 18:31 |
| stgraber | had some problems when we were doing that in apport :) | 18:32 |
| hallyn | the dlopen method would require a mutexed count of # of threads running in the api right now | 18:32 |
| hallyn | so on every api call we would grab whatever is the fastest userspace lock there is; bump the use count; drop the lock; do the call; get lock; drop count; drop lock; | 18:38 |
| hallyn | then for re-exec we would grab a big mutex, set NO_NEW_API_CALLS true; grab the little lock, check for use count == 0; drop lock; spin until count is 0; do new dlopen; dset NO_NEW_API_CALLS false; drop the big lock | 18:39 |
| hallyn | or mayb we can just keep a refcounted list of dlopen() results | 18:41 |
| hallyn | (where 'on reexec' means when we get a sighup) | 18:42 |
| teward | so, should I be concerned if my schroots in sbuild can't update to Xenial because libuuid1 throws postinstall fails | 18:45 |
| teward | (Xenial) | 18:45 |
| infinity | teward: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804167 | 19:05 |
| ubottu | Debian bug 804167 in libuuid1 "fails to upgrade" [Serious,Open] | 19:05 |
| infinity | teward: It's specific to your host system being somewhat mismatched with the chroot, but will be fixed soon anyway. | 19:05 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| hallyn | stgraber: https://github.com/lxc/lxcfs-pkg-ubuntu/pull/2 look ok ? | 19:45 |
| stgraber | hallyn: so I'm not sure that the killmode change is actually required. | 19:46 |
| stgraber | hallyn: I mean, we do want "systemctl restart" and "systemctl stop" to work with lxcfs, we just don't those called on upgrade | 19:46 |
| hallyn | yeha, wasn't sure. i'll revert that | 19:47 |
| bdmurray | Laney: Your glib2.0 upload to the Wily SRU queue seems to have no LaunchpadBugsFixed | 19:58 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| mterry | @pilot in | 20:21 |
| === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry | ||
| === _salem is now known as salem_ | ||
| === MrBIOS_ is now known as MrBIOS | ||
| pgquiles | why can't I comment on developer.ubuntu.com/blog ? Always a "CSRF verification failed" error :-( | 21:19 |
| pgquiles | zbenjamin: re your post on the new ubuntu-sdk- packages, shouldn't a "Conflicts:" in debian/control take care of the removal of qtcreator and qtcreator-plugins-* ? | 21:20 |
| dobey | pgquiles: Breaks: would do it | 21:36 |
| === salem_ is now known as _salem | ||
| teward | infinity: okay, odd though that creating a fresh schroot doesn't appear to trigger the same problem. | 21:59 |
| teward | only the 'upgrade' portion | 21:59 |
| teward | thanks for the info though :) | 21:59 |
| pgquiles | dobey: shouldn't one use Conflicts: in this case? According to the Debian Policy, "Conflicts should be used when two packages provide the same file and will continue to do so", which is the case e. g. with /usr/bin/qtcreator in qtcreator and ubuntu-sdk-ide | 22:10 |
| mterry | @pilot out | 22:41 |
| === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| ari-tczew | robert_ancell: I've just send you an email, did you see? | 23:01 |
| ari-tczew | about network manager | 23:01 |
| robert_ancell | ari-tczew, I was just replying | 23:01 |
| ari-tczew | cool | 23:02 |
| === MrBIOS_ is now known as MrBIOS | ||
| zbenjamin | pgquiles: you need to talk to bzoltan_ about the sdk packaging. | 23:41 |
| zbenjamin | pgquiles: he did most of it, but i think there was a reason why we could not use it | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!