=== MrBIOS_ is now known as MrBIOS
=== waspinator_ is now known as waspinator
tsgmicahg, kitterman: submitted backport request again as suggested - https://bugs.launchpad.net/trusty-backports/+bug/151771304:00
ubottuLaunchpad bug 1517713 in trusty-backports "Please backport liberasurecode 1.1.0-2 (main) from xenial" [Undecided,New]04:00
tsgScottK: ^^04:00
pittiGood morning06:13
didrocksgood morning pitti06:14
pittibonjour didrocks !06:14
RAOFAloha didrocks, pitti!06:15
didrockshey RAOF!06:15
=== cpaelzer_ is now known as cpaelzer
Mirvlpotter: 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=ubuntu07:10
Mirvlpotter: 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=15007:10
Mirvs/irssi// :)07:13
dholbachgood morning07:36
lpotterMirv: so how does the bzr repo fit in? it doesn't seem to be used at all07:39
Mirvlpotter: 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
lpotterspecifically qtbase07:44
lpotterhttps://code.launchpad.net/ubuntu/+source/qtbase-opensource-src is what I am looking at07:45
lpotterhttps://code.launchpad.net/~ubuntu-branches/ubuntu/wily/qtbase-opensource-src/wily this seems to contain 5.0.207:48
Mirvlpotter: 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
Mirvlpotter: as another example, https://code.launchpad.net/~ubuntu-branches/ubuntu/wily/qtdeclarative-opensource-src/wily seems to be just correct07:59
Mirvthe 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 them08:00
MirvI create them with dget <url.dsc> ; bzr init ; quilt pop (repeat so that all are popped) ; bzr add * .qmake.conf ; bzr commit -m import08:01
rkuskaHello, 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
seb128hum, is https://errors.ubuntu.com stucked on "loading..." for others as well?09:19
seb128ah, loaded now09:20
seb128so maybe just slow09:20
pittiwgrant: can we open https://translations.launchpad.net/ubuntu/xenial/+language-packs ?09:41
seb128pitti, cjwatson opened xenial translations some weeks back09:42
seb128aren't the langpack automatically enabled when a serie opens?09:42
pittiI figure LP needs to adjust the cronjobs for the exports09:42
pittiwgrant: export on Sunday/build on my side on Monday seems to be a free slot?09:43
=== greyback__ is now known as greyback
cjwatsonseb128,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
pitticjwatson: ah, thanks11:15
pittidpm: ^ what is the next step there?11:17
dpmcjwatson, 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
dpmthe e-mail seems to list all steps already, but let me double-check11:20
* xnox waves hi11:21
pittihey xnox11:21
=== _salem is now known as salem_
dpmcjwatson, 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
cjwatsondpm: our master list says that should be after cron jobs are set up, though I suppose it doesn't matter *too* much11:27
cjwatsondpm: https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings11:27
dpmyeah, I think it's fine. Translators can start doing their jobs before the cron jobs are set up11:28
dpmI've just approved a couple of templates in the imports queue and going through the rest quickly11:28
dpmI think after that I can just open them in LP11:28
cjwatsonpitti,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
pitticjwatson: Sunday export is fine for me (can't speak about the rest, but I suppose that's c&p)11:49
dpmcjwatson, 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/26607311:51
cjwatsondpm: see immediately above11:51
cjwatsondpm: oh, you mean stats, not translations11:52
cjwatsondpm: sure, I can include that in the same ticket11:52
dpmcjwatson, I think we're talking of a different type of export: I mean the .json export for translation stats11:52
dpmyeah, that'd be great, thanks11:52
cjwatson*mutter* that's such an evil job11:52
cjwatsonI must have another go at those webservice exports at some point11:53
cjwatsondpm: I'm just waiting for webops to get the crontab back in sync with reality after the last change before I propose this11:53
dpmok, thanks!11:54
Laneytyhicks: 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
ubottuLaunchpad bug 1489489 in dbus (Ubuntu) "The org.freedesktop.DBus.GetConnectionAppArmorSecurityContext() method is deprecated" [Medium,Triaged]12:06
LaneyIt'd be good to not have to carry the patch into the release12:07
cjwatsonmarcoceppi: 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
cjwatsonpitti,dpm: OK, this is RT#86504 now13:25
kenvandinepitti, ubuntu-system-settings is blocked on some autopkgtests that say they're in progress but the tests aren't actually running13:43
Laneykenvandine: that means they're in the queue13:43
pittikenvandine: yes, the queues are still very long13:43
kenvandineah... is there a way to view the queue?13:43
kenvandineit's been more than 24 hours, figured it would have been done by now :)13:43
pittiI 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
kenvandinei'd imagine13:44
pittikenvandine: queue view> yes, but not publicly yet; I'm working on it13:44
kenvandineok, thx for the info13:44
kenvandinepitti, ok, cool13:44
Laneywith that management plugin or something?13:44
seb128unsure what to do about such issues, is that dpkg bugs?13:46
dpmthanks cjwatson13:46
seb128" 13:47
seb128Processing triggers for mime-support (3.59ubuntu1) ...13:47
seb128dpkg: error processing package libbsd0:i386 (--configure):13:47
seb128package libbsd0:i386 is already installed and configured"13:47
seb128same with https://errors.ubuntu.com/problem/923088c36748eaa801974b5e87dd89022f3f12b8 " triggers looping, abandoned?"13:48
pittiLaney: you know how to get the queue count; I think queue contents can be done with the mgmt plugin13:49
pittiLaney: 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
Laneypitti: ah, yeah, I thought you meant you had a prototype of contents13:52
=== nudtrobert1 is now known as nudtrobert
=== dpm is now known as dpm-afk
matsubarapsivaa, 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
tyhicksLaney: hello - I think it is doable15:24
psivaamatsubara: 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 that15:31
matsubarapsivaa, hmm ok, rbasak was ready to review it...15:32
psivaamatsubara: https://code.launchpad.net/~psivaa/ubuntu-test-cases/lvm-grub-preseed-fix is the personal branch for that. please feel free to fork it15:33
rbasakmatsubara: the other one was https://code.launchpad.net/~om26er/ubuntu-test-cases/fix_minimal_image_size_test/+merge/235298 which also 404s.15:43
rbasakpsivaa: do you want anything merging right now?15:44
matsubararbasak, right, likely it was deleted in the same way. I can't find om26er around here, so I'd ask him15:45
tewardneed 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
ubottuLaunchpad bug 1517865 in nginx (Ubuntu) "nginx-extras push module fd leak" [Undecided,New]15:54
rbasakteward: generally a cherry-pick is what is required for an SRU.15:59
=== tdaitx_ is now known as tdaitx
rbasakteward: 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
tewardbut Debian's solution was to just update the module16:01
psivaarbasak: not at the moment16:05
rbasakOK, thank.s16:05
hallynstgraber: 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
stgraberhallyn: no17:45
stgraberhallyn: standard behavior is to write to /run/reboot-required and /run/reboot-required.pkgs17:45
stgraberhallyn: which will show the reboot warning in MOTD and if on desktop, the matching notification17:46
stgraberthat's what e.g. network-manager does17:46
stgraberand 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
hallyni thought maybe th epackaging would look at the priority or pocket...17:47
hallynhope springs eternal17:47
stgraberhallyn: 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 release17:55
hallynyeah tha's no good17:56
hallynobvoiusly 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 testing17:56
stgraberhallyn: 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 libfuse17:57
stgrabersecurity updates upstart-style17:57
hallynwhere's jodh when you need him17:58
stgraberwell, I hear we got xnox back :)17:59
xnoxhallyn, hello.18:01
stgraberhallyn: 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
hallyni know, a dbus service :)18:08
stgraberhow about, no? :)18:08
xnoxif one is stateless, re-exec whilst keeping sockets open and passing them across should be trivial, no?!18:09
xnoxwithout even a library split.18:09
xnoxwith extra magic systemd unit restart commands.18:10
xnoxhallyn, ^18:10
stgraberyeah, I'm just not sure of how that'd affect fuse18:10
stgraberour code wouldn't mind for sure, libfuse might18:10
xnoxone can totally reuse systemd socket activation for that, to serialise opened sockets to keep them for re-exec.18:10
xnoxstgraber, well, true.18:10
hallynthe dlopen might be complicated by  our now threaded nature...18:15
hallynxnox: lxcfs is not completely stateless.  in particular fuse keeps pointers on directory entries to cached data (for open files/dirs) in our memory18:16
hallynso 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
hallyni suppose dlopen must be process-wide, so just doing it once under a global mutex should suffice18:18
stgraberLooks 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
hallynsimpler 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 mountpoints18:31
hallynnot has elegant18:31
stgraberand from past experience, very tricky to get right, wrt running random binary in the container from the host in a safe way :)18:31
stgraberhad some problems when we were doing that in apport :)18:32
hallynthe dlopen method would require a mutexed count of # of threads running in the api right now18:32
hallynso 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
hallynthen 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 lock18:39
hallynor mayb we can just keep a refcounted list of dlopen() results18:41
hallyn(where 'on reexec' means when we get a sighup)18:42
tewardso, should I be concerned if my schroots in sbuild can't update to Xenial because libuuid1 throws postinstall fails18:45
infinityteward: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=80416719:05
ubottuDebian bug 804167 in libuuid1 "fails to upgrade" [Serious,Open]19:05
infinityteward: 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_
hallynstgraber: https://github.com/lxc/lxcfs-pkg-ubuntu/pull/2 look ok ?19:45
stgraberhallyn: so I'm not sure that the killmode change is actually required.19:46
stgraberhallyn: I mean, we do want "systemctl restart" and "systemctl stop" to work with lxcfs, we just don't those called on upgrade19:46
hallynyeha, wasn't sure.  i'll revert that19:47
bdmurrayLaney: Your glib2.0 upload to the Wily SRU queue seems to have no LaunchpadBugsFixed19:58
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
mterry@pilot in20: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
pgquileswhy can't I comment on developer.ubuntu.com/blog ? Always a "CSRF verification failed" error :-(21:19
pgquileszbenjamin: 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
dobeypgquiles: Breaks: would do it21:36
=== salem_ is now known as _salem
tewardinfinity: okay, odd though that creating a fresh schroot doesn't appear to trigger the same problem.21:59
tewardonly the 'upgrade' portion21:59
tewardthanks for the info though :)21:59
pgquilesdobey: 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-ide22:10
mterry@pilot out22: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-tczewrobert_ancell: I've just send you an email, did you see?23:01
ari-tczewabout network manager23:01
robert_ancellari-tczew, I was just replying23:01
=== MrBIOS_ is now known as MrBIOS
zbenjaminpgquiles: you need to talk to bzoltan_ about the sdk packaging.23:41
zbenjaminpgquiles: he did most of it, but i think there was a reason why we could not use it23:41

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!