[03:28] <Unit193> pitti: Up so early?
[03:28] <pitti> Good morning
[03:28] <pitti> Unit193: yeah
[03:29] <pitti> too much to do before the weekend and 3 days of holiday :)
[05:46] <rsalveti> diwic: just saw pulseaudio is getting 'permission denied' when trying to make the sink/source thread realtime (calling org.freedesktop.RealtimeKit1 - MakeThreadRealtime), is that expected?
[05:47] <rsalveti> I noticed pulse itself got a higher priority when starting
[05:47] <diwic> rsalveti, I'd say it's something that needs fixing
[05:47] <rsalveti> Jun 27 05:33:56 ubuntu-phablet pulseaudio[30497]: [pulseaudio] core-util.c: RealtimeKit worked.
[05:47] <rsalveti> Jun 27 05:33:56 ubuntu-phablet pulseaudio[30497]: [pulseaudio] core-util.c: Successfully gained nice level -11.
[05:47] <rsalveti> but can't set the thread though
[05:47] <rsalveti> right
[05:48] <rsalveti> started a few weeks ago afaik, just got time to understand the error
[05:48] <rsalveti> rtkit was upload with a newer version in may 22
[05:48] <rsalveti> *uploaded
[05:49] <diwic> rsalveti, sometimes I've seen the rtkit fail when you run PA from a terminal but succeed when you autostart it the normal way
[05:49] <rsalveti> right, in this case I'm also getting from autostart
[05:49] <diwic> rsalveti, nice level is one thing, rtprio is another - it's the rtprio we want
[05:49] <diwic> i e, SCHED_RR
[05:50] <rsalveti> yeah
[05:51] <rsalveti> the error message: 'core-util.c: Failed to acquire real-time scheduling: Permission denied'
[05:52] <diwic> rsalveti, maybe it's an apparmor related problem
[05:52] <rsalveti> yeah
[05:52] <rsalveti> can try to disable it and retry
[05:52] <jjohansen> how about checking for a denied message
[05:53] <jjohansen> rsalveti: what was the error exactly?
[05:53] <rsalveti> didn't get any denied though
[05:53] <rsalveti> in syslog
[05:54] <rsalveti> would I get that when apparmor blocks a dbus call?
[05:54] <jjohansen> rsalveti: you would it will be in /var/log/syslog
[05:54] <sarnold> rsalveti: yes, unless there is a 'deny' rule to deny an access silently
[05:54] <jjohansen> grep DENIED /var/log/syslog
[05:54] <jjohansen> true, but you can turn quieting off
[05:56] <rsalveti> no denial for it
[05:56] <rsalveti> worked fine in image 44, but that's a bit old
[05:56] <rsalveti> and with previous rtkit
[05:56] <rsalveti> Jun 27 05:55:44 ubuntu-phablet pulseaudio[2532]: [alsa-source-MultiMedia1 (*)] core-util.c: RealtimeKit worked.
[05:56] <rsalveti> Jun 27 05:55:44 ubuntu-phablet pulseaudio[2532]: [alsa-source-MultiMedia1 (*)] core-util.c: Successfully enabled SCHED_RR scheduling for thread, with priority 5.
[05:57] <jjohansen> rsalveti: well you can try disabling apparmor, or just doing /etc/apparmor.d/teardown to unload all the current profiles, so you don't have to reboot
[05:57] <rsalveti> cool, will give it a try
[05:57] <sarnold> /etc/init.d/apparmor teardown rather
[05:57] <diwic> then it's probably the new rtkit and not apparmor
[05:57] <diwic> in which case I haven't seen it (yet)
[05:57] <jjohansen> rsalveti: oops yeah what sarnold said /etc/init.d/apparmor teardown
[06:00] <rsalveti> diwic: yeah, image 44 + latest rtkit is already enough to reproduce the error
[06:00] <rsalveti> so not apparmor
[06:52] <dholbach> good morning
[07:49] <LocutusOfBorg1> can anybody please help me with this bug?
[07:49] <LocutusOfBorg1> * Topic for #debian-devel is: Broken: Permissions on alioth | https://db.debian.org/debian_known_hosts | help with QA, review packages with no bugs today! http://deb.li/nobugs
[07:49] <LocutusOfBorg1> * Topic for #debian-devel set by vorlon!~vorlon@becquer.dodds.net (Sun Jun  1 05:05:36 2014)
 ehhhh
[07:49] <LocutusOfBorg1> * vbernat has quit (Remote host cl
[07:49] <LocutusOfBorg1> ops sorry
[07:49] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1334864
[07:49] <LocutusOfBorg1> I don't understand how to proceed, seems a critical bug for me (if reproducible)
[07:54] <rsalveti> diwic: so, here is the issue, with latest rtkit they fixed the RLIMIT_RTTIME value type (was nsec, but it's actually usec)
[07:54] <diwic> rsalveti, oh
[07:54] <rsalveti> and previous max timeout was static unsigned long long rttime_nsec_max = 200000000ULL; /* 200 ms */
[07:54] <rsalveti> changed to: static unsigned long long rttime_usec_max = 200000ULL; /* 200 ms */
[07:55] <rsalveti> if (rttime <= rttime_nsec_max)
[07:55] <rsalveti> to
[07:55] <rsalveti> if (rttime <= rttime_usec_max)
[07:55] <rsalveti> so pulse is setting max timeout to 1 sec
[07:55] <rsalveti> but rtkit only allows 200 ms
[07:55] <diwic> rsalveti, thanks for finding
[07:56] <rsalveti> diwic: should I change pulse's default rlimit_rttime to 200ms then?
[07:57] <rsalveti> upstream is also using 1sec
[07:57] <rsalveti> http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/daemon/daemon-conf.c
[07:58] <diwic> rsalveti, the change was done 2012, weird that you're the first one to discover it?
[07:59] <rsalveti> diwic: the error only shows with log level debug
[07:59] <rsalveti> but yeah
[07:59] <rsalveti> really weird :-)
[08:00] <rsalveti> happens on my desktop as well
[08:00] <diwic> rsalveti, let me ask the other PA developers. If you don't hear back from me today, please go ahead and change PA's max rttime
[08:00] <rsalveti> diwic: great, thanks
[08:17] <Saviq> mardy, hey, I was getting password prompts on login on utopic desktop these past few days... now I noticed I have no "online accounts" in the settings, any idea how that could've happened, and what should I install to get them back again?
[08:17] <Saviq> mardy, the pass prompts apparently were caused by missing google account plugin
[08:19] <Saviq> mardy, ah, found it again
[08:19] <Saviq> u-c-center-signon
[08:19]  * Saviq looks when it got removed
[08:20] <Saviq> hmm no commandline associated...
[08:20] <Saviq> mardy, as you were, then... must've been some PPA's fault or something
[08:28] <mardy> Saviq: hi! Sorry, I didn't see your messages. I really hope it was a PPA, but TBH I have no idea :-)
[08:29] <Saviq> mardy, no worries
[08:29] <Saviq> mardy, I just have http://pastebin.ubuntu.com/7710032/ in apt history.log
[08:30] <Saviq> mardy, no command line, no nothing, just "remove"...
[08:30] <Saviq> mardy, ppa-purge most probably
[12:25] <tvoss> xnox, cjwatson I'm looking at https://code.launchpad.net/~alecu/unity-scope-click/explicit-gcc-version/+merge/224550
[12:25] <tvoss> xnox, cjwatson I would propose that we get native compilation done first, to unblock the toolchain transition, and focus on cross compilation thereafter
[12:25] <tvoss> thoughts?
[12:28] <cjwatson> tvoss: I agree, and would add that making this work with cross-building is a centralised problem; see my comments in #ubuntu-ci-eng a little while back
[12:28] <tvoss> cjwatson, yup. xnox ^
[12:28] <cjwatson> tvoss: It's unfortunate fallout
[12:29] <tvoss> cjwatson, yup, let's focus on the core problem first and clean up in step 2
[12:29] <tvoss> thostr_, ^
[12:29] <tvoss> thostr_, please update the MP accordingly such that we can get the silo building
[12:31] <cjwatson> Have you dealt with all my review comments?  Most of them ought to be done before you start building it all.
[12:31] <cjwatson> And you'll need to fix the mir failure.
[12:33] <mdeslaur> cjwatson, beuno, sarnold: I've created a basic wiki page for click package signing here: https://wiki.ubuntu.com/SecurityTeam/Specifications/ClickPackageSigning
[12:34] <mdeslaur> cjwatson, beuno, sarnold: could you please take a look and make sure we're in agreement on the concept?
[12:34] <cjwatson> queued up, thanks
[13:17] <beuno> mdeslaur, thanks!
[13:18] <beuno> (reading)
[13:18] <stgraber> @pilot in
[13:35] <beuno> mdeslaur, so. I'm wondering if we want the signature to involved the URL from which it needs downloading from
[13:35] <beuno> to prevent MITMing the json outpu
[13:35] <beuno> *output
[13:36] <beuno> although I guess the device would only valdidate our signatures
[14:16] <brendand_> mvo, hey
[14:17] <mvo> brendand_: hello
[14:21] <brendand_> mvo, do you know where in jenkins your click jobs are?
[14:23] <mvo> brendand_: uh, I need to search
[14:23] <brendand_> mvo, no it's alright. i'll find out - and then let you know :)
[14:24] <cjwatson> brendand_: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-click/  https://jenkins.qa.ubuntu.com/view/Utopic/view/All/job/click-utopic-armhf-ci/
[14:24] <cjwatson> I expect those are the two relevant sets
[14:24] <brendand_> mvo, cjwatson knows :)
[14:24] <cjwatson> Well, cjwatson's browser history knows
[14:24] <cjwatson> Disturbingly sentient, that thing
[14:25] <mvo> heh :)
[14:25] <mvo> thanks cjwatson
[14:25] <brendand_> and it has the coverage report - excellent!
[14:25] <brendand_> mvo, cjwatson - now i can get that in the dashboard
[14:25] <brendand_> \o/
[14:25] <mvo> !!!
[14:37] <zul> xnox:  ping you know python-wsgi-intercept ftbfs right?
[14:38] <xnox> zul: hm, didn't notice, yet.
[14:39] <xnox> zul: the one in git shouldn't, it's ahead of what's in the archive.
[14:39] <zul> xnox:  just thought i would point it out
[14:41] <xnox> zul: haha. yeah i didn't get an email about it cause it synced from debian under team name
[14:42] <xnox> zul: and it's clearly trying to do network access which is allowed on my local builds & debian builds, but not ubuntu launchpad
[14:57] <alexbligh1> I have a conffile question (again, sorry). rbasak was helping me with this yesterday and I thought I had got the answer, but I now don't think I have. The issue is that apache2.2 provides mod_ident and apache 2.4 does not, leading to it going AWOL on an upgrade from Precise to Trusty. When apache 2.2 is removed (or perhaps when 2.4 is removed) a conffile in /etc gets removed from the disk, but not from the DB,
[14:57] <alexbligh1> so installing a new mod_ident package with the same conffile omits the conffile because the system thinks the user has chosen to delete it. rbasak  pointed me to https://wiki.debian.org/DpkgConffileHandling in some detail, and I've now looked at the source to dpkg-maintscript-helper, but this only seems to deal with removing (or moving) the conffile, and not correcting the database which is by now wrong. Any id
[14:57] <alexbligh1> eas?
[14:57] <alexbligh1> This is LP#1333388 (for the mod_ident bug)
[14:57] <mdeslaur> beuno: yeah, even if someone MITMed it, the only thing it would allow them to do is proxy the package and the valid signature, not alter them
[14:58] <mdeslaur> beuno: they could replace the package with another
[14:58] <mdeslaur> beuno: but, it's still using ssl, so even that isn't a huge risk
[14:58]  * beuno nods
[15:11] <brendand_> cjwatson, btw this job makes sure not to run integration tests prior to generating coverage right? https://jenkins.qa.ubuntu.com/view/Utopic/view/All/job/click-utopic-armhf-ci/7/cobertura/_default_/
[15:12] <cjwatson> brendand_: I wouldn't expect it to run integration tests at all, since that's done in autopkgtests
[15:21] <brendand_> cjwatson, mvo proposed to have them run on each merge proposal as well. not sure if that job does that
[15:22] <rbasak> alexbligh1: I think you need to publish a new apache2 package to your repo, which does the conffile handling and deletes it. And then publish a mod-ident package to your private repo, which pre-depends on a minimum of your specific apache2 version.
[15:22] <cjwatson> brendand_: seems to, we get MP reviews
[15:22] <rbasak> alexbligh1: then when you update a system, it'll pick up the apache2 fix for the conffile first, and dpkg will forget about the conffile. Only then will your mod-ident package be installed which will supply a new one.
[15:23] <rbasak> alexbligh1: then, get an apache2 SRU sponsored, which either also removes the conffile correctly, or restores mod-ident.
[15:23] <rbasak> (if I sponsor you, I will prefer what Debian does to fix this issue, assuming it affects them also)
[15:23] <alexbligh1> rbasak, I've investigated a bit further. Actually what is happening is that the preinst and postinst of apache2.4 *do* treat it as an obsolete conffile - i.e. they do it exactly per the book. They see its md5sum hasn't changed, then they delete it. That's the problem. That prevents it from ever being used by any debian package again as far as I can see.
[15:24] <alexbligh1> rbasak, I'd actually be compounding things if I published my own apache2.4 version, as apache2.4 does it precisely correctly according to the link you published.
[15:24] <rbasak> alexbligh1: hmm, OK. I think I understand what you're saying, but that doesn't match my understanding. I don't believe that it's possible to make packaging prevent a conffile from ever being used again.
[15:24] <rbasak> alexbligh1: you may well be right though - this is beyond my knowledge in that case though.
[15:25] <alexbligh1> I did an strace of dpkg-query et al. The issue is (I think) that the updates file continues to list a conffile entry for that file under apache 2.2. So if someone ever purges apache 2.2 then it will be deleted.
[15:25] <alexbligh1> I am presuming dpkg does not in general cope well with a conf file owned by two packages anyway.
[15:26] <brendand_> cjwatson, doesn't look like it runs the integration tests though
[15:27] <brendand_> mvo, you might want to check up on that - if you were expected it to run the integration tests
[15:27] <cjwatson> brendand_: Like I say, those are run in autopkgtests
[15:27] <cjwatson> brendand_: see the first link I gave you
[15:27] <cjwatson> brendand_: Oh, yeah, it's true those aren't currently run on every MP - sorry misunderstood
[15:27] <brendand_> cjwatson, :)
[15:28] <alexbligh1> rbasak, hmmm - if I add Conflicts: apache2.2-common, Breaks: apache2.2-common, will that cause apache2.2 to be purged (effectively) when my package is installed? Or at least get the conffile 'ownership' removed?
[15:28] <rbasak> alexbligh1: maybe. You could try Breaks/Replaces, too.
[15:28] <rbasak> It won't purge the old package, but dpkg will understand that the new package owns the files.
[15:29] <alexbligh1> rbasak, that sounds worth a try. And would be very simple.
[15:38] <tedg> jodh, Do you guys have a plan when you expect to release the next Upstart?
[15:45] <mvo> brendand_: aha, thanks. I will have a look
[15:46] <mvo> brendand_: I need to check in what kind of container they are running, the nice property of the autopkgtest is that they run as root so I can install clicks systemwide etc in the integration tests
[15:47] <jodh> tedg: we're still battling some issues with the async handling. fia estimate - end of next week earliest tbh.
[16:04] <tedg> jodh, Okay, thanks for the info.
[16:10] <shadeslayer> cjwatson: btw requirements sent to ubuntu-release
[16:11] <shadeslayer> for Plasma 5 ISO
[16:12] <jodh> grr - emulator still borked for me :(
[16:13] <alexbligh1> if I'm reporting a bug that a precise->trusty upgrade fails in an lxc container, what package should I report it against?
[16:15] <cjwatson> shadeslayer: thanks
[16:16] <stgraber> alexbligh1: what kind of failure are you getting?
[16:16] <alexbligh1> stgraber, I /thought/ I was was getting a hang somewhere on udev on reboot. But it appears it's a 2 minute wait. I'll see if the wait reoccurs if I stop and start it.
[16:17] <alexbligh1> stgraber, I am obviously too impatient
[16:18] <alexbligh1> stgraber, yup, a nice long wait after "Starting Bridge file events into upstart   ...done." - was starting instantly under precise.
[16:20] <stgraber> alexbligh1: hmm, weird
[16:20] <stgraber> alexbligh1: you may want to wipe /var/log/upstart/* and reboot the container, then check again after boot for any scary error
[16:20] <stgraber> alexbligh1: typically 2min delay means something failed during network bring up
[16:21] <alexbligh1> stgraber, literally all I had done was make a new precise container, install apache2, install update-manager-core, then do do-release-upgrade -d.
[16:21] <alexbligh1> I have no RDNS but that surely should not be an issue
[16:21] <stgraber> alexbligh1: ok, trying that quickly here
[16:24] <alexbligh1> stgraber, I selected all default options on do-release-upgrade save that I said it could restart services itself
[16:25] <alexbligh1> stgraber, and wiping /var/log/upstart/* does not help
[16:28] <stgraber> alexbligh1: it shouldn't help but it should then log some useful things in there
[16:30] <alexbligh1> stgraber, I /think/ it might be stuck on dhclient.
[16:30] <alexbligh1> which is odd as I have a static IP in my lxc file
[16:32] <alexbligh1> hmm. well it comes up with the right IP despite me not running dhcp.
[16:33] <stgraber> alexbligh1: I'm running the same test here now
[16:34] <alexbligh1> stgraber, tell me if you have the same result. the logs show it is trying for dhcp a lot, but sadly aren't timestamped. I snapshotted the container.
[16:39] <stgraber> alexbligh1: worked fine here
[16:39] <alexbligh1> stgraber, are you using dhcp?
[16:39] <stgraber> alexbligh1: create a container with "lxc-create -t download -n precise -- -d ubuntu -r precise -a amd64", started it, installed apache2 and update-manager-core, ran do-release-upgrade -d, rebooted, still works fine and booted as quickly as usual
[16:39] <stgraber> alexbligh1: yep, all default config, so dhcp
[16:40] <alexbligh1> stgraber, I think the issue (via a look at pstree) is if you are NOT using DHCP but using a static IP set it lxc config file, that precise boots quickly and trusty hangs for dhcp. Seems to be the same on a clean trusty install.
[16:41] <stgraber> alexbligh1: ah yeah, could be ifupdown or dhclient being confused by a pre-existing IP
[16:41] <alexbligh1> stgraber, I'm sort of confused as to why console login should not be available until dhclient times out
[16:42] <stgraber> alexbligh1: you should be able to fix that by either mark eth0 as manual in /etc/network/interfaces in the container or by not setting the ip in the container config
[16:42] <alexbligh1> stgraber, I shall indeed do that, but I just thought it was odd it all worked with Precise.
[16:42] <stgraber> alexbligh1: the /dev/console getty is only started once most of the boot sequence is done. That's so you can see any boot messages that'd appear
[16:43] <slangasek> why do Mint users keep filing random bugs against the nfs-utils package?  (bug #1325367, bug #1335199)
[16:43] <stgraber> alexbligh1: yeah, I think this is in the realm of undefined behavior, something must have changed somewhere in ifupdown or dhclient that makes it fail badly rather than just ignore pre-existing config
[16:43] <alexbligh1> stgraber, thx
[16:44] <alexbligh1> slangasek, the second of those, maybe they need the -orsize,wsize options :-)
[16:45] <slangasek> heh
[16:47]  * rbasak is tempted to troll slangasek with more Mint-related nfs-utils -unrelated bugs
[16:47] <slangasek> rbasak: pretty sure I will know it's you though :)
[16:47] <rbasak> :)
[16:49] <Laney> Bobie Rasak
[16:57] <alexbligh1> rbasak, (after some container fun) sadly Provides: & Breaks: doesn't work. dpkg-query still thinks the config file is owned by apache2.2-common. I'm guessing the problem here is Provides: Breaks: to replace files only works for binaries and not for conffiles. Bit stuck!
[16:57] <rbasak> alexbligh1: you do mean Replaces, right?
[16:57] <rbasak> If not you need that.
[16:57] <alexbligh1> um
[16:57] <alexbligh1> Breaks: & Replaces:
[16:57] <alexbligh1> ignore Provides:
[16:58] <rbasak> alexbligh1: I'm not sure exactly what's going on there, sorry. I do think it must be possible.
[17:00] <alexbligh1> apache2.2-common is showing the conffile as obsolete (which is an improvement), but dpkg still didn't see fit to actually install it!
[17:04] <alexbligh1> rbasak, well, if I do Replaces:+Breaks: and check for the existence of the file in postinst and if it's not there, copy it in, that appears to leave the system in a sane state. Which is disgusting but works for now.
[17:14] <sergiusens> pitti: hey, I'm looking at that dbus/autopilot issue; I need some clarification on how some things work
[17:15] <alexbligh1> stgraber, stranger and stranger. It wasn't dhcp. static interface file does the same thing. But I found this suspicious item in pstree: "sleep 40"
[17:16] <stgraber> alexbligh1: if you have an IP defined in the container config, you need to have /etc/network/interfaces say "iface eth0 inet manual"
[17:17] <stgraber> alexbligh1: putting inet static is as invalid as inet dhcp so both will result in the 2min wait at boot time (which is what you'll see as a bunch of sleep of various lengths)
[17:17] <alexbligh1> stgraber, I've got it auto static (with the right set of IPs). Is that bad?
[17:17] <alexbligh1> oh
[17:17] <stgraber> auto eth0
[17:17] <alexbligh1> I'll try manual then
[17:17] <stgraber> iface eth0 inet manual
[17:17] <stgraber> or just nothing at all (which should give you the same result)
[17:20] <alexbligh1> stgraber, thanks, that fixed it :-
[17:20] <alexbligh1> :-)
[17:21] <sarnold> cjwatson, beuno, mdeslaur: one the one hand, I'd really like the json response from the server to be signed as well so the user has some confidence that what was on screen at "install" button-clicking time is actually what gets installed. On the other hand, if the user can't tell the difference between "netflix" and "netflıx" application launch icons, they won't be able to tell the difference between "netflix" and "netflıx" ap
[17:22] <beuno> right
[17:22] <beuno> do you have an idea on how to make those things clearer to the user?
[17:22] <mdeslaur> display the publisher
[17:22] <sarnold> cjwatson, beuno, mdeslaur: and I'm a little concerned about what happens if a developer submits an application package with a package name that's 254 chars long; tacking .asc on the end will probably break something :)
[17:23] <mdeslaur> sarnold: we can add that check to our click package sanity script thingy
[17:23] <sarnold> beuno: I'm afraid it's mostly on us to help prevent fishing attack copy-cat applications. :(
[17:23] <beuno> mdeslaur, the publisher should either be already displayed, or is on someone's ToDo. I can check.
[17:23] <mdeslaur> beuno: that's cool
[17:23] <cjwatson> Of course that just moves the problem to copy-cat publisher names
[17:24] <beuno> yes it does
[17:24] <cjwatson> My best suggestion for this is to make sure there's an ASCII-only identifier and always show that somewhere as well (even if perhaps not prominently)
[17:24] <cjwatson> Probably also forbidding whitespace in that
[17:25] <cjwatson> The existing full package name should do
[17:25] <beuno> well, I guess those are the rules for...right
[17:25] <mdeslaur> displaying the publisher, and the other apps from the same publisher simply allows a user to see if something is the real facebook app, and not one of the zillion webapps, but I agree copycat names would still be a problem
[17:25] <beuno> we also allow duplicate app names, so there can be thousands of apps called "Netflix"
[17:25] <cjwatson> Display names are all well and good but the requirements for them aren't really compatible with avoiding lookalike Unicode codepoints and so on
[17:26] <cjwatson> And that
[17:26] <mdeslaur> but copycat names can be viewed as a malicious attempt at fishing, and we can ban them once they are discovered
[17:26] <beuno> personally, I use popularity in the android store
[17:26] <mdeslaur> ah, yes, that's also good
[17:26] <beuno> as in, how many people downloaded it, reviews, etc
[17:26] <mdeslaur> anyway, this is a parallel problem to package signing
[17:27] <sarnold> "oh, good! twelve downloads! this must be the real thing to have so many" :)
[17:27] <beuno> but there's a bootstrapping period
[17:27] <beuno> hurtful!
[17:27] <sarnold> metcalf's law is a cruel heartless beast
[17:27] <beuno> and yes
[17:27] <beuno> it's orthogonal to signing
[17:28] <beuno> not something to ignore, just another level of a problem
[17:28] <beuno> you also have to make a payment in the android and ios stores
[17:28] <beuno> so that already is a small barrier
[17:28] <beuno> and some form of identification
[17:29] <mdeslaur> yes, it allows for getting a legal name and address
[17:29] <sarnold> mmm. tough. I can see the obvious appeal there :) but I think that's a barrier we'd rather not artificially throw in front of developers.
[17:31] <mdeslaur> sarnold: you can have different requirements...apps confined with standard policy groups are well confined, maybe not...apps that require manual review and/or agreements because they do something reserved, you most definitely want to know who the developer is
[17:31] <mdeslaur> but see, this is why I didn't study law
[17:31] <mdeslaur> too hand-wavy for me :)
[17:32] <beuno> it's all made up anyway
[17:32] <sarnold> mdeslaur: yeah, maybe there's room for fiddling there. I for one would like to know that the Chase Banking App I installed came from someone with $50 and a willingness to say "I legally represent Chase and I know they'll lop my head off if I'm lying"  :)
[17:32] <mdeslaur> sarnold: heck, I would even be good with us _giving_ $1 per app to people to be able to get a confirmed address
[17:33] <beuno> ok, so I'll pick this up in a separate thread
[17:33] <beuno> to not distract us from signing
[17:33] <sarnold> mdeslaur: well, okay, if you put it that way. What's one more buck to chase? :) haha
[17:34] <rbasak> How about doing a web browser green ev certificate style thing? Distinguish a "verified account" in the UI.
[17:34] <rbasak> Though that is another UX can of worms.
[17:34] <mdeslaur> sarnold: my point is, it's not about the fee, that's artificial, it's about getting someone's name and address, which is just high enough to prevent anonymous malware uploads
[17:35] <mdeslaur> rbasak: you could sell rankings
[17:35] <mdeslaur> the "official" apps always get listed higher for exact search terms for example
[17:35] <sarnold> ooops, we started a serious discussion on Security Team Evil Fridays  :)
[17:36] <mdeslaur> heh, an off-topic discussion in #ubuntu-devel no less
[17:36] <mdeslaur> mdeslaur: this channel is for development, go rant somewhere else.
[17:38] <rbasak> I also have an opinion that a web of trust is the only real way. App developers should either pay to have some official signature, or find a community member already in the PGP strong set. That should prevent phishing on similar-looking names, since someone signing for such names could always be blacklisted (and closer in the trust chain if necessary)
[17:38] <rbasak> But I understand that this might be too much of a barrier for new app developers.
[17:41] <sarnold> rbasak: not to mention it'd only take one person i nthe strong set to set up an auto-sign bot that includes anyone else into the strong set, hehe
[17:41] <rbasak> sarnold: that's what the blacklisting would be for :)
[17:42] <mdeslaur> rbasak: well, the web of trust people are able to understand is ranking, ratings, popularity...I'm not sure how you get users to make a decision based on anything else
[17:42] <rbasak> Users would make a decision based on identity name (uid), as signed into the strong set, and only that name.
[17:43] <mdeslaur> rbasak: users aren't able to do that
[17:43] <mdeslaur> "FacebookApp", "FaceBook", "Facebook" all look the same to users
[17:43] <rbasak> mdeslaur: right, but somebody who signs anything that looks like Facebook into the strong set without it actually being Facebook deserves to be blacklisted.
[17:44] <rbasak> And it's less whack-a-mole since anything on that trust path can be blacklisted.
[17:44] <mdeslaur> rbasak: so I was planning on calling my new game 'Apple', should I be blacklisted?
[17:45] <rbasak> mdeslaur: no, but your PGP uid "Apple" should not be signed into the strong set, and anybody who does deserves to be blacklisted.
[17:46] <rbasak> I suppose there are edge cases like what happens if I change my name to "Apple" by deed poll.
[17:46] <mdeslaur> rbasak: oh, my uid is going to be 'Equinox', or 'Chase'
[17:46] <mdeslaur> I haven't decided yet
[17:46] <mdeslaur> perhaps 'Acme'
[17:46] <rbasak> Still though, I think by having a trail of real identities much of the phishing problem will go away. They only exist because others can't identify them through any path.
[17:47] <rbasak> That's just IMHO. I accept that only practice will determine the effectiveness of my approach.
[17:49] <mdeslaur> I do believe we should be protecting the big names and make sure we don't end up like this: http://www.geek.com/microsoft/when-will-microsoft-clean-up-the-windows-phone-store-1583813/
[17:50] <mdeslaur> original link: http://oneslash.postach.io/microsoft-please-clean-your-store-from-junk#.Uu5FGbRGa9U
[17:50] <mdeslaur> anyway, way off-topic for #ubuntu-devel
[17:50] <rbasak> Yes - I agree that's an important problem.
[17:50]  * rbasak shuts up now
[18:10] <smoser> hey.
[18:11] <smoser> who would i ask to get a trusty-netboot at http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/
[18:12] <smoser> to follow from https://launchpad.net/ubuntu/+source/linux-meta-lts-trusty
[18:12] <infinity> smoser: s/-updates/-proposed/
[18:12] <infinity> smoser: If you test the one in -proposed and tell me it's not busted, I'll happily promote it.
[18:13] <smoser> hm..
[18:13] <smoser> i suppose maybe i can do that.
[18:13] <smoser> infinity, is there a bug that i'd report that on ?
[18:14] <infinity> smoser: Nope, just a verbal "it doesn't entirely suck" is fine.
[18:14]  * infinity needs to run out for a bit.
[18:32] <smoser> infinity, ugh. this could be user error, but when debootstrap starts i see:
[18:32] <smoser>  Warning: Couldn't download package bsdutils (ver 1:2.20.1-1ubuntu3 arc amd64)
[18:48] <cjwatson> smoser: Probably needs apt-setup/proposed=true at the moment
[18:48] <cjwatson> smoser: Otherwise (unfortunately) you end up with a mismatched set of things from bug 1172101
[18:49] <cjwatson> All the fixes from that, bug 1135163, and bug 833994 need to be tested and promoted-or-not together
[18:50] <cjwatson> And I think they deserve the full seven-day aging period, not a fast-tracked promotion, especially since some others have expressed interest in testing them
[18:50] <cjwatson> infinity: ^-
[18:51] <cjwatson> I know that isn't directly related to -lts-trusty, but I can't disentangle them now without a complete revert and starting from scratch, which I'm probably not willing to do given that the HTTPS fixes are needed for 12.04.5
[18:52] <smoser> why are https fixes needed ?
[18:53] <cjwatson> We have customers
[19:27] <stgraber> @pilot out
[20:02] <smoser> infinity, well, i did run through a basic test
[20:02] <smoser>  http://paste.ubuntu.com/7712804/
[20:02] <smoser> seems reasonable. as cjwatson pointed out, it does require the proposed
[20:07] <infinity> smoser: It shouldn't require proposed, the kernel is in -updates now.
[20:07] <smoser> see cjwatson's comments.
[20:07] <infinity> smoser: Oh, the wget thing, right.
[20:07] <smoser> it does require proposed
[20:07] <smoser> yeah
[20:08] <infinity> Happy to let that bake and have it tested more.
[20:09] <infinity> smoser: But if it works for you with proposed=true, yay.  That's one useful datapoint.
[20:09] <smoser> right. so its not completely broken.
[22:13] <Noskcaj> mterry, Could you have another look at bug 1327458 please?
[22:14] <mterry> Noskcaj, still needs a bug subscriber
[22:14] <mterry> but I can look at the rest
[22:15] <Noskcaj> I was hoping the desktop team would be the subscriber, but i've got no responce
[22:18] <mterry> Noskcaj, looks good besides that, will comment so
[22:19] <Noskcaj> thanks