[00:00] <psusi> cjwatson, well, I've spent tonight going over all of the debian patches and either removing them because they are merged upstream, or refreshing where needed... most of them dropped out
[00:00] <cjwatson> That's not the hard bit :-)
[00:01] <cjwatson> Honestly, we've had this conversation before
[00:01] <cjwatson> You just don't believe me, but I can't help that :)
[00:02] <cjwatson> If you want to actually move this forward, forget about parted - look at the partman-base bug I'll file in a moment and implement that
[00:16] <cjwatson> Debian #696123
[00:16] <cjwatson> right, really bed now
[02:52] <ScottK> infinity: Keeping mpi in Universe is the reason we split the boost source package in half, so good call on valgrind ...
[03:18] <hyperair> rc0.d is the shutdown runlevel, right? does are SXXfoo* scripts supposed to be called with start or stop when shutting down?
[03:18]  * hyperair noticed an S90halt that seems to do nothing on start but does stuff on stop instead.
[03:19] <StevenK> S* are calling when switching to that runlevel
[03:19] <StevenK> *called
[03:26] <infinity> hyperair: "The two runlevels 0 (halt) and 6 (reboot) are slightly different. In these runlevels, the links with an S prefix are still called after those with a K prefix, but they too are called with the single argument stop."
[03:26] <hyperair> ah i see.
[03:26] <hyperair> infinity: where does that come from?
[03:27] <infinity> hyperair: From Policy, §9.1
[03:27] <hyperair> aha, okay, thanks
[06:54] <pitti> Good morning
[06:54] <pitti> bdmurray: .crash with out SAS> oh I am! can you please file a bug and attach the file there?
[06:55] <pitti> infinity: no, it's not meant to defer crash reports; as long as update-notifier is running, they should be reported right away
[06:55] <pitti> infinity: you can call /usr/share/apport/apport-gtk to show the pending ones
[07:48] <pitti> infinity: you can call /usr/share/apport/apport-gtk to show the pending ones
[07:55] <dholbach> good morning
[08:03] <pitti> hey dholbach
[08:04] <dholbach> hey pitti
[08:32] <dholbach> can somebody please reject https://code.launchpad.net/~logan/ubuntu/raring/php-horde-crypt-blowfish/debian-merge/+merge/139545 (based on the last comment)?
[08:34] <pitti> dholbach: done
[08:34] <dholbach> thanks pitti
[08:46] <infinity> pitti: Hrm.  update-notifier's running, but definitely no reports.  Weird.
[08:48] <mpt> pitti, hi. Three main issues have stopped me when considering whether to design a Presentation Mode or Do Not Disturb mode in the past. First, most of the notifications I've seen examples of, that would be suppressed in that mode, are notifications that probably shouldn't be shown as bubbles in the first place -- except perhaps for chat, and that's handled by Busy status. Second, how you'd remember that you'd gone into that mode, so that you could exit late
[08:48] <mpt> r. And third, what would happen when you did exit: would notifications be queued up, or would they just be dropped?
[09:02] <pitti> mpt: ah, thanks for the heads-up; JohnLea pointed me to http://design.canonical.com/the-toolkit/unity-multi-monitor-interactions/ → Multiple Monitors UX Specification → Presentation mode
[09:04] <mpt> pitti, that takes me to a sign-in page :-]
[09:04] <mpt> ah, I found the section
[09:07] <mpt> pitti, doesn't look like that document addresses those issues either
[09:10] <pitti> mpt: not for providing an option to turn them off, just for not displaying them when you are in a fullscreen app, etc.?
[09:10] <infinity> pitti: Running apport-gtk appears to have done nothing...
[09:11] <mpt> pitti, I mean (1) examples of notifications that would be suppressed but normally shown, (2) how you would notice/remember that you'd gone into that mode, and (3) what would happen when you exited.
[09:11] <pitti> infinity: then it seems you do not have crash reports which weren't already presented
[09:11] <infinity> pitti: That's patently untrue, I have 10 new ones.
[09:11] <infinity> pitti: And if my last few logins are anything to go by, they'll all get presented next time I reboot. :P
[09:12] <infinity> (But maybe not this time?)
[09:12] <pitti> infinity: can you pastebin the output of stat /var/crash/* ?
[09:12] <pitti> infinity: it tells apart "seen" from "unseen" by atime > mtime
[09:12] <infinity> http://paste.ubuntu.com/1444864/
[09:13] <pitti> /var/crash/xserver-xorg-video-intel.2012-12-12_19:28:48.563612.crash looks strange
[09:14] <pitti> Access: 2012-12-12 19:28:48.559803473 -0700
[09:14] <pitti> Modify: 2012-12-12 19:28:48.567803473 -0700
[09:14] <pitti> atime < mtime
[09:14] <pitti> but that should count as "new"
[09:14] <infinity> They all look like that.
[09:14] <infinity> Isn't that vaguely normal for open, write, close?
[09:14] <pitti> no, the top ones have atime > mtime, e. g. /var/crash/xserver-xorg-video-intel.2012-12-11_06:55:33.704464.crash’
[09:14] <infinity> Well, the top ones have a higher atime because they've been reported.
[09:15] <infinity> All the unreported ones don't.
[09:15] <pitti> infinity: these are root ones, so you need to run sudo /usr/share/apport/apport-gtk
[09:15] <pitti> does that work?
[09:16] <infinity> Oh, perhaps that's the problem?  Maybe update-notifier doesn't pick up rooty ones?
[09:16] <pitti> the bottom block indeed
[09:16] <pitti> they also don't have .upload files
[09:16] <pitti> the top ones do, and it's apport itself which creates the .upload stamps
[09:16] <pitti> so these must have been shown
[09:16] <infinity> pitti: Yes, the top ones were all shown.
[09:16] <infinity> pitti: It's the 10 at the bottom that I'm saying haven't been.
[09:17] <infinity> pitti: And having them all show (very, very, slowly, I might add) on login is pretty unfriendl.
[09:17] <infinity> unfriendly, too.
[09:17] <pitti> infinity: what's the exit code of "/usr/share/apport/apport-checkreports --system"?
[09:17] <infinity> As opposed to right after the crach, which is what I'd expect.
[09:17] <pitti> infinity: yep; we have a design to fix that
[09:17] <pitti> infinity: but assuming that your desktop session actually survives the intel crash, that's actually supposed to happen right now
[09:18] <infinity> pitti: That returns 0.
[09:18] <pitti> ok, then update-notifier doesn't pay enough attention to that
[09:18] <infinity> pitti: Yeah, my session survives, the reports, as mentioned, don't happen until next login.
[09:18] <pitti> infinity: can you kill it and run it on a terminal?
[09:18] <pitti> infinity: it waits for a minute or so before it checks for crash reports
[09:19] <pitti> infinity: then "sudo touch" an already seen one, that ought to trigger its attention
[09:20]  * pitti tries here with sudo sh -c 'kill -SEGV $$'
[09:20] <pitti> that brings up apport just fine
[09:21] <rbasak> How do I get ubiquity to use -proposed? Will apt-setup/proposed=true in the kernel cmdline work?
[09:21] <rbasak> infinity: you're up early! Or late? I've managed to reproduce bug 1079185 using ubiquity. Need to try -proposed now.
[09:22] <infinity> rbasak: Did you not notice the part where I already marked it v-done?
[09:22] <rbasak> Oh, you have?
[09:22] <infinity> rbasak: Two days ago...
[09:22] <rbasak> It would help if I were subscribed to the bug, wouldn't it!
[09:22] <rbasak> Thanks!
[09:25]  * rbasak puts his pandaboard stack away
[09:37] <xnox> rbasak: hmm.. in what sense do you mean -proposed?
[09:38] <rbasak> xnox: nm, it turns out that infinity already tested it. What I meant was that I wanted ubiquity to pick up flash-kernel-installer from -proposed, if that's possible (or else I wanted to manually update it before it used it)
[09:38] <xnox> rbasak: ah. ack.
[09:41] <rbasak> xnox: for future reference, how would I achieve that?
[09:42] <xnox> rbasak: if a package is just installed - you can upgrade it in the tty1 however you like.
[09:42] <rbasak> xnox: including udebs?
[09:42] <xnox> rbasak: we do not use udebs.
[09:43] <xnox> rbasak: in ubiquity we unpack them at source build time & embed udebs in the ubiquity package.
[09:43] <xnox> rbasak: so for those you need to rebuild ubiquity package & upgrade that in live environemnt...... or simply replace bits & bobs in-place (if it's not compiled stuff ;-) )
[09:43] <rbasak> OK, got it. Thanks!
[09:44] <xnox> =)
[10:34] <infinity> pitti: Oh, FFS, I did have an apport dialog hidden behind all my windows that I found when I went to shut down.
[10:34] <infinity> pitti: Now, how long that's been there, I can't say.
[10:34] <pitti> infinity: ps aux|grep apport-gtk
[10:34] <pitti> that should tell you?
[10:35] <infinity> That had nothing in it the last time I looked.
[10:35] <infinity> That initial "problem detected" dialog isn't from apport, is it?
[10:35] <infinity> I'm assuming it's from update-manager.
[10:35] <pitti> right, update-notifier
[10:35] <pitti> my bad
[10:36] <infinity> And now I get to go through the pain of reporting 10 of these.
[10:36] <infinity> Which takes way longer than seems reasonable.
[10:36] <pitti> it's ten times click "ok"
[10:36] <infinity> No, the gpu crashes take eons to actually do their thing.
[10:37] <pitti> but indeed, as I said we have a design for batching those
[10:37] <infinity> Not sure what they're doing, but they don't do it quickly.
[10:37] <pitti> infinity: or just close the dialog; we have enough of those already, after all
[10:37] <infinity> Gah, and typing while modal dialogs keep popping up = bad.
[10:37] <infinity> *sigh*
[10:37] <pitti> infinity: they attach a load of log files, and dissect the GPU dump for a signature
[10:38] <infinity> pitti: Sure, but I can't see how that takes more than a few seconds.
[10:38] <infinity> (It's literally a minute or more per crash)
[10:39] <infinity> Which is extra entertaining when I have more GPU crahes while reporting my GPU crashes. :)
[10:39] <mitya57> hey dholbach, so do you know what happened to translations.js?
[10:39] <infinity> (The only reason I report them at all is to not give the impression that the bug is fixed, or becoming less frequent)
[10:39] <dholbach> mitya57, no, I'm afraid I didn't get a chance to do that, but it's next on my list
[10:40] <dholbach> mitya57, the script which updates developer.u.c seems to cause some other breakage as well (intermittent failures to update), so this is a good chance to make it more robust
[10:40] <mitya57> dholbach: ok. that's minor thing, but it prevents some sphinx's built-in strings from being translated
[10:41] <dholbach> I'll let you know :)
[10:42] <dholbach> mitya57, ru.po is up to 61% :)
[10:43] <mitya57> wasn't it at the same value when we were discussing it last time? :)
[10:44] <dholbach> mitya57, I think we added some strings in the meantime ;-)
[10:44] <mitya57> I do not have too much time to translate it myself, but other 3 people do it very well...
[10:44] <dholbach> but yeah, it's still pretty close to the threshold of 70
[10:44] <dholbach> I'm sure we'll get there
[10:44] <mitya57> of course :)
[10:45] <mitya57> btw, I'll maybe find some time for Sphinx SRUs after 1.2 release which will be soon
[10:47] <dholbach> sweet
[10:51] <ciao> ciao
[10:51] <ciao> help
[11:09] <mpt> barry, hi, any chance of landing the SRU for bug 846044 soon?
[11:11] <mitya57> mpt: it's already in -proposed, and will be moved to -updates when someone adds verification-done tag...
[11:15] <mpt> mitya57, who is "someone" in this context? :-) (I'm not familiar with the details of the process)
[11:15]  * mpt should just go read it
[11:16] <mpt> ah, the SRU Verification Team
[11:16] <dholbach> mitya57, fixed
[11:17] <xnox> mpt: to be honest anyone. If you can reproproduce the problem, upgrade to -proposed, follow the test-case realise that (i) the problem is fixed & (ii) there are no regressions then just comment on the bug that "performed verification followed these steps, etc"
[11:17] <mitya57> dholbach: nice, thank you!
[11:17] <dholbach> mitya57, anytime :)
[11:18] <xnox> then it can get marked verification-done very quickly & sru team will weight on that comment & release the update.
[11:22] <mitya57> dholbach: maybe it's possible to link singlehtml/search.html -> html/search.html for every language? so that people don't think that search is broken.
[11:22] <dholbach> bah
[11:22] <dholbach> ok
[11:22] <dholbach> publishing these docs is a giant hack :)
[11:23] <mitya57> that was nitpicking :)
[11:24] <mitya57> unfortunately it can't be done in the branch because there are no html subdirectories in our packages
[11:26]  * dholbach nods
[11:26] <dholbach> I'll look into it
[11:56] <Daviey> doko: Does libboost-thread-dev  need a MIR, considering Boost is already main?  bug 1086423
[11:57] <infinity> Daviey: No.
[11:57] <doko> Daviey, no, I don't think so. we don't have a good way to track binary package which we do want to keep out of main
[11:59] <Daviey> Yeah, i didn't just want to action it... as a MIR had alrady been opened and assigned to you
[12:01] <infinity> To be fair, I'd rather see a few unnecessary MIRs than the inverse, so I don't mind that one was opened.
[12:01] <infinity> But yeah, not necessary in this case.
[12:01] <infinity> boost was already split intentionally for main/universe reasons, it's fairly safe to assume that anything coming from the main sources is fine for main.
[12:02] <infinity> (It's just that some of it is in universe because nothing currently depends on it)
[12:02] <Daviey> yeah.. I was just checking, as mterry had assigned it to doko.. and i didn't want to trump over that without checking :)
[12:11] <shnatsel> cjwatson: Hello! I see the Precise seeds have been switched to 3.5 kernel a while ago for x86 achitectures, but the daily ISOs still contain 3.2 kernel. Is that intentional?
[12:44] <infinity> shnatsel: If by "still contain", you mean they have both, yeah, that's known.
[12:44] <infinity> shnatsel: Not intentional, per se, and needs fixing, but known.
[12:57] <shnatsel> infinity: they default to 3.2, not sure if they actually contain 3.5; elementary's ISOs build from mostly the same seeds do not contain 3.5.
[12:57] <shnatsel> infinity: thanks! I'll look for Launchpad bug report and subscribe.
[13:15] <xnox> shnatsel: well 3.5 is shipped under a new package name, so you do need to change your seeds if you wish to have 3.5.
[13:17] <shnatsel> xnox: I did - I've merged the changes from Ubuntu's seeds. I do have the package with "quantal" in its name in seeds, but ISOs still use 3.2 by default. I've checked today's Ubuntu Precise daily build and it has the 3.2 kernel too.
[13:22] <infinity> xnox: Changing seeds doesn't help, as "apt-get install ubuntu-desktop^" uses task headers, which we can't change post-release.
[13:22] <xnox> true & *sigh*
[13:22] <infinity> So, the solution for Ubuntu's images will require some mangling, either removing the release kernels manually, or switching to using metapackages.  Undecided yet on which is more annoying.
[13:23] <infinity> My gut feeling is that doing the removal may be less scary than switching from tasks to metapackgaes and trying to determine if that causes fallout.
[13:23] <infinity> It's on my TODO, at any rate.
[13:57] <pitti> jibel: FYI, if your current gnome git fails to build in g-i: https://bugzilla.gnome.org/show_bug.cgi?id=690347
[14:24] <doko> what does this mean?
[14:24] <doko> dpkg-source: warning: unknown information field ')description' in input data in package's section of control info file
[14:24] <doko> the dsc file looks fine
[14:31] <arand> What does your debian/control file look like?
[14:47] <pitti> mdeslaur: many thanks for the glibc fix!
[14:47] <mdeslaur> pitti: yw! sorry for having broke it in the first place :P
[14:59] <pitti> mdeslaur: https://launchpad.net/ubuntu/+source/postgresql-8.3/8.3.22-0ubuntu8.04 \o/
[15:00] <mdeslaur> cool :)
[15:20] <mpt> ev, https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/500175/comments/10
[15:50] <bdmurray> pitti: bug 1091289
[15:50] <pitti> bdmurray: thanks
[15:51] <pitti> bdmurray: ah, that's an easy one
[15:52] <pitti> bdmurray: bug updated
[15:52] <pitti> bdmurray: i. e. I don't think we should allow that low level of stacktrace quality
[15:53] <pitti> it severely increases the probability of false positives for duplication
[15:53] <bdmurray> So then should we not notify about those somehow?
[15:53] <pitti> the user/reporter can hardly do something about it
[15:54] <pitti> I think we can just keep them in errors.u.c. without being able to auto-duplicate them
[15:54] <bdmurray> I believe errors didn't take it because it had no SAS
[15:55] <pitti> I don't have much confidence in a stack trace starting off a NULL pointer
[15:55] <pitti> basically, everything we know about it is "it crashed and corrupted memory"
[15:55] <bdmurray> okay, and point is apport shouldn't offer to report it then
[15:56] <pitti> well, I wonder why we wouldn't
[15:56] <pitti> ev seems rather adamant of collecting each and every "unreportable" crash where we already know that it is the user's fault
[15:57] <pitti> for those we should probably collect them as well, so that we know how many "no SAS" crashes we have?
[15:57] <pitti> bdmurray: anyway, I guess we can add an UnreportableReason: field to it and tell the user "sorry, we cannot report this"
[15:57] <bdmurray> I thought ev had a counter of errors with an SAS coming in
[15:57] <pitti> but as there is no feedback after submitting a crash anyway, this would not actually make much of a difference
[15:57] <bdmurray> er without an SAS
[15:59] <pitti> if we do, we kind of do report them then?
[16:00] <bdmurray> yes, I guess so.  Perhaps we should look at the counter sometime in the future and see how many there are and if the quantity is high consider it as detracting from the user experience, because we have excessive error dialogs.
[16:20] <pitti> doko: cross toolchains> really cool!
[16:35] <infinity> BenC: I'm going to delay that linux-ppc build for a bit, if you don't mind terribly.
[16:35] <BenC> infinity: not a problem
[16:38]  * xnox is sorry for [ab]using buildds for upstart sprint =)
[16:44] <infinity> xnox: Given that all those builds fail anyway.. :P
[16:48] <xnox> infinity: the last one actually works now =)
[16:49] <xnox> infinity: https://code.launchpad.net/~canonical-foundations/+recipe/upstart-daily-nonvirt
[16:53] <infinity> xnox: "the last one actually works"... You sound surprised.
[16:54] <infinity> "I wrote some code and it actually kinda compiles a little bit and might even run sometimes, you should totally check it out."
[17:00] <stgraber> infinity: well, we found a few "interesting" bugs where the tests would hang if they were run from within a directory containing a ~ in its name
[17:00] <stgraber> infinity: took me a little while to figure out that one and fix it ;)
[17:01] <xnox> infinity: and ppa recipes add ~release1 at the end..... =)
[17:01] <stgraber> now we still have the problem that the tests hang on virt but pass on non-virt, but I'm just blaming 2.6.24 for now (downloading a hardy ISO to test here)
[17:01] <infinity> stgraber: Hahahahaha.
[17:02] <infinity> stgraber: (To the ~ bug)
[17:03] <stgraber> infinity: why the -2 for our "good" upstart powerpc build? I already scored down all the ones that were pointless...
[17:05]  * stgraber rescored to the original score and made sure all the others are at -2 or lower
[17:05] <stgraber> we kinda want to confirm that upstart still builds on PPC, it's a pretty short build and we have a 99% change it won't hang like the last one (where I had to poke webops)
[17:08] <infinity> stgraber: Oh, sure, have one.  I just scored them all down cause several seemed excessive.
[17:08] <stgraber> infinity: you know, if only we had that nice cancel feature that the PPA have ;)
[17:12] <jono> is anyone else getting lockups in compiz/unity in raring?
[17:20] <infinity> jono: Intel graphics?
[17:23] <jono> infinity, yep
[17:24] <infinity> jono: Bunch of intel crashes in /var/crash?
[17:24] <infinity> jono: It's probably https://errors.ubuntu.com/bucket/?id=[sandybridge-m-gt2%2B]%20GPU%20lockup%20%20IPEHR%3A%200x0b160001%20IPEHR%3A%200x0b140001%20Ubuntu%2013.04
[17:25] <jono> infinity, yep, lots of them
[17:25] <infinity> jono: (for the record, on my laptop, it can worked around by VT switching to VT1 and back to VT7 every time it freezes)
[17:25] <infinity> Not that that's a pleasant workflow, but it avoids having to reboot. :P
[17:25] <jono> infinity, yeah, I noticed that too, but when in multi-monitor it doesnt work
[17:25] <infinity> Ahh, lovely.
[17:25] <jono> I switch VTs and when I switch back I get nothing, just a black screen
[17:25] <jono> infinity, is a bug filed for this?
[17:25] <infinity> Well, if you have dual graphics on that thing, I might recommend switching to the ATI/nvidia for a bit.
[17:26] <infinity> jono: It's the #4 crash on errors, the X guys are well aware of it.
[17:26] <jono> ahhh sweet
[17:26] <jono> thanks!
[17:26] <infinity> jono: I'm sure there's a bug matching it somewhere, though I don't know or care what the number is. :P
[17:26] <jono> np :-)
[19:00] <oVeRMiND> hello world!
[19:28] <zykes-> does Ubuntu / Debian have a equivelant to "repodata" as Fedora / RHEL things have?
[19:30] <sarnold> zykes-: I don't know what the fedora repodata contains, but the Packages files contain a _lot_ of data, see 'apt-cache showsrc sed' for a quick example of some of the data available
[19:32] <zykes-> sarnold: basically a overview of packages / files
[19:35] <dobey> zykes-: the apt Packages info doesn't contain the files list for the packages, iirc
[19:36] <zykes-> dobey: I basically need to get something equivelant to add .deb support to Pulp
[19:37] <sarnold> ah, perhaps the apt-file package can help you?
[19:42] <cjwatson> zykes-: Packages.gz if you're looking for metadata on binary packages; Sources.gz if you're looking for metadata on source packages; Contents-$ARCH.gz if you're looking for file lists
[19:42] <cjwatson> all in the dists/RELEASE/ directories
[19:50] <zykes-> cjwatson: is there any bindings in python to do this stuff ?
[19:50] <cjwatson> python-debian
[19:50] <cjwatson> handles a lot of it
[19:51] <cjwatson> Probably not Contents-*, I forget
[19:51] <zykes-> not python-apt ?
[19:51] <cjwatson> Whether any distribution other than Debian-based ones has felt the need to package python-debian, I couldn't help you with ...
[19:51] <cjwatson> python-apt does it too in a different way
[19:52] <cjwatson> If you have it you can use it.  I suggested python-debian because it doesn't depend on the apt libraries
[19:52] <zykes-> ok :)
[19:53] <cjwatson> python-apt mostly wants to operate on an apt cache, but it does have the apt_pkg.TagFile class which parses files of the general format used in Packages and Sources
[19:59] <cjwatson> The difference is basically that python-apt does the parsing in C++ via the apt libraries, while python-debian is in pure Python
[20:00] <cjwatson> Both support Python 3 with sufficiently recent versions; python-apt is probably generally faster at runtime
[20:00] <cjwatson> I often use a mix of the two depending on what I need
[20:06] <zykes-> cjwatson: what's the whole non-free main universe multiverse stuff for ubuntu ?
[20:55] <cjwatson> zykes-: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-sections
[20:56] <cjwatson> zykes-: briefly, main -> free+supported; restricted -> non-free+supported (hardware drivers only); universe -> free+unsupported; multiverse -> non-free+unsupported
[20:57] <cjwatson> although the meaning of "supported" there is currently fuzzy and so this is subject to change to fix that
[21:00] <mterry> mpt, poke.  Looking at SoftwareUpdates spec.  In the "available updates" part, you say that if a package isn't a dependency of ubuntu-desktop, it shouldn't be a part of the "Ubuntu base" item.  Is that true even for packages that don't have .desktop files?  (i.e. xubuntu-common or some such?)
[21:04] <cjwatson> Note that ubuntu-standard and ubuntu-minimal, and their dependencies, are intentionally not dependencies of ubuntu-desktop.
[21:05] <cjwatson> (Essentially to avoid cascading problems when people decide they want to substitute their own piece there.)
[21:22] <mterry> cjwatson, good note, thanks
[21:22] <jtaylor> achiang: I filed bug 1091411, happy testing ;)
[21:23] <achiang> jtaylor: thanks
[23:27] <semiosis> fwiw, i just got a ppa upload rejected email from launchpad for some other user's ppa
[23:27] <semiosis> i uploaded to mine & got rejected from someone elses
[23:27] <semiosis> if anyone cares to look into it i can forward the rejection email & any other info you need
[23:28] <semiosis> on second try i got an accepted email for my ppa