[00:28] <sexyboy> sup, why ubuntu full live images can't contain both graphical and alternate intallers?
[00:39] <infinity> sexyboy: Because they'd be twice the size.
[00:40] <sexyboy> i doubt, debian used to (or still does) contain both graphical and text installer
[00:40] <sexyboy> they just install packages from one pool
[00:40] <infinity> You may doubt all you want, but our installer isn't the same as theirs.
[00:41] <infinity> Our live installer doesn't install from packages, it just blats out the contents of the livefs, and does some post-copy twiddling.
[00:41] <infinity> Which is why it's so fast.
[00:41] <infinity> But also means it's awful for a highly customizable experience like d-i (the "alternate" installer)
[00:41] <sexyboy> i see
[00:42] <infinity> We do have a d-i that installs from live images too (we use it for the server CD), but to use that on the desktop CD, you'd either (A) end up with something identical to what ubiquity did, so who cares, or (B) have to remove hundreds of packages post-install.
[00:43] <sexyboy> infinity: how about this then: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1367487
[00:43] <infinity> sexyboy: Really, if you want to install (and mass install) from d-i, I'd recommend a netboot option.  Either the mini.iso for one-off installs or a PXE setup for mass installs.
[00:43] <sexyboy> yeah i know that mini uses it
[00:43] <sexyboy> but the issue with mini is lack of proper wlan support
[00:44] <infinity> sexyboy: And yes, it's known that ubiquity still doesn't have 100% feature parity with d-i (and, in some cases, may never have all the features)
[00:44] <infinity> But, as you point out, ubiquity has some fancy features d-i doesn't (like better wireless support).
[00:44] <infinity> Anyhow, merging the two can't really be done, so it's not worth exploring.
[00:44] <infinity> Hacking on one installer or the other to add features you want is more productive.
[00:44] <sexyboy> so how about improving ubiquity to make it more rich in features?
[00:45] <sexyboy> s/more rich/richer
[00:45] <sexyboy> well, the issue that troubles me the most is described in the launchpad ticket
[00:46] <infinity> Patches always welcome. ;)
[00:46] <sexyboy> heeh
[02:50] <sexyboy> freaking hell, ubi-partman.py has 141K of lines... this gonna take a while
[02:52] <sexyboy> ah no, just over 3k
[02:52] <sexyboy> mc misslead me
[02:55] <sexyboy> i hope some of you will assist me in this
[04:54] <ScottK> pitti: Is "Could not find executable /tmp/adt-run.fS2Wfy/build.00G/ark-4.14.0/obj-i686-linux-gnu/kerfuffle/tests/jobstest.shell" an indication of a package problem or the ADT environment?
[05:05] <pitti> Good morning
[05:06] <sexyboy> morning
[05:06] <pitti> slangasek: you mean the "on starting dbus"? That waas supposed to ensure that cgmanager is always started when lightdm starts; but we didn't want to add a cgmanager dep to lightdm
[05:08] <pitti> ScottK: apparently something in the shared kde packaging tools changed recently to stop building these .shell files? I haven't checked the reason; they still all succeeded until not too long ago, one could probably limit the time of breakage with the history
[05:09] <ScottK> Thanks.
[05:09] <pitti> ScottK: one thing to try would be if it also happens in utopic, or whether it's something in -proposed
[05:09]  * pitti tries ark in both
[05:09] <ScottK> The same versions had passed previously.
[05:10] <pitti> yes, it affects pretty much all kde packages in the same way, it's obviously not a change in the leaf packages
[05:10] <ScottK> Riddell: Maybe it's apachelogger's fault^^^
[05:28] <pitti> desrt: wow, nice work on shim! I assume we want to get this packaged ASAP; slangasek, are you on it or want me to?
[05:32] <pitti> ScottK, Riddell: ah, I think I found it
[05:32] <ScottK> Oh?
[05:32]  * pitti does last re-run to confirm
[05:32] <pitti> Test project /tmp/adt-run.936IOo/ark-4.14.0/obj-i686-linux-gnu
[05:32] <pitti> /tmp/adt-run.YPh6KC/build.6NC/ark-4.14.0/obj-i686-linux-gnu/plugins/clirarplugin/tests/clirartest.shell
[05:32] <pitti> note the different tmpdir
[05:33] <pitti> that was a bug that I fixed recently in autopkgtest, it copied the previously built tree into the previous instead of current temp dir
[05:33] <pitti> after a reboot/reset
[05:33] <pitti> so apparently this is necessary as in this case the tests hardcode the full absolute path somewhere
[05:34] <pitti> so after a testbed reset I guess we need to copy it to the same name and live with the naming race condition (no big deal)
[05:34] <pitti> I'll get to that ASAP
[05:37] <ScottK> Great.  Thanks for your detective work.
[05:37] <ScottK> doko_: ^^^
[05:45] <sexyboy> so i'm thinking about modifying ubiquity to make lvm partitioning available
[05:45] <sexyboy> i know it uses d-i as a backend
[05:45] <sexyboy> and i'm not a coding guru so any hints on what should i start with would be helpfull
[05:53] <sexyboy> i'm looking at the ubi-partman.py plugin code
[05:54] <sexyboy> not sure which functions are responsible for calling d-i
[05:54] <sexyboy> ehm
[05:54] <sexyboy> anyone?
[06:00] <sexyboy> eh i'd need to remind some python basics
[06:30] <slangasek> pitti: for the reasons described, the 'on starting dbus' doesn't do anything to ensure ordering
[06:30] <slangasek> pitti: systemd-shim - I'll have a look at it tomorrow
[06:30] <pitti> slangasek: hm, that's not how I understand starting(7)
[06:31] <pitti> when a job A has "start on starting B", then I expect B's startup to be delayed until A has fully started
[06:31] <pitti> like a reverse dep
[06:32] <dholbach> good morning
[06:32] <pitti> "init(8) will wait for all services started by this  event  to  be  running, [...] before allowing the job to continue starting."
[06:32] <pitti> slangasek: ^ so is that not true/misleading, and A and B start in parallel?}
[06:33] <pitti> so cgmanager "start on starting dbus" should ensure that cgmanager starts before dbus (and thus lightdm), or on systems without cgmanager it wouldn't change anything (we wanted to support the latter and thus avoid changing lightdm to append "and started cgmanager")
[06:33] <slangasek> pitti: job A is not 'start on starting dbus', it's 'start on virtual-filesystems or mounted [...] or starting dbus'
[06:34] <pitti> slangasek: right, but wouldn't the other two at most make it start even earlier?
[06:34] <slangasek> pitti: 'start on A or B' means that when A is emitted, the job is started and *only* A is blocked
[06:35] <pitti> hm, so if that doesn't work, how else could this be declared?
[06:36] <slangasek> using wait-for-state
[06:38] <pitti> so a pre-start script in dbus.init that checks if cgmanager is installed, and if so, waits for it to be started
[06:38] <slangasek> or a separate job that's part of the cgmanager package which is 'start on starting dbus' + wait-for-state
[06:39] <pitti> slangasek: why would the latter need wait-for-state then? dbus would block on that new job with that, wouldn't it?
[06:40] <slangasek> the new job is just the glue
[06:40] <slangasek> you need to tell it how to wait for cgmanager to be started
[06:41] <slangasek> so 'start on starting dbus' / 'exec start wait-for-state WAITER=cgmanager-dbus WAIT_FOR=cgmanager'
[06:43] <pitti> slangasek: /e/i/wait-for-state.init has env TARGET_GOAL="start"; does that mean it defaults to "started" or "starting" (or any) when not given?
[06:44] <slangasek> those are states, not goals
[06:44] <slangasek> by default it expects start/started
[06:44] <slangasek> (goal/state)
[06:44] <pitti> ah, it's grepping status, I see
[06:50] <doko> pitti, please restart the python2.7 i386 autopkg test
[06:59] <pitti> doko: done
[07:04] <Mirv> could I get a packaging ack from a core dev for unity SRU microversion bump, visible at: https://ci-train.ubuntu.com/job/ubuntu-landing-005-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity_7.2.3+14.04.20140826-0ubuntu1.diff ? (there's also a patch removal for a fix that was now included properly)
[07:08] <pitti> Mirv: LGTM, it's just a bit weird that it's two changelog records?
[07:11] <Mirv> pitti: thanks. and yes. the last published version matches current trusty correctly, but their merge requests combined with CI Train "logic" came up with such solution unfortunately.
[08:32] <rbasak> infinity: http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-September/007015.html
[08:32] <rbasak> infinity: thank you for getting me to check.
[08:32] <rbasak> (did I say this already?)
[08:32] <rbasak> infinity: do you have any suggestions for what to do to get out of this mess?
[08:35] <zbenjamin> jdstrand: ping
[08:35] <zbenjamin> jdstrand: the test is working fine now ;),   For the location of the files i need to create, could i use TMPDIR? or XDG_RUNTIME_DIR?
[08:37] <zbenjamin> jdstrand: i 'm wondering if that would not the more correct location because those files should not be permanent
[09:18] <mlankhorst> is there an archive admin to accept fglrx to -proposed?
[09:32] <mlankhorst> it's blocking my xorg-server upload :-)
[10:02] <pitti> ScottK, Riddell, doko: ok, KDE autopkgtest failures sorted out now
[10:04] <Riddell> yay thanks pitti, sorry I've not been around, busy at akademy
[10:04] <Riddell> pitti: what was up?
[10:04] <mlankhorst> ScottK: did you get around to testing mesa?
[10:04] <pitti> Riddell: ah, have fun at akademy! (I saw your blog posts)
[10:05] <pitti> Riddell: apparently the built tests contain absolute file names to a temporary build dir; there was a bug with copying back the previously built directory into the new testbed after reset, but I added a hack for that now
[10:09] <doko> pitti, Riddell, ScottK: kopete still fails. should it be overridden?
[10:10] <pitti> doko: no, it just succeeded
[10:11] <pitti> it just took very long (finished a few mins ago), so britney didn't pick it up yet
[10:12] <pitti> doko: sorry that gcc is always the scapegoat for finding bugs in pretty much any test; fortunately delaying propagation for a bit doesn't matter much
[10:13] <doko> pitti: thanks. and I just see that the debci build ftbfs
[10:13] <pitti> yep, that's on my list; if it's blocking anything, I'm fine with removing it from -proposed, too
[10:13] <pitti> (but it doesn't AFAIK)
[10:15] <mlankhorst> doko: ping?
[10:16] <doko> mlankhorst, you see that I'm here ...
[10:16] <mlankhorst> doko: I want to reduce the delta with debian-unstable's xorg-server, is the patch debian uses sufficient for our needs too?
[10:16] <mlankhorst> they only export xserver_confflags
[10:16] <doko> mlankhorst, what do I else?
[10:16] <mlankhorst> xserver_confflags_main / udeb / xserver_vars
[10:17] <mlankhorst> but their xserver_confflags also contains the contents of _main
[10:22] <pete-woods> cjwatson: hi. do you have time to do another check of https://code.launchpad.net/~unity-api-team/click/scope-facing-apis/+merge/233974
[10:22] <pete-woods> I've done the resubmit now
[10:23] <cjwatson> pete-woods: approved.  tarmac should get round to landing it in a bit
[10:23] <pete-woods> cjwatson: awesome. thanks!
[10:26] <mlankhorst> so if I can get some confirmation that change is fine with vnc (should be) then I can upload a new xorg-server :-)
[10:33] <doko> mlankhorst, just do it, tigervnc is still in NEW :-/
[10:53] <mlankhorst> ok
[11:08] <doko> neutron (1:2014.2~b2-0ubuntu1 to 1:2014.2~b3-0ubuntu1)
[11:08] <doko> Maintainer: Ubuntu Developers
[11:08] <doko> 0 days old
[11:08] <doko> python-neutron/i386 unsatisfiable Depends: pthon-babel (>= 1.3)
[11:08] <doko> python-neutron/i386 unsatisfiable Depends: python-oslo.rootwrap (>= 1.3.0~a1)
[11:08] <doko> Not considered
[11:08] <doko> zul, ^^^ "pthon-babel"
[11:17] <zul> doko: crap ill fix it
[11:18] <desrt> pitti: :)
[11:18] <doko> zul, and a new version of python-oslo.rootwrap is needed
[11:18] <zul> doko: ok
[11:22] <doko> pitti: should init be kept in main?
[11:28] <doko> seb128, Laney: firefox-globalmenu and thunderbird-globalmenu are considerd for demotion. is this intended?
[11:32] <seb128> doko, that's a question for chrisccoulson but I think not
[11:33] <doko> ok, asking
[11:34] <pitti> doko: fine to go to universe for now; we haven't yet discussed what to do with that metapackage in ubunut
[11:34] <doko> pitti: and cgroup-lite?
[11:34] <pitti> I don't know about that one -- stgraber, hallyn ^ ?
[11:43] <doko> jtaylor, I remember some request from you. what was this?
[11:47] <Mirv> in case anyone is interested, my apt complaining about all signing keys missing was apparently about some resource limit in keyblock resource files /etc/apt/trusted.gpg.d/. I removed a few and ran sudo dpkg-reconfigure ubuntu-keyring
[11:49] <Mirv> so apparently something like bug #1263540
[12:15] <infinity> doko: cgroup-lite probably wants to be removed completely, but stgraber would know for sure.
[12:17] <jdstrand> zbenjamin: for click apps, TMPDIR is set to a subdirectory in XDG_RUNTIME_DIR. so, I recommend TMPDIR :)
[12:17] <jdstrand> zbenjamin: you may want to fallback to /tmp if it isn't set though (to handle non-confined (or differently-confined) apps)
[12:27] <flexiondotorg> cjwatson, I have word from Canonical IS that there is enough spaces to accommodate Ubuntu MATE. The Ubuntu Tech Board gave the project the green light.
[12:27] <flexiondotorg> cjwatson, How should I proceed to get Ubuntu MATE integrated into the official build infrastructure?
[12:30] <doko> mlankhorst, libepoxy promoted
[12:31] <cjwatson> flexiondotorg: mail me with the location of your seeds and a pointer to your current ad-hoc build system for reference
[12:32] <flexiondotorg> cjwatson, Will do.
[12:32] <mlankhorst> thanks
[12:42] <infinity> cjwatson: And pretty please made sure core-dev has write access to your seeds, in case we need to do some rapid fixes that can't handle an MP turnaround.
[12:42] <infinity> Err.
[12:42] <infinity> flexiondotorg: ^
[12:43] <flexiondotorg> infinity, core-dev being who?
[12:43] <infinity> flexiondotorg: 06:09 <infinity> Maybe tox just needs a tox-lite that doesn't have the pip/virtualenv bits turned
[12:43] <infinity>                  on (and thus, hasn't the dependencies).
[12:43] <infinity> 06:09 <infinity> Though, without archive reorg, that would still be a forked source package. :/
[12:43] <infinity> 06:10 <infinity> Oh, unless it doesn't need them at build time, which I suppose it might not.
[12:43] <infinity> Err.
[12:43] <infinity> flexiondotorg: https://launchpad.net/~ubuntu-core-dev
[12:44] <infinity> I can't paste today to save my life.
[12:44] <infinity> Motor skills at 7am are not my thing. :/
[12:46] <flexiondotorg> infinity, Do I do that by subscribing ubuntu-core-dev to the repository?
[12:46] <infinity> flexiondotorg: The traditional way to do that seems to be for your seeds to be owned by a mate-developers (or similar) team, and then invite ubuntu-core-dev to join that team.
[12:46] <flexiondotorg> infinity, Thanks.
[12:50] <flexiondotorg> infinity, cjwatson I currently have some packages in a PPA that a required to "make" Ubuntu MATE. Will these need uploading to the official archive as prerequisite?
[12:50] <flexiondotorg> I believe there are 2 sponsors who can/will upload packages on my behalf, until I have PPU rights.
[12:51] <infinity> flexiondotorg: If it's not buildable without them, it's certainly a prereq for us being able to test things reasonably.
[12:56] <flexiondotorg> infinity, Email sent to Colin. ubuntu-core-dev added the ubuntu-mate-dev team. I'll contact our sponsors and progress package uploads.
[12:57] <desrt> pitti: looks like slangasek is not on it :)
[12:57] <desrt> pitti: (due to sleeping)
[12:57] <pitti> desrt: he said he'd get to it in his morning
[12:57] <desrt> ah. nice.
[12:57]  * desrt missed that
[12:57] <pitti> I offered to do it, but I don't want to step on his toes
[12:58] <flexiondotorg> pitti, Did you offer to act as sponsor for uploading Ubuntu MATE packages? Sorry, it wasn't clear if you are sponsoring or would find sponsors.
[12:59] <doko> cjwatson, ok to demote libparted-i18n?
[12:59] <doko> don't know about gfxboot-themes
[13:00] <popey> flexiondotorg: dholbach also said he'd help ☻
[13:00] <popey> he owes me anyway ㋛
[13:00] <dholbach> popey, how can I help?
[13:00] <dholbach> flexiondotorg, ^
[13:00] <pitti> flexiondotorg: I can do a few, yes (just not right now); but you're welcome to ping/email me with the requests
[13:01] <mlankhorst> hm what was the magic command to test if my package is published to the archive already?
[13:01] <pitti> mlankhorst: you mean rmadison?
[13:01] <mlankhorst> ah probably
[13:01] <mlankhorst> thanks
[13:01] <dholbach> flexiondotorg, is it https://code.launchpad.net/~ubuntu-mate-dev/ubuntu/utopic/policykit-desktop-privileges/mate-fixes/+merge/230610?
[13:01] <flexiondotorg> dholbach, Thanks. There are not many. I'll email you details. Thanks for helping.
[13:01] <popey> dholbach: context is getting ubuntu mate packages in utopic. they are currently in a ppa. this is a step towards get ubuntu mate built on canonical infra
[13:01] <flexiondotorg> Well, that would be good. But not just that.
[13:02] <flexiondotorg> I have a few package for settings and themes.
[13:02] <flexiondotorg> sec...
[13:02] <dholbach> pitti, is the master of policykit, so I'd leave that one to him
[13:02] <dholbach> I'm happy to review the other packages, if you give me the links
[13:02] <flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-settings
[13:02] <flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-artwork
[13:02] <pitti> flexiondotorg, dholbach: will do pk-desktop-privs
[13:03]  * popey hugs dholbach 
[13:03] <flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-themes/ubuntu-mate-themes
[13:03] <dholbach> rock on
[13:04] <flexiondotorg> So, I have my own pkla file in ubuntu-mate-settings that will not be required when +merge/230610 is approved and integrated.
[13:06] <mvo_> cjwatson: would it make sense to drop "minimal" from the STRUCTURE for the ubuntu-sdk-libs-dev seed? when we build the click chroot we do not install minimal currently (and we don't need to afaict) but we need python3 for autopilot so I was wondering if I can simply make it a explicit dep of ubuntu-sdk-libs-dev but the inherit of minimal prevents that right now
[13:08] <pitti> dpm, wgrant: hm, what is the problem with https://translations.launchpad.net/ubuntu/utopic/+source/account-polld/+imports ?
[13:08] <pitti> dpm, wgrant: i. e. is it normal that po files are "stuck" in the import queue, or is there something particularly wrong about this package/project?
[13:09] <dpm> pitti, the .po files are only imported when the corresponding .pot file has been imported. However, I don't see any generic .pot file in the queue (I only see arch-specific ones) -> https://translations.launchpad.net/ubuntu/utopic/+source/account-polld/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot
[13:10] <pitti> dpm: ah, so if we reject those, the corresponding .po files will be discarded, too?
[13:10] <pitti> dpm: https://translations.launchpad.net/ubuntu/utopic/+source/account-polld/+pots/account-polld looks fine, after all
[13:11] <pitti> hm, there are no approved/imported POTs though
[13:11] <barry> mterry: what does "Needs team bug subscriber" mean?
[13:11] <pitti> dpm: ah, this is apparenlty a project which doesn't have a pot upstream, so I guess we can just pick any pot and use that
[13:11] <dpm> pitti, yes, it seems the translations for the generic template have been imported already. It might be that the imported translations have already been removed from the queue. When was the upload done?
[13:11] <infinity> barry: Means that the package needs a team subscribed to bugs that will take responsibility for them.
[13:12] <pitti> dpm: not sure, but the files have been waiting for a month or so, so presumably a while ago
[13:12] <dpm> pitti, POT-Creation-Date: 2014-08-11 15:35-0300
[13:12] <pitti> dpm: so what I don't understand is why LP shows translations at all as it doens't seem to have any pot file?
[13:12] <doko> zul, you are a bad lier, try harder next time ;-P #1367747  http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg might help
[13:13] <dpm> so at that point the template was uploaded and imported, along with its .po files
[13:13] <pitti> dpm: OTOH https://translations.launchpad.net/ubuntu/utopic/+source/dialer-app/+imports?field.filter_status=all&field.filter_extension=pot doesn't show anything either
[13:13] <infinity> barry: For Foundations MIRs, that's ~foundations-bugs
[13:13] <pitti> dpm: so I take it that LP just doesn't show already imported/approved POTs (<- wgrant)
[13:13] <pitti> dpm: so I'm just going to reject these extra POTs, ok?
[13:13] <mterry> barry, we try to avoid having packages in main that no one is caring for -- so at minimum, please find a team that is willing to look after the package in Ubuntu and subscribe to its Ubuntu bugs
[13:13] <dpm> pitti, they don't appear in the queue as they were imported a month ago. It clears them from the queue a while after they've been imported
[13:13] <zul> doko: pysnmp4?
[13:13] <dpm> pitti, actually, that's something I wanted to talk about with you
[13:14] <wgrant> pitti: lib/lp/translations/interfaces/translationimportqueue.py:    RosettaImportStatus.IMPORTED: timedelta(days=3),
[13:14] <pitti> dpm: I'm just looking at bug 1356939 and will build new langpacks now
[13:14] <wgrant> Imported queue entries will be deleted after three days.
[13:14] <doko> zul "Dependencies: All in main."
[13:14] <pitti> wgrant: ah ok, so that's normal; thanks!
[13:14] <dpm> pitti, http://pastebin.ubuntu.com/8309319/
[13:14] <zul> doko: uh i didnt write the MIR for that
[13:15] <barry> mterry, infinity for a while i've thought ubuntu could use a python team like debian, but for now, foundations-bugs would work.  i'll subscribe that team to nose2 (i am primary maintainer in debian so it seems reasonable)
[13:15] <wgrant> pitti: However, it seems like pkgstriptranslations is being a bit overzealous in some cases. On at least several packages we're seeing POTs and POs imported from both the source dir and the arch-specific build dir.
[13:15] <mterry> barry, OK cool
[13:15] <dpm> pitti, so in a nutshell, is there something we can do not to generate a .pot file for each architecture? It clutters the imports queue 3x more than necessary
[13:16] <pitti> wgrant: yeah, I guess we need to pick just one of those then; there are some (many?) packages which don't have a POT in the upstream source, or it's out of date, so it gets generated during package build
[13:16] <dpm> and the queue is just horrible as it is without duplicate arch-dependent .pots :)
[13:16] <barry> mterry: done.  should i toggle the nose2 mir back to new?
[13:16] <doko> zul, https://bugs.launchpad.net/ubuntu/+source/python-oslo.utils/+bug/1367747 thinks otherwise ...
[13:16] <wgrant> pitti: Right. Perhaps the build systems should be fixed to use a prefix not including the architecture.
[13:16] <pitti> dpm: not easy, due to the problem above; we could stop importing translations from anything but i386 perhaps
[13:16] <pitti> wgrant: yeah, that's a cmake-ish thing, but I doubt we can/should fix it downstream
[13:17] <wgrant> Ah, that makes sense.
[13:17] <zul> doko: we were talking about snmp4 werent we? if not ill fix oslo.utils
[13:17] <pitti> but perhaps building translation tarballs only for i386 and arch: all would suffice
[13:17] <wgrant> Right, it's always seemed a bit weird.
[13:17] <infinity> pitti: And that would lose translations on anything that doesn't build on i386.
[13:17] <wgrant> We coalesce entries with the same paths.
[13:17] <dpm> wgrant, we have some filtering in the imports queue already, IIRC. Would it be possible to filter out anything that looks arch-dependent?
[13:18] <pitti> infinity: right; question is, would that actually affect pacakges with translations
[13:18] <wgrant> dpm: That's pretty difficult to judge.
[13:18] <pitti> yeah, same ^ for pkgbinarymangler
[13:18] <pitti> it doesn't know what happens on other arches
[13:18] <infinity> pitti: It might.  I'd rather not introduce the obvious bug.
[13:18] <mterry> barry, yeah just comment on the bug is fine, that's enough so that I'll notice and look at it again
[13:18] <dpm> wgrant, all of them seem to start with "obj-x86_64-linux-gnu/src/launchpad.net/" or rather "$ARCH/src/launchpad.net/"
[13:18] <barry> mterry: ack
[13:19] <pitti> infinity, wgrant, dpm: it seems to me that the most robust place to filter this would be to ignore/unify multiple pots with the same name
[13:19] <wgrant> dpm: The pattern is usually rather obj-$TUPLE/$PATH
[13:19] <wgrant> But I'm reluctant to hardcode a list of tuples :)
[13:19] <pitti> it should be ok to take any pot in that list
[13:19] <pitti> wgrant: yeah, please let's not do that
[13:19] <wgrant> pitti: I don't think that's safe.
[13:19] <wgrant> But I'd need to check
[13:19] <wgrant> eg. it's very plausible to have src/foo.pot and doc/foo.pot
[13:20] <pitti> wgrant: no, that'd be utterly wrong
[13:20] <pitti> a POT file name must be called like the translation domain
[13:20] <dpm> indeed, that'd rather be src/foo.pot and doc/foobar.pot
[13:21] <zul> doko: python-oslo.i18n is in main, but python3-oslo.i18n is in universe
[13:21] <wgrant> Perhaps.
[13:21] <wgrant> It then becomes unclear how to autoapprove the POs.
[13:22] <wgrant> The POT filenames may be the same, but we rely on the template path to work out where various translation paths belong.
[13:22] <pitti> ah, that's right
[13:23] <doko> zul, hmm, no, it is in main, but still wants to demote ...
[13:24] <zul> doko: i can disable snmp4 in ceilometer its not a hard dependency
[13:24] <zbenjamin> jdstrand: ok, and for scopes? for them no TMPDIR is set
[13:26] <jdstrand> zbenjamin: you have a choice: @{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}/ or /run/user/[0-9]*/scopes/leaf-net/@{APP_PKGNAME}_@{APP_APPNAME}/
[13:27] <jdstrand> APP_PKGNAME is the "name" field in the click manifest. APP_APPNAME is the key in the hooks database
[13:28] <zbenjamin> jdstrand: ok, atm i derive those values from the appid in confinement. Is there a better way?
[13:28] <jdstrand> zbenjamin: note, we wanted TMPDIR set for scopes (see bug 1327426) but the scopes team disagreed
[13:29] <jdstrand> zbenjamin: just chop of _$version
[13:29] <jdstrand> off*
[13:29] <jdstrand> APP_ID is ${APP_PKGNAME}_${APP_APPNAME}_${APP_VERSION}
[13:29] <zbenjamin> jdstrand: yeah thats what i do,  for scopes _$version is not defined
[13:30] <zbenjamin> jdstrand: also not APP_ID btw ;)
[13:30] <zbenjamin> i had to pass it as a argument to the script
[13:30] <jdstrand> right, they are for some reason fundamentally opposed to env variables
[13:31] <zbenjamin> jdstrand: yeah afaik they derive the appid from the ini file name
[13:31] <doko> zul, it's not oslo.config, but oslo.utils
[13:31] <jdstrand> and they have an api for writable dirs that scopes use
[13:32] <doko> new b-d of heat
[13:32] <doko> no, keystone. heat needs python-saharaclient
[13:32] <zul> doko: ah ok
[13:33] <nik90> stgraber: ping (lxc)
[13:33] <zul> doko: can you open up a bug ill get to that today
[13:33] <doko> zul: the pysnmp4 MIR's are assigned to jdstrand. so maybe make up your mind before he starts working on these
[13:33] <zul> doko: yeah
[13:33] <zbenjamin> jdstrand: btw how is fat packaging supposed to work for scopes? they don't use the gnutriplet in the path to their libs afaik
[13:34] <jdstrand> zbenjamin: I thought the agreed to updating LD_LIBRARY_PATH. you might ask michi
[13:35] <jdstrand> they*
[13:36] <zbenjamin> jdstrand: hm thats how the current template for scopes creates the click package tree http://pastebin.ubuntu.com/8309447/
[13:37] <jdstrand> they may not suppot fat packages
[13:37]  * jdstrand doesn't know
[13:37] <hallyn> pitti: doko: it might be best to keep cgroup-lite in main for now.  i don't know how heavily libvirt's cgmanager patch (which is out-of-tree) has been tested.  i use it here with no problems, but ...
[13:37] <infinity> doko: Oh, you were pinging people about firefox on arm64/ppc64el last night, so I got grumpy and fixed it.
[13:37] <jdstrand> I filed that bug in an effort to get various env vars set for developers, etc
[13:38] <pitti> hallyn: so apparently it doesn't depend on/recommend cgroup-lite then?
[13:38] <tedg> slangasek, i can haz systemd-shim 8 ?
[13:39] <zbenjamin> jdstrand: ok thx for the infos :)
[13:41] <LocutusOfBorg1> can anybody please move insighttoolkit4 to release? needs a couple of rebuilds
[13:42] <pitti> skipped: insighttoolkit4 (0 <- 24)
[13:42] <pitti>     got: 58+0: i-58
[13:42] <pitti>     * i386: nifti2dicom, plastimatch, qnifti2dicom
[13:42] <pitti> LocutusOfBorg1: ^
[13:43] <pitti> LocutusOfBorg1: we can't (well, "won't") manually move it to release, the transition needs to be finished in -proposed first (then it'll go in automatically)
[13:45] <LocutusOfBorg1> isn't this what I asked? :)
[13:45] <hallyn> pitti: libvirt-bin should depend on cgmanager | cgroup-lite
[13:46] <LocutusOfBorg1> I meant a couple of rebuilds in proposed and than will move automagically to release, or not?
[13:46] <pitti> hallyn: ah, and since cgmanager is in main and the prefrerred dep, it would never actually install cgroup-lite
[13:46] <hallyn> docker depends on cgroup-lite, but it's in universe.  so technically cgroup-lite can be pulled out of main
[13:46] <hallyn> right
[13:49] <mlankhorst> is it ok to start uploading other packages depending on the new xorg-server with forced dep-wait?
[13:49] <mlankhorst> going to be a lot of packages
[14:07] <doko> hallyn, can you seed it please?
[14:13] <hallyn> doko: assuming i have the perms, i can look into it.  (i think i've got notes from 2 years ago sitting around)  you mean pull cgroup-lite out of the server seed?
[14:13] <doko> pitti, Riddell, ScottK: please could you have a look at the phonon autopkg test failures. this looks "shellish" too ...
[14:13] <doko> hallyn, not out of, but maybe into?
[14:14] <pitti> doko: phonon doesn't seem to have any tests in the first place?
[14:14] <pitti> doko: oh, you mean its rdeps
[14:14] <doko> pitti: but it triggers ...
[14:15] <hallyn> hmm
[14:15] <pitti> kscd succeeded this morning, now fails again on real test failures (not the ".shell not found)
[14:15] <pitti> I'll retry that one
[14:16] <pitti> eh, WTH
[14:17] <hallyn> doko: thinking a bit, i think it's better it be dropped
[14:20] <doko> hallyn, ok, done
[14:20] <pitti> doko: yes, putting on my list
[14:22] <mlankhorst> ok inc :-)
[14:27] <stgraber> nik90: pong
[14:28] <hallyn> doko: thanks
[14:28] <nik90> stgraber: hey I just created my first unpriveldges container after following your tutorial. When I run lxc-ls -f it shows the ip4 address which in your blog post is unknown
[14:28] <nik90> stgraber: is my container still running as unpriveldged?
[14:29] <nik90> I am not running lxc-create as root,
[14:29] <stgraber> nik90: yes, it took us a while to get IP addresses from unprivileged containers but LXC 1.0 does support it and so it's normal you see it now
[14:30] <nik90> stgraber: when running unprivileged, would my container still be able to access a nexus 4 device that I attach to the host?
[14:31] <stgraber> if you want to make sure your container is unprivileged, you can confirm with something like "ps u $(lxc-info -n container-name -p -H)" which will show you the uid your container is running as in the first column
[14:31] <nik90> stgraber: my goal here is run qtcreator (for ubuntu touch apps development) and use the lxc container to avoid overhead of a vm
[14:31] <nik90> ah ok
[14:32] <stgraber> nik90: it's certainly possible to make it work but it will need some creative configuration I suspect
[14:32] <nik90> stgraber: the n4 device part will be tricky? or just running qtcreator itself?
[14:35] <nik90> stgraber: I will follow your approach that you mentioned for running skype and see if that also works for qtc since both are qt based apps
[14:35] <nik90> stgraber: and see where I get from there
[14:35] <stgraber> nik90: so if you run qtcreator as your own user (with a straight uid/gid mapping for that one as I do in my chrome blog post) then all you should need is "lxc.mount.entry = /dev/usb dev/usb none bind,create=dir" in your container config
[14:36] <stgraber> so if uid 1000 in the container == uid 1000 outside of it (through the special mapping), then the user running qtcreator in the container will also have access to the /dev/usb/ entry for the adb device and will be allowed to connect just fine
[14:36] <nik90> stgraber: ah cool
[14:37] <nik90> stgraber: Does the uid of the host user change on reboot or something?
[14:37] <nik90> stgraber: I just checked that my user uid, gid is 1000
[14:37] <nik90> if it doesn't change, then this should all be a one-time configuration
[14:38] <stgraber> nik90: nope, it's constant, otherwise file ownership would be a mess :)
[14:39] <stgraber> nik90: the only case you'd care about doing something a bit more generic is if you plan on sharing this with other people as if they have multiple users on their system, their own user may be 1001 or something
[14:39] <nik90> stgraber: sry, all I am doing atm is following your blog post commands while trying to understand bits of this. ;)
[14:39] <nik90> stgraber: understood
[14:42] <mterry> barry, you broke my nose2 page...  The LP page for nose2 now gives me timeouts ever since you added a team!
[14:43] <barry> mterry: sweet!
[14:43] <mterry> barry, so while I can't verify what you did, I'll trust that you did it
[14:43] <barry> :)
[14:46] <cjwatson> doko: libparted-i18n, gfxboot-themes> fine
[14:47] <cjwatson> mvo: hm, maybe s/minimal/required/ for that then
[14:47] <doko> denoted
[14:47] <mvo> cjwatson: thanks for the hint, let me try that
[14:47] <cjwatson> mvo: or actually, how about s/minimal/build-essential/ ?
[14:47] <mvo> cjwatson: !!!
[14:49] <cjwatson> mvo: feels like a slightly better fit given that we have --variant=buildd
[14:49] <mvo> cjwatson: yeah, it will simplify the chroot generation code even further
[14:50] <mvo> cjwatson: I test the changes now :)
[14:50] <zbenjamin> jdstrand: quick question, can a confined app conntect to any session dbus interface?
[14:51] <jdstrand> zbenjamin: it can connect to the session bus. it may or may not be able to talk to services on the session bus (depending on the service)
[14:51] <zbenjamin> jdstrand: lets say i export a interface from the launcher (it would make it more reliable to get the configuration into the helper script)
[14:52] <jdstrand> that would not be allowed
[14:52] <zul> doko: ping
[14:52] <zbenjamin> jdstrand: ok thanks
[14:52] <jdstrand> that interface could be added to the debug policygroup
[14:52] <jdstrand> zbenjamin: ^
[14:53] <doko> zul, just jump on
[14:53] <zul> doko: there was an MIR for python-oslo.i18n already LP: #1349497
[14:54] <zbenjamin> jdstrand: nah, it seems to work fine now, as long as my confinement tests don't return different values in the 2 scripts it should be fine.
[14:54] <cjwatson> doko: python-oslo.i18n - you did change-override wrong, you overrode just the binaries and not the source
[14:54] <cjwatson> doko: -S when processing MIRs, please
[14:55] <doko> cjwatson, oops
[14:57] <doko> cjwatson, did you fix, or should I?
[14:58] <cjwatson> doko: I did not
[14:58] <doko> ok, will do
[14:59] <zul> doko: can you double check python-osprofiler and python-rfc6839 while you are at it
[15:01] <doko> zul: have a look at the commit message
[15:01] <doko> they are in main
[15:01] <zul> doko: cool thanks
[15:04] <mvo> cjwatson: one more question - right now we install ubuntu-ui-toolkit-doc in the click chroot, is that something we want to do or could we drop it, it feels a bit out of place
[15:07] <hallyn> slangasek: regarding bug 1355966, should i mark it as also afecting cgmanager, or file a new FFE for cgmanager?
[15:08] <cjwatson> mvo: bzoltan explicitly asked for that, I think so that the SDK can show matching docs
[15:08] <hallyn> since FFE was granted for systemd-shim i'd feel guilty usurping that for cgmanager, but as systemd-shim will block on cgmanager...
[15:08] <mvo> cjwatson: ok, thanks! does it feel cleaner to you to add it to the ubuntu-sdk-libs-dev or have it as a special case in chroot.py - I lean toward the later
[15:09] <cjwatson> mvo: marginally prefer the former but your call
[15:09] <mvo> cjwatson: heh :) totally fine as I did it this way but had second thoughts :)
[15:12] <roaksoax> is it safe to put stuff like "find /var/log/maas -not -user syslog -print0" in postinst scripts?
[15:17] <slangasek> hallyn: did you want to merge cgmanager into utopic or should I?  And does system-shim 8 need a versioned dependency on cgmanager 0.32 for any reason?
[15:17] <hallyn> systemd-shim needs a versioned dep, yes.
[15:17] <hallyn> the binary will refuse to run without cgmanager api version 8 anyway
[15:17] <slangasek> hallyn: bug #1355966> feel free to mark it as also affecting cgmanager
[15:17] <desrt> slangasek: we're using the new Prune and GetTasksRecursive APIs
[15:17] <slangasek> ack
[15:17] <zul> doko,  python-oslo.utils should be ok now correct?
[15:18] <desrt> should have pointed that out louder in the NEWS -- sorry
[15:18] <zul> doko: also just subscribed server team to python-oslo.utils\
[15:18] <hallyn> slangasek: ok, marked it affecting cgmanager;  all the ubuntu delta is obsolete so a straight syncpackage is fine
[15:19] <slangasek> hallyn: ok; are you doing that sync?
[15:19] <hallyn> sure, doing it now
[15:19] <slangasek> cheesr
[15:43] <doko> zul, afk now.
[15:44] <doko> zul, stevedore: unsatisfied dependencies, please drop the python*-argparse deps
[15:44] <zul> doko: k
[16:22] <slangasek> desrt, hallyn: systemd-shim 8-1 accepted into Debian unstable
[16:22] <desrt> nice!
[16:23] <desrt> i tried extra hard to make sure this one doesn't have any root exploits
[16:23] <hallyn> warm fuzzies - they elude me
[16:23] <slangasek> did that trying include asking the security team for review? :)
[16:24] <desrt> slangasek: yes.  precisely.
[16:24] <slangasek> ok
[16:24] <desrt> policy says that systemd-shim only takes messages from already-root users anyway though, right?
[17:02] <slangasek> pitti: do you understand this adt failure?  it seems to be having parsing problems with files that haven't changed: https://jenkins.qa.ubuntu.com/job/utopic-adt-systemd-shim/28/ARCH=amd64,label=adt/console
[21:10] <Noskcaj> Laney, Could you please refresh lp:~laney/ubuntu-system-settings/upower0.99
[23:18] <hallyn> slangasek: i've got a bit of a bugfix for cgmangaer for debian to queue up :(  not must-be-tonight urgent, but anyone using gettaskrecursive (which systemd-shim now uses) inside a container will cause cgmanager to restart
[23:19] <hallyn> (sigh) i'd say i'll push it in 2 minutes, but my downloads from archive.* seem to be constantly hanging today.  some net neutrality thing?
[23:21] <hallyn> hm, is it ipv6 messing me up?
[23:24] <hallyn> slangasek: cgmanager_0.32-2_source.changes pushed to mentors
[23:33] <hallyn> d'oh, another one
[23:34] <slangasek> another?
[23:35] <slangasek> hallyn: as in, another upload pending?
[23:35] <hallyn> slangasek: yeah, fraid so.  i will push in 2 hours
[23:35] <slangasek> ok
[23:36] <slangasek> so shall I hold off?
[23:36] <hallyn> slangasek: the other one won't break anything, so pushing now might be ok
[23:36] <hallyn> but holding off should be fine too, i dont' expect anyone to hit this.
[23:36] <hallyn> (sorry, being pulled away - bbl)