=== _salem is now known as salem_
=== ming is now known as Guest12249
=== beisner- is now known as beisner
=== FJKong is now known as FJKong_lunch
[04:57] <pitti> hallyn: thanks for teh lxc patch reviews; for those which you "acked-by"'ed, is there anything further for me to do, or will you just git am them to trunk? (they don't have particular dependencies on each other)
=== JanC_ is now known as JanC
=== salem_ is now known as _salem
=== FJKong_lunch is now known as FJKong
[05:48] <pitti> hallyn: cgmanager uploaded to Debian, thanks! But I have a question about integrating the remaining Ubuntu delta in https://mentors.debian.net/package/cgmanager
[05:52] <pitti> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
[05:53] <pitti> halfie: I also uploaded an Ubuntu merge
[05:54] <pitti> halfie: sorry, tab error; I meant hallyn
=== doko_ is now known as doko
[06:36] <dholbach> good morning
[06:37] <ptman> Hi! Is there a reason why http://changelogs.ubuntu.com/meta-release-lts doesn't advertise trusty? I thought do-release-upgrade should suggest trusty after 14.04.1 is released
[06:37] <ptman> I can't view the bug reports related to https://code.launchpad.net/~ubuntu-core-dev/meta-release/ubuntu
[06:37] <sarnold> ptman: I heard there was a pretty severe upgrade bug ...
[06:37] <pitti> hey dholbach
[06:38] <pitti> infinity: does this make sense? https://code.launchpad.net/~braiampe/ubuntu/trusty/overlay-scrollbar/fix-for-1262022/+merge/218899
[06:38] <ptman> sarnold, that would be a valid reason. Where should I be able to find out more?
[06:38] <pitti> infinity: i. e. does an Arch: all package really need to be marked as M-A: foreign to satisfy non-native arch dependencies?
[06:38] <pitti> infinity: that sounds wrong for arch: all, that should be implicit?
[06:38] <dholbach> hey pitti
[06:38] <sarnold> ptman: hmmm, this says 'fix released', maybe this wasn't the reason after all: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1347964
[06:39] <ubottu> Ubuntu bug 1347964 in ubuntu-release-upgrader (Ubuntu Trusty) "Precise w/Trusty HWE -> Trusty release upgrade fails : ubuntu-desktop fails to configure" [High,Fix released]
[06:39] <dholbach> Noskcaj, looks like doko fixed jquery
[06:39] <dholbach> Noskcaj, did you have a chance to look at python-wsme or libgtop2?
[07:07] <Tribaal> Hi all, silly question - my updated pacakge was pushed into trusty-proposed a while back (good), but I don't understand what it takes to land in the "real" archives. Could somebody shed light on the process?
[07:08] <sarnold> Tribaal: you might find it on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[07:08] <Tribaal> sarnold: nope, not on there
[07:09] <sarnold> oh, trusty, not utopic.. probably wrong place..
[07:09] <RAOF> Tribaal: It needs to be tested to work, marked as such, and then one of the SRU team will release it on the regular sweeps.
[07:09] <Tribaal> oh no sorry
[07:09]  * Tribaal blames coffee
[07:10] <Tribaal> I tested trusty, but it should have landed in *utopic*
[07:10] <Tribaal> nevermind :/
[07:22] <LocutusOfBorg1> pitti,
[07:22] <LocutusOfBorg1> sorry for bothering
[07:22] <pitti> hey LocutusOfBorg1
[07:22] <Tribaal> RAOF: so, it might actually make sense to backport the package that is in utopic now to trusty. Where should I start for an SRU?
[07:22] <LocutusOfBorg1> Hi, did you notice the build failure of libvncserver?
[07:22] <RAOF> Tribaal: https://wiki.ubuntu.com/StableReleaseUpdates ?
[07:22] <LocutusOfBorg1> thanks for the other merges BTW
[07:23] <pitti> LocutusOfBorg1: err yes, just saw the FTBFS mail coming in; apparently some uninstallability in -proposed?
[07:23] <Tribaal> RAOF: thanks :)
[07:23] <LocutusOfBorg1> pitti, the new package build-conflicts with libpng12
[07:23] <LocutusOfBorg1> because it wrongly links png stuff when available
[07:24] <LocutusOfBorg1> the problem is that I cannot reproduce on a clean pbuilder-dist utopic environment
[07:24] <Tribaal> ah, maybe I should target trusty-proposed instead
[07:24]  * Tribaal is a bit confused as to where the bits should ideally go
[07:24] <LocutusOfBorg1> BTW I don't know why the hell the debian people but a build conflict on png instead of a simple "--without-png" in rules
[07:25] <pitti> LocutusOfBorg1: so perhaps we should do that ^ ?
[07:26] <LocutusOfBorg1> don't know pitti
[07:26] <LocutusOfBorg1> I should talk with jcristau and luca about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725480
[07:26] <ubottu> Debian bug 725480 in libvncserver "libvncserver: don't link against libpng" [Normal,Fixed]
[07:27] <LocutusOfBorg1> I'm working on the package, will report back
[07:28] <pitti> LocutusOfBorg1: right, so if there's a --without-png and that works, that seems better than a build-conflicts
[07:28] <pitti> LocutusOfBorg1: cheers!
[07:28] <pitti> LocutusOfBorg1: should be easy to check, it shouldn't generate a libpng dependency
[07:29] <LocutusOfBorg1> yes I'm already doing that ;)
[07:29] <LocutusOfBorg1> I removed the conflict, rebuilding
[07:31] <LocutusOfBorg1> yes, ldd shows a libjpeg
[07:31] <LocutusOfBorg1> rebuilding with the autoconf flag
[07:32] <Tribaal> RAOF: so apparently an SRU is not what is appropriate in this case. Is it possible to put a package in -proposed instead? What is the policy there? (Sorry, I'm a new contributor as you can tell)
[07:33] <RAOF> Tribaal: -proposed is the staging ground that we test things to go into -updates. You might be looking for backports?
[07:33] <Tribaal> RAOF: ah, yes, probably
[07:53] <infinity> pitti: It's not implicit for arch:all, no.  arch:all is implicitly mapped to the native arch for sane backward compatibility.
[07:53] <pitti> infinity: hm; strange; why wouldn't it satisfy a dependency of e. g. an :i386 on amd64 to an arch:all package?
[07:53] <pitti> it seems weird having to change all arch:all packages for that
[07:54] <infinity> pitti: There were Good Reasons, but I can't think of that they are right now.
[07:54] <infinity> pitti: slangasek probably remembers better, he drove a lot of this.
[07:55] <pitti> infinity: ok, thanks; so this is good to sponsor (to utopic for now)
[07:56] <infinity> pitti: I didn't read the MP, but if the reasoning otherwise makes sense, and the syntax is correct, sure.  If there's an all->any->all sort of chain in play, one needs to make sure that whatever combinations can be installed will actually make sense and work.
[07:56] <pitti> ah, https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages
[07:58] <pitti> infinity: argh, can't sponsor; daily PS landing..
[08:07] <Noskcaj> dholbach, I can't get wsme to work locally still, and i think it's best to wait for debian for libgtop2
[08:07] <dholbach> Noskcaj, can't get to work in which way?
[08:23] <Noskcaj> dholbach, http://paste.ubuntu.com/7921912/
=== popey_ is now known as popey
[08:25] <dholbach> Noskcaj, as I said yesterday: install all the build deps first, then start with -3 - it should work
[08:25] <dholbach> if you don't have the build-deps, it'll try to download them
[08:25] <dholbach> which will then look like a diff to be applied
=== zdoch is now known as lubko
[08:58] <Laney> pitti: hey, can you moderate u-d-a?
[08:58] <pitti> Laney: doing
[08:58] <doko> ricotz, https://launchpad.net/ubuntu/+source/cogl/1.18.2-1/+build/6176965 please fix, this is a regression, please use dh-autoreconf
[08:59] <pitti> Laney: congrats for alpha-2!
[08:59] <Laney> cheers
[08:59] <Laney> I hacked $TZ to make it happen on the correct day. ;-)
[09:03] <doko> LocutusOfBorg1, libvncserver ftbfs on all archs
[09:03] <pitti> see IRC scrollback 1.5 hours ago, he's on it
[09:05] <pitti> Laney: yup, blame it on me for slow moderation :)
[09:05] <LocutusOfBorg1> doko, ready above
[09:05] <LocutusOfBorg1> :)
[09:06] <LocutusOfBorg1> s/ready/read
[09:06] <doko> ahh, thanks
[09:08] <LocutusOfBorg1> I subscribed you to lp 1349386
[09:08] <ubottu> Launchpad bug 1349386 in libvncserver (Ubuntu) "please merge libvncserver from debian" [Undecided,Fix committed] https://launchpad.net/bugs/1349386
[09:08] <LocutusOfBorg1> since it is your patch :)
[09:08] <LocutusOfBorg1> you can still take the first one and upload if you care ;)
[09:09] <LocutusOfBorg1> there is also a git commit waiting for upload on debian, so maybe fixing first there is better, but I don't know, it is up to you
[09:09] <pitti> LocutusOfBorg1: ah, https://bugs.launchpad.net/ubuntu/+source/libvncserver/+bug/1349386/comments/6 looks good, thanks; will upload
[09:09] <ubottu> Ubuntu bug 1349386 in libvncserver (Ubuntu) "please merge libvncserver from debian" [Undecided,Fix committed]
[09:09] <pitti> LocutusOfBorg1: we can still sync later (much appreciated)
[09:10] <pitti> LocutusOfBorg1: err, shouldn't --without-png be appended to dh_auto_configure insted of to dh?
[09:11]  * pitti does that
[09:14] <pitti> LocutusOfBorg1: uploaded with that change, thanks!
[09:17] <LocutusOfBorg1> yes pitti that was a mistake
[09:17] <LocutusOfBorg1> damn copy paste
[09:30] <doko> pitti, this test result looks ok to me: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-gem2deb/ARCH=amd64,label=adt/
[09:31] <pitti> doko: it's timing out; supposedly the new version is trying to download something from the network, or is just stuck in an infinite loop or something?
[09:31] <pitti> doko: the unit tests succeeded, but the first integration test is stuck
[09:32]  * pitti runs it locally
[09:34] <pitti> doko: works locally, so I suppose it's trying to download stuff from the internet?
[09:45] <doko> ahh
[09:45] <doko> well, it's gem2deb ...
[09:53] <doko> mitya57, want to have a look at a sphinx issue? https://launchpad.net/ubuntu/+source/heat/2014.2~b2-0ubuntu1/+build/6212253
=== ikonia_ is now known as ikonia
[10:20] <pitti> stgraber: I have a question for you in bug 1346734
[10:20] <ubottu> bug 1346734 in systemd (Ubuntu) "Unprivileged LXC containers don't work under systemd" [Undecided,Triaged] https://launchpad.net/bugs/1346734
[10:25] <darkxst> pitti, hey, what are the systemd plans for this cycle? sticking with 208?
[10:27] <pitti> darkxst: no, I hope 214 will land soon in Debian, then I'll update Ubuntu too
[10:27] <pitti> darkxst: but I want to stay in sync with Debian
[10:27] <pitti> i. e. same version (not literally the same source package)
[10:34] <darkxst> pitti, ok that would be good, can't build any gnome until we have 210+
[10:34] <darkxst> I fear everything is just broken again now ;(
[10:35] <darkxst> pitti, though I did have 214 running from unit's packages, its pretty broken since the cgmanager/shim changes landed
=== vila is now known as vila-lunch
=== MacSlow is now known as MacSlow|lunch
=== vila-lunch is now known as vila
[11:30] <pitti> darkxst: oh, how's that?
[11:30] <pitti> darkxst: 208 and 214 shouldn't be fundamentally different wrt. cgroups handling?
[11:31] <darkxst> pitti, I see lots of cgroups failed, file not found messages
[11:31] <darkxst> and drm fails
[11:31] <darkxst> lightdm loads, but not mouse/keyboard ;(
[11:31] <pitti> darkxst: oh, wait -- you probably still have cgmanager 0.27-0ubuntu8
[11:32] <pitti> darkxst: try 0.28-3ubuntu1 (landed in utopic today)
[11:32] <pitti> darkxst: that stops running cgmanager under systemd (indeed they fight)
[11:32] <darkxst> pitti, could be mirror lag
[11:33] <pitti> darkxst: yes, it really was just a few hours ago
[11:33] <pitti> darkxst: in the meantime, try if "sudo /etc/init.d/cgmanager stop" helps
[11:33] <pitti> darkxst: that's needed for e. g. making LXC work, too
[11:34] <darkxst> pitti, I can't even get to a working VT or ssh
[11:34] <pitti> darkxst: hmm; that sounds more like the symptom of having systemd 204 with cgmanager
[11:34] <pitti> i. e. bug 1342586
[11:34] <ubottu> bug 1342586 in systemd (Ubuntu) "[utopic] [proposed] cgmanager breaks lightdm login" [High,Fix released] https://launchpad.net/bugs/1342586
[11:34] <darkxst> pitti, no 204
[11:35] <darkxst> 208 works, 214 breaks
[11:35] <darkxst> I see cgmanager update on mirror now, will try that
[11:38] <darkxst> pitti, boom! I am in ;)
[11:38] <pitti> darkxst: \o/
[12:10] <pitti> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[12:42] <didrocks> stupid question, but with a local sbuild installation, is there any hook to log inside the chroot on build failure?
[12:43] <didrocks> google isn't my friend :/
[12:43] <xnox> didrocks: yes.
[12:43] <xnox> didrocks: you can set the option to preserve chroot session on build failures, and then use schroot to enter that session id
[12:44] <didrocks> xnox: that would be perfect! do you have a handy pointer to that option?
[12:44] <xnox> didrocks:        --purge-session=purge-mode
[12:44] <xnox>               Purge the schroot session following a build.  This is useful in conjunction with the --purge-build and --purge-deps options when using snapshot chroots, since
[12:44] <xnox>               by default the snapshot will be deleted.  Possible values are always (default), never, and successful.
[12:44] <xnox> didrocks: so i think you want "--purge-session=successful", and then list sessions in chroot (and or look up the session UUID from the failed buildlog) and enter it with schroot.
[12:45] <didrocks> xnox: let give me it a try :)
[12:45]  * xnox assumes you are using snapshots of some kind (overlayfs, lvm, btrfs...)
[12:45] <didrocks> yep
[12:46] <xnox> barry`: i've re-ported lazr.authentication to python3, cause i didn't notice your port. I think it's mostly equivalent, apart from your port being more resiliant to accepting either bytes or strings in the middleware.
[12:48] <xnox> barry`: or maybe not, cause e.g. i think autorization header is always string, yet in your code it's assumed to be bytes. Not sure.
[12:48] <xnox> barry`: and i wouldn't want distribute to be commited =)
[12:50] <didrocks> xnox: looking good! thanks a bunch :)
[12:56] <pitti> infinity: I'm stunned by bug 1351295 -- I can't see how this makes sense; does that ring a bell per chance?
[12:56] <ubottu> bug 1351295 in initramfs-tools (Ubuntu) "Boot fails if /sbin/init is an absolute symlink" [Undecided,In progress] https://launchpad.net/bugs/1351295
=== _salem is now known as salem_
[13:07]  * dholbach hugs pitti
[13:07]  * pitti hugs dholback
[13:28] <stgraber> pitti: hi
[13:28] <pitti> salut stgraber, ça va ?
[13:28] <stgraber> pitti: oui, très bien et toi?
[13:28] <pitti> stgraber: je vais bien aussi, merci; mais j'attends avec impatience le week-end :)
[13:29] <stgraber> :)
[13:29] <highvoltage> bon week-end à tous
[13:31] <pitti> stgraber: so I have a question for you in bug 1346734
[13:31] <ubottu> bug 1346734 in systemd (Ubuntu) "Unprivileged LXC containers don't work under systemd" [Undecided,Triaged] https://launchpad.net/bugs/1346734
[13:35] <hallyn> pitti: stgraber normally applies the patchset after it's fully acked.
[13:35] <pitti> hallyn: ah, thanks; so nothing left to do for me for those
[13:35] <pitti> hallyn: I sent a fixed patch for the missing "git add", and had some questions about the first one
[13:36] <stgraber> pitti: ah right, I saw your patches but since hallyn asked for some changes I didn't push them yet. I'll look at the mailing-list in a bit and process what's there.
[13:37] <stgraber> pitti: I also plan to tag alpha2 early next week (Monday or Tuesday) so unless you're in a big hurry, you'll get the change in the distro then
[13:37] <pitti> stgraber: that sounds perfect
[13:37] <pitti> stgraber: there's still bug 1350947 (but that has an easy workaround) anyway
[13:37] <ubottu> bug 1350947 in lxc (Ubuntu) "apparmor: no working rule to allow making a mount private" [Undecided,Triaged] https://launchpad.net/bugs/1350947
[13:37] <pitti> stgraber: but I'm not in such a hurry; I have my changes to trunk installed locally, so I'm a happy camper :)
[13:40] <hallyn> yeah that one has to wait on apparmor iiuc right?
[13:41] <pitti> hallyn: not sure whether it's in the parser (appamor) or in the kernel, but either way; jjohansen kindly said he'd look into it
[13:41] <pitti> hallyn: but for testing it's an one-line addition to the policy (I put the workaround in the bug)
[13:41] <hallyn> pitti: reagrding the apparmor load patch,
[13:41] <pitti> so doesn't block development/testing
[13:42] <pitti> hallyn: btw, new cgmanager working well; you also made darkxst happy :)
[13:42] <hallyn> hm, i guess it's ok.  it'll just do nothing if that prog doesn't exist
[13:42] <hallyn> pitti: I don't know who that is, but thanks :)
[13:42] <pitti> hallyn: ah, if you want to keep that in the distro for now, that's ok for me
[13:42] <hallyn> no, it' sok, i just wanted to make sure it won't break fedora etc
[13:42] <pitti> hallyn: once we have systemd 210+, we can probably just replace that with an ApparmorProfile= in the .service
[13:43] <pitti> hallyn: there's probably a more elegant way for Fedora ^
[13:43] <hallyn> 210+ has apparmor suport built-in?
[13:43] <pitti> yes, apparently
[13:43] <pitti> profile loading
[13:44] <pitti> hallyn: but anyway, it's all protected by test's, and no apparmor (by default at least) on Fedora, so I believe it should be reasonably safe
[13:46] <hallyn> so i'm back on my 4 year old sony.  it's like an old, i dunno, what do you put on, an old shoe?  and old glove?  my idioms fail me
[13:47] <stgraber> pitti: can you send your sign-off for the batch?
[13:47] <stgraber> (unless I missed it)
[13:48] <mdeslaur> pitti, hallyn: systemd only has profile _switching_, not loading...we need to create a proper apparmor parser library so we can get systemd to load apparmor profiles properly at boot
[13:49] <michagogo> pitti: thanks!
[13:49] <xnox> mdeslaur: and upstart?
[13:49] <xnox> mdeslaur: is that switching only as well?
[13:49] <mdeslaur> xnox: upstart has loading, and switching
[13:50] <xnox> mdeslaur: excellent. I wonder if I can do archive wide massacare of /lib/init/apparmor-profile-load usage
[13:50] <xnox> =)
[13:50] <mdeslaur> xnox: but we call the parser in upstart, and it was made clear on the systemd list that we shouldn't do that, but link to a library
[13:50] <hallyn> mdeslaur: and does someone have time to do that?
[13:50] <pitti> stgraber: you mean self sign-off all the patches and re-send them all?
[13:51] <pitti> mdeslaur: ah, thanks; so we'll still need that script
[13:51] <mdeslaur> hallyn: we know we need to do it soon...it's planned, we just haven't gotten to it yet
[13:51] <pitti> michagogo: err - you're welcome (for whatever :) )
[13:52] <michagogo> pitti: 1314616
[13:55] <stgraber> pitti: or just reply to Serge's last e-mail asking for a single sign-off for the whole series
[13:55] <pitti> michagogo: ah :)
[13:56] <pitti> stgraber: ok; I never understood the purpose of Author: having to sign off himself, but sure :)
[13:56] <xnox> pitti: it's a declaration that you own copyright, and/or have appropriate permission to open source it.
[13:56] <stgraber> pitti: it means that you confirm you have the right to give that to the project (as in, your employer allows you to)
[13:56] <xnox> *snap* =)
[13:57] <pitti> I'm sure sabdfl doesn't mind me contributing to LXC :)
[13:58] <xnox> pitti: without consulting colicitor first?! =)))))) https://code.launchpad.net/~harmoney/upstart/manpage-fixes/+merge/20878
[13:59] <xnox> ( i loved that merge proposal comments )
[14:04] <pitti> hallyn: replied to both now
[14:04] <pitti> xnox: colic.. WHAT? get a room!
[14:04]  * pitti hugs xnox, TGIF
[14:05] <pitti> xnox: oh argh; yay bureaucracy
[14:05] <xnox> pitti: i mean a lawyer =)
[14:05] <xnox> pitti: TGIF - T.G.I. Friday's?!
[14:06] <xnox> pitti: re: systemd-sysv, can't it just install real files and do dpkg-divert and not conflict with upstart?
[14:06] <pitti> hallyn: ooh, sorry, I understand now
[14:06] <xnox> pitti: imho, at the moment we want to be able to install systemd-sysv and be able to uninstall it to go back to upstart.
[14:06] <pitti> hallyn: git-email converts Author: to the email From:; I'm too used to attaching patches to mails, instead of sending ptaches *as* mails
[14:07] <pitti> see, I can even learn stuff on a Friday afternoon!
[14:07]  * pitti needs an ice cream now to cool down his brain after this enormous exercise (and also go for some errands)
[14:08] <xnox> pitti: as i new comer to VCS systems - git was my first one ever. And it all made sense until I was asked to setup mta for the first time and somehow learn that the "format-patch" thing it generates doubles up as an email was a complete mystery to me.
[14:09] <pitti> wow, you are young!
=== manjo` is now known as manjo
[14:13] <hallyn> heh
[14:15] <hallyn> pitti: regarding full paths, my point was precisely that by pulling a part of the init script into a script elsewhere on the system, you're encouraging use by something other init, where paths are *not* sanitized.
[14:16] <hallyn> of course all setuid-root binaries *should* be sanitiziing paths, but this is a favorite exploit in capture-the-flag contests at least :)
[14:26] <tseliot> pitti: thinking of nvidia-persistenced, I think I've found a udev rule that could work to start the nvidia-persistenced daemon. I also have to stop the daemon using udev. Is there a recommended way to do it?
=== barry` is now known as barry_
=== barry_ is now known as barry
[14:45] <barry> bdmurray: ping me when you're online
[14:47] <bdmurray> barry: I'm online
=== gaughen_ is now known as gaughen
[15:08] <tseliot> pitti: never mind, problem solved
[15:34] <jpds> $ sudo apt-get install rtpproxy
[15:34] <jpds> $ grep DAEMON /etc/init.d/rtpproxy
[15:34] <jpds> DAEMON=/usr/sbin/$NAME
[15:34] <jpds> $ ls -l /usr/sbin/rtpproxy
[15:34] <jpds> ls: cannot access /usr/sbin/rtpproxy: No such file or directory
[15:34] <jpds> Ah, quality.
[15:36] <stgraber> barry: system-image-cli is missing a depend on python3-dbus and python3-xdg
[15:38] <barry> stgraber: dang.  i think both should be added to system-image-common.  i can do that for 2.3.2 which is in the citrain now
[15:44] <stgraber> barry: do you ever still test system-image-cli without udm?
[15:44] <stgraber> barry: I'm testing an ubuntu core image with system-image and it appears to hang on downloading the indices
[15:48] <barry> stgraber: no.  it's currently non-functional without udm.  i have a stalled branch that adds an asyncio internal downloader alternative but haven't had time to finish that yet
[15:49] <barry> stgraber: and yes, there are occasional "weird" things happening with udm ;)
[15:49] <stgraber> barry: hmm, ok, it's going to become pretty critical seeing how we need this to make progress on the ubuntu core system image stuff
[15:49] <stgraber> slangasek, jodh_: ^
[15:50] <stgraber> hmm, hold on, udm is actually installed
[15:50] <stgraber> (which we probably don't want in this case, but still, things should kinda work then...)
[15:51] <slangasek> yes... using udm for server images may not make the most sense, but it should be functional for a first cut :)
[15:52] <stgraber> yeah, trying to figure out why it doesn't... no errors in the log...
[15:53] <stgraber> ok, so the target dir didn't exist (we need to set this to something else than /android/cache/recovery ...), creating it and killing udm did the trick
[15:55] <barry> stgraber: oh jeez, i just got a crash of udm doing a local test build of si 2.3.2.  this is after this morning's dist-upgrade
[15:55] <barry> so i think that's a new problem
[15:55] <barry> (existing known problems w/o resolution: it occasionally downloads files to the wrong place, and there are intermittent timeouts)
[15:56] <barry> looks like the crash was in passing a pause signal to udm
[15:56] <slangasek> pitti: fwiw these dependencies on upstart can mostly be dropped not because the packages support systemd as an alternative, but because they're versioned deps that are no-ops post-14.04
[16:24] <jcastro> is `do-release-upgrade` from 12.04 supposed to prompt for 14.04.1 yet?
[16:24] <jcastro> aka. did we flip the switch?
[16:31] <TJ-> jcastro: I think the update to meta-release-lts has been delayed by a 12.04 update-manager bug-fix in precise-proposed
[16:31] <TJ-> jcastro: Not 100% since no-one has admitted responsibility for a finger on the switch :)
[17:46] <jcastro> TJ, thanks
[18:18] <ventura> i wish to deploy deb packages to my ppa, however i need that during the install processes the 'terms of service' be displayed to the user
[18:18] <ventura> how is it done according to ubuntu policies? preinst scripts?
[18:19] <dobey> what are you packaging that would require a terms of service be displayed at install time?
[18:22] <dobey> and do you have a commercial support contract on launchpad? because its terms do not allow you to put non-redistributable software in a PPA unless you have a commercial agreement and own the rights to that software
[18:36] <ventura> for example, a oracle java 7. if i wish to create a debian package of it.
[18:36] <ventura> 1. does is respect launchpad terms?
[18:37] <rww> Oracle Java isn't allowed in Launchpad.
[18:37] <rww> Oracle changed the licensing terms, so...
[18:37] <ventura> rww: uhm
[18:38] <rww> I think webupd8 has a PPA which packages it similar to Flash where they download it from Oracle's site, though
[18:38] <rww> (i.e., there's no actual Oracle property in the PPA)
[18:39] <dobey> ventura: yeah, you can't ship the binaries, oracle's license doesn't allow redistribution
[18:40] <ventura> dobey, oracle was an example. however the point is extremely valid, thus i have to read if the terms of the binaries i wish to ship allow it too.
[18:41] <ventura> rww++
[18:41] <ventura> dobey++
[18:43] <dobey> ventura: if you don't have a commercial agreement with launchpad, and own the rights to the code, you can't put the binaries on launchpad. and there are almost no proprietary things that allow binary redistribution
=== roadmr is now known as roadmr_afk
[18:49] <dobey> if you want to make proprietary things installable, you're going to have to do it by writing an open source installer app and shipping that and/or doing an install in the same way that the flash plug-in does
[19:32] <ventura> dobey: thx
=== roadmr_afk is now known as roadmr
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[23:43] <xnox> ev: slangasek: why do we care about getting the same whoopsie id across re-installs? Full reinstall -> new encornation thus should be new id.
[23:44] <xnox> it doesn't affect any stats, as we only count active/relecently seen ids, and reinstalled machine with new id, is one for one trade.
[23:45] <xnox> we should use file cache / machine-id, and only if all fails doing the mac/imei guessing.
[23:45] <xnox> (i.e. stateless case)
[23:46] <xnox> it's not scalable that all launched emulators with same MAC and same IMEI have same whoopsie id.
[23:48] <xnox> root vs non-root user has different whoopsie ids =)
[23:51] <slangasek> xnox: we do care about being able to identify a device across reinstalls, for associating on errors.ubuntu.com
[23:51] <xnox> slangasek: no, we don't. =)
[23:51] <xnox> slangasek: i do factory reset, and sell my phone. I don't expect for new user to see my crashes =)
[23:52] <xnox> slangasek: and we have changed ID implementation at least 3 times now, and thus broke machine association.
[23:52] <xnox> (for typical machines)
[23:53] <xnox> using /etc/machine-id or even /var/lib/dbus/machine-id would have preserved association.
[23:53] <slangasek> xnox: there are reasons to prefer they not be visible, but for testing, where the device will be regularly reinstalled, not having a persistent id that they can use for locating the device is problematic
[23:54] <slangasek> now, if we were to use machine-id as the basis, maybe the answer would be for the test environment to update that id
[23:55] <xnox> slangasek: testing things should set CRASH_DB_IDENTIFIER environment variable, which can be passed e.g. on kernel command line.
[23:55] <xnox> slangasek: which overrides internal whoopsie identifier generator.
[23:55] <xnox> , if that fails and we have a machine-id, i think that should be used.
[23:55] <slangasek> editing the kernel commandline is hardly the most convenient interface on the phone
[23:56] <xnox> and only last case scenario - completly read-only stateless system -> use the generator.
[23:57] <xnox> slangasek: then we should extend both upstart and systemd units to source the /etc/default/whoopsie such that one can specify ID there.
[23:57] <xnox> slangasek: is that file RW on the phone?
[23:57] <xnox> (i'm not sure the current state of affairs around how to enable/disable it)
[23:57] <slangasek> no, it's not, and there's no particular reason to put it in that file
[23:58] <xnox> ack.
[23:58] <xnox> slangasek: well, i need to introduce a stable / persistant storage for the id, make it world readable, and make sure it's used by default.
[23:59] <slangasek> I'd rather we modify /etc/machine-id as part of the provisioning and make whoopsie honor that, than push it anywhere else
[23:59] <xnox> IMHO it's redicilous that whoopsie_identifier_generate() call is returning different value for root and non-root user.
[23:59] <slangasek> hah, does it?