[00:01] micahg: ok, thanks for your help [00:05] how long does it usually take for a package to show up in your ppa after uploading it? [00:06] ibbo: a few minutes [00:07] ok, it's not shown up yet, I'll leave it until the morning [03:15] Hey, I'm using Quickly to upload to a PPA (for the first time). I get an email saying that it was rejected because my PPA is disabled. I deleted the PPA a while ago. Why isn't Quickly/Launchpad using a working PPA? What's special about the first one I made? [03:16] aroman: You'll need to ask the Quickly developers. === matsubara-afk is now known as matsubara [11:56] Err... Any idea why I'm getting *hundreds* of e-mail about updates to https://code.launchpad.net/~vcs-imports/glusterfs/trunk ? [11:57] I just unsubscribed now, but they're still pouring in. [11:58] http://launchpadlibrarian.net/59656210/vcs-imports-glusterfs-trunk.log <- Most recent import log... Should I expect 775 e-mails? [12:03] soren: you shouldn't get those emails on an initial import, but if somebody just pushed 775 revisions onto that branch it might happen. [12:03] jelmer: I guess they might have. It just seems a bit extreme. [12:04] I mean.. They seem to push these things in bulk, but never this volume. [12:04] They've done perhaps 40-50 before. [12:05] jelmer: You're probably right. Sorry about the noise. [12:05] sounds like they should be aggregated [12:06] It's a bit of an odd case. In general, I do actually prefer individual e-mails per commit. I'm used to scanning through the headers looking for interesting things. [12:06] This was a bit overwhelming :) [12:07] When they've done the 40-50 commits at a time, it's been fine. [12:07] Yeah, perhaps Launchpad should notice when it's about to send more than say 50 emails to a single person with this sort of notification. [12:08] I received more than a thousand for a single branch one time, my mail server was not happy :-) === yofel_ is now known as yofel [14:02] Hello. I have a special email address that I use in a git trigger to send patches whenever there is a push to a tree. The trigger executes successfully and I see that a mail has been sent successfully to tarantool-developers@lists.launchpad.net in the trigger log. [14:02] However, the mail never arrives to the list. [14:03] Does a sender need to be subscribed to a list to be able to send emails? [14:04] There were no talk back either, seems that the mail is simply lost. [14:05] kostja_osipov: yes, it needs to be subscribed [14:05] okay. thanks! === matsubara is now known as matsubara-lunch [14:36] jml: i started looking at tarantool-developers archive more closely, and discovered that launchpad doesn't deliver some emails that are in the archive to all of the team members. Some of my team members have never received a few emails that are present in the archive. They did, however, receive other email. What can be an explanation of that? These problematic emails came from a email address that is registered on launchpad, but is not the primary [14:46] it seems that auto-subscription to the team mailing lists that is used when a member joins the team doesn't work === jelmer_ is now known as jelmer [14:55] o_O Mr Revell is not here? [15:11] https://bugs.launchpad.net/launchpad/+bug/681813 [15:11] Launchpad bug 681813 in Launchpad itself "Team mailing list feature simply doesn't work (affected: 1, heat: 6)" [Undecided,New] === matsubara-lunch is now known as matsubara [15:37] kostja_osipov: Just curious.. Your e-mail address wouldn't happen to be a gmail one, would it? [15:37] i send from osipov at corp.mail.ru. my recipients are also at corp.mail.ru [15:38] Ok. [15:38] the funny thing is that I do get email. my list subscribers don't [15:38] also, email from launchpad itself does go through. and email does show up in the archive [15:38] most of the time it's delivery that's broken. [15:39] I've just seen GMail silently discard e-mail with a @gmail.com sender address, not originating from one of their mail servers. [15:39] kostja_osipov: Do you control the mail server in question? [15:39] in what way? [15:39] kostja_osipov: Can you look at its logs? [15:39] I mean... Do you actually know for sure that Launchpad doesn't attempt delivery? [15:40] I'm not saying it does. It's just good to know for whoever's going to work on it. [15:40] soren: no, I am not 100% sure. But it would be a very weird behavior on behalf of the receiving server: to accept some mails, but not others [15:41] i.e. the issue is that say, email from 681813@bugs.launchpad.net sent to the list got delivered to all [15:41] but this mail: [15:41] kostja_osipov: It would also be very weird if Launchpad only sent some of the e-mails on the mailing list :) [15:41] https://lists.launchpad.net/tarantool-developers/msg00029.html [15:41] kostja_osipov: It's just not completely clear where the weirdness is. [15:41] did not get delivered to the send and a few others [15:42] yes, it's unclear, i agree. [15:43] s/to the send/to the sender/ === beuno is now known as beuno-lunch [15:47] soren: hm.. [15:48] there is a chance you were right. [15:48] i came to our corporate antispam department, and it turns out their DKIM configuration had issues [15:48] I'm waiting for results. [16:32] soren: there was a bug in our anti-spam system. it's resolved now. thank you so much for the insight! [16:33] (and I closed the bug as invalid) [16:34] kostja_osipov: No problem :) [16:37] is ther any way via the launchpad api to resolve the projects a person has contributed to.. or at least is a member of the driving team? === beuno-lunch is now known as beuno === matsubara is now known as matsubara-afk [17:43] How come staging.launchpad.net is out of sync with launchpad.net? [17:44] aroman, define out of sync? [17:44] aroman: we deploy new code to staging so people can test it. however, it runs against an old copy of the data. [17:45] jml, Well, does it _ever_ resync? [17:45] aroman: yes, about once a week, I think [17:45] jml, Oh boy. [17:45] aroman: why does it matter? [17:45] jml, I'll explain my situation. [17:47] jml, So I'm using Quickly, and I tried to publish my project to my PPA on launchpad. Because of some issues, I had to create a second launchpad account, and delete/deactivate the first one. This all went basically fine. In order to get quickly to work with my launchpad account, I need to tell Launchpad to allow quickly to access it. This is done via the launchpad staging system. However, my account was deleted just yesterday, and [17:47] staging doesn't know about it. [17:48] aroman: why are you using staging at all? [17:49] aroman, That's what quickly uses. I assumed it was because the functionality to allow desktop applications to work with launchpad on my behalf wasn't availible in launchpad proper. [17:49] hmm. [17:49] I'm fairly certain that's not the case [17:50] quickly probably defaults to staging for development purposes [17:50] actually, [17:50] aroman: were I you, I'd ask about this on #quickly, see if they can help you point it at the real Launchpad [17:50] now that I think about it, you're right. [17:51] I did this via the --staging argument, which I found by digging into the code of quickly itself. [17:51] ah :) [17:51] the reason i did this was because it seemed to be the only way to get quickly to switch from my old account to my new account [17:51] and sadly --purge remove'ing it didn't reset its prefs. [17:52] oh, you might have to do something irritatingly tedious like look in ~/.launchpadlib and delete some credentials [17:52] that's the sort of thing I was hoping to hear about :) [17:52] it varies based on the client app [17:52] by the way, quickly share --staging even says: WARNING: you are using staging and not launchpad real production server [17:52] I need to read better [17:52] :) [17:53] if humans paid attention to warnings, the world would be a strange place indeed [17:54] Do you know where I can find the prefs to nuke to reset my connection with launchpad? [17:57] YES! [17:58] $ locate is _the_ most useful command. Found the actual module that manages launchpad integration, and found where it's reading settings from [17:58] ~/.cache/lp_credentials/lp-cache/ [18:41] got the launchpad thing straightened out. I quickly share'd my app, got the accepted email, and trying to apt-add-repository, but it gives me Error: can't find signing_key_fingerprint at https://launchpad.net/api/1.0/~aroman/+archive/purple [18:55] nevermind, it fixed itself. === matsubara-afk is now known as matsubara [19:05] I tried to upload a package I made to my ppa yesterday, but it failed due to it being mixed binary and source. It is a game, so there are media files as well as source. I guess I'll have to split my package in to parts, but I'm struggling to find info on how to do that, can someone point me in the right direction? [19:06] ibbo: I htink the message has confused you [19:06] ibbo: when you prepare it for upload you need the -S switch to debuild [19:06] that doesn't surprise me [19:08] packages have (at the highest level) two components - a Source package and a Binary package. [19:08] we only accept Source packages [19:09] but the content of a Source package can be binary files [19:09] the -S option to debuild/dpkg-buildpackage tells it that you want a source package only. [19:09] right, ok [19:11] I think because my project is pure python it makes less sense for there to be a binary/source distinction [19:11] which I guess is what was confusing me [19:13] indeed [19:14] well source package has uploaded, just have to wait for it to appear, thanks for the help === matsubara is now known as matsubara-afk [23:31] When does PPA support for Jaunty get turned off?