| jtv | Otherwise you're counting bugtasks instead of bugs. | 00:00 |
|---|---|---|
| jtv | sinzui: still ok? | 00:05 |
| sinzui | jtv: I can tune this. I think 150 should be the minimum heat threshold because that is the minimum number for a private bug | 00:07 |
| sinzui | well, 250 might be best because private bugs are not community driven, but security are, which is 250 | 00:08 |
| jtv | sinzui: how does bug privacy factor into it all? | 00:08 |
| sinzui | jtv: I am reading the heat calculator. It add 150 points | 00:09 |
| jtv | oh ah | 00:09 |
| sinzui | I am sure the numbers are arbitrary. so are mine. I just want to get the packages that need the most love to be listed first | 00:10 |
| jtv | sinzui: do you see a big performance difference between those threshold? | 00:10 |
| jtv | s | 00:10 |
| sinzui | jtv: 67.82..27941.89 is better than 85994.40..85994.40 | 00:11 |
| jtv | sinzui: uh yes, looks like | 00:11 |
| jtv | sinzui: you could multiply the bug count by some factor to compensate. The ideal factor might be something like the average bug heat for bugs that stay below your chosen threshold. | 00:14 |
| sinzui | jtv: maybe: The heat filter keeps the top packages 100 very distinct | 00:15 |
| jtv | sinzui: you mean it sets them very far apart from the packages further down the list? | 00:16 |
| sinzui | yes, there is less variation in the mid range of packages because their bug heat scores are 0 | 00:17 |
| jtv | In the context of this list, do you care a lot about those packages? | 00:18 |
| jtv | Because maybe the list should just stop at some pseudo-arbitrary point. | 00:19 |
| thumper | Is anyone tackling the merge conflict from stable -> db_devel? | 00:26 |
| mwhudson | thumper: i'd got as far as thinking about it | 00:26 |
| mwhudson | thumper: seems trivial to fix, i'll do it | 00:28 |
| thumper | mwhudson: ta | 00:28 |
| thumper | mwhudson: rs=me if you don't want to rs=you :) | 00:29 |
| mwhudson | heh thanks :) | 00:29 |
| jtv | sinzui: I'm off... good night & good luck! | 00:32 |
| sinzui | me too | 00:32 |
| * mwhudson lunches | 00:35 | |
| lifeless | https://wiki.ubuntu.com/PackagingGuide/PatchSystems | 00:46 |
| lifeless | bah sorry | 00:46 |
| thumper | mwhudson: Add a new code import result for success of partial import | 01:20 |
| thumper | mwhudson: was that the commit that you fixed after | 01:20 |
| thumper | ? | 01:20 |
| thumper | mwhudson: just wondering about the qa status | 01:20 |
| mwhudson | thumper: yeah, that's the commit that was fixed in two followup branches | 01:20 |
| thumper | mwhudson: we should change it's status to FIXED | 01:21 |
| thumper | mwhudson: I'm not sure I like the RCFIXED, as it wasn't an RC | 01:21 |
| thumper | mwhudson: perhaps just move it to OK now | 01:21 |
| mwhudson | thumper: ok | 01:21 |
| mwhudson | thumper: well, the fix hasn't been QAed | 01:21 |
| thumper | ah | 01:21 |
| thumper | poo | 01:21 |
| mwhudson | yep | 01:25 |
| === bjf is now known as bjf-afk | ||
| kfogel | jml: you on? | 02:19 |
| * kfogel guessing not... | 02:19 | |
| kfogel | thumper: ah, but you might know: do we have any bugs filed for work on patch/branch equivalence? | 02:19 |
| kfogel | or story pages, etc? | 02:20 |
| kfogel | mwhudson: ^^ (if you know) | 02:21 |
| mwhudson | kfogel: i don't know of anything formal | 02:22 |
| kfogel | mwhudson: thanks | 02:22 |
| kfogel | mwhudson: I'm looking at bugs and branches under ~jelmer, just to see | 02:22 |
| thumper | kfogel: what exactly are you interested in? | 02:26 |
| thumper | kfogel: worth skyping about? | 02:26 |
| kfogel | thumper: hmrmrm. It is worth skyping about, but I can't do a skype right now (need to wrap up this draft blog post about the new patch report feature). I'm just listing, at the end of the blog post, some of the stuff we haven't gotten to yet, and that's on the list. If there were a bug or a spec to link to, I'd link to it. | 02:27 |
| thumper | I don't think there is a bug about it | 02:27 |
| thumper | kfogel: one thing we haven't gotten around to | 02:27 |
| thumper | kfogel: is automatically turning a patch into a branch if it applies to trunk cleanly | 02:28 |
| kfogel | thumper: :-) yes, that's one of the things I'm mentioning in the post | 02:28 |
| kfogel | thumper: you can't see this, right? http://blog.launchpad.net/?p=1356 | 02:42 |
| * thumper looks | 02:46 | |
| thumper | nope | 02:46 |
| thumper | mwhudson: ping | 03:27 |
| mwhudson | thumper: pong | 03:27 |
| thumper | mwhudson: what version of pygments are we using ATM? | 03:28 |
| mwhudson | thumper: good question | 03:28 |
| thumper | mwhudson: easy to find out? | 03:28 |
| thumper | mwhudson: is it an egg? | 03:28 |
| mwhudson | no, i think it's from the package | 03:28 |
| mwhudson | could/should switch to an egg though | 03:29 |
| mwhudson | thumper: seems like 0.9-2 | 03:29 |
| thumper | hmm... | 03:30 |
| thumper | bug 392406 | 03:30 |
| lifeless | mwhudson: why should? | 03:30 |
| mup | Bug #392406: Update Pygments library to version 1.1 or later <codebrowse> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/392406> | 03:30 |
| mwhudson | lifeless: easier for us to upgrade, more in line with what we do for everything else | 03:30 |
| lifeless | mwhudson: I don't really like what we do for everything else ;) | 03:31 |
| lifeless | its odd for us, a large chunk of an OS vendor, to ignore the OS for our products. | 03:31 |
| mwhudson | lifeless: i am having a little difficultly composing a civil reply here | 03:33 |
| lifeless | :> | 03:33 |
| lifeless | troll:1 burdened-programmer:0 ? | 03:33 |
| mwhudson | i guess | 03:33 |
| lifeless | I wasn't intending to troll, but I realise picking one package isn't a good way to change the systemic approach | 03:33 |
| mwhudson | right | 03:34 |
| lifeless | so - sorry; and please get back to what you're doing | 03:34 |
| mwhudson | thanks! | 03:34 |
| thumper | mwhudson: bug 153779 still an issue? | 03:38 |
| * thumper wanders off, back UK morning time | 03:39 | |
| mwhudson | thumper: not really i guess | 03:45 |
| * mwhudson closes it | 03:45 | |
| * mwhudson EODS | 03:46 | |
| mwhudson | not the most productive day, oh well | 03:46 |
| lifeless | heh | 03:46 |
| lifeless | I have had similar | 03:46 |
| lifeless | slow progress | 03:46 |
| mwhudson | maybe staging will be magically up to date when i start tomorrow | 03:46 |
| wgrant | It does seem particularly strange to me that a product from an OS vendor does not use a custom archive of dependencies, when a large part of the product is designed to produce custom archives. | 03:57 |
| adeuring | good morning | 08:27 |
| wgrant | When are the buildds expected back? | 09:37 |
| wgrant | This is the longest queue I have ever seen. | 09:37 |
| noodles775 | I haven't heard. bigjools ^^ | 09:37 |
| bigjools | I don't know | 09:38 |
| * noodles775 tries to find out. | 09:38 | |
| wgrant | 12 hours is way beyond "absolutely ridiculous" territory. | 09:38 |
| bigjools | FWIW the PPA service only has 4 builders, the others are a bonus | 09:38 |
| bigjools | (per arch) | 09:38 |
| wgrant | I thought it had only three. | 09:39 |
| bigjools | you could be right | 09:39 |
| bigjools | we're getting some more but they will be reserved for daily builds | 09:39 |
| wgrant | Hmmm. | 09:39 |
| adiroiban | henninge: Hi. do you have time to land my last branch review or should I ask the OCR ? https://code.edge.launchpad.net/~adiroiban/launchpad/bug-509252-take-2/+merge/19484 | 10:45 |
| henninge | adiroiban: oh sorry, forgot about that. Sure. Does it have a commit message? | 10:46 |
| henninge | adiroiban: ah, yes it does ;) | 10:46 |
| adiroiban | henninge: yes. and I have updated it | 10:47 |
| henninge | adiroiban: ok, landing it now. | 10:48 |
| adiroiban | henninge: if you have time, can you also QA the fix for this bug https://bugs.edge.launchpad.net/rosetta/+bug/127171 ? | 10:49 |
| mup | Bug #127171: Rosetta experts not allowed to "Change translators" <qa-needstesting> <Launchpad Translations:Fix Committed by adiroiban> <https://launchpad.net/bugs/127171> | 10:49 |
| adiroiban | I don't have rosetta admin rights | 10:49 |
| adiroiban | so I don't know how to test it on edge | 10:49 |
| henninge | adiroiban: we can probably make you an admin on staging | 10:49 |
| adiroiban | henninge: that is also OK | 10:50 |
| henninge | danilo__, danilos: ^^? | 10:50 |
| henninge | adiroiban: as a reminder: Please don't push to the branch anymore now that it is landing. | 10:50 |
| adiroiban | henninge: ok | 10:51 |
| danilos | henninge, /me is thinking... are there any privacy concerns? is rosetta-admins subteam of any generic team? | 10:51 |
| adiroiban | danilos: I just need that to test that fix | 10:53 |
| adiroiban | if some of you can qa it | 10:53 |
| adiroiban | it's ok for me | 10:53 |
| danilos | henninge, adiroiban: I've looked and it seems it's ok, I'll just do it and let Adi QA this :) | 10:55 |
| danilos | adiroiban, haha, there's also "Poor Adi" account, nice name for what I assume is a testing privilege-less account :) | 10:55 |
| danilos | adiroiban, anyway, you should be in rosetta-admins on staging now | 10:55 |
| adiroiban | danilos: yep :) | 10:55 |
| danilos | adiroiban, fwiw, staging will be refreshed sometime on weekend, so that's until when you've got the chance :) | 10:56 |
| adiroiban | danilos: ok. well I will try to qa it now as I will not have time on friday weekend | 10:57 |
| danilos | adiroiban, cool, thanks | 10:57 |
| adiroiban | and I don't want to fix it when pqm is closed | 10:58 |
| deryck | Morning, all. | 11:02 |
| adiroiban | danilos: can you please target this bug for the next release https://bugs.edge.launchpad.net/rosetta/+bug/462013 | 11:03 |
| mup | Bug #462013: Don't ask me to import obsolete templates <qa-ok> <trivial> <ui> <Launchpad Translations:Fix Committed by adiroiban> <https://launchpad.net/bugs/462013> | 11:03 |
| adiroiban | I think this is requred to me marked as „fix-released” | 11:03 |
| gmb | deryck: Do you have access to run a SELECT on staging? | 11:10 |
| deryck | gmb, I do, yeah. | 11:10 |
| gmb | deryck: Could you run http://pastebin.ubuntu.com/383617/ and paste me the output? | 11:10 |
| * gmb neatly sidesteps a) the LOSAs being sprinty and b) the fact that staging is 10 revs behind where he needs it to be. | 11:11 | |
| deryck | gmb, sure. doing now.... | 11:11 |
| gmb | Thanks. | 11:11 |
| adiroiban | gmb: when you have time, can you please try a new landing for https://code.edge.launchpad.net/~adiroiban/launchpad/bug-522188/+merge/19395 ? Thanks! | 11:12 |
| gmb | adiroiban: Sure, it's already on my list for today :). | 11:13 |
| adiroiban | :) | 11:13 |
| deryck | intellectronica, https://code.edge.launchpad.net/~deryck/launchpad/max-heat-by-target-511382/+merge/19998 | 11:28 |
| intellectronica | deryck: as it happens i already read through it and ran it working on the patch for updating the column, so r=me :) | 11:29 |
| deryck | intellectronica, excellent! easy-peasy. Thanks! :-) | 11:29 |
| intellectronica | deryck: actually, scratch that. did you want me to review just the db patch, or the rest of the code? | 11:29 |
| deryck | intellectronica, the code | 11:30 |
| intellectronica | if the latter then i need to go through it more thoroughly | 11:30 |
| intellectronica | ok | 11:30 |
| deryck | intellectronica, yeah, the code. stub and BjornT are on the patch. | 11:30 |
| intellectronica | deryck: i'm wondering, isn't there a more general getOrCreate sort of thing for DSPs? this can't be the first time we do this in the code | 11:34 |
| intellectronica | and even in your test you repeat the code twice | 11:34 |
| intellectronica | ehrm, not in the test, in the distro model object | 11:35 |
| intellectronica | maybe bigjools will know if there's something like that | 11:36 |
| deryck | intellectronica, hmmmm, let me look at the diff.... and I greped for something and didn't find anything, and I was also following what is already there for another bit of code. | 11:36 |
| deryck | intellectronica, ah, I see what you mean, to get the DB version of the class. | 11:36 |
| bigjools | whu what? | 11:36 |
| intellectronica | deryck: yes | 11:36 |
| intellectronica | bigjools: is there a standard getOrCreate thingster for DistributionSourcePackageInDatabase ? | 11:37 |
| bigjools | I have no idea, Gavin wrote it! | 11:37 |
| intellectronica | a getOrCreateDistributionSourcePackageInDatabase :) | 11:37 |
| bigjools | I'd be looking for it | 11:37 |
| deryck | intellectronica, I copied the bits from what I assume Gavin had before, but I can refactor into a nicer getInDB method. | 11:38 |
| deryck | I did think about that and never went back. | 11:38 |
| intellectronica | deryck: if there isn't anything already in existence i'm fine with just filing a bug for doing it later (if you don't want to spend time on it now) | 11:39 |
| intellectronica | deryck: why do we need a set on distroseries if all it does it delegate it to the distro? | 11:40 |
| intellectronica | isn't it better to just not implement it? | 11:40 |
| deryck | intellectronica, but in the distro series bug view you'll have to get at the max_bug_heat for that, right? I thought it made using max_bug_heat less tricky if everything implemented it. | 11:41 |
| intellectronica | deryck: yes, it makes sense to have a getter, but does it make sense to have a setter | 11:42 |
| intellectronica | since we don't currently have any code that relies on it, i think it might be better to throw a NotImplementedError or something | 11:43 |
| deryck | intellectronica, ah, right. Yeah, I went back and forth on that. I don't know that it makes sense. You would never set on the series, but there's no harm in doing so. | 11:43 |
| deryck | intellectronica, and given past bugs I fixed I have a nervousness about NotImplementedError :-) | 11:43 |
| intellectronica | deryck: in fact, i'm not even sure we need a setter anywhere. as i just discussed with stub, it looks like we'll update this column from a trigger. | 11:43 |
| intellectronica | though i guess at the very least it's useful for testing | 11:44 |
| deryck | intellectronica, yeah, that was my reaction. without a setter, from the test's pov it's just a useless attribute. | 11:44 |
| intellectronica | deryck: so, i rather not set if it's done through delegation, because it can be confusing and lead to subtle errors. if you throw an error then whoever is trying to write to the attribute will become aware of the way it's implemented and do the right thing | 11:45 |
| deryck | intellectronica, good point. I'll do that then. | 11:46 |
| intellectronica | cool | 11:46 |
| intellectronica | deryck: r=me with that change | 11:47 |
| deryck | intellectronica, excellent. thanks! | 11:49 |
| wgrant | adiroiban: What is the 'archive name' of a source package? | 12:37 |
| adiroiban | wgrant: repository | 12:37 |
| adiroiban | maybe the info is already available in API... but it is not obvious how to retreive it | 12:38 |
| wgrant | A SourcePackage doesn't really have an archive. | 12:39 |
| wgrant | Except potentially primary vs. partner. | 12:39 |
| adiroiban | ah... | 12:40 |
| adiroiban | looks like in the UI is called component | 12:40 |
| === matsubara-afk is now known as matsubara | ||
| adiroiban | https://edge.launchpad.net/ubuntu/karmic/+source/kubuntu-docs | 12:40 |
| wgrant | Oh. that's something completely different to an archive or a repository. | 12:40 |
| adiroiban | it may be... | 12:41 |
| adiroiban | but on the Internet | 12:42 |
| adiroiban | it is said that an Ubuntu package is part of main or universe repository | 12:42 |
| wgrant | They are wrong :) | 12:43 |
| wgrant | The term has always been component, both inside and outside Launchpad. | 12:43 |
| adiroiban | yep. someone is always wrong on the Internet :) | 12:43 |
| adiroiban | I will update the bug report | 12:43 |
| * wgrant looks around for somebody who can be bribed into bumping a build score. | 12:45 | |
| === thekorn_ is now known as thekorn | ||
| deryck | three cheers for adeuring killing 4 bugs with one branch. errr, 4 cheers, then. | 13:41 |
| adeuring | deryck: thanks but the cheers should go to sinzui | 13:49 |
| deryck | he does know our bugs well now. | 13:49 |
| sinzui | adeuring: It would have been cruel for me to ask you to fix it without first finding out why the page has been broken for 18 months | 13:50 |
| leonardr | wgrant, i'm looking at https://code.edge.launchpad.net/~wgrant/launchpad/export-das-chroot/+merge/19759 | 13:53 |
| leonardr | can you explain to me what exactly a chroot is? some sort of massive file stored in the librarian? | 13:53 |
| james_w | leonardr: yep, it's a tarball of a filesystem stored on the librarian and used by the buildds when building packages | 13:54 |
| wgrant | leonardr: "massive" being about 60MiB a the moment, but potentially some hundreds of megabytes. | 13:55 |
| leonardr | wgrant: i haven't swapped in all the details yet, but to publish a librarian file on the web service you should export a Bytes field | 14:10 |
| leonardr | the example i'm working from is IBugAttachment.data | 14:10 |
| wgrant | leonardr: But that's not going to do anything useful like giving me hashes, is it? | 14:11 |
| leonardr | wgrant: it will not give you hashes, but it will let users read the librarian file from within launchpadlib rather than having to fire up httplib2 to grab the librarian url | 14:12 |
| BjornT | leonardr: what's stopping us from exporting ILibraryFileAlias? | 14:14 |
| leonardr | BjornT: well, there's no code in lazr.restful for that because the library file alias is launchpad-specific | 14:15 |
| leonardr | but there is code in lazr.restful for publishing 'bytes' fields as generic hosted files, and code in launchpad for hooking up LibraryFileAlias to that implementation | 14:15 |
| wgrant | Could one not easily export ILFA with a Bytes field inside it? | 14:16 |
| leonardr | wgrant, what information does your end-user want? | 14:17 |
| wgrant | leonardr: I would like to be able to verify the content of the files, given that I downloaded them over HTTP. | 14:17 |
| leonardr | so like the md5 sum? | 14:18 |
| wgrant | Yes. | 14:19 |
| leonardr | ok, i filed a bug at one point to publish a json representation of a hosted file resource which would contain that information | 14:20 |
| wgrant | Thanks. | 14:20 |
| leonardr | this would be a change to lazr.restful (and to the launchpad implementation of the hosted file), and publishing ILibraryFileAlias vs publishing IBytes would not change anything | 14:20 |
| leonardr | i'm trying to find that bug | 14:20 |
| leonardr | i really hate how that bug could have been filed in one of four projects | 14:21 |
| wgrant | Hmm. | 14:21 |
| leonardr | wgrant: see if this is what you want | 14:21 |
| leonardr | https://bugs.edge.launchpad.net/lazr.restful/+bug/406912 | 14:21 |
| mup | Bug #406912: Publish a JSON representation of a binary file containing metadata <lazr.restful:New> <Ubuntu:Invalid> <https://launchpad.net/bugs/406912> | 14:21 |
| wgrant | leonardr: Looks good to me. | 14:23 |
| leonardr | ok, i'll respond to the review | 14:23 |
| wgrant | Thanks. | 14:23 |
| leonardr | wgrant: shall i add on to this bug that you requested the md5 sum of the file? | 14:23 |
| BjornT | leonardr: i just find it odd that in python code we say that an attribute is an ILFA, while we have to export it as Bytes. seems easier and more intuitive if we could export ILFA themselves, with a Bytes field inside them. | 14:23 |
| wgrant | leonardr: And the other hashes, too. | 14:23 |
| leonardr | wgrant: i don't know what other hashes you're refering to | 14:24 |
| leonardr | oh, sorry | 14:24 |
| leonardr | i thoguht you meant hash as in the data structure | 14:24 |
| wgrant | Ah, no, the cryptographic variety, sorry. | 14:24 |
| leonardr | bjornt: i'm doing research to understand what you mean, but lazr.restful wouldn't care what is inside an exported field. if we got some way to export ILFA, then some representation of the ILFA would go into the entry's representation, and that's is | 14:25 |
| leonardr | s/is/it/ | 14:25 |
| jml | good morning Launchpadders | 14:27 |
| jml | wgrant, are you visiting New Zealand or perhaps some Pacific island? | 14:27 |
| jml | wait. | 14:27 |
| jml | wgrant, I mean, are you visiting Perth or perhaps some island in the Indian Ocean? | 14:27 |
| wgrant | jml: No.. | 14:29 |
| wgrant | It's not yet 1:30. | 14:29 |
| jml | wgrant, that's still kind of late :) | 14:31 |
| wgrant | jml: I blame Enablement for making PPA builds take too long. | 14:34 |
| wgrant | But it looks like my build still isn't going to happen for at least another hour, so i might as well sleep. | 14:35 |
| === henninge_ is now known as henninge | ||
| leonardr | BjornT: the basic reason is that lazr.restful is not part of launchpad, so it can't know anything about ILibraryFileAlias | 14:41 |
| leonardr | if this was a huge problem i could put some indirection in place such that ILibraryFileAlias could substitute for Bytes, but i just don't consider it that big a problem | 14:42 |
| BjornT | leonardr: right. i was talking about how we export things in LP. | 14:43 |
| leonardr | me too | 14:43 |
| leonardr | there's a slight possibility you could get it to work by making ILibraryFileAlias subclass Bytes, but if that doesn't work i don't think it's worth putting in additional work | 14:45 |
| leonardr | s/Bytes/IBytes/ | 14:45 |
| BjornT | leonardr: i don't get why we need to hide ILFA. Bytes and ILFA are different things. why does the exported API need to be different from our internal API? | 14:46 |
| leonardr | BjornT: when the web service starts up, the launchpad classes are run through lazr.restful | 14:48 |
| leonardr | when lazr.restful encounters a published Bytes field, it thinks "this is a hosted binary file" | 14:49 |
| leonardr | and when the time comes to create a representation of it, lazr.restful performs a lookup, adapting the field to some interface (provided by launchpad) | 14:49 |
| leonardr | when lazr.restful encounters a published ILibraryFileAlias field, it thinks "i've never heard of this", and crashes | 14:50 |
| adiroiban | hi. do you know where I cound find some info about how to write API tests? I was looking at this API https://api.launchpad.net/+apidoc/#translation_import_queue_entries , and grepping the whole source tree after „translation_import_queue_entries” did not reveal any test | 14:51 |
| BjornT | leonardr: but ILibraryFileAlias have (or should have) a Bytes field for its content, and ILibraryFileAlias could be exported just like any other interface, like IBug, IPerson, etc. no? | 14:52 |
| leonardr | bjornt: ok, you want to publish ILibraryFieldAlias as an entry, not a field | 14:53 |
| leonardr | i didn't understand that | 14:53 |
| leonardr | bjornt: what you describe is technically possible, and it's the launchpad team's decision how to do that, but i think publishing the hosted file as a Bytes field would give a better end-user experience | 14:57 |
| leonardr | bjornt: because right now you have, eg. a bugattachment object that has a 'data' field | 15:00 |
| leonardr | right now you can do something analogous to open(bugtask.attachment.data).read() | 15:00 |
| leonardr | if data was an ILibraryFileAlias then that would be open(bugtask.attachment.data.file).read() | 15:01 |
| leonardr | but it should still be possible | 15:01 |
| BjornT | leonardr: well, i see now that IBugAttachment is lying. it says that IBugAttachment.data is a Bytes field, yet BugAttachment.data is an ILibraryFileAlias | 15:02 |
| BjornT | we should make sure that our content objects provide what the claim to provide | 15:04 |
| === matsubara is now known as matsubara-lunch | ||
| leonardr | bjornt: unless ILibraryFileAlias can subclass IBytes i don't see any good way to resolve that problem | 15:08 |
| leonardr | flacoste might be able to help | 15:08 |
| BjornT | leonardr: i think there are a few options, although i'm not sure how feasible they are. one is of course to have our exported API to behave the same way as our internal API | 15:09 |
| leonardr | actually, we could define a new interface in lazr.restful and have ILibraryFileAlias subclass that | 15:09 |
| BjornT | leonardr: if we want to have it work like it works today, we could mark ILibraryFileAlias, and say that this is our hosted file, and provide an adapter, or something like that | 15:10 |
| leonardr | bjornt: how about this. define lazr.restful.interfaces.IHostedFile | 15:10 |
| leonardr | have ILibraryFileAlias subclass IHostedFile | 15:10 |
| leonardr | change lazr.restful to treat IHostedFile the same way it treats Bytes | 15:10 |
| leonardr | use IHostedFile instead of Bytes in launchpad | 15:10 |
| BjornT | leonardr: what would IHostedFile look like? | 15:11 |
| leonardr | BjornT: i don't think it has to have any fields | 15:12 |
| leonardr | this is work i don't want to do, but it should work | 15:12 |
| flacoste | leonardr: i think your idea sounds good, the end result is that we want to be able to export a Bytes or LibraryFileAlias field as a hosted file | 15:13 |
| BjornT | leonardr: why do we call export_as_webservice_entry() when exporting interfaces, rather then subclassing marker intefaces? | 15:13 |
| BjornT | leonardr: or a better question: does lazr.restful deal with ILibraryFileAlias, or LibraryFileAlias to make the decision that it's a hosted file? | 15:19 |
| leonardr | BjornT: lazr.restful deals with Bytes to make that decision | 15:27 |
| leonardr | the only Launchpad-specific code it uses in this process is lib.canonical.launchpad.rest.bytestorage.LibraryBackedByteStorage | 15:27 |
| leonardr | basically it adapts the Bytes object to IByteStorage | 15:28 |
| leonardr | and launchpad says the IByteStorage adapter to use is LibraryBackedByteStorage | 15:28 |
| leonardr | LBBS hides all the details of LibraryFileAliases, how to create and delete them, etc | 15:28 |
| leonardr | so the change i'm proposing is to replace Bytes with IHostedFile, and adapt IHostedFile to IByteStorage | 15:29 |
| BjornT | leonardr: so it doesn't make sense to say that LibraryFileAlias is an IHostedFile then? if so, it seems like you should mark ILibraryFileAlias, rather then subclassing. but i'm not sure i follow completely | 15:33 |
| === matsubara-lunch is now known as matsubara | ||
| leonardr | bjornt: it makes sense to say that LibraryFileAlias is an IHostedFile, but it doesn't make sense to tell lazr.restful anything about LibraryFileAlias | 15:53 |
| === salgado is now known as salgado-lunch | ||
| adeuring | intellectronica: http://paste.ubuntu.com/383753/ For larger maxet values, you'll get a sort of "gap" after the relative heat 2/3 | 16:00 |
| adeuring | intellectronica: but i think ii have a proposal for a better function | 16:00 |
| adeuring | just a second | 16:00 |
| adeuring | intellectronica: http://paste.ubuntu.com/383761/ is at least "smoother" | 16:07 |
| adeuring | intellectronica: I'm getting quite bad error in lib/lp/bugs/tests/../stories/bugtask-searches/xx-listing-basics.txt with your branch | 16:35 |
| intellectronica | adeuring: damn | 16:40 |
| intellectronica | let me check | 16:40 |
| james_w | noodles775: still around? | 16:41 |
| intellectronica | adeuring: yeah, i'm getting the errors too. looking at them now | 16:42 |
| rockstar | abentley, your superseded comments stuff is made of awesome. | 16:44 |
| abentley | Thanks, but you designed about half of it. | 16:45 |
| abentley | rockstar, chat? | 16:45 |
| rockstar | abentley, gimme a bit to clear the backlog of reviews here. | 16:46 |
| abentley | rockstar, sure. | 16:46 |
| deryck | intellectronica, I just merged you branch and will push up now. If you're fixing errors could you merge our combined branch, or else branch new from me? | 16:54 |
| deryck | intellectronica, since I fixed some of the changed elements. | 16:54 |
| intellectronica | deryck: sure, i'm remerging your branch | 16:55 |
| intellectronica | will ping you when i've got a fix for you guys to pull | 16:55 |
| deryck | intellectronica, still running a test.... a minute more and will push up the version from me. sorry. | 16:55 |
| deryck | I started the test before I saw the scrollback here. ;) | 16:56 |
| deryck | intellectronica, it's up now. thanks! | 16:57 |
| intellectronica | cheers | 16:57 |
| jtv | eod! eod! eod! | 17:00 |
| intellectronica | deryck: strange, i get ForbiddenAttribute: ('max_bug_heat', <lp.registry.model.distributionsourcepackage.DistributionSourcePackage object at 0xd224aec>) | 17:07 |
| intellectronica | could it be that wer're missing the zcml to allow the new attribute or something? | 17:07 |
| deryck | intellectronica, hmmm, maybe. and I just realized I haven't done the NotImplementedError you suggested yet. Sorry. | 17:08 |
| deryck | intellectronica, yeah, I bet DSP needs some zcml. Sorry. because I used zopeless layer in test it by passes that check, right? | 17:08 |
| intellectronica | deryck: yeah, i now see that dsp uses the verbose attribute-by-attribute format for permissions | 17:09 |
| intellectronica | i'll fix it in my branch, since you have to re-merge it anyways | 17:09 |
| deryck | excellent. thanks! | 17:10 |
| intellectronica | whoa, it gets weirder. after fixing the permission problem i get 'InternalError: transaction is read-only' | 17:12 |
| intellectronica | deryck: too early to tell, but my first guess is that something is not ok with your getOrCreate trick | 17:15 |
| intellectronica | deryck: i pushed the fixes in my branch, if you want to look | 17:16 |
| deryck | intellectronica, ok, thanks. | 17:16 |
| intellectronica | deryck: my guess is we're using the read-only store, and then you try to create the dsp but you can't, so somehow we need to force it to use the read-write store | 17:16 |
| deryck | ah, right | 17:17 |
| deryck | intellectronica, ok, I'll look closely here in just a sec. Trying to go over the latest bug about log() with adeuring. | 17:17 |
| deryck | intellectronica, I think we may have to adjust your branch a bit, too. Sorry to send more work you way again. | 17:18 |
| adeuring | deryck: intellectronicagive me a second for a proposal of a better function | 17:18 |
| intellectronica | deryck: in what way? | 17:18 |
| deryck | intellectronica, in that the current branch will make anything 2/3 and up 4 flames. We want something more like: if max_heat is 100, use intervals 0..40, 41..70, 71..80, 91..100 | 17:19 |
| intellectronica | deryck: i don't think it will. see the documentation | 17:19 |
| === beuno is now known as beuno-lunch | ||
| * deryck looks again | 17:20 | |
| intellectronica | but as i said this is hardly my expertise. if you have a better transformation go for it | 17:20 |
| * deryck is playing with numbers in the doc test | 17:24 | |
| deryck | intellectronica, I'm actually getting the numbers of how many bugs will get what flames right now. That might help us decide. | 17:31 |
| intellectronica | cool. nothing like real data :) | 17:32 |
| adeuring | deryck, intellectronica: http://paste.ubuntu.com/ (no lint check ;) | 17:33 |
| intellectronica | adeuring: are you asking for input? ;) | 17:33 |
| adeuring | intellectronica: well, that's a proposaal for other thresholds in calculate_heat_display() | 17:34 |
| intellectronica | adeuring: right, but you only gave the url to the pastebin, not to the pasted item | 17:34 |
| adeuring | intellectronica: argh, I am idiot... http://paste.ubuntu.com/383823/ | 17:34 |
| adeuring | another option are median statstics, BTW | 17:36 |
| intellectronica | adeuring: yes, that looks like a good way to do it | 17:36 |
| adeuring | intellectronica: how/when do we calculate heat values (or max_heat for targets)? | 17:37 |
| adeuring | if this is done by a script, we could set the threshold based on actual data to build thresholds that match the data. | 17:37 |
| intellectronica | adeuring: i'm creating a trigger that calculates it whenever a heat value is entered for a bug | 17:38 |
| adeuring | so that we have the same number of bugs with 0, 1, 2,... flames | 17:38 |
| intellectronica | yes, that was the original idea, but i think for now it's too complicated | 17:38 |
| adeuring | intellectronica: ah, no, running median statistics tehre is not a good idea, I think. | 17:38 |
| adeuring | intellectronica: I suspect that the function can be simplified.... | 17:41 |
| adeuring | let me see | 17:41 |
| deryck | adeuring, intellectronica -- I'm preparing real numbers with both approaches for what ubuntu and malone (extreme and average) would do in terms of bug distribution in these scales. | 17:44 |
| adeuring | deryck: cool, I'm curious | 17:44 |
| intellectronica | deryck, adeuring: so i fixed the problem with getting max_heat from a dsp. you can now re-merge my branch | 17:52 |
| adeuring | intellectronica: too late: EC2test is already running... | 17:52 |
| adeuring | ...for my branch... | 17:52 |
| intellectronica | adeuring: well, it will fail | 17:52 |
| intellectronica | unless you fixed it independently | 17:53 |
| adeuring | yours is already merged? | 17:53 |
| intellectronica | deryck: ftr, i did that by removing the bit that creates the record in the getter. thinking about it it really shouldn't have been there, since it potentially allows anonymous users to create new records | 17:53 |
| intellectronica | adeuring: no, that's the branch you presumably branched from. you notified me of errors and i fixed them. | 17:53 |
| deryck | intellectronica, ok. I'll look closer here in a minute. | 17:54 |
| adeuring | intellectronica: yeah, but that's not what I got reviewed, and so deryck suggested I just go ahead with my branch. | 17:55 |
| intellectronica | deryck, adeuring: i have to go out for a few hours soon. if you need me to update the scaling, or whatever, drop me a line and i'll do that later in the evening when i'm back. sorry to have to leave you like that. | 17:55 |
| deryck | intellectronica, no worries. So far, your scaling is looking better. Though both have issues. Will email. | 17:55 |
| adeuring | intellectronica: seems that I'm also getting tired. I think I can proposed a more efficient varaint than what is in the pastebin, but i need a bit more time ;) | 17:56 |
| intellectronica | adeuring: i'm not sure i understand. in my scale-heat branch there was one error that originated in my branch, and another error the originated in deryck's branch. i fixed both and pushed, and thought that if you branched from it you might want to re-merge. | 17:56 |
| adeuring | intellectronica: no, I simply stared from a devel branch... | 17:57 |
| deryck | intellectronica, abel's branch is based on devel. He's just changing icons, no? | 17:57 |
| adeuring | ...started... | 17:57 |
| adeuring | deryck: well, no... | 17:57 |
| adeuring | i changed also the HTML rendering | 17:57 |
| adeuring | and the place where that happens changed | 17:58 |
| adeuring | in intellectronica branch | 17:58 |
| deryck | ah, right. | 17:58 |
| intellectronica | adeuring: right, and i told you that you will have to look at my branch since the place where the rendering is done has changed in my branch | 17:58 |
| intellectronica | heh | 17:58 |
| === salgado-lunch is now known as salgado | ||
| deryck | heh. | 17:58 |
| adeuring | argh... I missed that.... | 17:58 |
| deryck | adeuring, can you just kill your run. and we can merge your branch into intellectronica's. Or vice versa. And one of you can fix conflicts. yes/no? Likey? :) | 17:59 |
| intellectronica | adeuring: well, if your branch lands in devel then i guess i'll just have to merge and resolve the conflict. no big deal | 17:59 |
| adeuring | intellectronica: ok, thanks | 17:59 |
| deryck | yeah, that works. | 17:59 |
| deryck | intellectronica is waiting on me anyway :-) | 17:59 |
| intellectronica | i'm not. i'm going to a concert :) | 18:00 |
| deryck | heh | 18:01 |
| deryck | intellectronica, adeuring -- so enjoy the night. I'll send my numbers in email. We'll stick with Tom's scale now and re-evaluate later if need be. | 18:01 |
| deryck | we still end up with large numbers in 0 flames with both. | 18:01 |
| intellectronica | deryck: but that's desirable, no? | 18:03 |
| intellectronica | most bugs are not hot | 18:03 |
| deryck | intellectronica, maybe so. | 18:03 |
| deryck | intellectronica, I worry in Ubuntu that the drop off is too quickly. For average projects it looks nice. But we can revisit if we need. | 18:04 |
| deryck | but the package view should be nice, I imagine. | 18:05 |
| * intellectronica --> pere ubu | 18:10 | |
| === beuno-lunch is now known as beuno | ||
| === gary_poster is now known as gary-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| EdwinGrubbs | sinzui, bac: Can you give me your feedback on these two mockups on the Upstream connections portlet? It looks like Brad recently moved name/value pairs onto a single line, which has some advantages, although it is inconsistent with other portlets. https://chinstrap.canonical.com/~egrubbs/upstream/ | 19:09 |
| sinzui | EdwinGrubbs: yes, he did, it is inconsistent, but it solved a space and scanning problem. We can do the same if we have the same problem again | 19:10 |
| sinzui | EdwinGrubbs: I started to read the blueprint a few minutes ago | 19:10 |
| bac | EdwinGrubbs: i didn't know i was introducing an inconsistency but i think it looks better | 19:11 |
| sinzui | bac: I think I mentioned it was odd in my comments in the blueprint | 19:12 |
| bac | sinzui: perhaps. | 19:12 |
| EdwinGrubbs | sinzui, bac: I'm not against it, but it is a little confusing on how to move forward with it. It also might be nice to structure projectgroup/project/series so that it is left to right and possibly a little terser similar to the breadcrumbs. | 19:14 |
| === gary-lunch is now known as gary_poster | ||
| paki | hi all | 19:27 |
| paki | i have a problem | 19:27 |
| paki | how to show changelog in update manager? | 19:28 |
| paki | anyone can help me? | 19:39 |
| sinzui | paki: update-manager? the desktop application? | 19:42 |
| paki | yes | 19:42 |
| sinzui | paki: this channel is for building the launchpad.net website | 19:43 |
| * sinzui checks his update-manager | 19:43 | |
| paki | uff | 19:44 |
| paki | where could i ask? | 19:44 |
| === deryck[lunch] is now known as deryck | ||
| paki | is a very stupid thing | 19:44 |
| sinzui | paki: You are asking why some packages do not include a meaning changelog? The answe most of the time is that packager did not prepare one | 19:45 |
| * sinzui has looked at the package in launchpad often and not found a log | 19:45 | |
| paki | no, i'am a mantainer..can i include my changelog for update-manager? | 19:46 |
| paki | how to do? | 19:46 |
| sinzui | paki: okay, now I understand. This is a motu question. let me look for a channel | 19:47 |
| paki | excuse my crappy english :S | 19:47 |
| paki | ok, where is this channel? | 19:48 |
| paki | ok, thanks | 19:48 |
| sinzui | paki: try #ubuntu-motu | 19:50 |
| paki | thanks sinzui :) | 19:50 |
| EdwinGrubbs | sinzui, bac: I added two more screenshots. https://chinstrap.canonical.com/~egrubbs/upstream/ | 19:51 |
| sinzui | EdwinGrubbs: I think we need to be clear what is set by the series and what is set by the project. The reason fixing this is so effing hard is that the locations are not obvious, and changing a project changes the information for all series, and all packages that come from that series | 19:57 |
| sinzui | EdwinGrubbs: have you noticed the new behaviour of the bug app? https://bugs.staging.launchpad.net/gedit | 20:03 |
| mwhudson | good morning | 20:04 |
| sinzui | EdwinGrubbs: bac: your blueprint extends scope to allow jumping to alternate services. I am not sure we want to do this, but it is worthy of discussion. Conversely, we (the registry team) may want to put a small barrier like the bugs app on Answers and Blueprints to make communities explicitly set the app locations | 20:06 |
| EdwinGrubbs | sinzui: I had not seen the new behavior of the bug app before. That seems relevant to the involvement portlet but unrelated to the upstream connections portlet that I'm working on now. | 20:23 |
| sinzui | Well, no, it is not | 20:23 |
| paki | one question | 20:26 |
| paki | how can update my pot file to launchpad? | 20:26 |
| paki | excuse me.. | 20:26 |
| paki | upload my pot file.. | 20:26 |
| sinzui | EdwinGrubbs: Our goals are to capture this information for the Ubuntu community, and they need to see it. I agree that Answers and blueprints are separate issues. But by locking the first page (/gedit does have bugs, but they cannot be viewed until someone clearly states how bugs should be used) | 20:26 |
| sinzui | EdwinGrubbs: Translations is already locked, but code is not | 20:27 |
| paki | in documentation i don't find a button to upload pot file | 20:27 |
| paki | explained in documentation but i don't find a button to upload pot file | 20:28 |
| sinzui | EdwinGrubbs: and per your portlet, we do not have to allow links to alternate services for users, that does not help ubuntu. What we need to do is callout information that Ubuntu needs to know | 20:28 |
| sinzui | paki: I think you want to use the #launchpad channel, which has many translations users tending it | 20:29 |
| paki | ok thanks | 20:31 |
| paki | bye | 20:31 |
| sinzui | EdwinGrubbs: I think the project homepage and freshmeat url can stay where they are. Your design hints at a problem in the UI right now. I think we should move the external downloads link to the downlaods portlet. | 20:32 |
| EdwinGrubbs | sinzui: as far as the information that Ubuntu needs to know, are you saying that just the Bugs and Source Code links in the involvement portlet should complain when they are not set? | 20:34 |
| sinzui | EdwinGrubbs: And translations | 20:34 |
| EdwinGrubbs | sinzui: I can updated the wiki and mockups and then send it to the mailing list. | 20:34 |
| sinzui | okay | 20:35 |
| sinzui | EdwinGrubbs: I really want to move the wiki link and change blueprints to use it when prompting for the blueprint URL. That will have to be on my own time though | 20:35 |
| EdwinGrubbs | sinzui: do you have any opinions on these screenshots: https://chinstrap.canonical.com/~egrubbs/upstream/vertical_hierarchy.png https://chinstrap.canonical.com/~egrubbs/upstream/horizontal_hierarchy.png | 20:37 |
| sinzui | EdwinGrubbs: I saw those. As I said they do not make it clear what information is on the series, and what is on the project. That information will require different permissions to change... | 20:38 |
| leonardr | gary, flacoste: there's a multiversion test case it's proving difficult to handle. i don't think it's worth it to make it work properly right now (though i have a test case that i can use to let people know that the behavior is the way it is) | 20:39 |
| sinzui | EdwinGrubbs: ...Setting the project affects all series, and thus affects all packages from that series. Some series produce 10 different packages | 20:39 |
| leonardr | let me know if you agree | 20:39 |
| gary_poster | leonardr: back soon | 20:40 |
| leonardr | the test case is this: | 20:40 |
| leonardr | i'll use launchpad versions to make it concrete | 20:40 |
| leonardr | we stop publishing mutator methods as named operations in version 1.0 | 20:40 |
| sinzui | EdwinGrubbs: Maybe this will not be an issue if project-reconfiguration via AJAX rocks. | 20:40 |
| leonardr | named operations like 'transitionToStatus' | 20:41 |
| leonardr | right now, it is impossible to publish *any* named operation called 'transitionToStatus' in version 1.0 | 20:41 |
| sinzui | EdwinGrubbs: I need to get another child from school. I'll be back in a bit | 20:41 |
| leonardr | we can publish a transitionToStatus in version 2.0, but not in the version with the mutator named operation cutoff | 20:43 |
| leonardr | again, i don't think it's worth it, and if you agree, i can get this branch into review today | 20:43 |
| gary_poster | leonardr, back and reading | 20:56 |
| gary_poster | leonardr: by "2.0" in your description you meant "any version that is not 1.0" right? | 20:58 |
| bac | sinzui: have time for a quick call? i'm a bit wedged on a testing issue | 21:10 |
| sinzui | bac: sure, I'll get something to drink first | 21:11 |
| bac | ok, call when ready | 21:11 |
| leonardr | gary: yes, exactly | 21:13 |
| gary_poster | leonardr: sounds fine | 21:13 |
| leonardr | ok, cool | 21:13 |
| leonardr | also ready for call when you are | 21:13 |
| gary_poster | cool, will ping (on another call) | 21:13 |
| === salgado is now known as salgado-afk | ||
| sinzui | bac: I am ready | 21:17 |
| bac | sinzui: ok, can you dial? | 21:17 |
| sinzui | calling, skype say you do no exist | 21:17 |
| mwhudson | james_w: around? | 21:19 |
| mwhudson | wgrant: or you | 21:20 |
| * mwhudson just wants to ask some questions about building packages | 21:20 | |
| bac | sinzui: can you hear me? | 21:23 |
| sinzui | no | 21:23 |
| bac | i could | 21:23 |
| bac | stupid skype on phone | 21:23 |
| james_w | hi mwhudson | 21:33 |
| mwhudson | james_w: hi | 21:33 |
| james_w | how do? | 21:34 |
| mwhudson | james_w: i think i just wanted to ask about the mangling that needs to be done to a source package to build a different version | 21:34 |
| mwhudson | james_w: pretty good! | 21:34 |
| mwhudson | almost entirely unpacked in the new house... | 21:34 |
| james_w | excellent | 21:34 |
| james_w | the easiest way to do it is just to add a new changelog entry | 21:35 |
| james_w | let me see how they do it in Debian | 21:35 |
| mwhudson | this is where i get a teeny bit confused by questions like "what is a source package, again" | 21:35 |
| wgrant | mwhudson: Hi. | 21:35 |
| mwhudson | isn't the version specified in the .changes file? | 21:36 |
| wgrant | The binary build process cannot see the changes file. | 21:36 |
| mwhudson | ah ok | 21:36 |
| mwhudson | and 'make' seems to be broken in devel | 21:36 |
| wgrant | The changes file isn't really part of the package. | 21:36 |
| mwhudson | Error: There is a version conflict. | 21:39 |
| mwhudson | We already have: zope.interface 3.4.0 | 21:39 |
| mwhudson | anyone seeing this? | 21:39 |
| james_w | mwhudson: the .dsc has the version, taken from the debian/changelog inside the unpacked source package (unless you are nasty) | 21:39 |
| james_w | the .changes is a description of the upload, so is more about the delta than the state at the end | 21:39 |
| wgrant | mwhudson: I saw that around a month ago. A clean fixed it. | 21:40 |
| mwhudson | james_w: ah ok | 21:41 |
| mwhudson | so mangling the dsc is *an* option, although possibly not a very good one | 21:42 |
| wgrant | It won't work, will it? | 21:42 |
| mwhudson | for https://dev.launchpad.net/BuildBranchToArchive/MultipleSeriesBuilds | 21:42 |
| wgrant | It won't affect the unpackaged source, so binary builds will ignore it. | 21:42 |
| wgrant | s/unpackaged/unpacked | 21:43 |
| mwhudson | wgrant: make clean not helping :( | 21:44 |
| wgrant | james_w: Soyuz has no work towards binary rebuilds yet, and supporting them would require quite a few changes on both slave and master. | 21:47 |
| james_w | hmm | 21:47 |
| james_w | Celso told me there was some work towards it | 21:47 |
| wgrant | This is the same infrastructure that is needed for native backports. | 21:47 |
| james_w | it might have been very early steps though | 21:47 |
| james_w | wgrant: happen to know of any package in Debian with +b1 currently? ;-) | 21:48 |
| wgrant | james_w: No. Why? | 21:48 |
| james_w | just want to examine one | 21:48 |
| wgrant | I'm pretty sure they just magically somehow gain the extra changelog entry at the start of the build. | 21:49 |
| wgrant | It's added on the buildd side. | 21:49 |
| james_w | yeah, that's what I think too | 21:49 |
| james_w | just want to confirm before asserting it to be true | 21:50 |
| wgrant | Examining sbuild 0.60.0 might work. | 21:50 |
| wgrant | I would, but my connection really sucks at the moment. | 21:50 |
| james_w | http://packages.debian.org/sid/i386/libfacile-ocaml-dev/download | 21:51 |
| james_w | mwhudson: so yeah, we just tell the buildd to write a new changelog stanza as it starts the build | 21:51 |
| james_w | as I said, not exactly elegant, but does buy us several other useful features | 21:52 |
| wgrant | Presenting this in the UI is going to be interesting. | 21:52 |
| mwhudson | james_w: oh ok | 21:52 |
| wgrant | But it is a very useful feature. | 21:52 |
| wgrant | And probably a bit less evil than mutating the source. | 21:52 |
| james_w | yes | 21:53 |
| james_w | easier to implement | 21:53 |
| wgrant | james_w: Do you know how distro people feel about binNMUs? | 21:53 |
| james_w | but it still leaves us without no-change rebuilds and native backports | 21:53 |
| wgrant | I've heard some negativity around that area before. | 21:53 |
| james_w | it's mixed I think | 21:53 |
| wgrant | Does it? | 21:53 |
| james_w | done right I think it would be accepted | 21:54 |
| james_w | wgrant: you are saying we could use the same infrastructure to do them? | 21:55 |
| wgrant | james_w: Native backports and multi-series recipe builds without source changes seem to be the same concept. | 21:55 |
| mwhudson | james_w: for the "What happens when we open a new development release, there will be zero recipes associated with that series for people to choose from." question | 21:56 |
| mwhudson | i think that "build for all supported series" should be a distinct option from (currently) build for "lucid, karmic, jaunty and hardy" | 21:56 |
| === matsubara is now known as matsubara-afk | ||
| mwhudson | and uh intreprid i guess | 21:57 |
| wgrant | I'm not sure we do. | 21:57 |
| wgrant | There's probably no point doing daily builds for the first little while in each series. | 21:58 |
| james_w | mwhudson: yeah, the question may be moot, but we need to consider what happens when we open a new seris | 21:58 |
| james_w | wgrant: quite possibly | 21:58 |
| mwhudson | wgrant: well, maybe, but that's not actually in too much opposition to what i said | 21:59 |
| james_w | wgrant: I was going to say that it doesn't fit no-change rebuilds as it rebuilds the source package, so it may not be no-change, but that's the status quo anyway | 21:59 |
| mwhudson | maybe not "all supported series" but "some default set of series" | 21:59 |
| wgrant | james_w: It doesn't really rebuild the source package; it unpacks it, adds a changelog entry, and builds a binary from it. | 22:00 |
| james_w | wgrant: sorry, status quo in Ubuntu | 22:01 |
| james_w | apt-get source; dch -i; debuild -s; dput | 22:01 |
| wgrant | james_w: Oh, you meant the status quote may not be no-change. | 22:01 |
| wgrant | True. | 22:01 |
| james_w | yes | 22:02 |
| james_w | we hope it is no substantive change | 22:03 |
| wgrant | But autofoo or blah blah. | 22:03 |
| james_w | wgrant: but regardless of the implementation we will be able to do no-change rebuilds server side with build from branch :-) | 22:06 |
| wgrant | True. | 22:07 |
| mwhudson | oops, i probably didn't want to delete download-cache in my trunk directory... | 22:11 |
| EdwinGrubbs | maxb: ping | 23:16 |
| mwhudson | hm | 23:54 |
| mwhudson | thumper: does 'make' work in devel for you? | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
