[01:52] <MTecknology> lifeless: but i don't like reporting bugs :(
[01:52] <lifeless> MTecknology: we don't like having them either
[02:00] <MTecknology> lifeless: alrighty... bug 771568 filed and waiting for smart people :D
[02:00] <ubot5> Launchpad bug 771568 in Bazaar "nest-part unable to nest files" [Undecided,New] https://launchpad.net/bugs/771568
=== nhandler is now known as Guest956
=== nhandler_ is now known as nhandler
[02:18] <MTecknology> lifeless: ya know.... the easy option would be to just let users use shell commands in lp recipes.... I made this work with that
[02:18] <lifeless> MTecknology: runs in a trusted context; not at all easy to change
[02:18] <spiv> MTecknology: thanks, I've posted some analysis on the bug
[02:18] <StevenK> MTecknology: That's *DANGEROUS*, which is exactly why we forbid it.
[02:22] <MTecknology> StevenK: i know... :(    maybe lock down the environments :D
[02:23] <spiv> MTecknology: Or, alternatively, we could fix the nest-part feature :)
[02:23] <MTecknology> spiv: so I'll be able to start doing recipe builds this way tomorrow? :D
[02:23] <StevenK> MTecknology: As lifeless says, the recipe is evaluated in a trusted context. The environment the recipe is built in is an untrusted sandbox.
[02:23] <StevenK> MTecknology: Possibly not tomorrow, but 'soon'?
[02:23] <MTecknology> well... I was hoping by the end of the night... but...
[02:24] <StevenK> We can't quite rollout that fast. Yet.
[02:24] <MTecknology> i suppose I can wait- if i have to- for someone else to fix it- instead of me
[02:24] <MTecknology> I'm just delighted it's not a horribly hard fix.
[02:25] <MTecknology> nightly builds for nginx were just tossed into my head today so the urgency is pretty low
[02:26] <MTecknology> ah crap... I'm going to need a CHANGES file....
[02:31]  * MTecknology wonders what the longest recipe currently in use is..
[02:31] <MTecknology> bet mine is pretty far up the latter
=== sinzui changed the topic of #launchpad to: https://launchpad.net/ | Help contacts: - | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/
=== Ursinha is now known as Ursinha-afk
[06:51] <aviksil> I'm having problem in uploading *source.changes file to my ppa using dput. it's stalling during uploading. Any idea? Other files are uploaded successfully.
[07:23] <rgl> hi
[07:23] <rgl> is there a way to get statistics about PPS usage?
[07:23] <rgl> err PPA usage!
[07:24] <wgrant> rgl: You can get basic stuff through the API, but it's a bit raw at the moment.
[07:25] <wgrant> See the getDailyDownloadTotals/getDownloadCount/getDownloadCounts methods on https://api.launchpad.net/+apidoc/devel.html#binary_package_publishing_history . Suggestions for improvement welcome.
[07:25] <rgl> humm didn't known there was an ap :-)
[07:25] <rgl> thx, will check :)
[07:28] <microcai> jcsackett:  thanks , my package now appears on PPA
[07:31] <rgl> wgrant, for example, how one would get the stats for https://launchpad.net/~rgl/+archive/elasticsearch/+files/elasticsearch_0.16.0-0ubuntu1_amd64.deb ? I can see the url https://api.launchpad.net/devel/<distribution.name>/+archive/<binary_package.name>/+binarypub/<id> on the docs, but what value should I use in the <id> and other <param>?
[07:34] <wgrant> rgl: You'd get the PPA using something like lp.people['rgl'].getPPAByName(name='elasticsearch'), then use something like ppa.getPublishedBinaries(binary_name='elasticsearch', version='0.16.0-0ubuntu1')
[07:34] <wgrant> That will give you a list of binary_package_publishing_history objects.
[07:34] <wgrant> On which you can call the methods I referenced.
[07:34] <rgl> humm lp is the python launchpadlib?
[07:35] <wgrant> That's the normal way to use it, yes. See https://help.launchpad.net/API/launchpadlib
[07:35] <wgrant> That page calls the object 'launchpad' where I've used 'lp', but same thing.
[07:37] <rgl> I see . thx!
[07:37] <wgrant> Hopefully one day we will have pretty graphs.
[07:37] <wgrant> But not yet.
[07:37] <rgl> hope the lib that ships with ubuntu 10.04 will work =)
[07:37] <wgrant> Yup.
[07:38]  * rgl brb quick reboot..
[08:19] <xdatap> morning everybody
[08:21] <xdatap> guys, we've some problem on the project ubuntu-it on launchpad: https://launchpad.net/ubuntu-it we get Timeout error.
[08:25] <wgrant> xdatap: Let me have a look.
[08:26] <xdatap> wgrant, please note that https://launchpad.net/~ubuntu-it is working good
[08:27] <xdatap> wgrant, but in top of subpages there's the link without ~
[08:27] <xdatap> wgrant, IE: https://blueprints.launchpad.net/ubuntu-it/+spec/ubuntu-party on the "Overview" link you will find the first link, without ~
[08:39] <rgl> when we upload an PPA can it be built for several distributions?
[08:39] <rgl> or we have to upload the source for all of the dist?
[08:39] <rgl> (the source package)
[08:39] <wgrant> rgl: You can copy the source and binaries to another series if it doesn't need rebuilding.
[08:40] <wgrant> rgl: Or you can use a source package recipe to automatically build from a branch for multiple series.
[08:40] <wgrant> Otherwise, yes, you have to upload to each series separately.
[08:41] <rgl> wgrant, how do you do the recipe? is there an example PPA that shows how to do it?
[08:43] <wgrant> rgl: https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[08:46] <rgl> wgrant, I have to put my "debian" directory on a bazar repo?
[08:58] <rgl> wgrant, https://gist.github.com/943881 Its odd it only accounts for a single download count. but I could use the API. thx :)
[08:59] <StevenK> Argh, a Launchpad script on github
[08:59] <wgrant> rgl: For a recipe, yes, you have to be able to build from bazaar branches (these could be automatic imports from github, if you must use git)
[09:00] <rgl> StevenK, oh is there a gist thingy on lauchpad?  github gist is easy to use for me hehe
[09:01] <wgrant> paste.ubuntu.com is what we tend to use. It's not version-controlled, but that's rarely necessary.
[09:01] <rgl> ack :)
[09:02] <rgl> wgrant, don't recall an example PPA and bazar repo that already does what I want? =)
[09:03] <wgrant> rgl: What do you want to do? did you read the wiki page I linked to?
[09:05] <rgl> wgrant, use a single package source (a bazar branch I guess) to automatically build a PPA that works on several ubuntu dists
[09:05] <rgl> automatically build and upload to launchpad :)
[09:06] <wgrant> rgl: Recipes do the build and upload and several Ubuntu series bits. You just need a branch containing the tree you'd run 'debuild' in locally.
[09:07] <rgl> wgrant, alright. I'll finish read the wiki, and talk to you later :)
[09:07] <rgl> thx for the tips!
[09:07] <wgrant> You can then tell it to automatically build whenever the branch changes, and other nice stuff like that.
[09:07] <rgl> nice :)
[09:07] <wgrant> [A3
[09:07] <wgrant> Gar.
[09:08] <rgl> what?
[09:08] <wgrant> A typo.
[09:08] <wgrant> Well, SSH lag.
[09:08] <rgl> ah ok
[09:11] <lag> wgrant: I haven't said anything! ;)
[09:12] <Sweetshark> hi all! how do I prevent team membership expiration? I am team admin, but just got a note that my membership is about to expire.
[09:13] <wgrant> Sweetshark: On the team page you'll see an "All members" link. There you'll see a list of members and their expiry dates, and an edit link where you can extend the date or remove it entirely.
[09:15] <Sweetshark> wgrant: got there, but the exp date is fixed there. I can only change admin status and fill a comment field.
[09:17] <wgrant> Sweetshark: Ah, I guess it's possible you can't change your own expiry date.
[09:18] <wgrant> Hmm.
[09:18] <wgrant> Sweetshark: Which team?
[09:18] <Sweetshark> wgrant: LibreOffice Packaging
[09:18] <Sweetshark> ^^^ doko_
[09:19] <Sweetshark> wgrant: doko_ is admin (and owner) there too, maybe he can change it?
[09:19] <wgrant> Sweetshark: He should be able to, yes.
[09:20] <wgrant> Sweetshark: Admins can't change their own expiry date unless they're also the owner.
[09:20] <doko_> bah
[09:20] <wgrant> Which I guess makes sense, or there wouldn't be much point.
[09:27] <xdatap> wgrant, sorry again. did you checked the problem on the ubuntu-it project? What do you reccommend?
[09:30] <wgrant> xdatap: It's bug #739051, no real workaround right now. What did you want from that page?
[09:30] <ubot5> Launchpad bug 739051 in Launchpad itself "Product:+index timeouts" [Critical,Triaged] https://launchpad.net/bugs/739051
[09:32] <xdatap> wgrant, well it's the prject that indetify our loco team. We use it for blueprints mainly
[09:33] <xdatap> wgrant, ok, i'll subscribe the bug. Thanks for your time
[09:33] <wgrant> xdatap: Right, but blueprints.launchpad.net/ubuntu-it should still work fine.
[09:33] <xdatap> wgrant, yes
[09:33] <wgrant> Just launchpad.net/ubuntu-it won't for now.
[09:34] <xdatap> wgrant, yes, it's not critical
[09:35] <xdatap> wgrant, but somebody should have it on its bookmark, we've got this from users
[09:36] <wgrant> Hmm.
[09:36] <xdatap> wgrant, no problem btw, we'll wait until it's fixed
[09:36] <xdatap> wgrant, thanks again
[09:37] <wgrant> Great.
=== Ursinha-afk is now known as Ursinha
=== yofel_ is now known as yofel
=== mrevell is now known as mrevell-lunch
=== adeuring1 is now known as adeuring
=== mrevell-lunch is now known as mrevlel
=== mrevlel is now known as mrevell
=== doko_ is now known as doko
=== benji is now known as Guest41434
=== jcsackett changed the topic of #launchpad to: https://launchpad.net/ | Help contacts: jcsackett | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/
=== benji____ is now known as benji
[14:13] <MTecknology> spiv: alrighty.. i'm trying it out...
[14:18] <MTecknology> spiv: lovely! was able to build, but failed to upload
[14:19] <MTecknology> and now past my natty quota :P
[14:35] <MTecknology> In the debian/rules file... if I add something to .PHONY, it should be run, right?
[14:35] <MTecknology> .PHONY: build clean binary-indep binary-arch binary install -->  .PHONY: setup build clean binary-indep binary-arch binary install
[14:35] <james_w> nope
[14:35] <MTecknology> setup should run before anything else ?
[14:36] <MTecknology> am I understanding the .PHONY line wrong?
[14:36] <james_w> PHONY means that the target doesn't correspond to a file on disk
[14:36] <MTecknology> oh...
[14:36] <james_w> the change you made just tells make that it should ignore any "setup" file that it finds on disk and always run the target when something has it as a pre-requisite
[14:36] <james_w> when do you want setup to run?
[14:37] <james_w> it it something like ./configure?
[14:37] <MTecknology> it's before that
[14:37] <james_w> but similar?
[14:37] <MTecknology> ya
[14:37] <james_w> or something that has to run before clean?
[14:38] <MTecknology> ya
[14:38] <james_w> then make build have it as a prerequisite
[14:38] <MTecknology> would 'clean: setup' make sense?
[14:38] <MTecknology> or build:
[14:38] <james_w> yes, if it has to run before clean
[14:39] <MTecknology> thanks :)
[14:39] <MTecknology> I understood that puppy horribly wrong
[14:44] <spiv> MTecknology: glad to hear you're making progress :)
[14:53] <MTecknology> spiv: shouldn't ~natty1 increment itself?
[14:54] <MTecknology> failing to upload because the upload already happened and that number doesn't increment
[14:56] <MTecknology> I could add {time}, but that seems to defeat the point of having a number at the end of the series
[15:03] <spiv> MTecknology: you set the version template in the recipe
[15:04] <spiv> MTecknology: actually, I guess you understand that
[15:04] <spiv> I'm not sure what your issue is, and it's bedtime here :)
[15:04] <spiv> I'm sure someone that's awake can figure it out though :)
[15:05] <MTecknology> spiv: {debupstream}-svn{revno}-ppa{revno:packaging}  ... will produce 1.0.0-svn3185-ppa199~maverick1
[15:05] <MTecknology> spiv: but if that was uploaded already, it's not smart enough to produce 1.0.0-svn3185-ppa199~maverick2 instead
[15:05] <MTecknology> that makes it fail to upload...
[15:07] <spiv> MTecknology: off the top of my head that doesn't sound right
[15:07] <spiv> MTecknology: ~maverick1 doesn't occur in your template, why is it in the result?
[15:08] <spiv> But I could just be too sleepy
[15:08]  * spiv -> zzz
[15:08] <MTecknology> spiv: alrighty, probably worth a bug report - and this build just failed anyway
[15:14] <wgrant> spiv, MTecknology: We automatically append that to allow multi-series builds. The number is always 1.
[15:15] <MTecknology> wgrant: why the number if the number is always the same?
[15:16] <MTecknology> I love the addition of ~series, just assumed the number added was intelligent
[15:16] <wgrant> It's conventional to always have a number (like backports do).
[15:17] <MTecknology> maybe a feature request to make it more useful?
=== deryck is now known as deryck[lunch]
[16:09] <aber> I try create a new source package recipe. Is it as easy as pulling the debian section from a release merge it into the branch?
[16:40] <Technoviking> mrevell and lifeless: We need to get the Launchpad login plugin the LP team designed for the forums upgrade to work with the version of the forums software we are upgrading to.
[16:41] <Technoviking> Can we get that on the LP team schedule and something in the next couple of months?
[16:42] <jcsackett> aber: not exactly sure i parse your question right, but there's help for recipes on the help wiki https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[16:42] <mrevell> Hey Technoviking
[16:44] <Technoviking> mrevell: hiya
=== deryck[lunch] is now known as deryck
=== beuno is now known as beuno-lunch
[17:34] <aber> jcsackett: Looks like i did it :)
[17:34] <jcsackett> aber: as in, things are working for you?
[17:54] <aber> Like, it compiled successful. But my version string is not as expected.  debian version is: '1:16-1', i used {debupstream}-0~{revno} and i got 16-0~5900
[17:55] <aber> Is this correct, so i have to use 1:{debupstream}-0
=== beuno-lunch is now known as beuno
[18:35] <aber> I'm not able to rebuild the package, because the file already exits inside the ppa, how can i fix this?
=== zyga is now known as zyga-afk-bbl
[18:41] <jcsackett> aber: i'm sorry, i missed your earlier comments. we're sadly veering out of my area of knowledge.
[18:41] <jcsackett> abentley: is there any chance you can help aber? you did a great deal of the recipe stuff, right?
=== sinzui changed the topic of #launchpad to: https://launchpad.net/ | Help contacts: sinzui | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/
[18:57] <aber> jcsackett: Thank you. I just included the timestamp and now it works. It is a bit strange...
[18:59] <jcsackett> aber: when you say you included timestamp, do you mean in the version num? i do know that ppa's require the version number to be bumped anytime you make make changes.
[18:59] <jcsackett> since otherwise, there is no way to signal to users of your ppa that they need to update.
[19:01] <aber> I changed the version from 16-0 to 1:16-0. And that did not work.
[19:07] <trijntje> ping fta
[20:03] <kirkland> hmm, having some mailing list issues with ecryptfs-devel
[20:03] <kirkland> some messages aren't making it through
[20:04] <kirkland> i need to do two things ...
[20:04] <kirkland> 1) figure out why these messages aren't making it through
[20:04] <kirkland> 2) disable moderation
[20:05] <sinzui> \o/
[20:05] <sinzui> kirkland: I pinged you last week about that
[20:06] <kirkland> sinzui: oh?
[20:06] <kirkland> sinzui: sorry, i was sprinting last week, must have missed it
[20:06] <sinzui> kirkland: that list has 100's of messages in its moderation queue. the next highest is 30. the average is 0
[20:07] <kirkland> sinzui: https://launchpad.net/~ecryptfs-devel/+mailinglist-moderate says "There are no mailing list messages requiring your review."
[20:07] <tyhicks> kirkland: FWIW, I see the same thing
[20:08] <kirkland> sinzui: this mailing list has always been problematic, for unexplained reasons...
[20:08] <tyhicks> same thing == "There are no mailing list messages requiring your review."
[20:08] <kirkland> sinzui: tyhicks is an admin of ~ecryptfs-devel too
[20:08] <sinzui> Oh, I may be thinking of ~ecryptfs. Can you make me a team admin so that that I want investigate the messages?  I will clear the queue for you :)
[20:10] <kirkland> sinzui: sure
[20:10] <kirkland> sinzui: LP id = irc nick?
[20:10] <sinzui> okay, now I will think about ~ecryptfs-devel. Lp lists except emails from from team members. Lp users are moderated...but once their first message is approved, all subsequent messages will go directly to the list
[20:10] <tyhicks> Hmm... it seems that the link in the notifications from launchpad about pending messages is wrong
[20:11] <sinzui> kirkland: ~sinzui
[20:11] <tyhicks> kirkland: https://launchpad.net/~ecryptfs/+mailinglist-moderate shows > 400 messages pending
[20:11] <kirkland> sinzui: done
[20:11] <kirkland> tyhicks: sweet;  knock yourself out on that one :-)
[20:12] <sinzui> I have a high tolerance for data. I have read every project page in Lp
[20:12] <sinzui> I have no social life
[20:12] <tyhicks> kirkland: ecryptfs-devel seems to be moderated at the link with ~ecryptfs instead of ~ecryptfs-devel
[20:12] <kirkland> tyhicks: yeah, odd
[20:13] <kirkland> sinzui: i'll make you admin of ~ecryptfs too
[20:13] <sinzui> thanks
[20:14] <kirkland> wow, russian ladies are ALL ABOUT ecryptfs
[20:14] <tyhicks> :)
[20:14] <sinzui> I am looking at -devel first since you think messages are missing. Do you know which user is missing email to start the hunt
[20:15] <tyhicks> sinzui: For example, look at this thread: http://article.gmane.org/gmane.linux.kernel/1131956
[20:15] <tyhicks> sinzui: We never received a notification that Roberto's emails were pending and they never seemed to hit ecryptfs-devel, despite him cc'ing the list
[20:15] <tyhicks> sinzui: But then Casey Schaufler replied and that hit ecryptfs-devel
[20:16] <sinzui> roberto.sassu is not a launchpad user, or at least, he has not registered that email address: https://launchpad.net/people/?name=roberto.sassu%40polito.it&searchfor=peopleonly
[20:16] <tyhicks> sinzui: So he can't send email to the list?
[20:16] <sinzui> No
[20:16] <tyhicks> ...
[20:17] <tyhicks> sinzui: Is there a switch to flip to allow that?
[20:17] <tyhicks> (on a per-project basis)
[20:17] <sinzui> No. Lists are for team members with an exception for launchpad users
[20:18] <kirkland> sinzui: tyhicks: i'm manually clearing out the spam now
[20:18] <sinzui> Without an address matching an active lp user profile, the message is immediately discarded.
[20:18] <tyhicks> sinzui: So the spammers are lp users? :)
[20:18] <kirkland> tyhicks: hmm, we might need to find a different mailing list solution :-(
[20:18] <tyhicks> kirkland: Agreed
[20:18] <sinzui> kirkland: that can be true, a few have done that
[20:19] <kirkland> sinzui: any pointers?
[20:19] <sinzui> We have a script that can import the users from an mbox archive to setup a team or list. I do not think that helps you :(
[20:19] <kirkland> tyhicks: we can probably get one at kernel.org, right?
[20:19] <tyhicks> kirkland: Probably - would you like me to look into that?
[20:19] <kirkland> tyhicks: yeah, please
[20:20] <tyhicks> will do
[20:20] <tyhicks> sinzui: Thanks for your help
[20:20] <kirkland> sinzui: agreed, thanks
[20:20] <sinzui> tyhicks: We can provide the mbox if you want to preserve history.
[20:21] <tyhicks> sinzui: That would be helpful
[20:21] <tyhicks> sinzui: Let me look into other options and if we can import an mbox first, before you do anything
[20:21] <sinzui> okay
[20:22] <kirkland> sinzui: is there any way we could forward messages to ecryptfs-devel@launchpad to the new list, at least for a short time?
[20:22] <kirkland> sinzui: set it as the contact address, or some other hack?
[20:23] <tyhicks> sinzui: I was joking earlier, but I really am curious about how spam gets through to require list moderation in the first place? It seems like it would be dropped immediately, too.
[20:24] <sinzui> tyhicks: that is why I was perplexed about this one list. I know know the answer
[20:25] <sinzui> There was a bug were you could send an email claiming to be from the list itself...the list knows it has a valid email address. That bug was closed, but ~ecryptfs spam is from ~ecryptfs-devel. Was the team/list renamed in the past?
[20:25] <sinzui> I can see that no spam was queued after the fix was released?
[20:26] <sinzui> kirkland: we do not have a means to setup an alias for a launchpad list address.
[20:27] <tyhicks> kirkland: I don't remember a rename, but could be mistaken
[20:27] <kirkland> tyhicks: sinzui: okay, 500+ clicks later, https://launchpad.net/~ecryptfs/+mailinglist-moderate is clean
[20:27] <tyhicks> oops, that was for sinzui
[20:28] <kirkland> sinzui: it's possible, i don't recall
[20:28] <sinzui> ah, that explain why by clicks seem to have done nothing
[20:29] <lifeless> wait what
[20:29] <sinzui> kirkland: okay. I will continue to investigate this.
[20:29] <lifeless> we're losing a mailing list?
[20:30] <tyhicks> lifeless: Probably so - an open source project's mailing list should accept mail from non-lp users
[20:31] <sinzui> lifeless: Lp requires all the list participants to be Lp users
[20:31] <lifeless> sinzui: was it always like that?
[20:31] <sinzui> yes, be design in fact
[20:31] <lifeless> ah
[20:31] <lifeless> do we tell the non-lp user that their mail is being non-delivered and not-queued-for-moderation ?
[20:32] <sinzui> though as you can see, this makes it challenging to grow a community by casual acquaintance.
[20:32] <lifeless> yes
[20:33] <lifeless> Is this an easy to change policy?
[20:33] <sinzui> barry wrote an importer that can setup users from an mbox, this helps lists migrate to Lp, but the central issue of growing contributors is not addresses.
[20:33] <lifeless> or is it complex and hard?
[20:33] <lifeless> sinzui: are we happy with this by-design thing, or is it something we'd consider changing?
[20:34] <sinzui> complex, though I do not believe it is a lot of code. I think there are nuances about trust
[20:35] <sinzui> lifeless: , sorry missed your other question. The non-lp user's message is quietly discarded.
[20:36] <sinzui> Mm has a name for that, umm...vette
[20:36] <sinzui> anything that hits that rule is silently dropped
[20:37] <tyhicks> sinzui: Is this documented very well?
[20:37] <lifeless> sinzui: so, I think minimally that silently dropping casual mails is pretty poor form
[20:37] <sinzui> No. I learned about it when I wrote a replacement test and discovered the behaviour
[20:38] <tyhicks> lifeless: I agree
[20:38] <lifeless> sinzui: who set that design rule, or can we reevaluate? It sounds like you're not completely in favour of it either?
[20:38] <sinzui> I think I can speak confidently about how it does work and how to change it
[20:38] <sinzui> lifeless: sabdfl
[20:38] <lifeless> flacoste: ^ yo :)
[20:39] <lifeless> tyhicks: imagine some pepy hold music for a minute :)
[20:39] <lifeless> tyhicks: just finding how rock-solid this is
[20:39] <tyhicks> lifeless: Thanks for digging in
[20:40] <sinzui> but we can change it. I put thought to it when I discovered the behaviour. I pondered an implicit import user rule liek we do with po files and code. We need to have away to ensure spam does not get out of hand again
[20:41] <tyhicks> sinzui: Can you explain what you're thinking about an implicit import user rule?
[20:41] <lifeless> sinzui: well, if it was like this from the start, then we've never tried without it ;>
[20:41] <tyhicks> sinzui: Seems like manual moderation of non-lp users' mail would be feasible, but allowing the moderator to check a box to always allow this user to email the list from now on
[20:42] <sinzui> Just accepting the email will not allow us to except the user from future posts, which is what the moderation queue does for approved users. The approve could setup the profile with the address and name. It will not be active, but could be considered usuable for lists
[20:43] <sinzui> tyhicks: you are actually doing that each time you approve a message. the issue is that the queue required the email address to be associated with an existing user.
[20:43] <tyhicks> sinzui: ok - now I understand, thanks
[20:44] <lifeless> sinzui: that sounds like a reasonable compromise; and if a spammer registers one of these we can zap it to banned
[20:45] <sinzui> Suspend does the right thing. I have used it to stop users from sending.
[20:45] <lifeless> \o/
[20:45] <lifeless> tyhicks: lets start with a bug report on this
[20:45] <sinzui> I believe this is one, though it does not have this analysis
[20:46]  * sinzui looks
[20:46] <lifeless> thanks!
[20:47] <sinzui> btw, the ~ecryptfs was a victim of this bug 770329
[20:47] <ubot5> Launchpad bug 770329 in Launchpad itself "Mailing lists must reject emails that claim to be from teams." [Critical,Triaged] https://launchpad.net/bugs/770329
[20:50] <sinzui> I am opening  new bug since I do not see a bug that really phrases the issue as we discussed. I think the one I have in mind was duped against another bug because this issue often includes several items in one bug
[20:56] <lifeless> cool
[20:56] <lifeless> grabbing food, back in a bit
[20:58] <kirkland> "Jamie Strandboge (jdstrand) has assigned this bug to you for vsftpd in Ubuntu:" ...
[20:58] <kirkland> technically, he assigned it to a team that I'm a member of
[20:58] <kirkland> rather than me, personally
[20:59] <kirkland> it would be nice if LP's emailer made that distinction in this first line of the email
[20:59] <beuno> big +1
[21:00] <beuno> I get confused by that all the time
[21:00] <sinzui> I thought this was bug 599436, but I see it is different.
[21:00] <ubot5> Launchpad bug 599436 in Launchpad itself "email footer for assignee is technically incorrect" [Low,Triaged] https://launchpad.net/bugs/599436
[21:02] <flacoste> lifeless, sinzui: i think creating inactive profile for outside contributors is a good compromise
[21:03] <flacoste> it does mean that people will have to moderate more spam though
[21:03] <flacoste> whereas that's not the case now
[21:03] <lifeless> right
[21:03] <flacoste> and by looking at the moderation for lists.canonical.com
[21:03] <flacoste> that would be a lot
[21:03] <lifeless> OTOH not getting cc'd peoples emails == very surprising
[21:04] <flacoste> well
[21:04] <flacoste> is it
[21:04] <flacoste> people are used to 'look into spam folder' dead hole
[21:04] <lifeless> nuances: private lists
[21:04] <lifeless> flacoste: they are, but we don't have that here :)
[21:05] <flacoste> no, but i mean, sending email and the recipient doesn't receive it is annoying, but is common place nowadays
[21:05] <flacoste> spam is a prevalent problem with email
[21:06] <lifeless> true
[21:06] <flacoste> and given barry credentials he took the 'minimize spam problems' approach to the design
[21:06] <flacoste> so discard instead of bounce to avoid bounce-back-spam issues
[21:06] <flacoste> discard unknown lp users to avoid infinite moderation list
[21:07] <flacoste> in a way, i'm sure that if we changed behavior
[21:07] <flacoste> we'd get a lot of people stopping using lists because there is too much moderation to do
[21:07] <flacoste> because of spam
[21:08] <lifeless> stop using
[21:08] <lifeless> or use a different provider?
[21:10] <sinzui> lifeless: flacoste: https://bugs.launchpad.net/launchpad/+bug/772000
[21:10] <ubot5> Ubuntu bug 772000 in Launchpad itself "allow non-lp users to post to mailing lists" [Low,Triaged]
[21:13] <flacoste> i'm wont-fixing this actually
[21:14] <lifeless> flacoste: really?
[21:14] <lifeless> flacoste: I think we need to do something about the surprise minimally
[21:14] <lifeless> flacoste: currently we have an undocumented eat-your-contributors-mail feature :(
[21:15] <lifeless> flacoste: I'm not arguing /for/ non-users being able to post - look at google groups which requires a signup as well
[21:15] <lifeless> flacoste: I think the drop-on-the-floor behaviour is the crucial element of OMG surprise
[21:15] <flacoste> again, changing that would cause more trouble
[21:15] <sinzui> I think we could make this work if we have a satisfactory trust check.
[21:16] <flacoste> sinzui: dkim?
[21:16] <lifeless> flacoste: you're talking about spam backscatter ?
[21:16] <flacoste> yes
[21:16] <flacoste> the ratio of legitimate use to spam is probalby in the order of 1-1000
[21:16] <lifeless> flacoste: I can think of several ways to mitigate that
[21:16] <flacoste> maybe even more
[21:16] <sinzui> well, you must be aware that 80% of all Lp spam is from gmail
[21:17] <flacoste> sinzui: through gmail or fake gmail address?
[21:17] <sinzui> gmail. Users discover the spam in the gmail sent folder
[21:18] <sinzui> or how what every gmail uses to model sent emails
[21:18] <flacoste> sinzui: ah, so browser exploits
[21:18] <flacoste> interesting
[21:18] <sinzui> and phone appently
[21:18] <flacoste> haha
[21:18] <flacoste> even better
[21:19] <sinzui> regardless. We deal with 2-5 spammers every week. they are all Lp users. To move forward, we need to see that lists are dropping
[21:31] <tyhicks> sinzui: I'm going to drop you from the ecryptfs groups now - is that alright?
[21:32] <maco> https://bugs.launchpad.net/launchpad/+bug/614948 and https://bugs.launchpad.net/launchpad/+bug/155956 are duplicates of each other i think
[21:32] <sinzui> yes thanks
[21:32] <ubot5> Ubuntu bug 614948 in Launchpad itself "Option for list of sponsored uploads" [Low,Triaged]
[21:32] <ubot5> Ubuntu bug 155956 in Launchpad itself "+me/+packages should present different sections for sponsored uploads" [Low,Triaged]
[21:32] <sinzui> ^ tyhicks yes, thanls
[21:33] <tyhicks> ack
[21:34] <sinzui> maco: thanks! I agree. I think I may be able to link this to another class of bugs too
[21:34] <tyhicks> sinzui: Hm... is 'deactivate' the right thing to do?
[21:34] <sinzui> tyhicks: yes
[21:49] <maco> sinzui: in 570856 i was actually asking something slightly different though
[21:50] <maco> 155956 is about on your +me, showing a list of everything you've sponsored for others.  570856 i was looking for having an icon  *other* people's +packages page to indicate which of theirs you were the sponsor for
[21:50] <maco> (if you sponsor a lot, you may lose track of whether you've sponsored for that person yet or not)
[21:50] <sinzui> It is slightly different, but I think both perspectives are the same bug
[21:52] <maco> sinzui: can i modify 570856's description to say both views?
[21:53] <sinzui> maco: please do
[21:54] <sinzui> I should have done that or copied the extra info to a comment. My bad
[21:57] <lifeless> kirkland: hi
[21:57] <kirkland> lifeless: howdy
[21:57] <lifeless> we're not going to change the list behaviour short term
[21:57] <lifeless> bug 772000
[21:57] <ubot5> Launchpad bug 772000 in Launchpad itself "allow non-lp users to post to mailing lists" [Low,Triaged] https://launchpad.net/bugs/772000
[21:57] <lifeless> we've filed another high bug about the fact its not documented
[21:58] <lifeless> changing the behaviour is a high impact thing because our net reputation as a mail host can easily get trashed if we start sending thousands or millions of NDRs in backscatter
[21:58] <lifeless> and we currently don't really have spam integration at all with l.l.n
[21:58] <lifeless> kirkland: this is a darn tricky area and spam sucks.
[21:59] <kirkland> lifeless: understood
[21:59] <kirkland> lifeless: i think we can get a mailing list at kernel.org for ecryptfs
[21:59] <lifeless> kirkland: how does kernel.org handle spam ?
[22:00] <kirkland> lifeless: no idea
[22:00] <lifeless> kirkland: and as a user, if you had dozens of spam a day to moderate, bu would get mails like this, is that a better or worse tradeoff ?
[22:00]  * lifeless is fishing for data
[22:00] <kirkland> lifeless: no better;  i moderated the 500 spams in the ecryptfs queue today
[22:00] <flacoste> kirkland: make that hundred
[22:00] <flacoste> daily
[22:01] <flacoste> that's what we get on our lists which are not hosted by LP
[22:01] <lifeless> flacoste: ! not on the lists I moderate (bzr
[22:01] <flacoste> interesting
[22:02] <lifeless> anyhow
[22:02] <flacoste> is the bzr mailing list less widespread than launchpad-feedback?
[22:02] <flacoste> i mean its address
[22:02] <lifeless> flacoste: I don't see why it would be
[22:02] <lifeless> it was unobfuscated on the wiki for a long time
[22:02] <lifeless> flacoste: launchpad-feedback is a poor data point, because we want everything to reach it
[22:03] <lifeless> flacoste: it probably has its spam threshold tuned way down *so that* we can be reached.
[22:03] <flacoste> maybe
[22:03] <lifeless> (just guessing, elmo would know)
[22:08] <sinzui> launchpad-feedback We have been driving users away from that address for the last 7 months too
=== Ursinha is now known as Ursinha-afk
[23:46] <aber> hello, is the number of hosts available for the launchpad build farm lower then normal, because of the upcoming release?
[23:52]  * sinzui checks