[00:06] <thumper> james_w: https://code.edge.launchpad.net/ubuntu/+source/ghostscript
[00:06] <thumper> james_w: new layout
[00:12] <Lumiere> back
[00:13] <thumper> Lumiere: ok, a few quick questions:
[00:13] <thumper> Lumiere: what version of bzr do you have, and which format were you upgrading to?
[00:13] <Lumiere> 19:13:31 jstraw@shipon:~ 1$ bzr version
[00:13] <Lumiere> Bazaar (bzr) 1.13.1
[00:13] <Lumiere> I was just doing bzr upgrade without flags
[00:15] <thumper> ok
[00:15] <thumper> Lumiere: is your local copy upgraded?
[00:15] <Lumiere> I couldn't get it checked out to me
[00:15] <Lumiere> but the person I am working with had branch type 6 vs 5 on lp
[00:16] <thumper> ?
[00:16] <Lumiere> thumper: which seemed odd to me
[00:16] <thumper> are you using checkouts?
[00:17] <thumper> are you a member of the team that owns the branch?
[00:17] <Lumiere> yea
[00:17] <Lumiere> using branches
[00:17] <Lumiere> and I am jasonstraw in that team
[00:17] <Lumiere> the person who had the upgraded one is jelkner
[00:18] <thumper> have you done a `bzr lp-login`?
[00:18] <Lumiere> on other projects
[00:18] <thumper> bzr should remember
[00:18] <thumper> so you should have been able to do a checkout
[00:18] <Lumiere> it times out halfway through
[00:18] <thumper> although we recommend branches
[00:18] <thumper> bzr branch lp:gasp-lessons
[00:19] <thumper> that'll give you a complete local copy
[00:19] <thumper> which you can upgrade
[00:19] <Lumiere> yes
[00:19] <Lumiere> it was a network issue
[00:19] <thumper> mthaddon: how about we just run upgrade for Lumiere?
[00:19] <Lumiere> please
[00:19] <Lumiere> and thank you
[00:20] <mthaddon> thumper: sure - leave dirs as is and just run upgrade?
[00:20] <Lumiere> the branch was taking so long to do it
[00:20] <thumper> mthaddon: you'll need to (re)move the current backup.bzr
[00:20] <Lumiere> that it timed out/crashed
[00:20] <thumper> mthaddon: and just a vanilla bzr upgrade
[00:20] <mthaddon> Lumiere: ok, that's done
[00:20] <Lumiere> thank you
[00:21] <thumper> mthaddon: thansk
[00:21] <mthaddon> np
[00:21] <Lumiere> 19:21:01 jstraw@shipon:~/compile/gasp 24$ bzr branch lp:gasp-lessons
[00:21] <Lumiere> bzr: ERROR: The branch lp:gasp-lessons has no revision None.4
[00:23] <mthaddon> thumper: any ideas? ^
[00:23] <thumper> mthaddon: can you run check on the branch?
[00:24] <thumper> Lumiere: what do you have in ~/compile/gasp ?
[00:24] <Lumiere> nothing
[00:24] <thumper> Lumiere: no existing .bzr?
[00:24] <Lumiere> correct
[00:25] <mthaddon> thumper: http://pastebin.ubuntu.com/214009/
[00:25] <thumper> mthaddon: that was the broken upgrade :(
[00:25] <mthaddon> :( didn't give me any errors when doing it
[00:26] <mthaddon> so what now?
[00:26] <thumper> mthaddon: did you keep the old backup.bzr?
[00:26] <mthaddon> yep
[00:26] <thumper> ok
[00:26] <thumper> delete the existing .bzr
[00:26] <thumper> move the oldest backup.bzr to .bzr
[00:26] <thumper> and do a check
[00:26] <thumper> (pre upgrade .bzr hopefully)
[00:26] <thumper> failing all this, we can grap the mirrored copy
[00:27] <mthaddon> ok, should be all good now
[00:27] <mthaddon> bzr check worked fine before and after the upgrade
[00:27] <thumper> mthaddon: check was good?
[00:27] <thumper> kk
[00:27] <thumper> Lumiere: try now?
[00:28] <Lumiere> it is branching
[00:30]  * thumper afk, bbs
[00:40] <james_w> thumper: I saw, thanks
[00:40] <james_w> looks great
[01:06] <micahg> where would I file a bug to request ppa build cancellations?
[01:06] <micahg> as a feature
[01:07] <micahg> malone?
[01:07] <thumper> soyuz
[01:07] <micahg> ah
[01:07] <thumper> if in doubt, choose launchpad
[03:35] <Turl1> hi
[03:35] <Turl1> how much time does it take to import svn into launchpad's bzr?
[03:36] <lifeless> depends on the project
[03:38] <Turl1> lifeless: it's a small project, it's been 8 hours and it's still pending review :/
[03:38] <mwhudson> Turl1: what's the branch?
[03:39] <Turl1> mwhudson: https://code.launchpad.net/~vcs-imports/autoptimize/trunk
[03:44] <mwhudson> Turl1: approved
[03:46] <Turl1> thanls mwhudson :)
[03:47] <Turl1> thanks*
[03:49] <mwhudson> np
[07:12] <wgrant> Can somebody please look up OOPS-1287EC164 in a few minutes? It's repeatedly crashing one of my scripts.
[07:43] <mwhudson> wgrant: looks like something to do with an unsigned publication
[07:46] <wgrant> mwhudson: Thanks.
[07:46]  * wgrant will poke Soyuz people when they appear.
[08:11] <noodles775> wgrant: Have you got a minute to help me understand the context of bug 378876
[08:12] <wgrant> noodles775: Sure.
[08:13] <noodles775> wgrant: so from what I can understand in cprov's comments, the later upload is cruft because there was already a source published that superseded it right?
[08:13] <noodles775> In which case, why isn't the later upload *marked* as superseded?
[08:14] <noodles775> I'm not sure I understand why the front-end code should be checking 'should I really be superseded'... that should be done by the publisher... but I'm probably missing something.
[08:17] <wgrant> noodles775: The problem is that the binaries are superseded, not the source (that's called cruft, in the Debian world)
[08:18] <noodles775> hmm...
[08:18]  * noodles775 tries to wrap his head around the source *not* being superseded, but the binaries generated from that source being superseded...
[08:19] <noodles775> wgrant: ok, I think I've got it... thanks for the help!
[08:20] <wgrant> noodles775: While you're here - is OOPS-1287EC164 likely to have been caused by bigjools' recent addition addition of package_signer to the webservice export of ISPPH?
[08:20]  * noodles775 looks
[08:20] <MaWaLe> morning folks : do someone knows when LP will be released to be donwloadable?
[08:21] <wgrant> That SPPH doesn't OOPS any moe.
[08:21] <wgrant> Probably because it's published.
[08:21] <wgrant> A different unpublished one OOPSes now.
[08:21] <wgrant> MaWaLe: Late July or early August is the latest word.
[08:21] <noodles775> MaWaLe: see the link in the subject
[08:22] <MaWaLe> thx wgrant
[08:22] <MaWaLe> noodles775: i'm asking just to have a confirmation
[08:22] <MaWaLe> as a coordinator of the Web&Tech team of our LoCo, we are planning to hold a classroom on it
[08:24] <noodles775> MaWaLe: Cool! But that link is *the* authority on the subject... you might be able to chat with kfogel (who edits it) when he's around...
[08:26] <noodles775> wgrant: hmmm... so the SPR isn't signed... in primary... I'm not sure whether it's bigjools' change or not, but definitely log a bug for it (if you haven't already)
[08:27] <wgrant> noodles775: That was my suspicion, but I don't see why the SPR wouldn't be signed.
[08:27] <wgrant> Oh.
[08:27] <wgrant> A sync.
[08:27] <wgrant> Of course.
[08:27] <noodles775> wgrant: actually, is it possible that you might be grabbing the SPPH as soon as it's been published...
[08:27] <noodles775> before it has been signed?
[08:27] <wgrant> No, the SPR should be signed on creation.
[08:27] <noodles775> OK, so what did you mean above by sync?
[08:27] <wgrant> But some of them aren't, because they're not really uploaded.
[08:28] <noodles775> Ah ok.
[08:28] <wgrant> sync-source.py (as used by the Ubuntu archive admins) doesn't actually use real Soyuz copying. It generates a new source package, and uploads it unsigned from cocoplum.
[08:28]  * wgrant files a bug.
[08:29] <wgrant> noodles775: Thanks.
[08:29] <noodles775> wgrant: Thanks. Also, with the cruft bug above...
[08:30] <noodles775> wgrant: I'm assuming that if the second source package generates 10 binaries, and only one of them superseded, that the summary for the SPPH should be FULLYBUILT_SUPERSEDED?
[08:30] <wgrant> noodles775: I am running away screaming now.
[08:30] <noodles775> heh
[08:30] <wgrant> noodles775: I don't know. Nobody has done this sort of thing before.
[08:31] <noodles775> wgrant: it seems strange to summarise the SPPH as FULLYBUILT_SUPERSEDED when it might only be one binary... OK, I'll comment on the bug and see what the others think...
[08:32] <wgrant> noodles775: Sounds good.
[08:34] <wgrant> Bug #397732
[08:35] <noodles775> Great, thanks wgrant
[09:15] <nfilus> hello
[09:15] <nfilus> can anybody help me in getting the import of .pot files reviewed?
[09:18] <noodles775> henninge: ^^^^ Is that something you could help with?
[09:19] <henninge> nfilus: All files will be reviewed eventually. When did you upload them?
[09:19] <nfilus> last friday
[09:19] <henninge> ok, a week is a lot
[09:20] <henninge> nfilus: what's the project's name?
[09:20] <nfilus> what kind of review is needed?
[09:20] <nfilus> centreon
[09:20] <henninge> nfilus: https://help.launchpad.net/Translations/ImportPolicy
[09:21] <nfilus> henninge: I know this page
[09:21] <nfilus> henninge: the technical criteria are met
[09:21] <henninge> nfilus: cool
[09:22] <nfilus> henninge: a simple ACK would be enough :)
[09:24] <nfilus> henninge: I uploaded 2 templates for stable and trunk. the language files will be added one by one, when we understand the process and advantages of rosetta better
[09:26] <nfilus> henninge: is this ok? or would it be better to upload everything including the requested directory structure?
[09:27] <henninge> nfilus: yes, it would be much better to upload them all in one go
[09:27] <henninge> nfilus: either as a tarball or from a bzr branch
[09:27] <henninge> nfilus: most of all it would be much easier for you ...
[09:28] <henninge> and for us because we see the whole situation at once
[09:28] <henninge> nfilus: but I can approve the templates now
[09:28] <nfilus> the whole sources are outside of launchpad in svn und the director structure is different
[09:29] <henninge> nfilus: what do you mean different?
[09:30] <nfilus> trunk/centreon/de_DE/LC_MESSAGES/messages.po
[09:31] <henninge> nfilus: that is missing some directory ...
[09:31] <henninge> don't see that in your svn
[09:31] <henninge> nfilus: I am at http://svn.centreon.com/trunk/centreon/
[09:31] <nfilus> translations have a seperate svn
[09:32] <nfilus> http://forge.centreon.com/repositories/browse/translations/trunk
[09:32] <nfilus> or ...
[09:32] <nfilus>  http://svn.modules.centreon.com/centreon-translations/trunk
[09:33] <henninge> I see
[09:33] <nfilus> how can we integrate both structures better?
[09:33] <henninge> yes, that will need some scripting or so anyway
[09:34] <henninge> nfilus: I am sorry, Launchpad does not support that format directly
[09:36] <henninge> nfilus: for an automatic approval and import you would have to rename the files to de.po etc...
[09:36] <nfilus> henninge: no problem. currently I can do it manually, but would like to know how to map the structures onto each other
[09:36] <nfilus> henninge: ok
[09:36] <henninge> nfilus: so, de_DE/LC_MESSAGES/messages.po -> centreon/de.po
[09:37] <henninge> please avoid the locales like de_DE or es_ES or el_GR.
[09:37] <henninge> pt_BR is okay, pt_PT should just be pt
[09:37] <nfilus> henninge: I will discuss this with the core devs and must have a look at the needed code changes
[09:38] <nfilus> the naming scheme is inconsistent
[09:39] <henninge> nfilus: I could approve your templates now but that might get people starting to translate before you upload the translations thus causing double work.
[09:40] <henninge> nfilus: or you set the permission to "closed" for now.
[09:40]  * henninge goes to file a bug
[09:40] <nfilus> so should I upload the current translations?
[09:41] <henninge> nfilus: you can do that but to have them approved automatically (that is quickly) they need to be renamed as described.
[09:42] <henninge> nfilus: also, I saw that your templates are named differently but I guess they are really the same, right? It is just for a different series.
[09:42] <wgrant> noodles775: You seem to have misunderstood the issue in bug #378876. I've replied.
[09:42] <henninge> nfilus: also!
[09:42] <henninge> nfilus: We have message sharing in place now!
[09:42] <noodles775> Thanks wgrant.
[09:43]  * wgrant fails.
[09:43] <nfilus> henninge: how to setup translations for different series?
[09:43] <wgrant> Two step 3s! And a typo in the first step 3.
[09:43] <henninge> nfilus: you did that right
[09:43] <henninge> nfilus: you uploaded the files to different series.
[09:44] <nfilus> henninge: ah, ok - I will have a targz ready in 3 minutes to upload everything
[09:44] <henninge> nfilus: I am just saying they don't need to be named differently and in fact shouldn't if you want to take advantage of message sharing
[09:45] <henninge> nfilus: we take the name and translation domain from the file name.
[09:46] <noodles775> wgrant: so perhaps I misunderstood when cprov wrote "the later source is cruft"..
[09:47] <wgrant> noodles775: I suspect he meant the former.
[09:47] <noodles775> wgrant: yes, I guess he did. Thanks!
[09:48] <wgrant> noodles775: And there are actually two cases here - the display and handling of the situation needs to differ depending on whether any binaries remain.
[09:49] <noodles775> wgrant: do you mean when the earlier source has some binaries that have been superseded, but others that are not? If so, yes, that's the issue I tried to highlight on the bug...
[09:49] <lamalex> How do I revert a backedup .bzr dir on launchpad?
[09:50] <lamalex> I have a botched bzr upgrade, and need to put the backup.bzr back as .bzr
[09:50] <wgrant> noodles775: Right.
[09:50] <wgrant> lamalex: Use lftp or lp:hitchhiker.
[09:50]  * wgrant -> dinner.
[09:50] <noodles775> Enjoy :)
[09:50] <lamalex> wgrant: it tells me I can't rename something to .bzr
[09:52] <lamalex> also can't rename .bzr to /anything/
[09:55] <nfilus> henninge: please have a look at the new uploaded trunk templates
[09:57] <henninge> nfilus: looks very good!
[09:57] <henninge> nfilus: btw you have a broken locale
[09:58] <henninge> nfilus: zn_TW should be zh_TW
[09:58] <henninge> or we don't know that language ... ;)
[09:59] <nfilus> oh :)
[09:59] <nfilus> how to exchange that?
[09:59] <nfilus> upload again?
[09:59] <henninge> nfilus: yes, you can always upload again, entries with the same file name just get replaced.
[09:59] <henninge> nfilus: also
[10:00] <henninge> nfilus: please change the following locales while you're at it:
[10:00] <henninge> pt_PT -> pt, es_ES -> es
[10:01] <henninge> nfilus: we don't you those and thus they are likely to be missed by translators.
[10:01] <henninge> nfilus: I'll set the others to "Deleted"
[10:01] <nfilus> henninge: ok
[10:04] <henninge> nfilus: ok, I approved the trunk templates, the translation files will get approved and imported automatically now
[10:04] <henninge> give it 30-60 minutes, the overall queue is quite big.
[10:05] <nfilus> woow, thanks
[10:05] <nfilus> should I upload now only the renamed ones or the whole tar.gz again?
[10:06] <henninge> nfilus: use the tar.gz to keep the path
[10:06] <henninge> nfilus: single file uploads lose the path information (HTTP limitation)
[10:06] <nfilus> henninge: but all files included or the changed ones?
[10:06] <mariuz> hello
[10:06] <henninge> nfilus: yes, you can always upload again, entries with the same file name just get replaced.
[10:06] <henninge> nfilus: all files is fine.
[10:08] <mariuz> i have an issue with firebird code import in bzr https://code.edge.launchpad.net/~vcs-imports/firebird/trunk
[10:08] <nfilus> henninge: thank you very much!
[10:09] <henninge> nfilus: np, poke me when you need the template for the other series approved.
[10:13] <wgrant> lamalex: Allowed names are .bzr, backup.bzr, and .bzr.backup. I'd just remove .bzr, and rename backup.bzr to .bzr.
[10:13] <lamalex> wgrant: yah, i got it
[10:13] <lamalex> thanks
[10:15] <wgrant> bigjools: What time does edge update these days? I'll turn off my scripts until then, lest my inbox fill with errors.
[10:17] <bigjools> wgrant: I need to check
[10:17] <wgrant> It had been 4am UTC, but that doesn't seem to have held lately...
[10:18] <bigjools> I might push out a cherry pick to edge, it will be breaking james_w as well
[10:18] <bigjools> yes, that's why I need to check :)
[10:18] <wgrant> That would be good, thanks.
[10:18] <bigjools> it won't be for ~6 hours minimum if that happens though
[10:39] <wgrant> Um. Who stole all of the widgets from +filebug?
[10:39] <wgrant> On the second step, after you choose to report a new bug, only the summary, description and checkbox widgets appear.
[10:40] <wgrant> The rest have labels and descriptions, but the actual widgets are missing from the HTML.
[10:41] <henninge> wgrant: you mean under "extra options"?
[10:41] <henninge> because that WFM
[10:42] <wgrant> henninge: Yes. Hmmm.
[10:42]  * wgrant tries some non-Launchpad projects.
[10:44] <wgrant> Oh, maybe it is Firebug after all. I just noticed the widgets are in the HTML, but I missed them because it's all wrapped in tables.
[10:47] <DeSian> hi
[10:48] <DeSian> your system in translation, everytime with anew version from software, do XXXX problem for us
[10:49] <DeSian> we have translated wordpress 2.7 completlly and now is 2.8, you have imported the 2,7 in 2.8, but we must tranlate every line again.
[10:49] <DeSian> what is that for Bugy system you have?!!
[10:50] <DeSian> https://translations.launchpad.net/wordpress/2.8/+pots/wordpress/ckb/+translate
[10:51] <DeSian> we must edit every page and select the correct line
[10:51] <DeSian> can any one tell me, if you import the last translated version, why make you this mistake ever?
[10:54] <nfilus> henninge: something went wrong, german is translated in 100% (but some are fuzzy), but launchpad shows 0%
[10:54] <nfilus> henninge: same goes for french
[10:54] <nfilus> henninge: what could be the reason?
[11:00] <wgrant> Ooh shiny. Inline bugtask editing is arriving?
[11:01] <henninge> nfilus: German isn't imported yet.
[11:02] <henninge> nfilus: French looks fine now
[11:02] <nfilus> henninge: ok, I though every appearing lang is already imported
[11:02] <henninge> nfilus: wait until all files are "Imported".
[11:02] <henninge> nfilus: do you have "German" as a preferred language for your Launchpad account?
[11:03] <nfilus> henninge: no
[11:03]  * henninge looks
[11:03] <henninge> nfilus: ah, now
[11:03] <henninge> no
[11:03] <henninge> nfilus: the reason is: the language is created when the file is approved.
[11:03] <nfilus> henninge: I'm doing most things in english
[11:03] <henninge> nfilus: just wait for the imports to complete.
[11:03] <nfilus> henninge: that wasn't clear to me
[11:04] <henninge> nfilus: Aber du hast auch Deutsch in deinem Konto stehen ... ;-)
[11:04] <henninge> nfilus: You always see your preferred languages in a template.
[11:06] <nfilus> henninge: you mean the menus "Templates" or "overview" or messages.pot template?
[11:07] <henninge> nfilus: I meant this page: https://translations.edge.launchpad.net/centreon/trunk
[11:08] <nfilus> henninge: I see 9 languages, which several of them are neiter prefered nor spoken by me :)
[11:08] <nfilus> henninge: maybe because I'm project admin?
[11:08] <henninge> nfilus: No, I meant "your preferred languages in addition to those for which there are translations."
[11:09] <henninge> nfilus: for example, I see ten languages.
[11:09] <henninge> nfilus: I have Esperanto as a preferred language and so I see a line for it. Untranslated, of course.
[11:10] <nfilus> henninge: ok :)
[13:39] <wgrant> IArchive.newComponentUploader seems to not work on PPAs, even though it's meant to now... when I specify a component_name of 'main', it gives me a 400 stating that the component name must be 'main'.
[13:58] <bigjools> wgrant: that's err, less than optimal
[13:58] <bigjools> I am going for food now, I'll play with it when I get back
[14:00] <wgrant> bigjools: Thanks. And why are PPA package-specific uploaders not possible?
[15:08] <VK7HSE> Hi... just got the following...  (Error ID:OOPS-1287EB598)   when attempting an edit on https://edge.launchpad.net/ubuntu/jaunty/+source/me-tv/+edit-packaging
[15:11] <VK7HSE> and on a second attempt... (Error ID:OOPS-1287EC593)
[15:12] <james_w> bigjools: hey, was the problem you were talking about earlier an issue with OOPS from getPublishedSources?
[15:12] <bigjools> james_w: yes
[15:13] <bigjools> sorry for the cockup
[15:13] <bigjools> it will right itself next time edge is updated
[15:13] <james_w> AttributeError?
[15:15] <geser> james_w: see bug 397732
[15:15] <bigjools> james_w: I don't know how it manifested itself externally, but it oopsed when serialising sources with no signer
[15:17] <james_w> thanks for the quick fix
[15:17] <james_w> I'll assume it's the same
[15:17] <james_w> e.content just gives 'AttributeError' and nothing else, which is a bit odd
[15:17] <james_w> but it is the same error that the Oops shows
[15:25] <holzmodem> hey, I will rename my account, I can only change the Displayname, not the "Name": This user has a PPA and may not be renamed., I dont need this ppa, its empty. How Can i delete this?
[15:25] <kiko> cprov, ^^ holzmodem
[15:25] <bigjools> holzmodem: file a question on soyuz please, and we'll deal with it
[15:25] <kiko> VK7HSE, so that problem you're getting is because there's already a packaging entry with the data you're inputting. it's a bug, though
[15:26] <kiko> sinzui, does a bug already exist on https://lp-oops.canonical.com/oops.py/?oopsid=1287EB598
[15:26] <VK7HSE> kiko: thanks, I was attempting to change the development to stable...
[15:27] <sinzui> kiko: no, infact we have a opposite bug requesting that they no be unique
[15:27] <cprov> holzmodem: did you upload any packages to your PPA ?
[15:27] <holzmodem> yes, but i deleted all (or copied to a team ppa)
[15:28] <kiko> sinzui, I guess you can just lump it in then :)
[15:29] <sinzui> kiko: I see there is a recent bug: bug 352374
[15:29] <sinzui> kiko:  and bug 344376
[15:29] <cprov> holzmodem: cool, but unfortunately it doesn't suffice, we can't purge the history in your PPA.
[15:29] <sinzui> kiko:  both of these bugs can be fixed with a name field or a validator
[15:30] <cprov> holzmodem: for now file a question and we will deal with the required renaming involved.
[15:30] <holzmodem> cprov, the ppa is not the problem i want only change the name
[15:31] <cprov> holzmodem: right, but changing the account name implies in changes to the PPA repository path, and that has to be done manually right now.
[15:32] <cprov> holzmodem: no worries, file a question on soyuz and we will deal with it asap.
[15:32] <holzmodem> ok, filing question, thx
[15:55] <james_w> the dependencies of launchpadlib have ballooned somewhat
[15:57] <holzmodem> cprov, #76597 ^^
[15:58] <cprov> holzmodem: thank, I'm on it, will move the PPA repo path and rename your account.
[16:00] <cprov> holzmodem: 'raa' is taken -> https://edge.launchpad.net/~raa
[16:02] <holzmodem> :-( maybe; "ra"  or "raaa" ?
[16:03] <james_w> it really requires all that zope stuff now?
[16:04] <cprov> holzmodem: you tell me, pick one of your preference.
[16:05] <holzmodem> cprov, if ok "ra"
[16:05] <holzmodem> else "raaa"
[16:06] <james_w> ah, it's for testing apparently
[16:06] <cprov> holzmodem: 'ra' is also taken, going to https://edge.launchpad.net/~raaa. Please confirm that it's what you want in the question.
[16:11] <holzmodem> what i have to do? aking question for "raaa"? (sry english is not my native language)
[16:15] <cprov> holzmodem: nothing special, just post a new comment to the existing question.
[16:16] <holzmodem> done
[16:16] <cprov> holzmodem: thank you.
[16:56] <tumbleweed> question about branch merge requesting:
[16:57] <tumbleweed> when you request on the web interface, it automatically requests review
[16:57] <tumbleweed> when you bzr send or resubmit a merge request, it doesn't
[16:57] <tumbleweed> is there any reason for this difference?
[17:23] <holzmodem> cprov, how long does the change approximately took?
[17:32] <LarstiQ> tumbleweed: where are you `bzr send`ing it to?
[17:33] <tumbleweed> cocooncrash: that'd be you
[17:33] <tumbleweed> LarstiQ: I tend to use the web interface, cocooncrash tends to bzr send
[17:40] <bigjools> holzmodem: you need to wait for an admin to pick up your question, it should be within a day
[18:42] <cocooncrash> LarstiQ<EMAIL_ADDRESS>[18:43] <LarstiQ> cocooncrash: and what is the submit branch?
[18:43] <cocooncrash> LarstiQ: lp:ibid
[18:43] <LarstiQ> cocooncrash: because afaik, for the bzr project, it does work fine
[18:43] <cocooncrash> LarstiQ: The merge request is created fine -- it just doesn't set the reviewer.
[18:44] <LarstiQ> cocooncrash: yeah, I meant it setting the reviewer to bzr-core, sorry
[18:44] <cocooncrash> Oh, right.
[18:44]  * LarstiQ checks bzr project settings
[18:46] <LarstiQ> cocooncrash: looks similar to me
[18:46]  * LarstiQ leaves it up to an lp dev
[18:46] <cocooncrash> LarstiQ: Thanks
[18:48] <Hamaryns> ping gmb
[18:50] <rockstar> cocooncrash, you'll need to set the default review team of the target branch
[18:50] <rockstar> cocooncrash, or, you can type the following in your email
[18:51] <rockstar>  reviewer rockstar
[18:51] <rockstar> ...if you wanted me to review it.
[19:21] <DnaX> hi, someone LP admin can change an project name (id, not title)?
[19:24] <jpds> DnaX: File a question here: https://answers.edge.launchpad.net/launchpad/+addquestion about it.
[19:27] <cocooncrash> rockstar, LarstiQ: Apologies, bzr send isn't a problem
[19:28] <cocooncrash> But resubmiting merge requests doesn't assign the default reviewer.
[19:28] <cocooncrash> (And you also can't resubmit with bzr send, but I've filed a bug for that.)
[19:30] <tumbleweed> cocooncrash: cool
[19:30] <tumbleweed> you also can't resubmit with e-amil
[19:31] <cocooncrash> tumbleweed: bzr send is via email.
[19:31] <tumbleweed> cocooncrash: hmm, I suppose yes
[19:32]  * tumbleweed leave outta here for now
[19:44] <DnaX> thanks jpds
[23:06] <BUGabundo> guud evening
[23:06] <BUGabundo> I'm experiencing timeouts on Edge
[23:06] <BUGabundo> sending emails to contacts from their profile page
[23:11] <beuno> BUGabundo, could you file a bug with the OOPS ids?
[23:12] <RenatoSilva> what's the difference bewteen SSH and OpenPGP keys?
[23:12] <RenatoSilva> Aren't they both just RSA key pairs?
[23:15] <BUGabundo> beuno: I just get a blank page :(
[23:22] <maxb> RenatoSilva: an OpenPGP key contains more than just a single keypair
[23:23] <maxb> signed user ids, subkeys, potentially other extended information
[23:26] <RenatoSilva> maxb: wouldn't it be easier to just have two key pairs and everytime you want to send signed content you just sign it?
[23:26] <maxb> huh?
[23:26] <RenatoSilva> maxb: sorry
[23:26] <RenatoSilva> maxb: I don't get the sense
[23:27] <maxb> What would be easier? What would it be easier than? I don't understand the reasoning behind your previous question.
[23:28] <RenatoSilva> maxb: let's go abck to the question
[23:28] <RenatoSilva> maxb: I mean, huh for you heheh
[23:29] <RenatoSilva> maxb: why more than a key pair? for what?
[23:30] <RenatoSilva> maxb: I can't imagine what else than a key pair would I need to send signed content out there.
[23:30] <maxb> For starters, associating the keypair with an identity, and cryptographically signing that association
[23:31] <maxb> And not just a self signature - other people can sign the association to assert that the user id is genuine
[23:31] <maxb> This is the basis of the "web of trust"
[23:31] <RenatoSilva> maxb: if you have signed content in your openPGP key, then it's a mix of priv key + pub key + signed content, right?
[23:32] <maxb> yes
[23:32] <maxb> And then you can have subkeys - secondary keypairs with delegated authority
[23:33] <RenatoSilva> maxb: I can't figure out why would I need this default signed content
[23:33] <RenatoSilva> maxb: do you have an example?
[23:34] <RenatoSilva> maxb: and I'd appreciate too if you point me to a tutorial you it's good
[23:34] <maxb> My key asserts that I am Max Bowsher, and that I own a variety of email addresses, and moreover carries the certification of various people that I have met face-to-face that they believe that I, the owner of the key, are that person
[23:35] <RenatoSilva> maxb: humm, ok then would that be kind of a "default signed message for basic questions"?
[23:36] <maxb> um. that's kind of a weird way of describing it, and I don't know how to answer that
[23:37] <RenatoSilva> maxb: such as dose this email belong to him, or does he trust in this guy's public key...
[23:37] <RenatoSilva> s/dose/does
[23:38] <maxb> Essentially yes, though it's less of a "message" and more a core part of the way the keys are defined and used
[23:39] <RenatoSilva> maxb: I've found explanations in lp and ubuntu wiki, but they don't introduce the idea, and they don't point out a clever way to keep your priv key secure, whcih I think it's a very important step.
[23:40] <maxb> You're right, it's a vitally important step, since it potentially may be important to you for your entire lifetime
[23:41] <RenatoSilva> maxb: how to keep it secure? the question is for any pub/priv key pair I think
[23:41] <maxb> Exactly, it's in no way specific to PGP keys
[23:42] <maxb> And really it comes down to being sensible about where you put it
[23:43] <RenatoSilva> maxb: and how about creating many OpenPGP keys? For example, I need one to become an Ubuntero, and set up PPA etc. I want to create an OpenPGP key only for that use, in Launchpad. How about it?
[23:44] <maxb> Certainly doable
[23:45] <maxb> You might choose to indicate in the user id comment if the key is intended for a restricted purpose
[23:45] <RenatoSilva> maxb: I wonder if there are any specific steps, because anyone with physical access to the machine containing your private key would be able to access it
[23:45] <maxb> only if you keep it unencrypted, which would be foolish
[23:46] <RenatoSilva> maxb: encrypt with a password-based algorith?
[23:46] <RenatoSilva> m
[23:46] <maxb> However, you are right that you shouldn't keep high value keys on a machine to which others have physical access, even if they *are* encrypted
[23:47] <maxb> It is normal to keep your pgp key protected with a passphrase - preferably a fairly long one
[23:47] <maxb> mine is > 30 characters
[23:48] <RenatoSilva> I wonder if crypted .zips woud be enougth
[23:48] <maxb> erm, what?
[23:49] <RenatoSilva> maxb: you can put the key in a zip file, protected by pasword
[23:49] <RenatoSilva> maxb: when you want to extract the file, you must type the right password. I don't know if the algorith is trustable tough.
[23:50] <maxb> No, you don't do that - the program you use to sign/encrypt/verify stores it encrypted and decrypts on the fly when using it, never storing it on disk at all
[23:52] <RenatoSilva> maxb: I wonder if such encryption of the key-manager is enough too. PuTTY for example.
[23:52] <maxb> ?
[23:53] <RenatoSilva> maxb: are pass_word_-encrypted files enougth? Or do you really need a pass_phrase_ greater than 30 chars?
[23:54] <maxb> I like to be comfortable that I'm well beyond the possibility of a brute force search *and* sufficiently complex that someone couldn't feasibly watch me type it either
[23:55] <RenatoSilva> maxb: PuTTY is a Windows SSH client, it can generate a key pair. You can protect the private key with a pasword, but I wonder if that is really secure. Are password/phrase-based encryption really secure, enougth, as secure as or more than assimetric algorithm
[23:56] <RenatoSilva> s/Are/Is
[23:57] <RenatoSilva> s/enought/enough
[23:57] <RenatoSilva> s/enougth/enough
[23:57] <maxb> An asymmetric algorithm is irrelevant here. The aim is to secure data using a memorized key. Asymmetry serves no purpose.
[23:59] <RenatoSilva> maxb: I was jsut wondering how they compare, as it is standed that symetric algorithms are "better"


[03:41] <infinity> slangasek: Drat.  Remember when I said your mountall magicall fixes my "/tmp not ready yet" bug?
[03:41] <infinity> slangasek: I must have just had a few lucky reboots in a row, cause it's back.
[03:42] <infinity> slangasek: Which indicates it's a race of some sort, but I'm not sure why there's a race to find a filesystem for something without a mountpoint in the first place. :P
[04:27] <slangasek> infinity: very good question
[04:58] <mah454> Hello
[04:58] <mah454> I need confirm new distro template to apt-add-repository
[04:59] <mah454> I changed lsb_release
[05:25] <pitti> Good morning
[06:23] <FourDollars> pitti: Could you help to review https://code.launchpad.net/~fourdollars/language-selector/singleton_and_escape_key/+merge/132595 ? Thanks.
[06:24] <pitti> FourDollars: yes, can do today
[06:24] <FourDollars> pitti: Thanks.
[06:24] <FourDollars> pitti: Could you also help https://bugs.launchpad.net/precise-backports/+bug/1076901 ?
[06:25] <pitti> I'm not a backporter, sorry
[06:27] <FourDollars> pitti: Do you know who can help or what should I do next?
[06:27] <pitti> AFAIUI the backporter team regularly reviews pending requests
[06:29] <FourDollars> pitti: I see. Thanks.
[06:50] <didrocks> hey, can anyone reject https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422 please?
[06:51] <pitti> didrocks: fini
[06:51] <didrocks> pitti: thanks :)
[07:39] <pitti> jibel: so, cjwatson and I didn't talk about britney integration of adt yet; however, I spent quite some time to fix two handfuls of failing adt tests
[07:47] <jibel> pitti, ok. I thought about it last week, and I think I'll have to split the job that triggers the tests in 2 parts, one part which identifies packages to test and the other part will deal with jenkins.
[07:47] <dholbach> good morning
[07:48] <jibel> pitti, this way, britney can start the jobs without any dependency on lab's specific bits, and will know which tests have been started.
[08:50] <pitti> @pilot in
[09:07] <zequence> Isn't there a ubuntu sys admin channel here somehwere?
[09:24] <lifeless> zequence: #canonical-sysadmins perhaps ?
[09:40] <pitti> $ bzr merge lp:~obounaim/ubuntu/raring/virtualbox/debian-merge
[09:40] <pitti> Unapplying quilt patches to prevent spurious conflicts
[09:40] <pitti> bzr: ERROR: Unable to unapply quilt patches for 'other' tree: rmdir: failed to remove `.pc/cve-2012-3221.patch': No such file or directory
[09:40] <pitti> did anyone happen to run into this before and knows how to fix/workaround?
[09:42] <xnox> pitti: yes.
[09:43] <apw> do i recall correctly that build essential in raring is now 'correct' that we have less extraneous things in the chroots by default
[09:43] <xnox> pitti: in the ~/.bazaar/builddeb.conf set "quilt-smart-merge=False"
[09:43] <xnox> pitti: and then unapply patches yourself in the old branch & the new branch. Commit in both, then merge.
[09:43] <xnox> pitti: re-push quilt series.
[09:44] <pitti> what could be easier...
[09:44] <pitti> so I need to check out two full virtualbox branches, fun
[09:44] <xnox> probably the package is in 1.0 source package and builddeb got it wrong.....
[09:44]  * pitti screws it, downloads the diff, applies manually and lets the package importer sort it out
[09:44] <xnox> pitti: bzr init-repo virtualbox; cd virtualbox
[09:44] <OdyX> win 23
[09:45] <xnox> then it's only half the download =)
[09:45] <xnox> pitti: i tend to always upload and let the package importer sort it out. But I do use bzr for auto-merging most of the stuff for me.
[09:45] <pitti> xnox: pre-applied patches and I have a deep hate for each other
[09:46] <xnox> heh
[09:46] <pitti> I yet have to find a person who gets along with those without sacrificing chicken and screwing it up from time to time
[09:49] <cjwatson> I do :)
[09:49] <cjwatson> Not that I think the importer's approach is ideal, but
[09:52] <xnox> doko_: the reason for python-imaging and python-reportlab is hplip
[09:53] <xnox> on the cd, that is.
[10:14] <apw> cjwatson, i think you were working with benc on linux-ppc, i see it ftbfs and (if you arn't already) was planning on trying to fix that to release linux
[10:15] <cjwatson> apw: I was just processing it through the archive
[10:15] <cjwatson> apw: Be my guest, though I see he has his own git branch for it
[10:15] <zequence> lifeless: That's the one. Thanks
[10:16] <apw> cjwatson, i have his branch indeed, will use that as a base and send it back to him
[11:08] <pitti> . o O { sponsoring merges as Ubuntu MPs is about as far away from "fun and efficient" as it could be }
[11:08] <cjwatson> Sponsoring merges is hopeless
[11:09] <cjwatson> One of the reasons I discourage people from doing that until they can upload directly
[11:09] <pitti> a nice and clean "current debian - merged ubuntu" debdiff attached to a bug is fine IMHO
[11:09] <pitti> but hopping through all that "checkout ubuntu, merge, fight with teh quilt patches, etc." until you get to that debdiff is a pain
[11:13] <xnox> huh?! if you are sponsoring you checkout the sponsoree branch and diff against the tags within that branch.
[11:14] <xnox> unless it's a horrible mess with forgotten $ bzr add .pc
[11:14] <pitti> xnox: ah, I guess you could do that if you don't push it back to the official branch anyway
[11:15] <xnox> pitti: yeap. and you can do $ bzr bd -S to get a source package out of the sponsoree branch. If that doesn't work, throw it back.
[11:15] <seb128> pitti, I found the launchpad diff mostly useful for those, it's the ubuntu->ubuntu diff basically, so you see "ok, few revisions from debian added, looks good"
[11:16] <xnox> and there you have your source package with the pristine-tarball regenerated.
[11:16] <seb128> you just need to filter you the quilt noise when debian added new patches
[11:16] <pitti> seb128: yeah, but I do want to verify the d->u debdiff, as that's the one which we should minimize
[11:16] <xnox> pitti: $ bzr diff -rtag:1.0-2
[11:16] <seb128> pitti, then you are going over sponsoring in fixing it yourself mode ;-)
[11:16] <pitti> xnox: right, thanks
[11:16] <seb128> pitti, well I usually read the changelog summary to see the diff
[11:17] <seb128> "diff", e.g what changes we carry
[11:17] <pitti> seb128: not necessarily fixing, but I don't want to sponsor merges which have obsolete stuff in them
[11:17] <seb128> right, I found that the changelog was enough to check the changesets and their validity usually
[11:17] <seb128> but maybe I check less into details than you do
[11:18] <cjwatson> pitti: clean debdiff> It depends what you're checking.  That's still a royal pain if the merge is at all complex and you're trying to check whether the merged debdiff actually matches what used to be in the Ubuntu delta
[11:18] <cjwatson> pitti: I've had too many instances of well-intentioned newcomers dropping patches they don't understand to skip that kind of verification, and it ends up being significantly more work than doing the merge myself
[11:19] <pitti> cjwatson: I look at both, but the more interesting one is the d->u one for me usually
[11:20] <pitti> so I guess I go with xnox's approach to only checkout the proposed branch, check the diffs against the tags, and never push it back
[11:20] <pitti> did that with one branch now, and it's a lot easier indeed
[11:23] <seb128> pitti, what tag do you check against? the vcs from contributor doesn't have the current debian versions right? e.g no way to do "current debian to proposed update" from the vcs?
[11:23] <xnox> well. to address cjwatson's concern and pitti's usability I do this. Checkout proposed branch. generate the new d->u diff and u->u diff. But also pull the old d->u diff (with pull-lp/debian-source & debdiff). and then review old d->u & new d->u.
[11:23] <pitti> seb128: they do have the current Debian version
[11:23] <pitti> seb128: I guess because the creator of the branch actually used "bzr merge lp:debian/foo"
[11:23] <pitti> that imports all the tags etc.
[11:24] <seb128> oh ok, nice
[11:24] <seb128> quite some don't
[11:24] <xnox> with the last step, I catch a few "overzealous" preservations: double application of the same patch due to fuzz, and keeping the changelog entries for "actually merged in debian long time ago".
[11:24] <xnox> seb128: if there is no debian tag, throw the branch a way. It was not a bzr merge, I will not trust it.
[11:24] <pitti> seb128: e. g. I check out lp:~logan/ubuntu/raring/desktop-base/debian-merge, and "bzr diff -r tag:7.0.0ubuntu2" gives me u→ u, and "bzr diff -r tag:7.0.3" gives me d→ u
[11:25] <seb128> pitti, xnox: nice tip, thanks
[11:25] <xnox> (e.g. if the importer is lagging, atleast bzr import-dsc should have been done)
[11:25] <Laney> why do you need to pull-*-source if you have the old tags in vcs too?
[11:25] <seb128> I usually end up dgetting the ubuntu and debian versions and doing debdiffs locally
[11:25] <pitti> that's what I did before, and download the diff from the MP, clean it, and apply it locally
[11:25] <seb128> when the merge is not trivial, when it's trivial (like most of those from "logan" I usually can ack it from the launchpad diff)
[11:26] <xnox> seb128: dgetting or pull-[lp|debian]-source $pkg [version|release] ? =)
[11:26] <pitti> (clean: throw away the "applied patches" portions)
[11:26] <seb128> xnox: I'm too old school, dunno about those pull tools :p
[11:26]  * seb128 notes to try those
[11:26] <xnox> I also do ` | filterdiff -x '*.pc*'
[11:27] <seb128> pitti, oh, I usually bzr branch the vcs from the submitter and bzr bd --source it
[11:27] <seb128> pitti, then work from the source package, dput that
[11:27] <pitti> seb128: yeah, that's what xnox told me as well; I initially tried "bzr merge" and tried to push that back, but that's too brittle
[11:27] <seb128> take from the discussion: everybody is working using a different workflow
[11:28] <xnox> pitti: the problem with $ bzr merge, is that it always try to do "merge from debian" e.g. auto-unappy quilt patches. Which doesn't make sence when merging a proposed to-be-sponsored branch.
[11:29] <xnox> pitti: with those, if they are actually clean. I push them to lp:ubuntu/$pkg. Or do pull/merge with quilt-automerging turned off.
[11:32] <cjwatson> seb128: Heh, even as an old-schooler, pull-{lp,debian}-source are the best things ever
[11:33] <seb128> cjwatson, no doubt, I just didn't know about them ;-)
[11:34] <seb128> too many scripts and I don't keep up with everything which is available there
[11:34] <seb128> seems like I should ;-)
[11:34] <pitti> +1 on pull-*-source
[11:34] <xnox> generally, if the utility is shipped in ubuntu-dev-tools it generally means that "all of your aliases and scripts suck compared to this shiny command line toy"
[11:35] <cjwatson> Heh
[11:36] <pitti> I go through dpkg -L ubuntu-dev-tools every 6 months or so, and so far it never failed to surprise me with at least one new cool thing :)
[11:36] <mlankhorst> xnox: or it's too ugly for ubuntu-dev-tools ;)
[11:39] <rbasak> pitti: what's the rationale for autopkgtest/dep8 to treat a zero exit status but output to stderr as a failure? Eg. wget prints progress to stderr, so script that calls wget is treated as a failure by default. I guess we could wrap it, but is there a more general answer?
[11:39] <xnox> rbasak: currently implementation.
[11:40] <xnox> as in, that's what the currently implementation does from historic reasons dating back to 2007
[11:40] <pitti> rbasak: I'm not quite sure TBH; it's nice to detect new warnings that weren't there before, but of course it's a bit pointless if your tests are expecting to write stuff to stderr
[11:40] <xnox> e.g. for desktop apps, launching and having output on stderr is bad, means some errors are present.
[11:41] <rbasak> How about a "writes-stderr" "restriction"?
[11:41] <pitti> rbasak: for Python unitest I usually use "unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdout, verbosity=2))"
[11:41] <pitti> to fix python's unfortunate default of writing the regular output to stderr
[11:41] <cjwatson> Or wrap in a script that does 2>/dev/null if you know you never care
[11:41] <pitti> yeah, a lot of tests do that, too
[11:42] <rbasak> The thing is if the test does fail, then the output that went to stderr may be useful
[11:42] <pitti> rbasak: writes-stderr> not sure whether upstream likes that, but seems fine to me
[11:42] <pitti> rbasak: oh, we do keep that; if stderr is nonempty, you see it as an artifact in jenkins
[11:42] <rbasak> Yes, but if the workaround is to >/dev/null, then it won't be :)
[11:43] <pitti> rbasak: 2>&1 is better really
[11:43] <cjwatson> stderrfile="$(mktemp)"; cleanup () { rm -f "$stderrfile"; } trap cleanup EXIT HUP INT QUIT TERM; run-tests 2>"$stderrfile" || cat "$stderrfile" >&2
[11:43] <xnox> wget has --quiet option
[11:43] <cjwatson> Or something
[11:43] <cjwatson> But yeah, it's often less effort to silence the spurious errors in the first place ...
[11:43] <rbasak> xnox: yes, but the script that we're calling doesn't (currently) have a --quiet option, so it won't pass through to wget. We're not testing wget - we're testing a script that calls wget
[11:43] <pitti> if I get along with fixing the output fd of unittest, I usually prefer that; for others, debian/tests/foo doing 2>&1 seems the next best approach
[11:43] <xnox> rbasak: I see. ok.
[11:44] <rbasak> cjwatson: that's exactly what I'm suggesting that a "writes-stderr" restriction might do :)
[11:45] <xnox> I did patch guilt package test-suite to be sensitive on $ADTTMP, which means roughly - we are in autopkgtest environment, use system install, don't do silly things on stderr, but do fail on stderr.
[11:47] <rbasak> OK, thanks all
[12:02] <xnox> thinking about the hash-sum missmatch from apt (which I just had on my laptop) - shouldn't apt be smart about those & requeue and try updating that repo again (with custom delta-t & #-retries) before giving up?
[12:04] <rbasak> It's pretty awkward to fix that within apt
[12:04] <rbasak> I'm hoping to fix it for good with the by-hash stuff this cycle
[12:08] <xnox> rbasak: explain why it's awkward to fix that within apt? does it return a different error code on hash-sum missmatch? if it does a wrapper script around apt-get update installed with dpkg-divert, which loops around apt-get update should do it.
[12:09] <xnox> rbasak: although by-hash stuff is nice, I feel cautious that not all mirrors will support it any time soon.
[12:09] <rbasak> xnox: inside apt, the code that manages the downloads is extremely twisted and laden with more tech debt than any other project I've ever seen
[12:10] <xnox> 8) ok.... scary
[12:10] <rbasak> xnox: an outside wrapper would definitely be far easier. I'm not sure if apt returns a unique return code, but that probably wouldn't be too hard to do (or to parse the stderr)
[12:10] <xnox> parse the stderr sounds dirty =)) but why not ;-)
[12:11] <rbasak> Yeah mirrors might take a while to pick it up. Including our own. But the nice thing is that if you care you can implement your own by-hash mirror without upstream support :)
[12:11] <rbasak> (admittedly that still doesn't solve the problem in the general case)
[12:25] <xnox> rbasak: where/how are the cloud images generated? I'd like to tinker with a few settings to improve performance and reduce size those.
[12:25] <rbasak> xnox: utlemming and smoser manage those
[12:25] <xnox> rbasak: thanks.
[12:26] <rbasak> I think the scripts that generate them are in LP somewhere
[12:26]  * xnox wishes lp had "show all activity bzr/revisions/pushes for a person", cause I bet the branch has team owner.
[12:34] <xnox> rbasak: https://code.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds
[12:34] <xnox> looks about right?! it's referenced in the build-logs of the cloud-images available for download.
[12:34] <rbasak> xnox: seems likely. smoser can confirm when he comes online
[12:35] <xnox> rbasak: yeap, it is right. Referenced in https://help.ubuntu.com/community/UEC/Images
[13:40] <pitti> @pilot out
[13:58] <smoser> xnox, that is not correct any more. unfortunately that document is out of date.
[13:59] <smoser> https://wiki.ubuntu.com/UbuntuCloud/Images/Publishing is *better*, but still out of date.
[13:59] <xnox> smoser: hm.. ok. where is _the_ source?
[14:00] <smoser> well, that url above references just about everything except for reference to live-build branch that we use
[14:00] <smoser> lp:~ubuntu-on-ec2/live-build/cloud-images
[14:01] <xnox> ok...
[14:01] <xnox> thanks
[14:01] <smoser> http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/misc/ec2-build-on-ec2 does much of it.
[14:01] <smoser> what were you looking to fix/change?
[14:01] <xnox> default apt & dpkg settings.
[14:02] <smoser> as in?
[14:02] <xnox> maybe it should be in cloud-init instead, I am not sure.
[14:02] <xnox> do not download description translations, disable i386 multiarch on amd64 images.
[14:02] <xnox> possibly set lang to C and purge all translations.
[14:03] <xnox> unless all of this is already done on the recent images.
[14:03] <xnox> cut's down apt-get update time by more than a half.
[14:03] <smoser> weell..
[14:03] <xnox> maybe,  not the lang bit =)
[14:04] <smoser>  - translations: i dont know enough about how they work to decide if its ok or not. i'm not opposed to it, but it would be a regression for some users i'm sure (being uncultured american, it "works for me")
[14:04] <xnox> well the fact is that currently you are downloading normal package list & then the en_US translation of the same package list.
[14:04] <ogra_> why dont run the cloud builds oem-config on first login ?
[14:05] <xnox> doubling your package list.
[14:05] <xnox> ogra_: no oem-config. ever on cloud.
[14:05] <ogra_> xnox, right, but why ?
[14:05] <xnox> ogra_: we don't want to manually configure 100 instances I spin up for my haddoop. ever.
[14:05] <ogra_> oh, just have a default preseed
[14:05] <smoser>  - i386 on amd64 images: i think i've actually tried to do this unsuccessfully.  in the maas ephemeral image (http://bazaar.launchpad.net/~smoser/maas/maas.ubuntu.com.images-ephemeral/view/head:/maas-cloudimg2ephemeral line 251)
[14:06] <ogra_> only if you dont use that preseed you can manually configure
[14:06] <xnox> ogra_: well, think of cloud images more as if they are pre-installed for automated usage.
[14:06] <ogra_> yes, i do
[14:06] <smoser> ogra_, cloud-init does what you want it to do.
[14:06] <xnox> ogra_: there is cloud-init which allows you to change settings on first boot.
[14:06] <cjwatson> You don't download a separate package list for translations, only files containing the different descriptions.
[14:06] <cjwatson> (point of information)
[14:06] <ogra_> well, oem-config uses a statndardized way also the installer uses so you get changes automatically
[14:07] <smoser> - setting lang to C: i'm probably not opposed to that, setting it as a default. cloud-init will change it to en_US on first boot though.
[14:07] <smoser> unless we also change that.
[14:08] <smoser> cjwatson, the translation downloads are annoying, though if not needed. especially with S3 mirrors, where the serial small file requests are quite painful.
[14:09] <xnox> cjwatson: true. but it's a lot of queries to see if they are updated for each component/pocket, isn't it? plus they are useless waste on auto-spinned up instances...
[14:09] <cjwatson> I don't really care either way.  I was just taking issue with the description.
[14:09] <smoser> rbasak, was/is going to make apt able to do parallel there, which will allow us to blast S3 very unfriendly-like.
[14:09] <rbasak> smoser: that a separate thing that I hope to do this cycle to. apt happens to have the logic in there that should make this change easy
[14:10] <rbasak> that's a separate thing that I hope to do this cycle too.
[14:10] <smoser> i hope so too
[14:10] <smoser> :)
[14:10]  * rbasak learns to speak English
[14:11] <smoser> for the reader, each http connection to S3 has a large overhead (on the S3 side). as a result, the average download time across some large get like 'apt-get --download-only install ubuntu-desktop' tops out at like 8M/s (maybe 12).
[14:11] <smoser> but if we parallelize that (with apt-fast), we can saturate a gigabit link.
[14:12] <smoser> and if S3 doesn't stand up, thats their fault. (especially since amazon explicitly told us that S3 was not designed for lots of little files like apt is doing... after they told us to put mirrors in S3 and ignored my complaints about speed).
[14:13] <smoser> (and for the record pipelining there has just about zero affect)
[14:13] <smoser> xnox, so in general, i'm not opposed to any of your changes, but i'm careful in all changes.
[14:15] <xnox> smoser: I understand. I want to play around with these settings and see if I can still generate images and launch them & check the performance differences.
[14:15] <smoser> speed of 'apt-get update' is a pretty important thing in my opinion
[14:16] <smoser> and i'd love for the images to not use i386 on amd64.
[14:18] <xnox> ack.
[14:20] <smoser> ogra_, fwiw, you can feed debconf preseed to cloud-init just like you would the installer.
[14:21] <smoser> cloud-init does not recondifgure anything alreadyy installed (arguably a bug), but new packages installed would then get those preseeds.
[14:21] <ogra_> does it use the udebs ?
[14:21] <xnox> no =)))))
[14:21] <ogra_> link ubiquity/oem-config does
[14:21] <ogra_> aha
[14:21] <ogra_> that was actually my point :)
[14:22] <ogra_> so you dont have to re-implement all these bits all the time when something changes
[14:22] <smoser> i'm probably just being ignorant, but i have no idea why i would want to use udebs.
[14:22] <smoser> example of change?
[14:22] <ogra_> the sudo group
[14:23] <xnox> hmm... oem-config is meant to be run with tty, where as cloud-init is always unattended.
[14:23] <ogra_> the point is, by using the udebs you dont have to care for the backend stuff at all, whatever the distro changes will happen there and you just inherit
[14:24] <xnox> not sure it would be wise to mix the two.
[14:24] <smoser> i'm not opposed to getting "free stuff"
[14:24] <ogra_> oem-config runs fine on serial tty's etc and you can preseed it as well as you can any other bit
[14:24] <ogra_> in which case it wont need a tty
[14:24] <xnox> amazon cloud does not give you serial tty =)
[14:25] <ogra_> well, you dont need one if you prseed
[14:25] <ogra_> but if you can have one and dont preseed you would get a proper fist login configuration
[14:25] <ogra_> and everything for free without having to poke at backend code ;)
[14:26] <ogra_> anyway, just wondering ... its not my work area :)
[14:26] <smoser> i'm not opposed to it in principle, but not convinced of the merrit. the sudo group change sucked, but generally we have very few such things "baked in".
[14:26] <xnox> ogra_: well.. the "first login" is the problem that cloud-init solves. By default you can't login into ec2 image. You have ssh, but then your ssh key needs to be in the user-account pre-setup.
[14:27] <ogra_> xnox, right, but where doies the functionality of cloud-init differ from what a reseeded oem-config does ?
[14:27] <xnox> and clound-init does that funny grub booting as well.
[14:27] <ogra_> i dont think it does
[14:27] <ogra_> (differ i mean) ...
[14:30] <xnox> the way the first user is done and the hostname is different, and apart from locale choice nothing else is common between the two.
[14:30] <toabctl> can someone please have a look at #1077938, please? maybe that's something for an SRU, too.
[14:31] <xnox> such that, sure cloud-init can use oem-config, but it would still require to calculate all the values & preseed them to the oem-config which then hopefully will succeed in setting them.
[14:31] <xnox> it already does the calculation bit, and simply sets them straight away, instead of generating pressed & feeding it to the oem-config.
[14:31] <xnox> so oem-config would be an extra (un-necessary) layer.
[14:33] <ogra_> well, it seems just like a lot less work to rely on oem-config/ubiquity/d-i
[14:33] <ogra_> (which are the same backend wise)
[14:34] <xnox> but d-i is not used at all on cloud images.
[14:34] <xnox> so why _add_ it?
[14:34] <ogra_> ?
[14:34] <ogra_> i didnt say you shoudl add d-i
[14:34] <ogra_> just that the backend functions of d-i and oem-config or ubiquity are identical
[14:35] <ogra_> its all coming out of the same usebs, so you would get distro code changes for free
[14:35] <ogra_> instead of chacing a rabbit and trying to keep up with what the distro does
[14:35] <ogra_> less error potential
[14:36] <ogra_> *chasing
[14:36] <xnox> i am not aware of any distro changes that are being chased.
[14:36] <ogra_> well, bits like dropping groups from the default set and the matching transitions for example
[14:38] <xnox> smoser: did ^^^^ need manual intervention on cloud-init side to handle?
[14:39] <ogra_> to be consistent you simply need to know exactly what changed in distro plumbing to have it in your code as well
[14:40] <smoser> we were affected (and had to realize) the sudo group.  it didn't really affect anything though.
[14:40] <smoser> but there is very little *distro plumbing* baked in to the images, and anything that is, is probably specifically done with intent.
[14:40] <smoser> the group thing sucked. but creation of that default user is now moved to cloud-init.
[14:40] <smoser> the images themselves actually have no local user now.
[14:40] <xnox> smoser: none of which is needed nor wanted in the oem-config.
[14:41] <xnox> smoser: ok. that's what I was thinking that if $ adduser is used, no need to hard-code the default groups.....
[14:41] <smoser> xnox, well, its configurable. it has a default list
[14:42] <xnox> and the default groups come from the deboostrap
[14:42] <xnox> hmm..
[14:43] <smoser> i dont really remember. we did (and do) have a hard coded list of groups that the default user is present in. and we were making the 'sudo' group.
[14:43] <smoser> i forget.
[14:47] <xnox> ogra_: maybe there is point to dig into cloud-init and see how much stuff can be refactored.
[14:47] <ogra_> xnox, well, i'm not really after oem-config in cloud setups ... but more after the functionality that ubiquity uses to make use of the udebs
[14:47] <ogra_> i.e. if you look at the user-setup udeb you wil find it dfoes a lot more than just aclling adduser
[14:48] <ogra_> *calling
[14:48] <ogra_> or rather user-setup-allpy which does the actual user creation
[14:48] <ogra_> *apply
[14:52] <pitti> jodh: hey James, how are you?
[14:52] <jodh> pitti: good thanks - you?
[14:52] <pitti> jodh: fine, thanks!
[14:53] <pitti> jodh: you said in bug 1075976 that eatmydata was a red herring, so do you still need the --no-eat option?
[14:53] <ogra_> xnox, wrt default groups ... http://paste.ubuntu.com/1353260/
[14:53] <pitti> jodh: I'll take the typo fixes in any case of course, thanks!
[14:53] <xnox> ogra_: well on cloud, we have: ubuntu:ubuntu with password ubuntu, no auto-login, no encryption, system groups + inject ssh key fingerprint into ~/.ssh/authorized_keys.
[14:53] <jodh> pitti: I think not, so feel free to ignore that MP (sorry - forgot to cancel it)
[14:53] <pitti> jodh: I like "Lauchpach"!
[14:54] <ogra_> xnox, right, does printing work ? :)
[14:54] <jodh> pitti: :)
[14:54] <pitti> jodh: I'll use it for the typos then; thanks!
[14:54] <jodh> pitti: thanks!
[14:54] <xnox> ogra_: the bits about the groups, yes are correct. but creating lpadmin & sambashare is very "desktop" like
[14:54] <xnox> ogra_: and these are done by those packages anyway.
[14:54] <ogra_> xnox, right, but the udeb would inherit that stuff even from debian, you would have to care if i.e. debian decides to rename lpadmin to lpadmins
[14:54] <xnox> ogra_: so the only useful bit in the whole script (from cloud perspective) is the passwd/user-default-groups
[14:55] <ogra_> -*wouldnt
[14:55] <xnox> which notice, it does not create the user-default-groups first (unless I missed something)
[14:55] <ogra_> xnox, i'm talking about maintenance overheard
[14:55] <ogra_> someone would have to knwo debian renamed the group
[14:55] <ogra_> and would have to change the cloud-init code manually for it
[14:55] <ogra_> instead of just inheriting the change
[14:55] <xnox> the maintainence overhead of keeping the rest of the script working in the cloud image, which doesn't have apt-install and the rest of it.
[14:56] <xnox> is what I think will be more.
[14:56] <ogra_> k
[14:56] <xnox> but we don't know for sure, unless we try =/
[14:57] <cjwatson> Yeah, I think the duplication is justifiable in this case.
[14:57] <cjwatson> It doesn't seem worth all the effort of reengineering that, to me.
[15:21] <toabctl> pitti, can you look at bug 1077938?
[15:23] <pitti> toabctl: deferring to mvo, who is our upgrade master
[15:23] <toabctl> pitti, thx
[15:56] <pitti> bdrung: hey Benjamin, how are you?
[15:56] <pitti> bdrung: I have a question for you in bug 1073390
[16:12] <toabctl> xnox, any news for bug 1037588 ?
[16:14] <xnox> toabctl: no news, it is ok for this be sponsored in debian-experimental + sync into raring, or upload into raring.
[16:15] <xnox> heck, it's one liner. can be done.
[16:18] <toabctl> xnox, seems that the debian maintainer wants to wait until wheezy is released. so we can fix it in ubuntu.
[16:18] <toabctl> right?
[16:19] <OdyX> toabctl: or in experimental
[16:20] <toabctl> OdyX, sure.
[17:01] <bdrung> pitti: ask.
[17:17] <seb128> hum, I managed to screw my apt/dpkg dunno how
[17:17] <seb128> $ LC_ALL=C sudo apt-get install linux-firmware
[17:17] <seb128> dpkg: error processing linux-firmware (--configure):
[17:17] <seb128>  package linux-firmware is not ready for configuration
[17:17] <seb128>  cannot configure (current status `half-installed')
[17:17] <seb128>
[17:17] <seb128> does anyone know how to get out of that state?
[17:18] <xnox> seb128: $ sudo dpkg --configure -a
[17:18] <xnox> ?
[17:18] <seb128> xnox, tried that, no luck
[17:18] <xnox> =(
[17:18] <seb128> that returns without doing anything
[17:18] <xnox> $ sudo apt-get install --reinstall linux-firmware
[17:18] <xnox> ?
[17:18] <cjwatson> find the .deb for linux-firmware, dpkg --unpack it, continue
[17:19] <seb128> xnox, oh, that worked, thanks!
[17:19] <OdyX> (check disk space on the various partitions inbetween
[17:19] <seb128> OdyX, did that before ;-)
[17:19] <xnox> seb128: it's a slightly fancy way of doing what cjwatson suggested ;-)
[17:19] <seb128> OdyX, I stopped an upgrade my-unpacking by close the wrong win
[17:19] <seb128> xnox, cjwatson: thanks
[17:23] <cjwatson> apw: looks like that linux-ppc upload still fails?
[17:35] <apw> cjwatson, yeah benc is on the case
[17:36] <BenC> cjwatson, apw: Since it only takes me about 30 minutes, I'm doing a full binary-arch build to make sure this one works (my mistake for messing with d-i related things without testing that on the .3 upload)
[17:37]  * cjwatson nods
[17:37] <apw> BenC, thanks
[18:31] <janimo> slangasek, the consensus seems to be we need to prompt the user with the written license statement when installing nexus7 wifi/bt firmware. Is something better than debconf note to do that?
[18:57] <shadeslayer> chrisccoulson: got a moment?
[18:58] <shadeslayer> chrisccoulson: I wanted to talk about ubufox
[19:56] <soren> pitti, kees, stgraber, cjwatson, mdz: TB meeting in a couple of minutes, right? Wiki says 2000 UTC.
[19:58] <stgraber> soren: ah yeah, dst change. I'll be there
[20:02] <cjwatson> soren: available whenever anyone else shows up :)
[20:46] <slangasek> janimo: if it's an after-install package install, a debconf note is the right way to do it
[20:47] <slangasek> janimo: not a 'note' actually, but a debconf (boolean) question
[20:53] <kees> anyone know a good javascript CLI like OSX's "jsc"?
[20:55] <highvoltage> something doesn't feel right about that sentence
[20:55] <kees> agreed
[20:56] <mlankhorst> I guess it makes sense that at one point js replaces bash..
[20:56] <kees> I was just watching https://www.destroyallsoftware.com/talks/wat again and wanted to see the javascript bits myself
[20:56] <janimo> kees, nodejs? Not sure what you mean by good though :)
[20:56] <kees> just stuff where I can type   {} + []  and laugh
[20:56] <highvoltage> kees: I guess you've seen http://bellard.org/jslinux/ already :)
[20:57] <mlankhorst> that one was so amusing and scary to run for the first time..
[20:57] <kees> highvoltage: heh yeah
[21:00] <pitti> bdrung: I asked on the bug
[21:00] <pitti> soren: here now
[21:00] <kees> janimo: yeah, nodejs does the trick!
[21:01] <pitti> soren, kees, stgraber, cjwatson, mdz: but it's winter time again, so 2100 UTC?
[21:01] <pitti> I'm still at Taekwondo an hour before
[21:01] <kees> pitti: not sure. I'm fine to move it later
[21:01] <stgraber> 2100 UTC works fine for me too
[21:02] <pitti> perhaps we should define it as 21:00 London time
[21:02] <kees> yay, my day is complete:
[21:02] <kees> > Array(16).join("wat" - 1) + " Batman!"
[21:02] <kees> 'NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN Batman!'
[21:03] <lifeless> kees: the WAT talk ?
[21:03] <lifeless> kees: ah yes, classic
[21:03] <kees> lifeless: yeah, I watch it every few weeks. I got curious about what I could use on Ubuntu that was like "jsc" on OSX
[21:03] <lifeless> kees: question for you - the bug that the libguestfs FAQ points at about -r mode'd kernels
[21:03] <kees> though it looks like v8 is less "fun"^W^Wmore consisten
[21:03] <kees> t
[21:04] <lifeless> kees: he claims you can read the live kernel, but I wanted to verify - that requires root already, right ?
[21:04] <kees> yup
[21:05] <kees> lifeless: if he's got a way to real kernel addresses on a default ubuntu install NOT as the root user, I would consider it a bug.
[21:05] <kees> s/real/read/
[21:05] <lifeless> kees: I wonder if we should mark libguestfs as bad somehow then, since installing it lessens security.
[21:06] <lifeless>  / undoes your hard work
[21:06] <kees> hrm?
[21:07] <slangasek> kees: heh, people were criticizing that talk in CPH on the grounds that the examples don't work in nodejs
[21:07] <kees> slangasek: haha
[21:07] <lifeless> kees: installing it alters the settings you documented, making vmlinuz world readable
[21:07] <kees> slangasek: it's clearly undefined behavior manifesting as humor.
[21:07] <kees> lifeless: O_O
[21:07] <kees> lifeless: bug #?
[21:07] <slangasek> so their defense of the language is that the behavior isn't defined, yes :)
[21:08] <lifeless> kees: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725
[21:09] <lifeless> is the one where your thing is discussed
[21:09] <lifeless> do I need to make to libguestfs so that when a sysadmin installs it, it will
[21:09] <lifeless> change the permissions back to 0644 automatically?
[21:09] <lifeless> ^ is the author of libguestfs
[21:09] <lifeless> I am making an assumption that he has followed up and made those changes
[21:10] <kees> lifeless: well, the act of installing libguestfs shouldn't do the dpkg-statoverride changes -- that's up to an admin.
[21:10] <kees> as such, if an admin uninstalls, they should undo that fix.
[21:11] <lifeless> kees: ack
[21:19] <geofft> Is there an Ubuntu analogue of debian-keyring for PGP keys of individuals (for validating source packages)?
[21:23] <lifeless> geofft: ubuntu-keyring ?
[21:40] <geofft> lifeless: ubuntu-keyring looks like the analogue of debian-archive-keyring (PGP keys for signing the archive itself)
[21:40] <geofft> or am I misreading?
[21:41] <ScottK> No.  You aren't.  There's no exact analogue.  You'd have to find the key in Launchpad and see if it's owned by a developer.
[21:55] <BenC> cjohnston, apw: 0.5 ready and uploading
[21:56] <BenC> cjwatson: ^^
[21:56] <BenC> cjohnston: oops
[22:23] <cjohnston> exit
[22:35] <YokoZar> How do I figure out why my package has been sitting in raring-proposed for over a week?
[22:37] <tumbleweed> YokoZar: you look in http://people.canonical.com/~ubuntu-archive/proposed-migration/
[22:39] <infinity> YokoZar: Is this wine, or something else?
[22:49] <YokoZar> infinity: it is indeed wine, I'm not sure why it is claiming unsatisfiable depends there.  In fact I'm having trouble understanding the output of both of tumbleweed's pages linked.
[22:51] <infinity> YokoZar: It has unsatisfiable depends because it depends on things outside its architecture.
[22:51] <infinity> YokoZar: We'll have to hint it one when we're satisfied that it's otherwise sane.
[22:52] <infinity> YokoZar: As discussed elsewhere, we certainly don't want to allow cross-arch depends as the rule, rather than the exception, or it pretty much breaks the world.
[22:52] <infinity> YokoZar: (Since you could be out-of-date on an arch, but still migrate due to the dep being satisfiable from another, etc)
[22:53] <infinity> YokoZar: As it stands, britney has no concept of multiarch (it only examines the packages files for each arch as a self-contained unit), and I'm pretty sure it would be wrong to teach it otherwise.
[22:54] <infinity> YokoZar: Anyhow.  We'll sort out wine, and see if maybe there's some clever way we can make it an exception to the norm without breaking anything or having to do it manually every time.
[22:54] <infinity> YokoZar: (Talk to me about it tomorrow, when it's not a day off for me?)
[23:03] <YokoZar> infinity: That sounds reasonable, thanks.
[23:36] <bdrung> mdeslaur: libav got a security update, but libav-extra didn't. will it get a security update?