[07:27] <seb128> hey
[07:27] <seb128> could somebody help to understand that
[07:27] <seb128>  https://lists.ubuntu.com/archives/ubuntu-desktop/2015-February/004636.html
[07:27] <seb128>  why is the sync bug #1420948 reaching the desktop list?
[07:27] <ubot5> bug 1420948 in appstream-glib (Ubuntu) "Sync appstream-glib 0.3.4-1 (universe) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/1420948
[07:27] <seb128> "You received this bug notification because you are a member of GNOME3
[07:27] <seb128>  Team, which is subscribed to appstream-glib in Ubuntu."
[07:28] <seb128> but https://launchpad.net/~gnome3-team/+contactaddress
[07:49] <wgrant> seb128: ~ubuntu-desktop is a member of that team, and that team doesn't have a contact address.
[07:51] <seb128> oh, ok
[07:51] <seb128> that makes sense, thanks
[07:56] <darkxst> wgrant, why can't we forward mail to another team address?
[07:57] <darkxst> for seb128's issue above
[08:00] <wgrant> darkxst: What do you mean?
[08:01] <darkxst> wgrant, I can't use a Mailing list from a different team
[08:02] <wgrant> darkxst: That's correct and unavoidable.
[08:02] <wgrant> But why is bugmail going to the team anyway?
[08:02] <wgrant> Team subscriptions are almost always the wrong move.
[08:02] <darkxst> wgrant, MIR's
[08:03] <darkxst> seems to be  a pretty hard pre-requisite there
=== s8321414_ is now known as s8321414
[10:16] <HeOS> cjwatson, it's very interest - when my simple script is overloaded a staging.
[10:17] <Saviq> hey guys, I can't seem to add rtm tasks to any bugs all of a sudden, LP times out, any details I can supply?
[10:19] <wgrant> HeOS: staging runs on old, underspecced hardware. It's designed for testing and experimentation, not high-volume API scripts.
[10:19] <wgrant> Saviq: What's the OOPS ID?
[10:19] <Saviq> wgrant, OOPS-3f28155a61737185419afe0d45feacad for example
[10:19] <ubot5> https://oops.canonical.com/?oopsid=OOPS-3f28155a61737185419afe0d45feacad
[10:20] <Saviq> looks like a db timeout? yikes
[10:20] <wgrant> Saviq: Nothing obvious, probably just database server overload.
[10:21] <wgrant> I'd wait a few minutes and try again.
[10:21] <Saviq> wgrant, ok will do
[10:21] <wgrant> We're just weeks away from finally replacing the >7yo DB servers.
[12:18] <pstolowski> hey guys, https://bugs.staging.launchpad.net/ seems to be down; it's the first time i'm trying to use it, so not sure if it usually works?
[12:48] <HeOS> I don't touch a staging today. :)
[13:53] <cjwatson> pstolowski: It's not very reliable in general, but it's back up now.
[13:55] <pstolowski> cjwatson, great, thanks!
[16:28] <shadeslayer> could someone explain to me how dput parses incoming                = ~%(ppa)s for launchpad's ppas
[16:33] <cjwatson> shadeslayer: dput doesn't parse it, it just turns into a directory on upload.ubuntu.com
[16:33] <cjwatson> or ppa.launchpad.net as the case may be
[16:34] <shadeslayer> cjwatson: I still don't get how ~%(ppa)s works :)
[16:34] <shadeslayer> I'm trying to implement somthing similar for my host
[16:34] <shadeslayer> so that I can have a more generic config
[16:35] <shadeslayer> instead of having a entry for each upload target, where the final dir is the only thing that's different
[16:35] <cjwatson> Here's the internal comment on the various schemes we support: http://bazaar.launchpad.net/+branch/launchpad/view/head:/lib/lp/archiveuploader/uploadprocessor.py#L726
[16:36] <shadeslayer> aha
[16:36] <shadeslayer> thanks!
[16:36] <cjwatson> So, OK, dput does do *some* parsing
[16:37] <cjwatson> In that it substitutes the bit after ppa: on its command line in place of %(ppa)s
[16:37] <shadeslayer> ^^ :)
[16:37] <shadeslayer> right
[16:37] <cjwatson> But the hard work of working out what that actually *means* is up to LP
[16:38] <shadeslayer> HOST ARGUMENT
[16:38] <shadeslayer>        If a user passes an argument to a host by appending the hostname with a colon, %(HOSTNAME)s will be replaced with the specified argument. Otherwise, it will be  replaced
[16:38] <shadeslayer>        with an empty string.
[16:38] <shadeslayer> aha ^^ , found it in man dput.cf
[16:38] <cjwatson> right - sorry, took me a while to work out what you meant
[16:38] <shadeslayer> right
[16:38] <shadeslayer> cjwatson: thanks anyway! :D
[16:38] <shadeslayer> this will make my life so much easier :p
[16:53] <shadeslayer> so, uhm, question, if I call something like : echo $dput_config | dput -c /dev/stdin foo:bar/baz foobar.changes
[16:53] <shadeslayer> could something potentially go wrong with parallel calls ?
[16:54] <shadeslayer> i.e. config gets mangled because multiple things are writing to stdin?
[16:57] <cjwatson> what are your multiple things writing to stdin?
[16:58] <cjwatson> I only see one
[17:00] <shadeslayer> cjwatson: if I run multiple instances of that command parallely
[17:00] <shadeslayer> as far as I can see, stdin doesn't get mangled with my test
[17:02] <shadeslayer> my test : https://paste.kde.org/pu5snozp6
[17:03] <cjwatson> shadeslayer: they're different stdins
[17:03] <shadeslayer> oh ...
[17:03] <cjwatson> /dev/stdin is a symlink to /proc/self/fd/0, which is whatever the process in question's fd 0 is
[17:04] <shadeslayer> ahhh
[17:04] <shadeslayer> so every process gets it's own copy of stdin, stdout, stderr
[17:04] <shadeslayer> right