[01:35] <mwhudson> er so i'm having a problem with schroot
[01:35] <mwhudson> basically i can't expire sessions
[01:35] <mwhudson> http://paste.ubuntu.com/14042611/
[01:36] <mwhudson> running "fuser /var/lib/schroot/mount/xenial-amd64-52371fd8-4124-4584-a4ca-f53d43284765/home/mwhudson" shows the same output as "fuser /home/mwhudson"
=== yuning-afk is now known as yuning
=== timchen1` is now known as timchen119
[05:23] <sidi> Got an Autotools toolchain that works perfectly on Arch, but not on Ubuntu, need help figuring it out... Basically doing PKG_CHECK_MODULES in configure.ac, AC_SUBST my CFLAGS and LIBS variables, then assigning them in Makefile.in and adding the assigned vars to my CFLAGS and LDFLAGS. I have one sub-dir for which LDFLAGS dont work. No apparent typo in the Makefile... How can I debug that?
[05:28] <pitti> Good morning
[07:17] <dholbach> good morning
=== nudtrobert1 is now known as nudtrobert
[08:16] <pitti> apw: I further bisected bug 1526358 down to a single new line in a kernel header, a new syscall definition; I followed up with everything I can squeeze out of that with my puny little non-kernel developer brain
[08:16] <ubottu> bug 1526358 in systemd (Ubuntu) "xenial/i386 regression: nspawn fails with "Failed to add audit seccomp rule: Bad address"" [Medium,Triaged] https://launchpad.net/bugs/1526358
[09:12] <pitti> jdstrand, apw: I analyzed that further, I now have a tiny standalone .c file and some explanations; its' somewhere between libseccomp and the kernel
[09:12] <apw> pitti, ack
[09:28] <apw> pitti, ok these calls did not exist as separate system calls before 4.3, it seems sockets can be either exposed via socketcall multiplexed call or individually, and we switched to exposing them all to allow seccomp mediation
[09:28] <apw> pitti, i've put the details in the bug
[09:29] <pitti> apw: ah, so the x0xFFFFFF9B value before, was that a code for "does not exist", and thus seccomp filtering of socket() was simply ignored before?
[09:29] <apw> pitti, when i say i have added it to the bug, i have not because LP is broke
[09:29] <pitti> apw: did your comment time out? mine currently do, maybe LP upgrade going on
[09:29] <pitti> snap :)
[09:30] <apw> pitti, and now it is in ok
[09:30] <apw> pitti, yes literally before htere was socketcall(CONNECT, ...) instead, so no seccomp interaction at all
[09:30] <apw> pitti, so this could easily be a bug in either the kernel or library
[09:34] <alkisg> bdrung, bdrung_work_, hi, if it isn't too much trouble for you, could you send a build for adblock/xenial in the xul-ext ppa? thank you!
[09:37] <pitti> apw: splendid, thanks!
[09:41] <cjwatson> dannf: did you notice that it looks like your {vivid,wily}-proposed grub2 changes were dropped in the security update?  you'll need to rebase those
[09:42] <bdrung_work_> alkisg, done:  adblock-plus 	2.6.10+dfsg-1~ubuntu16.04.1~ppa1 uploaded
[09:42] <alkisg> Thank you very much bdrung_work_ :)
[09:43]  * alkisg has installed 16.04 to some schools in order to help iron out all the bugs in time, and adblock plus is vital there
[09:46] <henrix> pitti: can i get some vivid kernel tests re-run? run-autopkgtest -s vivid -a i386 --trigger linux-meta/3.19.0.41.40 glibc
[09:47] <pitti> henrix: sure! started
[09:48] <henrix> pitti: thanks
=== ara is now known as Guest6835
[09:48] <pitti> update-initramfs: Generating /boot/initrd.img-4.3.0-2-generic
[09:48] <pitti> sed: can't read /usr/share/plymouth/themes/.plymouth/.plymouth.plymouth: No such file or directory
[09:48] <pitti> E: /usr/share/initramfs-tools/hooks/plymouth failed with return 2.
[09:48] <pitti> didrocks: ^ does that ring a bell?
[09:48] <pitti> Laney: ^ (current mass-killing of workers)
[09:49] <Laney> pitti: oh noes
[09:49] <Laney> I didn't see that, did it just happen?
[09:49] <Laney> oh yeah, here it is
[09:51] <Laney> plymouth/.../.plymouth/.plymouth.plymouth his a great path
[09:52] <Laney> s/his/is/
[09:54] <apw> pitti, that looks a bit like a theme name of .plymouth was used
[09:56] <seb128> Laney, pitti, should we remove that version from proposed?
[09:56] <Laney> I have no idea, sorry
[09:56] <seb128> oh, not in proposed anymore
[09:56] <seb128> so ignore that
[09:57] <pitti> it only started today, so it wasn't didrocks's initial merge from last week
[09:59] <seb128> might be today's update?
[09:59] <pitti> ah, we got https://launchpad.net/ubuntu/+source/plymouth/0.9.2-3ubuntu6
[09:59] <pitti> it went through as the only direct rdepends lightdm is "always failed"
[10:00] <apw> pitti, i am guesing that "update-alternatives --query text.plymouth" is returning ""
[10:00] <apw> pitti, which the hook script does not handle
[10:00] <Unit193> Also, maintscripts didn't take care of /etc/init/plymouth*
[10:01]  * pitti kills the looping lightdm test
[10:06] <apw> pitti, which could occur if the alternative does not exist at all
[10:07] <apw> pitti, thogh quite why either would be missing, is a bit of a mystery
[10:12] <apw> pitti, i guess it should have osmething like this http://paste.ubuntu.com/14048328/ as protection
[10:29] <Saviq> pitti, hey, could I ask you to restart the failed qtmir-gles autopkgtest in https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-021/excuses.html
[10:30] <pitti> Saviq: done
[10:31] <pitti> Saviq: in http://autopkgtest.ubuntu.com/running.shtml#queue-xenial-amd64 now, there's some queue
[10:31] <Saviq> pitti, thanks! is there a way to restart those that does not involve you having to press dumb buttons?
[10:31] <Saviq> pitti, ack
[10:31] <pitti> silos are eating up a looot of resources, look at the vivid queue
[10:32] <pitti> Saviq: not at the moment, needs someone with access to snakefruit (cjwatson,seb128,doko,pitti,adconrad,vorlon,didrocks,stgraber,laney)
[10:33] <Saviq> pitti, thanks (and sorry everyone for triggering a mass-ping ;)
[10:33] <pitti> Saviq: it's planned to supporting restarting tests via some web UI, but that needs SSO etc. (which I'm not familiar with at all)
[10:33] <Saviq> ack
[10:34] <Saviq> pitti, this is AWESOME, btw, thanks!
[10:35] <pitti> :)
[10:38] <apw> pitti, i presume the git.l.n daemon must do all of the same authentication you need to do ... and as you are aqpm based a separate daemon service would work at least
[10:40] <pitti> apw: I don't know how this works really, but I assume I'd have a web service on autopkgtest.u.c. which does SSO auth, checks whether the user is able to upload that package, and if so triggers an AMQP request with its internal creds?
[10:40] <apw> pitti, i suspect you'd not do SSO but do LP auth and let it do SSO for you, as you need to ask about upload rights
[10:41] <pitti> apw: ah, or that
=== ara_ is now known as ara
[10:42] <cjwatson> apw: git.l.n isn't a good example for this :)
[10:42] <apw> pitti, though in practice they may be essentially the same for you
[10:42] <apw> cjwatson, damn :)  it seemed like it had the same relationship
[10:42] <cjwatson> apw: and no, you would do SSO directly
[10:43] <cjwatson> apw: the LP bits here AIUI can be done anonymously anyhow
[10:43] <cjwatson> apw: and even if the LP calls in question required auth, that would be auth with a different principal
=== henrix_ is now known as henrix
[10:44] <cjwatson> apw: git.l.n is different because (a) it's a privileged service and talks to a special internal port for some of its stuff (b) while the HTTPS frontend does do SSO, it's probably not good example code unless you're already using Twisted
[10:45] <apw> cjwatson, well here we need the very simplest daemon that can verify you and send a message to aqpm, so i guess anything close is a good example
[10:50] <cjwatson> pitti,apw: you'd normally just use the openid auth support in whatever framework you're using, e.g. django-openid-auth or flask.ext.openid, pointed at https://login.ubuntu.com/
[10:51] <cjwatson> the LP username will be one of the things you get back
[10:52] <cjwatson> https://git.launchpad.net/turnip/tree/turnip/pack/http.py is an example of doing it mostly by hand within Twisted, but like I say you probably don't want to do that :)
[11:02] <pitti> cjwatson: I don't really have a framework ATM, debci is just using some ruby scripts to generate the .html pages via scripts, but the web frontend is all plain html
[11:02] <pitti> cjwatson: which one would you recommend?
[11:07] <didrocks> pitti: hum, can be my update from today, which is weird, I tried multiple scenarios for 30 minutes…
[11:07] <didrocks> pitti: do you have the version and can add set -x to it?
[11:11] <didrocks> so, default config works, I tried as well to create dangling symlink by renaming text.plymouth and default.plymouth (each at a time and then both)
[11:11] <didrocks> so it's at least not the scenarios I tested, I would like to have a little bit more info about the config when this happens (probably a wrong sed substitution)
[11:12] <cjwatson> pitti: I'm the wrong person to ask for that I'm afraid :)  flask is probably reasonably decent at keeping mostly out of your way
[11:23] <didrocks> (I'm pretty sure http://paste.ubuntu.com/14048715/ is the correct fix to avoid theme copy loop, but I would prefer to confirm it by reproducing it first)
[11:25] <pitti> didrocks: so far I've only seen it in test logs, but from there it should be easy enough; hang on, still dealing with something else, sorry
[11:26] <pitti> didrocks: so similar in spirit as apw's http://paste.ubuntu.com/14048328/ ?
[11:26] <didrocks> pitti: no worry! I tried (the change was to handle that) to mv /etc/alternatives/{default;text}.plymouth
[11:26] <didrocks> pitti: well, apw's change isn't fixing it
[11:26] <didrocks> because update-alternatives return "none" as a Value when it's a dangling or unconfigured symlink
[11:27] <didrocks> but that's handled a little bit below in the hook as well, that's why I want to reproduce if possible
[11:27] <apw> didrocks, right we could only get this issue if there are no alternatives so there is no Value: in the output
[11:28] <apw> didrocks, then we do "basename .plymouth" and that returns .plymouth and we get the error
[11:28] <didrocks> apw: is that different from mv /etc/alternatives/default.plymouth /etc/alternatives/default.plymouth.old for instance?
[11:28] <didrocks> (as it's what I tested)
[11:29] <apw> didrocks, i am assuming like the output you get with --query foo
[11:29] <apw> essentially with the error redirect that can be empty
[11:29] <pitti> didrocks: hm, I don't get it with naively installing plymouth-theme-ubuntu-text and dist-upgrading from ubuntu5 to ubuntu6
[11:30]  * pitti tries the other way around
[11:30] <didrocks> apw: ah, interesting, indeed, update-alternatives is using something else as a base
[11:30] <pitti> didrocks: ah no, the test log shows that it was upgraded
[11:30] <pitti> Unpacking plymouth-theme-ubuntu-text (0.9.2-3ubuntu6) over (0.9.2-3ubuntu5) ...
[11:30] <didrocks> apw: as mv /etc/alternatives/default.plymouth /etc/alternatives/default.plymouth.old -> --query show Value: non
[11:30] <didrocks> "none"
[11:30] <didrocks> which is handled
[11:31] <didrocks> but if I --query foo, I see it's empty
[11:31] <didrocks> anyway, my patch should work (and can fix other weird case as well as being more correct)
[11:31] <didrocks> let me try it quickly
[11:40] <didrocks> apw: ok, your fix enables to go back to my default error handler and so protect against the empty variables. I reproduced locally and uploading it, thanks!
[11:40] <didrocks> pitti: sorry for the bother in the test bed
[11:40] <didrocks> (I also tried only corrupting one alternatives, and the other is still generated)
[11:41] <didrocks> I will now have a look why removing/renaming the symlinks gives different results for update-alternatives than using a non existing one (like "foo")
[11:54] <pitti> didrocks: no problem at all! they are there to be wedged :)
[11:54] <pitti> didrocks: many thanks for fixing!
[11:55] <didrocks> pitti: the positive side of -3ubuntu6 is that I hope to go to +100 lines diff in the hook with debian to 2 lines! :)
[11:55] <didrocks> (I basically refactored the hook to be useful to them)
[11:55] <pitti> wow
[13:08] <rbasak> pitti: please could you take a look at bug 1509816?
[13:08] <ubottu> bug 1509816 in init-system-helpers (Ubuntu) "Upgrade from 14.04 to 15.04 missed systemd-sysv and init package init 1.22ubuntu11 failed to install/upgrade: pre-dependency problem - not installing init" [Undecided,Confirmed] https://launchpad.net/bugs/1509816
[13:38] <pitti> rbasak: looking
[13:39] <pitti> rbasak: duped to bug 1032823
[13:39] <ubottu> bug 1032823 in lvm2 (Ubuntu) "package libdevmapper-event1.02.1 2:1.02.48-4ubuntu7.1 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,Confirmed] https://launchpad.net/bugs/1032823
[13:40] <pitti> I've seen reports about this a couple of times, I never saw it myself, though
[13:40] <pitti> rbasak: i. e. dmsetup -> libdevmapper -> libcryptsetup4 -> systemd-sysv -> init dependency chain/error chain
[13:48] <rbasak> pitti: thanks!
[13:49] <rbasak> pitti: that's 19 reports in total now. There must be some pattern we don't know about :-/
[13:50] <pitti> rbasak: oh, it's a circular dependency
[13:50] <pitti> Package: libdevmapper1.02.1
[13:50] <pitti> Depends: dmsetup
[13:50] <pitti> Package: dmsetup
[13:50] <pitti> Depends: libc6 (>= 2.14), libdevmapper1.02.1 (>= 2:1.02.107)
[13:50] <pitti> why would the library depend on the binary??
[13:51] <pitti> that can't be right, so perhaps if we drop the former to Recommends: or drop it entirely?
[13:51] <rbasak> Is that a bug in Debian too?
[13:52]  * pitti adjusts the bug prio and targets to xenial
[13:52] <pitti> rbasak: yes, it is
[13:53] <pitti> debian bug 586424
[13:53] <ubottu> Debian bug 586424 in dmsetup "dmsetup has circular Depends on libdevmapper1.02.1" [Normal,Open] http://bugs.debian.org/586424
[13:53]  * pitti links
[13:54] <pitti> Bastian's explanation is bogus, though; merely having the library installed should not imply any udev action etc.
[13:58] <pitti> rbasak: I followed up on the Debian bug
[13:59] <pitti> rbasak: I'm not very hopeful, though -- we've been carrying fixes for obvious and trivial bugs (with patches in the BTS) for 5 years or longer
[14:00] <pitti> didrocks: ok, the error message changed: http://paste.ubuntu.com/14050068/ but ubuntu7 is still failing :(
[14:03] <pitti> didrocks: so /etc/fonts/fonts.conf is coming from fontconfig-config
[14:04] <pitti> didrocks: but indeed I don't see any fontconfig* package in the package list
[14:04] <pitti> didrocks: should plymouth depend on fontconfig-config, or just not cp the file if it's absent?
[14:04]  * pitti hugs didrocks
[14:06] <pitti> Laney: FYI, I temporarily disabled xenial autopkgtesting due to that, so that it can at least catch up with vivid
[14:13] <didrocks> pitti: noooooooooooooooooooooooooooooooooooooooooooo
[14:14] <didrocks> pitti: what is this config where you have one "graphical" plymouth theme and not those debian packages?
[14:15] <rbasak> pitti: thanks
[14:15] <didrocks> pitti: I wouldn't be against knowing what the installed list of packages and what's configured the alternative in such a way
[14:16] <didrocks> even plymouth-label seems to be missing…
[14:16] <didrocks> from the warning
[14:23] <didrocks> pitti: the thing is: it seems that no theme is installed (as label.so module isn't there) and so the dep isn't matched. Would be better to understand what theme is configured for it (and so, goes into that path)
[14:27] <pitti> didrocks: it's based on the cloud images, let me try to reproduce locally
[14:27] <pitti> didrocks: I have libplymouth4, plymouth, and plymouth-theme-text installed, nothing else
[14:27] <didrocks> pitti: ok, let me try in parallel then
[14:27] <pitti> didrocks: and the only '*font*' match is fonts-ubuntu-font-family-console
[14:28] <didrocks> plymouth-theme-text shouldn't go into that code patch
[14:28] <didrocks> path*
[14:28] <pitti> didrocks: ah, I just reproduced the 0ubuntu6 failure
[14:28]  * pitti tries to apt-get update harder
[14:28] <pitti> didrocks: standard off-the-shelf "adt-buildvm-ubuntu-cloud" image, btw
[14:29] <didrocks> ah, I think the adt image is bigger
[14:29] <didrocks> weird… mine is maybe modified
[14:29]  * didrocks trashes it and builds one
[14:32] <pitti> didrocks: sorry, plymouth-theme-ubuntu-text, not plymouth-theme-text
[14:32] <didrocks> ahah!
[14:32] <didrocks> that starts to make more sense :)
[14:32] <didrocks> so yeah, the patch needs to be different, I guess we don't need any of those fonts in that case
[14:32]  * didrocks looks
[14:32] <tkamppeter> morphis, hi
[14:32] <pitti> didrocks: I grabbed the three binaries from https://launchpad.net/ubuntu/+source/plymouth/0.9.2-3ubuntu7/+build/8447092
[14:32] <morphis> tkamppeter: hey!
[14:32] <pitti> didrocks: and dpkg -i over ubuntu5 reproduces this
[14:33] <didrocks> pitti: mind (my image is still downloading), changing line 109 in /usr/share/initramfs-tools/hooks/plymouth
[14:33] <didrocks> it should be:
[14:34] <didrocks>     text|details)
[14:34] <didrocks> and replace with:
[14:34] <didrocks>     ubuntu-text|text|details)
[14:34] <tkamppeter> morphis, my last question was: A .override allows me to apply another method to start a daemon, but not to use a modified config file. What I need is that on the phone /etc/cups/cups-browsed.conf gets the lines "IPBasedDeviceURIs IPv4" and "CreateIPPPrinterQueues Yes" added.
[14:34] <pitti> didrocks: still the same, fails on missing /etc/fonts/fonts.conf
[14:34] <didrocks> ok, let me download
[14:35] <pitti> didrocks: that's precisely the code which does the cp -a /etc/fonts/fonts.conf "${DESTDIR}/etc/fonts"
[14:35] <didrocks> pitti: yeah, but it shouldn't reach it… this is the weird part :)
[14:35] <pitti> didrocks: oh, sorry, no -- the line you changed short-circuits that
[14:35] <pitti> I missed the ;;
[14:36] <didrocks> and THEME_NAME is supposed to be empty in that case
[14:36] <didrocks> oh
[14:36] <didrocks> it is empty
[14:36] <didrocks> so goes to *)
[14:36] <pitti> didrocks: $THEME_NAME is empty
[14:36] <didrocks> I bet!
[14:36] <pitti> yes
[14:36] <didrocks> making sense then :)
[14:36] <pitti> didrocks: I just added an echo
[14:36] <didrocks> phew
[14:36] <didrocks> so yeah, we need to go to that "null" case when empty
[14:36] <morphis> tkamppeter: ok, which daemon reads that config file?
[14:37] <pitti> didrocks: restarting from scratch to verify
[14:37] <pitti> didrocks: i. e. ""|text|details)
[14:37] <didrocks> yeah
[14:37] <tkamppeter> morphis, /usr/sbin/cups-browsed
[14:37] <didrocks> pitti: I would still replace with ""|ubuntu-text|text|details)
[14:38] <morphis> tkamppeter: can you pass the config file by with an argument?
[14:38] <didrocks> pitti: imagine someone decides to set ubuntu-text as their primary theme (not the alternative text one)
[14:38] <pitti> didrocks: what's weird is that the same code is already present in ubuntu5
[14:38] <didrocks> and don't have any graphical theme installed
[14:38] <didrocks> so no font
[14:38] <didrocks> -> that could happen
[14:38] <didrocks> pitti: yeah, the different is that I was exiting at the time
[14:38] <didrocks> (way before)
[14:39] <didrocks> so if you had a text theme
[14:39] <didrocks> but not a graphical one set
[14:39] <didrocks> -> no plymouth splash
[14:40] <pitti>         ""|ubuntu-text|text|details)
[14:40] <pitti> didrocks: ^ works
[14:40] <didrocks> phew!
[14:40] <didrocks> sorry *again* :/
[14:40] <pitti> didrocks: don't be
[14:40] <didrocks> pitti: let me upload with a good rationale in a sec
[14:40] <pitti> didrocks: celebrate some fun with the devel series!
[14:40] <didrocks> hehe :)
[14:41] <tkamppeter> morphis, not yet, but I am upstream of cups-browsed, so I can add this functionality, I can also add the possibility to supply config options via the command line, something like "cups-browsed -c cups-browsed-alternative.conf -O IPBasedDevicURIs=Ipv4"
[14:41] <morphis> tkamppeter: yeah, that would be the way to go
[14:41] <morphis> tkamppeter: if you then have a touch specific config file we can add it + the .override to lxc-android-config
[14:42] <tkamppeter> morphis, I will implement both methods, but probably use the "-o ..." method.
[14:42] <morphis> ok
[14:42] <morphis> tkamppeter: btw. I saw you did on MP for lxc-android-config
[14:42] <tkamppeter> morphis, yes, and it got approved but I have a question now.
[14:43] <didrocks> pitti: uploaded, I hope this is for good, this time :)
[14:43] <tkamppeter> morphis, On a merge proposal I got the answer "Review: Approve; LGTM but needs proper landing through the citrain", what do I have to do now?
[14:43]  * pitti hugs  didrocks
[14:43] <morphis> tkamppeter: you know the citrain?
[14:43] <tkamppeter> morphis, no.
[14:43]  * didrocks hugs pitti back
[14:44] <morphis> tkamppeter: the citrain is how we land things
[14:44] <morphis> there is a full documentation on https://wiki.ubuntu.com/citrain/LandingProcess
[14:44] <morphis> but it works basically like this:
[14:45] <morphis> 1. Create a landing request on https://requests.ci-train.ubuntu.com/ and press "Assign"
[14:45] <morphis> with that you get a silo (which is a specific ppa) assigned
[14:45] <morphis> you need to add the link to the MP in the landing request
[14:45] <morphis> 2. Build the silo, that will fetch the MP and build a package with that
[14:45] <morphis> and then put everything into the silo your request has assigned
[14:46] <morphis> 3. Test your silo
[14:46] <morphis> 4. When you are done with that you can mark your landing request as "Ready for QA"
[14:46] <morphis> then the QA guys will test your silo with the instructions you added to the request
[14:46] <morphis> if the are fine with your change the citrain will automatically land the package
[14:47] <morphis> the good thing for lxc-android-config is that the same change will land at the same time in xenial and our vivid overlay ppa
[14:47] <morphis> generally a nice and easy process but with some details to respect :-)
[14:48] <tkamppeter> So it needs all that work for such a tiny and obvious fix?
[14:48] <morphis> tkamppeter: but in other words: nobody will merge your MP for lxc-android-config you have to get it merged with citrain through the process I've described above
[14:48] <morphis> tkamppeter: it sounds more than it is
[14:48] <apw> pitti, ok i think i have this systemd thing identified as an issue with libseccomp (being out of sync with the kernel) and am testing a patch to fix that now
[14:48] <morphis> you get used to that and then it doesn't take much more time
[14:49] <tkamppeter> morphis, is it the same procedure to get the printing stack included in the phone OS?
[14:49] <apw> pitti, SCMP_SYS(socket) == 359 == 167
[14:49] <apw> Success
[14:49] <morphis> tkamppeter: to some degree, yes
[14:50] <morphis> tkamppeter: all phones are currently running vivid + an overlay ppa
[14:50] <morphis> so we're not landing anything in vivid through SRUs
[14:50] <tkamppeter> morphis, what means "to some degree" here?
[14:50] <morphis> so if you need a change there then you have to follow that way
[14:51] <pitti> apw: \o/
[14:51] <morphis> if you need a direct package upload to a silo then you can ask in #ubuntu-ci-eng for that
[14:52] <morphis> tkamppeter: the very important aspect here is that QA must approve your changes which helps quite a lot to get the quality up
[14:55] <tkamppeter> morphis, can I make one request called "Printing stack addition", containing the addition of all printing-related packages plus the current MP for cups.override plus another MP for the cups-browsed config?
[14:56] <morphis> tkamppeter: sure
[14:56] <apw> pitti, how does http://paste.ubuntu.com/14050659/ look to you
[14:56] <morphis> tkamppeter: however one thing you need to respect:
[14:57] <pitti> apw: urgh -- it looks to me like I don't want to read the other parts of libseccomp :)
[14:57] <apw> pitti, oh please let me have that luxury
[14:57] <pitti> apw: do they honestly re-hardcode every syscall? why doesn't that use the __NR_syscall macros?
[14:57] <apw> pitti, anyhow seems to fix x86
[14:57] <morphis> tkamppeter: we differentiate between dual-landings and one-distro-only landings
[14:57] <pitti> apw: but in the context of the other declarations that looks fine; thanks!
[14:57] <apw> pitti, yes they do, and then supply all sorts of fakers like for socketcall against socket/bind et al
[14:58] <morphis> tkamppeter: so if you put just a cups package for vivid in the silo then you have to put a xenial one too
[14:58] <pitti> apw: hang on before you upload -- "Add these to the 23bit x86 syscalls table"
[14:58] <pitti> apw: please add 9 extra bits
[14:58] <morphis> tkamppeter: or you do two silos: one for all dual landings, and one for the vivid-only stuff
[14:58] <apw> which is what was tripping us up.  i suspect we (and they) could generate the lists
[14:58] <apw> pitti, heh
[14:59] <dannf> cjwatson: yeah i did, thanks!
[14:59] <pitti> rbasak: I uploaded the lvm2 fix
[14:59] <apw> pitti, applied
[15:00] <tkamppeter> morphis, AFAIK printing should be added to the newest syystem, not backported, would then doing all this in Xenial be enough?
[15:00] <morphis> tkamppeter: no
[15:00] <morphis> tkamppeter: the phone will stay on vivid for still some time
[15:00] <morphis> so if you want a feature be included in a phone update release you need to do it on both
[15:03] <apw> pitti, anything else before i hit return ?
[15:03] <pitti> LGTM otherwise
[15:03] <apw> pitti, great, will do a couple more build tests and ram it in
[15:03] <pitti> apw: it's not that easy to attach a versioned kernel dependency to it, which is the only other thing I can think about
[15:04] <apw> pitti, no they have no meaning sadly
[15:05] <apw> this means we are not backwards compatible for sockets for things built since NR_socket appeared in glibc
[15:05] <pitti> apw: do you forward that to https://github.com/seccomp/libseccomp? or want me to help with that?
[15:05] <apw> pitti, i have no idea how to forward it, but am happy to do so :)
[15:05] <pitti> apw: normal github pull request, i. e. clone, apply, push your own branch, request a pull
[15:06] <pitti> apw: as I said, I can help you with that (it'll keep your author information of course)
[15:06] <apw> pitti, if yo uare all setup for that, then it might be easier if you do it :)
[15:06] <apw> pitti, though i guess we should confirm this fixes systemd as well though i think it must
[15:07] <apw> pitti, i guess we upload it and then do a couple --trigger test
[15:07] <pitti> apw: I'll test it; but nspawn uses that exact code
[15:07] <morphis> tkamppeter: but feel free to ask for help when you need it :-)
[15:07] <pitti> apw: it should actually auto-trigger, as systemd-container depends on it
[15:08] <pitti> ah, systemd itself too, as you can set seccomp restrictions in units
[15:08] <apw> yeah and sa we are single kernleed in that series
[15:08] <apw> as
[15:14] <pitti> apw: https://github.com/martinpitt/libseccomp/commit/5a93300830
[15:14] <pitti> apw: if that looks good to you, I'll create the PR
[15:15] <apw> pitti, lgtm if you need/want an sob feel free to add
[15:16] <tkamppeter> morphis, so it seems to be all dual-landing then. Can it be done all-in-one then?
[15:16] <morphis> yeah
[15:16] <pitti> apw: sligthly tweaked the commit message to say "Linux 4.3": https://github.com/martinpitt/libseccomp/commit/6dfabf20148
[15:17] <apw> pitti, yep makes sense
[15:19] <netbog> hello... how can i use qtquick to connect with mySQL db?
[15:20] <rbasak> netbog: try #ubuntu-app-devel
[15:20] <netbog> ok thank you
[15:21] <sil2100> pitti: hey! :) So, I would like to properly add qml-module-qtbluetooth to the touch seeds - I saw you were the one removing them recently, are there any reasons besides invalid placement?
[15:21] <sil2100> pitti: or is it ok for me to properly re-add those?
[15:23] <pitti> sil2100: oh, I did? I guess as part of sponsoring?
[15:24] <sil2100> pitti: not sure, it wasn't a merge... but maybe someone requested that ;) Anyway, re-adding those in the proper place as previously they were in the wrong section anyway
[15:24] <sil2100> If you don't remember any reasons for not having those then all's good
[15:30] <pitti> seb128: thanks
[15:30] <pitti> err, sil2100: thanks
[15:30] <pitti> seb128: thanks to you too, though, for taking care of the desktop! *hug*
[15:30]  * seb128 hugs pitti back
[15:31] <pitti> sil2100: no, I certainly don't touch (no pun intended) the touch seeds other than upon request
[15:31] <seb128> my please!
[15:31] <sil2100> ;)
[15:33] <tkamppeter> morphis, thank you, so I will put one silo together which adda the printing packages, and does the changes on cups.override and cups-browsed.override, but first, I will release cups-filters 1.5.0 where cups-browsed takes alternative config files and options via command line.
[15:40] <tkamppeter> morphis, WDYT?
[15:44] <pitti> apw: ah, upstream responded to https://github.com/seccomp/libseccomp/pull/22 -- at least we did due diligence
[15:44] <apw> pitti, yeah that souds like we have something which will work for us in the short term
[15:45] <apw> pitti, and we can check back in a bit and get something which will suck less :)
[15:45] <pitti> apw: yeah, the patch should just start to massively conflict once they fix it more properly, and until then it shouldn't be too hard to maintain
[15:46] <apw> right exactly
[15:46] <apw> and i think they need to fix it _soon_ for their own sanity
[15:47] <morphis> tkamppeter: sorry, was distracted
[15:47] <morphis> tkamppeter: sounds good to me
[15:51] <tkamppeter> morphis, OK, thank you very much. I will contact you if I have further questions. Until when (due to EOV) I can find you here?
[15:52] <morphis> tkamppeter: yes
[15:52] <morphis> tkamppeter: I am working till 12/23
[15:55] <tkamppeter> tkamppeter, OK.
[15:59] <smoser> cjwatson, maas is now installing by default to lvm. and thus we're seeing https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1313784
[15:59] <ubottu> Launchpad bug 1313784 in grub-installer (Ubuntu) "File descriptors leaked on lvs invocation" [Undecided,Confirmed]
[15:59] <smoser> is that something we need to worry about?
=== cpaelzer is now known as cpaelzer_afk
[16:05] <cjwatson> smoser: no, it's totally pointless whining from lvm
[16:06] <smoser> would you care to comment in that bug to that affect ?
[16:08] <seb128> bah
[16:08] <seb128> my xenial vts are doing qwerty today
[16:09] <seb128> is that a known issue? (not respecting locale keymap)
[16:09] <cjwatson> smoser: done
[16:10] <smoser> cjwatson, thank you.
[16:28] <seb128> cyphermox, hey, is there any reason to keep building the n-m migration code? that was from < 0.9 updated and trusty already had 0.9 ... build with --disable-migration drops the gconf depends
[16:28] <cyphermox> oh, by all means if that's the case it could be dropped
[16:31] <seb128> cyphermox, yeah, I just tried
[16:31] <cyphermox> cool
[16:32] <seb128> Depends: [-gconf-service,-]
[16:32] <seb128> , [-libgconf-2-4 (>= 3.2.5),-]
[16:32] <seb128> cyphermox, should I do an upload for that?
[16:32] <cyphermox> sure
[16:33] <cyphermox> I don't really plan to touch NM soon
[16:38] <seb128> cyphermox, done
[16:42] <mdeslaur> cyphermox: your evil plan worked, you're no longer TIL on NM :)
[16:42] <seb128> shrug, or not
[16:42] <seb128> cyphermox, upload failed because you didn't commit https://launchpad.net/ubuntu/+source/network-manager-applet/1.0.6-2ubuntu3 to the vcs and I didn't check before
[16:42] <seb128> shrug
[16:42]  * seb128 does uncommit&wget&patch&override dance
=== imcleod is now known as imcleod_dogwalk
=== francisco is now known as Guest17227
[18:14] <Laney> barry: any chance you could look at bug #1526267?
[18:14] <ubottu> bug 1526267 in synaptic (Ubuntu) ".../softwarecenter/backend/scagent.py : no module named "spawn_helper"" [High,Confirmed] https://launchpad.net/bugs/1526267
[18:14] <Laney> could be nothing but I have to go now
[18:14] <Laney> sorry
[18:16] <barry> Laney: i'll look
[18:47] <teward> can someone help me figure out why there's an FTBFS on my latest nginx upload, for ppc64el?  https://launchpadlibrarian.net/230254441/buildlog_ubuntu-xenial-ppc64el.nginx_1.9.6-2ubuntu1_BUILDING.txt.gz
=== imcleod_dogwalk is now known as imcleod
[18:58] <rbasak> teward: I've not seen that before. See if it reproduces by hitting the retry button maybe?
[19:03] <teward> rbasak: i think i saw that issue in the past, though it's been a while, and only ever once or twice in the PPAs...
[19:03] <teward> but i've retried the ppc64el build for now
[19:03] <teward> no others have sent me back "It Died" responses yet
[19:03] <teward> arm64 and ppc64el are the last two to build, all others were successful :)
[19:07] <teward> rbasak: retry worked.  :)
[19:07] <teward> just waiting on arm64 to start :P
[19:08] <rbasak> \o/
[19:10] <pitti> Laney: FTR, xenial re-enabled, seems new plymouth is calm now
[19:43] <blake_r> pitti: I got a systemd issue/question if you got the time
[19:45] <sarnold> blake_r: pitti's probably going to see that message in nine or ten hours.. you're more likely to get a response "quickly" if you also include the question, so you don't have to wait another day to ask it when he says "yes" :)
[19:46] <blake_r> sarnold: okay thanks for the info
[19:46] <blake_r> pitti: this will give you the question and the context - http://paste.ubuntu.com/14055580/
=== cpaelzer_afk is now known as cpaelzer
[20:58] <Unit193> Oh, crap.  Accidentally dput something without a target, thank goodness for autorejects!
[21:27] <ancaemanuel> go 1.6 beta 1 will be released tomorrow, https://groups.google.com/forum/#!topic/golang-dev/6Ga5o2Ao2WM
[21:27] <ancaemanuel> There are some really good improvemens on gc and runtime https://github.com/golang/go/commits/master
[21:28] <ancaemanuel> Can you consider an ppa for testing this version in xenial ?
[21:30] <ancaemanuel> sorry for my english...
=== nobuto_ is now known as nobuto
=== cpaelzer is now known as cpaelzer_afk
[22:43] <teward> is there any way to see a running autopkgtest on britney or no?  Asking because the link from the update_excuses page takes me to a page that doesn't list that package's autopkgtest
[23:04] <ancaemanuel> teward: this is the page http://autopkgtest.ubuntu.com/running.shtml , and the system is not perfect yet. It requires a lot of manual intervention.
[23:05] <teward> ancaemanuel: indeed.  seems the autopkgtests just move faster than I can get to them xD
[23:05] <teward> unfortunately
[23:06] <teward> but the ones i was caring about didn't fail, so at least I'm good there :)
[23:06] <ancaemanuel> most of the work is done by piti http://status.ubuntu.com/ubuntu-x/
[23:18] <ancaemanuel> more details here https://launchpad.net/~canonical-foundations/+upcomingwork
[23:21] <ancaemanuel> is there an public link for RT#84348 ?
[23:32] <ancaemanuel> anybody can explain what RT (in an bug description) means ?
[23:34] <sarnold> ancaemanuel: "request tracker"
[23:35] <sarnold> it's sort of like a bug tracker, but better suited to requests for services from IS staff
[23:53] <hloeung> ancaemanuel: https://portal.admin.canonical.com/84348