| adeuring | good morning | 08:28 |
|---|---|---|
| mrevell | Hi! | 09:12 |
| wgrant | bigjools: Morning... | 09:12 |
| bigjools | morning! | 09:12 |
| wgrant | So, I found something in Dominator this morning which is indeed rather similar to the ddeb issue - atomic arch-indep domination, which I didn't really know existed before reading the code. | 09:13 |
| bigjools | yeah I've not delved into that code | 09:14 |
| wgrant | Turns out it suffer(s|ed) from the same problems I identified with the ddeb situation: bug #178102, bug #192547. | 09:14 |
| mup | Bug #178102: (Pro|De)motion loses arch: all binaries <Soyuz:Fix Released by cprov> <https://launchpad.net/bugs/178102> | 09:14 |
| mup | Bug #192547: Doubly-overridden binaries get eaten <Soyuz:Triaged> <https://launchpad.net/bugs/192547> | 09:14 |
| bigjools | aha | 09:14 |
| wgrant | (I reported both, but forgot about them, funnily enough) | 09:14 |
| bigjools | :) | 09:14 |
| wgrant | The first was fixed by doing what you suggested last night: matching component/section/priority. | 09:15 |
| bigjools | oh jeez, see #lanchpad :) | 09:15 |
| wgrant | Hahha. | 09:15 |
| wgrant | The second was marked as a duplicate of another bug, but I do not understand how a fix for one fixes the other. | 09:17 |
| bigjools | I'm just reading it | 09:18 |
| wgrant | Presumably Celso had some idea, but there is no public record of that. | 09:18 |
| bigjools | it's ok I know where he lives, I can kidnap his dog | 09:20 |
| wgrant | Heh. | 09:20 |
| bigjools | wgrant: the duped one could be un-duped and fixed as easily as you suggest | 09:23 |
| bigjools | I don't quite understand why it's a dupe wither | 09:24 |
| wgrant | bigjools: But I didn't suggest... | 09:24 |
| bigjools | either | 09:24 |
| bigjools | wgrant: in the description for it you suggest not allowing identical overrides | 09:24 |
| wgrant | That was before I saw the code. | 09:24 |
| wgrant | That's not feasible. | 09:24 |
| bigjools | lol | 09:24 |
| bigjools | ok I think I see why it's a dupe | 09:25 |
| wgrant | In the initial case that I saw, the binary had been consecutively overriden identically twice. | 09:25 |
| wgrant | But the same problem will occur even if there are intermediate overrides. | 09:25 |
| wgrant | Oh, really? Please explain! | 09:25 |
| wgrant | I considered that the override could instead mutate an existing Pending publication, which would probably fix this. | 09:26 |
| wgrant | But that seems a bit evil. | 09:26 |
| bigjools | yeah can't do that | 09:26 |
| bigjools | or the publisher would have some issues | 09:26 |
| wgrant | No, there are no publisher problems there. | 09:26 |
| wgrant | But you seem to have a better solution. | 09:27 |
| bigjools | well it would need to re-write indexes | 09:27 |
| wgrant | If it's Pending, it hasn't written it out in the first place. | 09:27 |
| bigjools | anyway I don't have a solution | 09:27 |
| wgrant | Oh, right, you just had a reason for it to be a dupe. What is that? | 09:28 |
| bigjools | if it's published, it has | 09:28 |
| wgrant | If it's published, it won't cause itself to be dominated. => not a problem | 09:28 |
| wgrant | Hmm. | 09:28 |
| wgrant | Anyway. Why is it a dupe? | 09:28 |
| bigjools | I am not particularly familiar with the code there, but you'd surely need to know where it was overridden from | 09:29 |
| bigjools | I think it's to do with the fact that the whole overriding mechanism is a bit bong and has many race conditions | 09:30 |
| bigjools | I'm still getting it straight in my head | 09:30 |
| wgrant | If this problem hadn't popped up in ddeb territory too, I would be more likely to place the blame on the fairly strange way that arch-indep publications work. | 09:31 |
| jml | wgrant, "should be pretty easy" -- famous last words :) | 09:41 |
| * bigjools nods | 09:41 | |
| wgrant | jml: Pfft. | 09:44 |
| wgrant | Admittedly I didn't see ddeb stuff getting even close to this hairy. | 09:44 |
| simon-o | Hi, when I merge a branch is and push it. Is the status of the branch I merged from automatically set to merged? | 10:05 |
| jml | simon-o, I think so. | 10:07 |
| jml | simon-o, but I think it depends on the branch that was merged into. | 10:07 |
| simon-o | jml: thanks, I guess it just takes some time | 10:07 |
| jml | simon-o, only a few minutes, normally. | 10:07 |
| BjornT | jml: it depends on into which branch you're merging into, no? | 10:07 |
| jml | BjornT, yes, that's what I meant to say :) | 10:08 |
| jml | also, we don't mark series branches as merged, since that turns out to be a real pain. | 10:08 |
| BjornT | simon-o: which two branches did you merge? | 10:09 |
| simon-o | BjornT: I merged lp:~simono/launchpad/xx-links into lp:~launchpad-dev/launchpad/python-migration | 10:10 |
| simon-o | and the MP was set to merged and I wondered what happens to my branch now | 10:11 |
| BjornT | simon-o: i suspect the status won't change. it's a bit odd, though, since the MP was set to merged, so i would file a bug about it. | 10:12 |
| wgrant | I don't think it's safe to automatically change the branch status in that cas.e | 10:14 |
| wgrant | Or I will start hiding everybody's branches by merging them into mine. | 10:14 |
| jml | yeah. | 10:15 |
| simon-o | wgrant: that's correct, but in which case can you change the status automatically? Because I never changed the status of my branches myself | 10:15 |
| jml | the "Merged" status sucks. | 10:15 |
| jml | simon-o, when they are merged into trunkp. | 10:15 |
| BjornT | wgrant: why not? he said was intending to merge the branch. | 10:16 |
| simon-o | jml: ok, that makes sense. And it explains why I never saw this before, because I nearly always merge into trunk | 10:16 |
| wgrant | BjornT: Perhaps, but that may not be final. I think it's best to be conservative when making branches disappear. | 10:17 |
| BjornT | wgrant: i said it was odd because there was an MP indicating the intention to merge. if you would merge my branch, without there being an MP to merge into your branch, we should definitely not change the status | 10:17 |
| jml | simon-o, right :) | 10:17 |
| jml | just to be clear | 10:17 |
| jml | having a status of a branch called "Merge" is a misfeature. | 10:17 |
| jml | "Merged", rather. | 10:17 |
| BjornT | wgrant: why show the branch, if there are no new revisions in that branch? | 10:17 |
| BjornT | jml: i agree that the branch status story needs a bit of a re-design | 10:18 |
| wgrant | BjornT: define "new" | 10:18 |
| BjornT | wgrant: revisions in A that aren't in branch B (where B is the branch that branch A was to be merged into) | 10:19 |
| wgrant | Perhaps. It all needs a big rethink. | 10:20 |
| noodles775 | thumper: did you mention something recently about counting queries during tests? If so, where can I find it? | 10:36 |
| noodles775 | (sorry to disturb your evening if you're already gone!) | 10:36 |
| jml | noodles775, it's in the base TestCasue | 10:40 |
| jml | lp.testing.TestCase | 10:40 |
| noodles775 | jml: great, thanks. | 10:40 |
| jml | noodles775, np. | 10:40 |
| mwhudson | hello jml | 10:48 |
| mwhudson | (and everyone else!) | 10:49 |
| jml | mwhudson, hi | 10:51 |
| jml | mwhudson, mwhudson, http://code.mumak.net/2009/10/command-line-apps.html | 11:54 |
| === mpt_ is now known as mpt | ||
| === bigjools is now known as bigjools-lunch | ||
| === matsubara-afk is now known as matsubara | ||
| === mrevell-lunch is now known as mrevell | ||
| jml | sinzui, I'm working on a script that maybe will make reviewing projects easier | 14:03 |
| sinzui | Do you want mine? auto-approve does a lot of nice things | 14:03 |
| jml | sinzui, http://pastebin.ubuntu.com/293935/ is the output of the first chunk of work: a nice display of useful bits of a project | 14:04 |
| jml | sinzui, oh, yes please. | 14:04 |
| jml | sinzui, I couldn't find it in lp-dev-utils. | 14:04 |
| sinzui | It is very personal. I codified the rules I observed I used | 14:04 |
| jml | oh. | 14:04 |
| jml | sinzui, well that's good. I was planning on making something that was still manual, just less manual than the web ui. | 14:05 |
| sinzui | jml: http://pastebin.ubuntu.com/293940/ <- The one aspect that is missing is announcements, They are not exposed in the UI, but I tend to approve when I see them. | 14:06 |
| === bigjools-lunch is now known as bigjools | ||
| jml | sinzui, what's lpapi? | 14:09 |
| sinzui | jml, the undecided license scenario should be automated in Launchpad because we really need to communicate with the owner that they can easily violate the terms of hosting if they write or choose a non-standard license. | 14:09 |
| jml | sinzui, agreed. | 14:09 |
| sinzui | jml: lpapi came from launchpadlib | 14:10 |
| jml | sinzui, is projects.licensing_search restricted in some way? | 14:38 |
| sinzui | It is the same search that is used on the review page? | 14:38 |
| jml | sinzui, it's what auto-approve uses. | 14:39 |
| jml | sinzui, I don't know if it's what the review page uses. | 14:39 |
| sinzui | the page that lists the projects uses the license search. | 14:40 |
| jml | sinzui, I'm getting a 401 Unauthorized error when I try to use it in APIs | 14:41 |
| jml | does it require lp.Edit maybe? | 14:41 |
| jml | ahhh, yes it does. | 14:41 |
| jml | that's probably a bug. | 14:41 |
| sinzui | it certainly is if you can use the page, but not the api | 14:42 |
| jml | sinzui, well, I can use the API, but I need to grant my application "Change" permissions on the oauth page. | 14:44 |
| jml | sinzui, I shouldn't have to do that to run a search. | 14:44 |
| sinzui | hmm | 14:44 |
| sinzui | That script I sent does lots of changes. | 14:45 |
| jml | sinzui, yes, but me doing a search shouldn't require any changes | 15:01 |
| === danilo_ is now known as danilos | ||
| sinzui | agreed. I do not think that feature reveals confidential information, but that may need to be vetted | 15:01 |
| jml | sinzui, even so... | 15:02 |
| jml | sinzui, that's not what launchpad.Edit is for. | 15:02 |
| sinzui | jml: consider this feature was for a very restricted team of two users until recently | 15:03 |
| sinzui | I am sure we want to review the rules given that we have opened it up to more users | 15:03 |
| jml | sinzui, fair enough. | 15:04 |
| jml | sinzui, the script I've written downloads the entire list of projects to review, and then lets you select '(s)kip (a)pprove (q)uit (d)one' | 15:05 |
| sinzui | sweet. | 15:05 |
| jml | sinzui, and then, when you are done, it will (not done yet) submit all of the changes to Launchpad | 15:05 |
| sinzui | Does it send emails? yet? | 15:06 |
| jml | sinzui, I'm assuming that the "Approve" action is just "mark approved, mark reviewed, clear whiteboard" | 15:06 |
| jml | sinzui, do we need to send emails for approval? | 15:06 |
| sinzui | No | 15:06 |
| jml | sinzui, ok. then we'll worry about that when I add a '(r)eject' option :) | 15:07 |
| sinzui | Nor do I think we should send emails to feedback if we want the user to provide more information, but we approved it anyway...because we do not intend to followup wit that | 15:07 |
| jml | sinzui, yeah. there should be a more info action too. | 15:10 |
| matsubara | gary_poster, rockstar, bigjools, danilos, sinzui, allenap, Chex: LP production meeting in 14 min @ #launchpad-meeting | 15:46 |
| gary_poster | ty | 15:46 |
| danilos | matsubara: if I must, sure :) | 15:47 |
| matsubara | danilos, you can send someone else, if the timing is not good for you | 15:49 |
| danilos | matsubara: nah, everybody else (apart from Ursula and me) is on vacation, I am just not feeling too good, but IRC meeting should be something I can handle | 15:50 |
| matsubara | danilos, ok | 15:51 |
| jml | beuno, sinzui, is there any particular reason that we didn't put the series / milestone graph on distros? | 16:29 |
| sinzui | jml: development time | 16:29 |
| beuno | jml, IIRC, missing API | 16:29 |
| sinzui | beuno: API + code | 16:30 |
| jml | what we like to call "work" :) | 16:30 |
| beuno | yes, missing work | 16:31 |
| sinzui | jml: we did not consciously reject it. it is a matter of thousands of project verses 6 distros | 16:31 |
| jml | sinzui, I guess this means that distros & projects present substantially different interfaces re series & milestones? | 16:31 |
| * sinzui thinks more code needs to move into PillarMixin and SeriesMixin | 16:31 | |
| jml | sinzui, well, I was thinking more that there should be an ISeries interface that the graph could be written in terms of | 16:32 |
| sinzui | jml ^ Not at all, We need to dismantle the impelmentation into their common parts | 16:32 |
| jml | hmm. | 16:32 |
| jml | sinzui, when you implement a series- or milestone-related feature now, do you in general have to do the work twice: once for projects, once for distros? | 16:33 |
| sinzui | jml: I did not focus on distros, but distros, projects, and series all use the same milestone mixin to implement IHadMilestone | 16:34 |
| jml | ok. | 16:35 |
| sinzui | jml: I think you need to keep in mind that these very early objects need more than love, sometimes bombs are needed to remove the cruft. Once the team faltered in February, we focused on the greatest need | 16:36 |
| jml | sinzui, *nod* | 16:37 |
| jml | sinzui, my questions were aimed at figuring out whether we should allocate time to cleaning up the model here | 16:37 |
| sinzui | jml: They really do need to be dismantled to bring consistency. There are blocking issues too, like I cannot make compatible urls for distros, projects, and projectgroups without very invasive work | 16:37 |
| jml | sinzui, I am interested in your ideas and wish to subscribe to your newsletter. | 16:38 |
| sinzui | jml: 15% of registry bugs about removing unused features, or reconcilling behaviour | 16:38 |
| sinzui | jml: Removing the cruft from the models will make launchpad easier to learn because it is consistent. We are maintaining this cruft too. | 16:41 |
| jml | sinzui, easier to learn is good, but it's not quite as interesting to me as "faster to develop" or "harder to miss things" | 16:42 |
| jml | sinzui, although they aren't exactly mutually exclusive :) | 16:43 |
| sinzui | jml: my team was create to think about this. It did take me a year to digest every bug and touch all the code to see the big problem. It can also be challenging since these are core object that other teams are making assumptions about | 16:44 |
| jml | sinzui, I'll bet! :) | 16:44 |
| jml | sinzui, I imagine that sometimes the other areas of the app are making crappy assumptions. | 16:45 |
| jml | sinzui, do you have a roadmap for cleaning up the registry, or is it mostly in your head still? | 16:45 |
| sinzui | yes. but there is still the case were one team does a fab implementation for one pillar, but does not consider that it can be applied to all pillars | 16:45 |
| sinzui | No map. My hopes were dashed in March. I really thought the series and project work would let me fix the models | 16:46 |
| jml | *nod* | 16:47 |
| sinzui | The bugs are tagged with cleanup, tech-debt, infrastructure. I can get you a report (using tags) for next week | 16:48 |
| jml | sinzui, ok. no rush, but it'd be nice to have by UDS. | 16:48 |
| jml | sinzui, regarding good implementations for one pillar, but not for others | 16:48 |
| sinzui | for some reason these core bugs keep showing up in my searches. maybe that is why I think they are core | 16:48 |
| jml | sinzui, that's a problem we really need to solve exactly once. | 16:49 |
| sinzui | yep | 16:49 |
| jml | sinzui, where we = you, BjornT & I and whoever else is interested | 16:49 |
| bigjools | sinzui: so where did you get to with the script failure? | 16:51 |
| sinzui | bigjools: I am subscribed to the list. | 16:52 |
| bigjools | what list? | 16:53 |
| sinzui | My filter is on nightly and on (Daemon|script-failures) | 16:54 |
| sinzui | bigjools: I cannot find how I am getting the email. I recall subscribing to a list and configuring to to send only certain classes of emails | 16:58 |
| bigjools | isn't it sent to the internal list? | 16:58 |
| === salgado is now known as salgado-lunch | ||
| === dpm is now known as dpm-afk | ||
| === beuno is now known as beuno-lunch | ||
| mrevell | okay, g'night friends | 18:02 |
| === matsubara is now known as matsubara-lunch | ||
| === beuno-lunch is now known as beuno | ||
| === salgado-lunch is now known as salgado | ||
| sinzui | barry, bac, EdwinGrubbs: release meeting in 2 minutes | 18:59 |
| === matsubara-lunch is now known as matsubara | ||
| dobey | hrmm | 20:09 |
| dobey | kfogel: ping | 20:09 |
| === salgado_ is now known as salgado | ||
| === ursula_ is now known as Ursinha | ||
| barry | thumper, mwhudson ping | 20:36 |
| mwhudson | barry: good morning | 20:36 |
| barry | mwhudson: hi. do you have a few minutes to join a discussion going on in #launchpad-sprint? | 20:37 |
| barry | we're working on the py2.4 -> 2.5 upgrade and there are soem questions about a codehosing test | 20:37 |
| barry | er, code hosting | 20:37 |
| barry | :) | 20:37 |
| mwhudson | jml: did you get my twisted talk slides? | 21:13 |
| EdwinGrubbs | sinzui: ping | 21:34 |
| sinzui | Hi EdwinGrubbs | 21:34 |
| mwhudson | rockstar, abentley: i feel like i'm lagging horribly on this call | 21:34 |
| mwhudson | back to os x tomorrow then i guess | 21:35 |
| EdwinGrubbs | sinzui: I was thinking about removing the "PPA Packages" link from the person/team index page since there is already a link next to it to the "Related projects" page, and that page has a menu with a link to the "PPA Packages". | 21:36 |
| sinzui | hmm | 21:36 |
| sinzui | There are two problems here isn't there? One link is to *related* PPAs which I do not own and *Owned* PPAs | 21:37 |
| EdwinGrubbs | sinzui: correct. The related PPAs are ones that contain a package that was created by that person, although it may have been copied into that PPA by someone else. | 21:39 |
| sinzui | yes, so we need to keep those links distinct. I would prefer to remove all *related* paages since no one can say what they are for | 21:39 |
| EdwinGrubbs | sinzui: that sounds like a soyuz bug to me. | 21:40 |
| sinzui | EdwinGrubbs: they say we own it, which is why I think I have the right to remove them | 21:40 |
| bigjools | sinzui: I | 21:41 |
| bigjools | 'm sure I told you a few times | 21:41 |
| sinzui | EdwinGrubbs: https://edge.launchpad.net/~launchpad <- the links under kiko need to read | 21:42 |
| sinzui | (i) Related project (i) Related PPA packages | 21:42 |
| sinzui | bigjools: You have said that user can see packages and software. But since there are no actions that can be taken from that information I do not value it | 21:43 |
| bigjools | sinzui: I said that the MOTUs use it to review new MOTU applicants' work | 21:44 |
| sinzui | bigjools: https://edge.launchpad.net/~sinzui/+related-software | 21:44 |
| sinzui | ^ is a bug fat lie and I do not want anyone to every see that lie | 21:44 |
| sinzui | bigjools: so do we need to see projects and PPAs? Packages are the motu work? | 21:45 |
| sinzui | bigjools: And what is the action item? Add this user to the motu team? | 21:45 |
| bigjools | yes | 21:45 |
| bigjools | or not add | 21:45 |
| bigjools | but I suggest you talk to wgrant about it as he's our MOTU contact | 21:46 |
| sinzui | Surprisingly I did not get a persuasive reason. | 21:46 |
| bigjools | and dare I say it, ScottK | 21:47 |
| sinzui | Given that wgrants opinions are viable/doable items, I took the ambiguity to mean it is not important | 21:48 |
| bigjools | what is it you want to remove exactly? | 21:48 |
| sinzui | +uploaded-packages, +ppa-packages, +related-projects because they seem to guess wrong most of the time about what is truely related | 21:49 |
| sinzui | If I had a real story/use case, I think I would create an very different feature from how these fail to operate | 21:50 |
| bigjools | ok well my advice is to talk to more people first, since I had some very irate users in the past complaining about the performance of those pages | 21:50 |
| sinzui | EdwinGrubbs: I do not think you can trust the related portlet to always display. I only appears if a team owns a project, but a team can manage packages and PPAs with out ever owning a project | 21:56 |
| EdwinGrubbs | sinzui: I was referring to the "Related projects" link and not the portlet. According to the sourcecode, the "Related projects" link is always displayed above the yui grid. | 22:03 |
| sinzui | That is true | 22:03 |
| EdwinGrubbs | sinzui: do you want me to track down the people involved or just send out an email to launchpad-dev? | 22:09 |
| sinzui | EdwinGrubbs: Fixing those pages are out of scope for this release. I think packaging is in scope for 3.1 and we should fix that feature | 22:11 |
| EdwinGrubbs | sinzui: are you talking about packaging as in the planning meeting we just had or as in the "PPA packages" link? | 22:13 |
| sinzui | EdwinGrubbs: be mindful when we remove links or information from a page because there is no information, users then file bugs that they spent 2 hours searching launchpad for the information. When I reply that is because there was nothing to be found, the user states if we knew that we should have made that clear before he wasted 2 valuable hours of his life. | 22:13 |
| sinzui | EdwinGrubbs: You are working on a UI bug and we need to keep the scope at that. We start new work next release | 22:14 |
| EdwinGrubbs | sinzui: it sounds like you are saying, "don't spend a lot of time on it, but don't just remove the link." This brings us back to your suggestion to use "Related PPA packages", which sounds fine to me, but the conversation after that confused me. | 22:19 |
| sinzui | sorry | 22:20 |
| sinzui | Edwin: there are two issue with the bug. 1) two links with the same name. we need to fix the name of +ppa-packages. The other +archive/ppa should not be shown if there the user does not own a PPA | 22:22 |
| sinzui | EdwinGrubbs: and the +archive/ppa can be empty | 22:23 |
| sinzui | EdwinGrubbs: we might able to remove all but the related software links from person and teams. We rename the single link (i) Related software and packages. | 22:25 |
| === ursula is now known as Ursinha | ||
| jml | mwhudson, I did. | 22:26 |
| mwhudson | jml: great | 22:26 |
| jml | mwhudson, I've replied to exactly three emails that required thinking today. | 22:26 |
| EdwinGrubbs | sinzui: the +archive/ppa link only appears if that ppa exists. Compare /~launchpad and /~launchpad-dev. An empty PPA needs to be listed just like an empty series does. +1 on the "Related software and packages" link. | 22:26 |
| mwhudson | jml: :) | 22:27 |
| mwhudson | jml: no real hurry | 22:27 |
| mwhudson | well, the conference guy wants slides by monday, but i have a long and proud history of ignoring deadlines like that | 22:28 |
| sinzui | EdwinGrubbs: I am sure we are showing all the links to avoid changing lots of tests that test their presence from the old nav menu. Feel free to delete the redundant tests | 22:28 |
| EdwinGrubbs | ok, cool | 22:29 |
| === salgado is now known as salgado-afk | ||
| === matsubara is now known as matsubara-afk | ||
| wgrant | sinzui, EdwinGrubbs: +uploaded-packages is critical to Ubuntu developer review workflows. | 23:27 |
| sinzui | wgrant: great how is it used what should link to it and what should it link to or actions it should contain | 23:28 |
| EdwinGrubbs | wgrant: our current plan is just to have a single link to +related-software, and that page will keep its links to +uploaded-packages, +ppa-packages, and +related-projects. | 23:28 |
| wgrant | sinzui: It just needs to be somehow accessible, and needs to contain links to all SPRs in the primary archive where the person is mentioned in Changed-By. | 23:30 |
| wgrant | So exactly what it does now. | 23:30 |
| sinzui | Why do you want to see it? | 23:30 |
| wgrant | So that the MOTU Council (or new Developer Membership Board) can see what a prospective developer has done. | 23:31 |
| sinzui | wgrant: Fab | 23:31 |
| sinzui | Do you use the ppa or releated software views? | 23:32 |
| wgrant | PPA occasionally. | 23:33 |
| wgrant | But projects are not relevant, and usually incorrect. | 23:33 |
| sinzui | wgrant: I think these pages might be better if they contained information about motu with links about how to become a motu. | 23:34 |
| wgrant | sinzui: I don't think so. | 23:34 |
| wgrant | That's not the sort of thing LP does. | 23:35 |
| sinzui | maybe it should. Launchpad has packaging and package linking features that do a poor job of explaining their value. Launchpad could do a better job mobilising users and getting bug and code upstream | 23:36 |
| sinzui | maybe the person and team page should include latest packages uploaded like it should include latest branches and merge proposals | 23:38 |
| wgrant | That would indeed make sense. | 23:39 |
| sinzui | The distroseries page is not what I wanted to do. The top of the right column should be something that needs to be done or can be done right now to contribute. I think linking package to upstream might be what belongs there. | 23:40 |
| sinzui | I wonder how much labour is needed to repurpose the sparkline code to show other activities link package uploads, linking, bug fixes. | 23:42 |
| mwhudson | !! | 23:50 |
| mwhudson | no gpg-agent in karmic? | 23:50 |
| maxb | ? | 23:53 |
| mwhudson | well, not installed any more it seems | 23:53 |
| sinzui | mwhudson: I had some issues with it a few days ago. I need a good kick. bac also had issues with it | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!