[02:02] <sqwishy> I made a project in staging, how long before it becomes inaccessible?
[02:04] <persia> Unreliable timing, but often less than a day and only exceedingly rarely as much as a week.
[02:05] <lifeless> sqwishy: its reset weekly at the moment
[02:05] <lifeless> sqwishy: but we make no guarantees about when or how often.
[02:05] <lifeless> staging is a QA environment
[02:05] <lifeless> thats its primary use; the fact that users can use it as a playground is nice, but secondary.
[02:06] <sqwishy> ktnx
[02:07] <persia> lifeless, Isn't use as a playground QA on external clients?
[02:07] <lifeless> persia: EPARSE
[02:08] <persia> So, if I'm working on some code that interacts with LP, oughtn't I be QA'ing that against staging?  If so, how is this distinguished from other playground use?
[02:08] <lifeless> persia: qastaging
[02:09] <lifeless> persia: staging runs a different schema
[02:09] <persia> Oh, heh, cool.  Same update rules as staging (stale data, updated once in a while but usually at least once a week)?
[02:11] <lifeless> yes
[02:11] <lifeless> qastaging runs the prod schema
[02:11] <lifeless> and its what we qa deployments on
[02:13] <persia> Excellent resource, really.  Thanks for the heads-up.
=== Lcawte is now known as Lcawte|Away
=== evilnhandler is now known as nhandler
=== almaisan-away is now known as al-maisan
=== LinuxJedi|away is now known as LinuxJedi
[10:38] <thekorn> hi guys, I've a question about packaging recipes for branches: are there plans to allow `run` commands in recipes on launchpad in the 'near' future?
[10:44] <jml> thekorn: not right now
[10:44] <jml> thekorn: there's a bug about this
[10:44] <jml> thekorn: https://bugs.launchpad.net/launchpad-code/+bug/608450
[10:45] <ubot5> Launchpad bug 608450 in Launchpad Bazaar Integration "Can't use 'run' in recipe (affected: 2, heat: 10)" [Undecided,Invalid]
[10:46] <persia> Um, so, can't anyone in the mood subvert a build system to do precisely all the same things "run" can do?  This appears to even be suggested in the comments on that bug.
[10:46] <wgrant> persia: Yes.
[10:46] <wgrant> Anyone saying it's a security issue is wrong.
[10:47]  * persia thinks comments #1 and #6 are just entirely wrong, and isn't sure why the bug is "Invalid"
[10:48] <wgrant> The last paragraph of #6 is odd.
[10:48] <wgrant> Perhaps it refers to the recent move of the tree build to outside the chroot.
[10:48] <wgrant> But this remains within a secure virtualised builder.
[10:49] <persia> Regardless, it already runs arbitrary untrusted code.
[10:55] <jml> part of the motivation is to keep recipes declarative, and avoiding them becoming a mass of arbitrary code
[10:57] <persia> But, makefiles can do *anything*, and most implementations are happy executing ELF debian/rules.
[10:57] <jml> yes.
[10:58] <persia> So, I think the bug should be valid.  I don't care if it's wishlist/triaged or wontfix.
[10:58] <persia> (and I can see good arguments for wontfix)
[10:58] <wgrant> Opinion!
[10:58] <persia> My opinion about opinion is lodged in a wontfix bug.
[10:58] <wgrant> Heh.
[10:58] <jelmer> wgrant: my thoughts exactly :-)
[11:00] <jelmer> jml: I'd like to be able to update the build dependencies debian/control and this is impossible to do from debian/rules (it's already too late by the time debian/rules gets run).
[11:00] <jelmer> jml: But I don't see a good way to keep recipes declarative without turning manifests into full-fledged tarballs or bzr trees.
=== matsubara-afk is now known as matsubara
[11:05]  * thekorn subscribes to this bug, thanks
=== LinuxJedi is now known as LinuxJedi|away
[11:25] <alf_> Hi all! Is there a direct URL to get to a bug in launchpad if I just know the bug number?
[11:28] <spiv> alf_: https://launchpad.net/bugs/NNN
[11:28] <alf_> spiv: Thanks!
[11:29] <spiv> (Or if you want a cute short URL: http://pad.lv/NNN)
=== bilalakhtar_ is now known as bilalakhtar
=== JanC_ is now known as JanC
[12:57] <Laney> 246067 just got spammed
[12:58]  * bilalakhtar checks
[12:58] <bilalakhtar> though I cannot do much
[12:59] <Laney> should probably just do a question about it
[13:00] <bilalakhtar> Laney: ah, you mean comment #151
[13:00] <bilalakhtar> Yes, it should SURELY be removed
[13:00] <bilalakhtar> Any LP admin here?
[13:01] <Laney> i did a question
[13:01] <Laney> no need to ping i guess
=== Ursinha-afk is now known as Ursinha
=== mrevell is now known as mrevell-lunch
[14:08] <nekohayo> hey there, I got added to https://launchpad.net/~ubuntu-answer but I still can't create FAQs for https://answers.launchpad.net/ubuntu/+source/pitivi/+question/132140/+createfaq (for example); I get the same "Not allowed here" error. What's up?
=== mrevell-lunch is now known as mrevell
=== LinuxJedi|away is now known as LinuxJedi
=== matsubara is now known as matsubara-lunch
=== jacob_ is now known as jacob
=== Lcawte|Away is now known as Lcawte
[15:57] <detritux> hi. I'm a bit confused: I'm trying to merge from my trunk to a "release1.2" branch (which is empty), using the propose for merge launchpad feature. How should I procede?
[15:57] <detritux> When I have an empty release1.2 branch, the diff fails, if I first branch the trunk into release1.2, then there's nothing to merge...
[16:04] <jml> a colleague is trying to unsubscribe the "Canonical Server Team" (canonical-server) from https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-process-review/ – is there a way to do this?
[16:05]  * robbiew is the "colleague" :)
[16:05] <jml> hi robbiew :)
[16:05] <micahg> ask a server team admin?
[16:06] <robbiew> wow
[16:06] <jml> micahg: robbiew is one
[16:06]  * micahg goes and hides
[16:06] <jml> :)
[16:06] <robbiew> lol
[16:07] <robbiew> I checked https://blueprints.launchpad.net/~canonical-server....nothing there
[16:07] <micahg> bug 50875
[16:07] <ubot5> Launchpad bug 50875 in Launchpad Blueprints "It is not possible to unsubscribe a team from a blueprint (affected: 1, heat: 0)" [Low,Triaged] https://launchpad.net/bugs/50875
[16:08] <robbiew> nice
[16:10] <robbiew> jml: ^^ yet ANOTHER reason to throwaway blueprints!
[16:11] <jml> robbiew: yeah. I was just thinking that.
=== matsubara-lunch is now known as matsubara
=== linuxjedi_ is now known as LinuxJedi
[17:31]  * SpamapS starts working on the mod-pagespeed ITP that he just filed. ;)
=== beuno-lunch is now known as beuno
=== LinuxJedi is now known as LinuxJedi|away
=== al-maisan is now known as almaisan-away
[18:24] <thopiekar> hi.. I removed a copyed source of xbmc into ppa:thopiekar/maverick-dev from lucid and wanted to rebuild it because it doesn't work now.. just seg. faults. however: I wanted to rebuild it and rebuilds of already compiled packages isn't available, so I removed the package and wanted to copy it agian, but I get this: xbmc 1:9.11-lucid3 in lucid (a different source with the same version is published in the destination archive).. could you fix
[18:24] <thopiekar> this?
[18:39] <micahg> thopiekar: you have to change the version
[18:39] <maxb> thopiekar: No. It is not a bug. It is the designed behaviour that you can never rebuild a package with the same version number. If not for this, how would apt on users machines know it needed an update?
[18:41] <thopiekar> maxb, micahg: true, thanks!
=== Ursinha-afk is now known as Ursinha
=== yofel_ is now known as yofel
=== zyga is now known as zyga-afk
=== Meths_ is now known as Meths
=== LinuxJedi|away is now known as LinuxJedi
=== nhandler_ is now known as nhandler
=== matsubara is now known as matsubara-afk
=== zyga-afk is now known as zyga
=== LinuxJedi is now known as LinuxJedi|away
=== jamalta_ is now known as jamalta
=== Lcawte is now known as Lcawte|Away