[00:17] dear launchpad people, why do you think i give a flying razoo about mythbuntu documentation, and why am I getting a mail that a mailing list now exists for it? [00:17] Hobbsee: because the world did? :-) [00:17] Hobbsee, I'd assume cause you're indirectly in a group that the list was created for... [00:17] ah. so not the world. just half of the world :-P [00:19] oh, because i'm somehow the owner of the team. [00:20] ah, by this new gateway thing. === matsubara is now known as matsubara-afk [00:20] so, what's the betting that ubuntu dev will now receive *all* mail for any projects that connect to that team. [00:20] ubuntu-dev-without-bugmail must be the biggest hack that I've seen on Launchpad. [00:21] heh [00:21] at least, all mailing list requests. [00:21] [00:21] Mythbuntu documentation [00:21] Via MOTU, Ubuntu Development Team, Ubuntu Development Team (bugmail catching gateway), Mythbuntu. [00:21] * Hobbsee wonders why the mailing list requests don't go to the higher team addresses. [00:22] I think that it is correct to send them to everybody. [00:22] But it wasn't designed for large team hierarchies like we have. [00:24] wgrant: yes....although you've got to wonder, if they wanted big groups to use launchpad, why not. [00:28] I think we really need a membership that simply grants permissions. [00:28] We're not all Mythbuntu developers, but if we want to have permission over the branches we have to be. [00:29] We don't want bugmail, or mailing lists, or any of the other exclusive club membership benefits. Just permissions. [00:29] Much like not all members should be able to upload to a team's PPA/ [00:30] would that work for projects in general, too though? [00:31] Why wouldn't it? [00:32] i'm not sure, i'm just thinking about it [00:33] trying to figure out if projects are also likely to want to. [00:33] i guess if projects get into collaboration with other projects, then they might. [00:38] thx bdrung :) [00:40] yannick: you are welcome [00:42] yannick: suggestion: use same version shema for backports than ubuntu: instead of 1:0.svn20070309-1ubuntu1-gutsybackport2 you could use 1:0.svn20070309-1ubuntu1~gutsy2 [the ~ means lesser, e.g. X~Y < X] [00:42] ok [00:45] yannick: e.g. i would use ekiga-snapshot - 20080826-0ubuntuX for intrepid, 20080826-0ubuntuX~hardyY for hardy, 20080826-0ubuntuX~gutsyY for gutsy, ... (X and Y as placeholder for numbers) [00:45] -0 means that this package is not in debian [00:45] so -0ubuntu1 would be the first release in ubuntu [00:46] i c [00:46] this is only a suggestion, you can name the version like you want, but if you also include ubuntu and debian packages its easier. [00:46] i c? [00:47] = i see? [00:47] yes [00:47] i am too tired already [00:47] for lazy people... [00:47] me too, it's late here [00:47] good night [00:48] i am lazy to, i abbreaviate words with two letters [00:48] (ok -> k) [00:48] gn8 [00:48] gn8 = gute nacht = good night [00:49] ;) bn8 in french [00:51] yannick: can i close your bug #259173? [00:51] Launchpad bug 259173 in launchpad-buildd "Dependancies are not updated even if packages are published." [Undecided,New] https://launchpad.net/bugs/259173 [00:54] bdrung, yes [01:23] hi all. can LP clone bugs? or do i just use 'also affects'? [01:36] wantok: use "also affects". [01:37] but not for too many bugs. [01:37] bdrung: ok. [01:37] er, not too many "also affects" on teh same bug, else launchpad starts timing out. [01:37] Hobbsee: hello [01:37] wantok: hi! [01:37] Hobbsee: :) [01:38] i dont plan to put lots of bugs - just the main bug+1 also affects [01:38] cool [01:39] hm. i want to 'also affects' a package, not an upstream project [01:42] you can do that. [01:42] it's the other button, unless they've been combined now [01:43] ah [01:43] they always confuse me, with that [01:44] not sure i'm Doing It Right, but i guess we will see. when someone looks at the but. [01:48] thanks for the help both. [01:48] :) [01:48] you're welcome [06:09] can teams have karma? [06:16] LaserJock: For what would they use it? Also, how would it be calculated? [06:16] I have no idea, I just wondered [06:16] because when I do a people/team search on LP all the teams have a 0 [06:16] Might also be tricky to differentiate the activity of a team vs. the activity of members of a team (which may not be in any way related) [06:16] Ah. Displaying "0" is probably a bug :) [06:17] so I was thinking, wouldn't it be much more useful to say put the number of members of the team rather than karma? [06:17] I believe currently all teams have zero karma, and no of no action that creates karma for a team. That said, I don't actually know if teams have karma in the DB. [06:17] tems don't do actions [06:18] right, but of course the members of the teams do [06:19] anyway, I was kind of hoping the answer was that they don't have karma, because I'd rather have # of members [06:19] they don't have karma last I checked [07:30] Can people edit their own mirror details? [07:42] lifeless: Teams can do actions, actually. It looks very strange in bugs, but it does happen. [07:43] wgrant: how? [07:43] You just need to know the email address of a team. [07:43] I wonder if teams do actually get karma when that happens. [07:43] wgrant: oh hmm, I'd file a bug on that [07:43] BjornT: ^ [07:45] I'll check that it actually still happens, and file it. [07:56] wgrant: I guess if you were evil you could subscribe a bug to a mailing list that was associated with a team [07:58] jamesh: I can do that anyway through the UI...p [07:59] wgrant: you can subscribe a mailing list to a bug through Launchpad's UI, yes. [07:59] One can unfortunately not associate OpenPGP keys with teams, so nasty things cannot be done. [07:59] I don't think you can do the opposite [07:59] Oh. [07:59] I see. [07:59] I misread. [07:59] I wouldn't be surprised if you can sign up a bug report for a Launchpad account either [07:59] Do dogfood or demo accept email? Staging seems not to? [08:00] jamesh: That would probably work! [08:01] demo accepts email, but won't send it to anyone not on a whitelist [08:02] I don't think staging or dogfood do email [08:02] Thanks. [08:03] wgrant: hi [08:03] jml: Hi. [08:03] wgrant: I just triaged a bunch of launchpad-bazaar bugs, and you filed a non-trivial number of them. [08:04] wgrant: thanks for the clear reports. :) [08:04] jml: So I saw, thanks. [08:04] wgrant: I've asked you for concrete suggestions a few times. The sooner you get around to commenting, the less likely the bugs will get lost. [08:05] I've commented on one so far. [08:05] Not sure what to do about 'Source Code', though mpt (nice timing) seemed to have some ideas. [08:05] I'd like to promise quick fixes, but I'm already kind of busy this cycle. https://edge.launchpad.net/launchpad-bazaar/+milestone/2.1.9 [08:06] Yay, stacked branches! [10:22] jml: After the bugmail I've received today, what's the status of bzr+http mirroring now? [10:24] Hmm, I should've written "After today's bug activity, ..." [10:29] bzr is making a fuss over the format of branches on launchpad. I don't suppose there's any way to upgrade remote branches? [10:30] `bzr upgrade lp:something` should work. [10:30] soren, sure, over sftp, with bzr upgrade sftp:/// [10:30] wgrant, that may default to bzr+ssh, which won't work very well [10:30] beuno: 'very well' or 'at all'? [10:31] wgrant, "at all" [10:31] from a user perspective :) [10:32] This should likely be documented somewhere. [10:32] agreed [10:32] I'll see what I can do about that [10:33] Thanks. [10:36] Ok, it's working now. If, theoretically, this fails... How can I restore the backup? [10:37] bzr+ssh upgrading was fixed in bzr 1.5 or 1.6. Is this some LP-specific brokenness? [11:26] Hi. Commits to various Bazaar branches on Launchpad seem to hang maybe 70% of the way through the progress bar and never make progress. I experienced this with ~planet-ubuntu/config/main yesterday, and am running into what looks like the same thing with ~ubuntu-core-dev/pkgsel/ubuntu today. [11:27] .bzr.log ends with: [11:27] 3.211 Using fetch logic to copy between KnitPackRepository('file:///home/cjwatson/src/ubuntu/pkgsel/pkgsel/.bzr/repository/')() and KnitRepository('bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/pkgsel/ubuntu/.bzr/repository/')() [11:27] 3.211 fetch up to rev {cjwatson@canonical.com-20080827102230-dohb70n2bl2vea1c} [11:28] (FWIW for ~planet-ubuntu/config/main both repositories are RepositoryFormatKnitPack1) [11:29] cjwatson, that's because the local version is in knits, and the it's packs in Launchpad [11:29] different repository formats makes it painfully slow [11:29] upgrading the local format will fix that [11:29] 11:28 (FWIW for ~planet-ubuntu/config/main both repositories are RepositoryFormatKnitPack1) [11:29] cjwatson, not according to the .bzr.log [11:29] KnitRepository('bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/pkgsel/ubuntu/.bzr/repository/') [11:30] I didn't paste you the .bzr.log for planet-ubuntu [11:30] siretart, are you here? [11:30] as I said, I'm encountering this on two different branches [11:30] I pasted you .bzr.log for the occurrence today, in pkgsel [11:30] also, that log seems to suggest that it's the Launchpad repository that uses knits, not the local one? [11:31] cjwatson, yes, sorry. Launchpad is using the old format [11:31] wgrant, are you around? [11:31] I'm happy to upgrade the Launchpad one, although of course that's also painfully slow :-/ [11:31] I got confused with the ~planet one... [11:31] .bzr.log for planet-ubuntu ended: [11:31] 9.774 added revision_id {cjwatson@canonical.com-20080826112957-4zdxi00q8yn2bpoq} [11:31] 9.779 Using fetch logic to copy between KnitPackRepository('file:///home/cjwatson/src/ubuntu/planet-ubuntu/main/.bzr/repository/')() and KnitPackRepository('bzr+ssh://bazaar.launchpad.net/%7Eplanet-ubuntu/config/main/.bzr/repository/')() [11:32] cjwatson, maybe, for planet, you hit an auto-repack. That makes it very slow. Logs should tell you what it did [11:32] according to the log I ctrl-c'ed at 128.802 [11:32] does it say anything about auto-packing? [11:32] the log does not say anything about auto-repacking [11:32] no [11:32] Rinchen: yes? [11:32] the messages pasted above, immediately followed by the KeyboardInterrupt traceback [11:32] siretart, fantastic [11:33] cjwatson, if this keeps happening, try using -Dhpss flag, so we can boil it down to a bug in bzr, or a network issue [11:33] I duplicated the same thing over sftp:// as well [11:33] siretart, can you tell me what problem MOTU faces currently with debian NSS changelogs not being complete inside Launchpad? What sort of pain does this cause? [11:33] what do you mean with 'NSS changelogs'? [11:34] Rinchen: I am. [11:34] siretart, Changelog repackaging for native source syncing - Allows us to store proper changelogs for Debian-NSS'd packages [11:34] wgrant, thanks. Same question to you as to siretart above [11:34] I'm trying to understand why that's a high priority for MOTU [11:35] There's no point having a changelog if it isn't complete. [11:35] why? [11:35] At the moment we have to download and extract the source package to get useful information. [11:36] why do you mean by useful? [11:36] s/why/what [11:36] kiko talked about this to me as well, but I wasn't clear on what the problem was. Is the problem that it's leaving out intermediate changelog entries when we skip over multiple versions in a sync? [11:37] cjwatson, yeah, we're talking about this right now in Danakil :-) [11:37] Rinchen: (BTW NSS is a confusing acronym here because it's also the name of a Debian package) [11:37] yeah [11:37] The NSS reference had me thoroughly confused at first. [11:37] my apologies [11:37] wiki page shorthand ;-) [11:38] Launchpad doesn't display the changelog at the moment, it displays a collection of almost-changelog-snippets from changesfiles. These often omit changelog entries. [11:38] A changelog isn't much use unless it lists the changes. [11:38] And if it omits some changelog entries, it doesn't list the changes. [11:38] of what use is the changelog in your process? [11:38] Rinchen: so what are you discussing right now, NSS or making launchpad displaying a proper changelog for a package? [11:38] I understand what LP is doing and why with respect to the changelog [11:39] I need to understand why this is a problem for you [11:39] siretart, proper changelog [11:39] Rinchen: the changelog is needed everytime you need to decide whether to sync or merge a package. or to see who to contact if someone has a question about a particular change in a package [11:40] Rinchen: omitted changelog entries mean that we loose both credits and useful information about who might know better about a package [11:40] Or if you want to see when a bug was introduced. [11:40] or fixed [11:40] Or that. [11:41] but if the the package is already synced, what else does your process require? [11:41] so, we have changelog entries 1,2, 5, and 6..... [11:42] the sync might have been a wrong decision. we need some way to notice and review that [11:42] espec. if a sync drops ubuntu changes [11:42] Changelog entry 4 says that a key piece of functionality was removed because it was non-free. [11:42] We now have a bug saying that it used to work but didn't. [11:43] I glance at the Launchpad-supplied changelog, believing that such a major change would be noted in the changelog. [11:43] Changelog entry 4 is missing, which misleads me into thinking that the user or something else is broken. [11:43] great, this is what I wanted to know.... [11:43] cjwatson, ^^ [11:44] Launchpad seems to aim to be everything to everybody, so it should either provide a useful changelog so that I don't have to open up a terminal and download the source package, or it shouldn't supply one at all. [11:44] It's like +packages was until 2.1.8 - incomplete is often worse than unavailable. [11:45] siretart, wgrant - great, thanks. [11:45] wgrant: moreover it seems to me that the package changelog on launchpad must be conceptually different from the changelog in the package [11:46] wgrant: the latest changelog in the package might miss ubuntu changes (e.g. after it was synced), or if earlier changelog entries have been edited or corrected [11:47] ideally launchpad would offer both: it's own package changelog and the bare debian/changelog file from the package so that a ubuntu developer can compare and check [11:47] Rinchen: ^^ [11:47] siretart, wgrant - thanks. I'm going to copy the above for our purposes. I appreciate it. I've got what I needed for scheduling purposes. [11:48] Rinchen: you're welcome [11:50] Rinchen: np [11:50] Rinchen: Thanks for trying to improve this. [11:51] Rinchen: if you have further questions or something, feel free to ask anytime! I do read backlogs :) [11:51] wgrant, our (really) pleasure. Part of what we were missing is "the why". Why was this important? If we don't understand the pain in the process it's hard for us to give it a good scheduling priority. [11:52] So the info about really helped with that [11:52] siretart, great! thanks. [11:52] wgrant, when associated with all the other items on our list that is.... [11:52] we have a huge list :-D [11:52] Of course. [11:53] Speaking of incomplete changelogs... do we have a changelog for what's new on edge/production yet? [11:53] yes, the list alone for malone was impressive :) [11:53] indeed, a list of changes between production and edge would be very handy [11:54] unfortunately that's hard to do at the moment for a few reasons. However, we've got some items on the priority list which will make this easier [11:55] also, when LP goes open source, it becomes significantly less of an issue and I'll have other options available to do this [11:55] This is true, and not that far off. [11:55] this is the 2nd time I hear about that plan. is there an official announcement for that that I missed? [11:55] e.g. pqm commits could go to a public email list [11:55] I'll be interested to see how you make it work. [11:56] wgrant, on the schedule to talk about later today I think :-) (we're doing a LP team lead meeting in London this week) [11:56] Aha. [11:58] LP in its entirety, or with Soyuz remove like the FAQ used to imply? [11:58] it was very helpful to have a set of priorities from siretart for motu btw [11:58] +d [11:58] It was excellent to have priorities requested. [11:58] LP entirely [11:58] we just happen to be talking about soyuz at the moment [12:22] argh. bzr upgrade sftp://bazaar.launchpad.net/... fails halfway through and now I can't retry it because backup.bzr already exists. [12:25] Can you manually sftp in and do something? [12:26] I can't ls backup.bzr so it's not clear to me that I'll be able to remove it [12:27] trying rm -rf with lftp [12:27] thumper, ^^ [12:29] cjwatson: did you move the backup.bzr dir back to .bzr? [12:29] no [12:29] it's ~ubuntu-core-dev/pkgsel/ubuntu [12:29] oh, err, shit, I shouldn't have attempted to remove backup.bzr should I ... [12:30] maybe not :) [12:30] thumper: any chance you could move it back, and I'll push my branch again to fix up any damage? [12:30] cjwatson: can you do the upgrade locally and repush? [12:30] I upgraded it locally about six months ago [12:31] hmm.. [12:31] I can certainly repush if the branch is now absent on Launchpad [12:31] pushing doesn't upgrade the remote end [12:31] beuno: how can we repush to overwrite the current? [12:31] cjwatson, try push --overwrite [12:31] although, if the .bzr dir is b0rked, that may not work [12:31] let's see how smart we are... :) [12:32] beuno: can he delete the .bzr dir completely, and repush with --use-existing? [12:32] thumper, yeap, that works too [12:32] the whole lack-of-remote-upgrade thing is such a pain [12:32] there's no working tree on LP, so that's fine [12:32] cjwatson, it is [12:32] s/lack-of-remote-//, really. [12:32] cjwatson: there is upgrade support over bzr+ssh [12:32] cjwatson: in bzr.dev now I think [12:32] thumper: is that new? there wasn't as of quite recently [12:33] beuno: so rm -rf .bzr over lftp? [12:33] cjwatson: yes it is new, but beuno just pointed out it doesn't do what I think it does [12:33] cjwatson, yeap, and then use push --use-existing, as thumper said [12:33] (that's actually faster than upgrading really) [12:33] interesting [12:33] No new revisions to push. [12:33] ugly, but way faster, as you only transfer once, and save CPU [12:33] ?? [12:34] ? [12:34] cjwatson, try --overwrite too [12:34] ¿ [12:34] wgrant: :) [12:34] beuno: hmm, because remote upgrade needs to fetch and then push? [12:34] LarstiQ, yeap, fetch, upgrade, and push [12:34] beuno: same [12:34] beuno: and do an additional conversion, whilst you've already done that locally? [12:34] Good recipe for my new book: "Creative ways to hack bzr and get away with it" [12:34] so 2x network, and CPU [12:34] beuno: right, makes sense. [12:35] cjwatson, nuke the branch in LP, re-push. thumper, that should work, right? [12:36] wait [12:36] * beuno is thrown off by bzr claiming that no new revisions are there, when the .bzr has been nuked [12:36] the .bzr directory is still there [12:37] I guess rm -rf in lftp didn't actually work [12:37] * thumper is looking on the actual codehost box [12:37] cjwatson: repush [12:37] cjwatson: with use-existing [12:37] thumper: I have done. twice [12:37] cjwatson: I've just moved the .bzr dir [12:37] once without --overwrite, once with [12:37] oh, ok [12:39] thumper, we need a how-to-upgrade in Launchpad entry en the help.lp.net wiki [12:39] beuno: we sure do [12:39] and start nagging people to upgrade [12:39] this sucks [12:40] more and more knit <> packs problems [12:40] can we not just upgrade everyone's branch on LP? :P [12:40] What? I'm sure thumper would love to be poked for every branch. [12:40] we need to make an easy way to handle this from bzr [12:40] ideally [12:40] meanwhile... [12:40] cjwatson: we can't guarantee their client version [12:40] cjwatson: ideally we want everyone to upgrade to format 1.6 [12:40] cjwatson: but hardy still has bzr 1.3.1 [12:41] format 1.6 requires bzr 1.6 [12:41] And Hardy will continue to have bzr 1.3.1 for 3 years. [12:41] right [12:41] wgrant, we don't have a new default format in 1.6 [12:41] it's experimental [12:41] so it's still 0.92-compatible [12:41] AFAIK [12:41] *intrepid* still doesn't have bzr 1.6 :P [12:41] wgrant: unless they add the bzr ppa :) [12:41] thumper's statement indicated a suspicion that it might change. [12:41] cjwatson: bzr 1.6 was only just released [12:41] indeed [12:42] thumper: But adding PPAs is mildly foolish. [12:42] wgrant: I understand, I got bitten yesterday with a ppa [12:42] thumper: They're unsigned, so it's worse than that. [12:42] bitten, chewed, and spit out in fact there thumper [12:42] wgrant, not for long ;-) [12:42] ideally I'd like to see bzr 1.6 backported to hardy... [12:43] Rinchen: Has a workable solution been devised? [12:43] but it doesn't quite fit the LTS idea [12:43] * thumper thinks [12:43] they've already said "no 1.6 in Hardy. Just a cherrypick for a few annoyances" :/ [12:44] This is how sane distributions work, I'm afraid. [12:44] wgrant, workable or not, we've made it a very high priority [12:44] Rinchen: Good to hear. [12:44] IIRC cjwatson wrote up a nice solution, but it does result in an awful lot of keys. [12:45] wgrant, siretart - so, if things done change, MOTU's request for signed ppas, changelogs, and support for pkg sync reviews should be in by December [12:45] s/done/don't [12:46] I'm glad that at least one of the horrible security holes has been fixed recently. [12:46] wgrant: "the correct number of keys" [12:46] And another by the end of the year is good. [12:47] cjwatson: Doesn't stop it from being awfully large. [12:47] the alternative is too bad :) [12:47] It is. === salgado is now known as salgado-brb [12:57] thumper: so now the same thing is happening when pushing that branch from scratch [12:58] thumper: it's hanging at "2.730 Using fetch logic to copy between KnitPackRepository('file:///home/cjwatson/src/ubuntu/pkgsel/pkgsel/.bzr/repository/')() and KnitPackRepository('sftp://bazaar.launchpad.net/%7Eubuntu-core-dev/pkgsel/ubuntu/.bzr/repository/')()" in .bzr.log [12:58] thumper: is it possible to find out what's going on at the server side? [12:59] the client progress bar says "Copying signature texts" [13:00] Rinchen: excellent! === salgado-brb is now known as salgado === DasIch_ is now known as DasIch [13:30] thumper: it timed out for the second time [13:31] thumper: let me know if you want me to re-run it when you're around to investigate === jordi_ is now known as jordi [14:16] gangotri seems to be failing at timezones again. [14:17] Date: Wed, 27 Aug 2008 13:49:24 -0000 [14:17] That is a lie. [14:17] It actually means +1000 [14:17] Er, +0100 [14:18] (this results in emails appearing an hour in the future, which is suboptimal) [14:22] hi to all [14:22] Someone know why I get "Failed to upload" error on [14:22] PPA? [14:22] devfil: it should give an explanation? [14:23] devfil: the source is generating binaries with old versions. [14:24] cprov: so I need to wait for the old binaries to be removed and then I should retry the build, right? [14:25] devfil: not really, nothing will be done automatically in this context, you have to remove existing ones manually and then retry the build. [14:26] cprov: how can I remove existing ones? [14:27] devfil: use the delete-package form on your PPA [14:27] devfil: what's the url of the failed-to-upload build ? [14:27] cprov: https://edge.launchpad.net/~msn-pecan/+archive [14:28] I've already requested the deletion for old packages [14:38] devfil: right, from what i see in your archive the binaries for amd64/lpia are gone, which means the failed builds should work, retry one of them and we will see. [14:45] devfil: it didn't work :( [14:45] cprov: failed to upload again [14:46] cprov: Version older than [14:46] that in the archive. 0.0.14+83-g03933cc-0msnpecan1 <= 0.0.14+g03933cc-0msnpecan1 [14:47] so I need to wait for the binaries removal [14:49] devfil_: the amd64 and lpia binaries are not there anymore, http://ppa.launchpad.net/msn-pecan/ubuntu/pool/main/m/msn-pecan/ [14:49] cprov: msn-pecan_0.0.14+g03933cc-0msnpecan1 version yes [14:51] devfil_: but "upstream+83" version is higher than that, no ? [14:51] cprov: it seems no [14:52] cprov: this is from the upload debug Version older than [14:52] that in the archive. 0.0.14+83-g03933cc-0msnpecan1 <= 0.0.14+g03933cc-0msnpecan1 [14:52] devfil_: it was considered so for i386 binaries [14:53] cprov: there are no i386 binaries for 0.0.14+g03933cc-0msnpecan1 version [14:54] devfil_: right, there we go ... [14:57] devfil_: $ dpkg --compare-versions 0.0.14+83-g03933cc-0msnpecan1 lt 0.0.14+g03933cc-0msnpecan1; echo $? [14:57] 0 [14:58] devfil_: 'g' > 8, I guess === danilo_ is now known as danilos [15:15] god damnit, that's annoying (mythbuntu new mailing list cascading up) [15:16] cprov: so what can I do? [15:21] devfil_: the only solution I can see is to upload a new source with sane version (but that might be simplistic) [15:22] cprov: who can remove the older debs? I think this solution is better [15:22] devfil_: you can do it ;) [15:23] cprov: I already asked with the form for the remotion, but who can really do it? [15:24] cprov: msn-pecan - 0.0.14+g03933cc-0msnpecan1 d.filoni 15 hours ago Deleted Intrepid Net Built successfully [15:24] Mez: See -motu. [15:24] status = deleted [15:24] wasn't in there... what'd I miss jpds [15:25]