| psusi | if a bug was mistakenly assigned to two packages instead of being reassigned, is there a way to remove the first task rather than just set its status to invalid? | 01:00 |
|---|---|---|
| micahg | psusi: no | 01:00 |
| micahg | you could remove the package if it's totally inappropriate | 01:01 |
| psusi | micahg, blast... can't even change the ordering? if you look up the bug by number it pulls up the first project where it is invalid | 01:01 |
| psusi | bug #401627 never had anything to do with the GNOME Terminal project, but that's what comes up when you open the bug via reference that does not specify the shadow package, like the link in the bug mail | 01:02 |
| ubot5 | Launchpad bug 401627 in shadow (Ubuntu) "Poor diagnostic when run by a non privileged user" [Low,Triaged] https://launchpad.net/bugs/401627 | 01:02 |
| psusi | there's no way to fix that? | 01:03 |
| micahg | psusi: that's a project, you can change it to the null project | 01:03 |
| psusi | hrm... then it would just come up as a bug in the "Null Project" wouldn't it? | 01:03 |
| RedSingularity | It seems that the font in launchpad just changed after a page refresh. Was there something done at the server level recently? | 01:14 |
| lifeless | yes | 01:19 |
| lifeless | we just deployed a new version of the code base | 01:19 |
| lifeless | we're now following the canonical web site style guidelines, which should make it more readable and we shouldn't be changing it as often | 01:19 |
| RedSingularity | lifeless: ah ok, just checking. Thanks :) | 01:20 |
| RedSingularity | looks good! | 01:20 |
| lifeless | micahg: psusi: you can't fix that [yet] because you cannot delete bugtasks. | 01:21 |
| lifeless | we're actively discussing how to do something that behaves (mostly) like deletion | 01:21 |
| psusi | what's wrong with ACTUAL deletion? ;) | 01:23 |
| lifeless | psusi: its very hard to undo | 01:24 |
| lifeless | psusi: things that are hard to undo you then need to make hard *to do* | 01:24 |
| psusi | it is? doesn't seem any harder than it was to add the task in the first place? | 01:24 |
| lifeless | psusi: it is | 01:24 |
| lifeless | consider | 01:24 |
| lifeless | bug on terminator upstream and linux-kernel in ubuntu | 01:25 |
| lifeless | someone deletes the linux-kernel task | 01:25 |
| lifeless | someone else remembers the bug and searches in ubuntu, can' find it. | 01:25 |
| lifeless | if we don't actually delete, but just don't show, then they can find via advanced search. | 01:25 |
| lifeless | psusi: and what about deleting the last task? | 01:26 |
| lifeless | a bug with no tasks can't be shown or search by LP at the moment. | 01:26 |
| psusi | yea, shouldn't be able to delete the last one obviously ;) | 01:27 |
| lifeless | well, if the user model is 'they can be deleted', why not ? | 01:27 |
| psusi | because you have to have at least one | 01:28 |
| lifeless | well | 01:28 |
| lifeless | I'm pointing out the discussions that will happen | 01:28 |
| lifeless | they take time and effort | 01:28 |
| psusi | hrm... how is this problem any different than reassigning the project to the null project? | 01:28 |
| lifeless | and the friction makes the product feel less polished | 01:28 |
| lifeless | better to avoid it by designing something more graceful in the first place | 01:29 |
| === jasono_ is now known as jasono | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| lifeless | quick poll, does lp feel fast or slow at the moment (production, not edge or *staging) | 09:13 |
| maxb | fast-ish? | 09:15 |
| lifeless | maxb: fingers crossed | 09:18 |
| === head_v is now known as head_victim | ||
| === matsubara-afk is now known as matsubara | ||
| mhr3 | hey there, is there any way to disable the "Successfully built" emails from daily builds? | 12:45 |
| mhr3 | i really don't care if it was built successfully | 12:45 |
| maxb | Unfortunately, no. | 12:46 |
| bigjools | those emails need to be stopped | 12:47 |
| maxb | They kinda-sorta serve a purpose | 12:47 |
| mhr3 | hmm.. too bad | 12:47 |
| maxb | It is mildly interesting knowing the ~bzr daily PPA recipes did someting | 12:47 |
| bigjools | we could make it opt-in, but now that the service is out of beta and supposedly reliable, it's probably more interesting to only know about failures :)( | 12:48 |
| mhr3 | and another one: can i mark a branch in a recipe to not trigger daily build? ie i merge multiple branches in a recipe and don't want a rebuild everytime any of them changes | 12:48 |
| mhr3 | ...just the primary one | 12:49 |
| didrocks | hey | 13:35 |
| didrocks | how long does it take for a dep-wait to be retried automatically in a ppa? | 13:35 |
| === dpm_ is now known as dpm | ||
| diwic | Hi! According to http://blog.launchpad.net/code/git-branch-imports-now-in-public-beta , importing Linux Kernel (or parts of it?) is not supported by Launchpad's code import. Well, I'd like to do this anyway, is there a workaround somehow? | 14:14 |
| maxb | diwic: The existence of https://code.launchpad.net/~vcs-imports/linux/trunk would suggest that it is no longer an issue | 14:20 |
| diwic | maxb, aha, interesting. Although when I try to look at the files present I get an error saying "Sorry, there was a problem connecting to the Launchpad server. | 14:22 |
| diwic | Try reloading this page in a minute or two. If the problem persists, let us know in the #launchpad IRC channel on Freenode. " | 14:22 |
| maxb | Unfortunately the web branch browser is a bit flaky | 14:23 |
| cjwatson | gmb: it looks like bug 28738 ended up Invalid in error. It was previously Invalid in launchpad and Confirmed in malone, but I think that when all the Launchpad projects got merged it ended up simply being Invalid | 14:23 |
| ubot5 | Launchpad bug 28738 in Launchpad itself "Launchpad Bugs doesn't know about the Flyspray BTS" [Low,Invalid] https://launchpad.net/bugs/28738 | 14:23 |
| cjwatson | gmb: should it be reopened? | 14:23 |
| cjwatson | I wonder how many bugs this happened to | 14:23 |
| maxb | diwic: However this shouldn't affect accessing the branch from a Bazaar client | 14:24 |
| gmb | cjwatson: Urk. That's slightly concerning. I'll re-triage it anyway. | 14:25 |
| gmb | sinzui: Do you know if any other bugs have been bitten by this ^^? | 14:25 |
| gmb | Whoops | 14:25 |
| * gmb accidentally WONTFIX'd it. | 14:25 | |
| sinzui | gmb: I believe there were about 200 bugs where there were multiple tasks. I reviewed many of conflicting ones, they were fine. I know that some had their status fixed because the guess was wrong | 14:28 |
| gmb | Ah, right. | 14:28 |
| sinzui | I think the invalid in Lp is a special case. We (as the authors of this mess) should have known to retarget | 14:29 |
| cjwatson | gmb: ta muchly. (not that I *hugely* care about this bug, I just happened to run across a use case for it.) | 14:32 |
| === vednis is now known as mars | ||
| === Ursinha is now known as Ursinha-lunch | ||
| abentley | sinzui: I'm exposing setPackaging over the API, so that we can update it in-line. Do I need to export both ProductSeries.setPackaging and SourcePackage.setPackaging, for the permissions to work right? | 15:09 |
| abentley | sinzui: And do you have a position on whether we should take SourcePackage or Distroseries,SourcePackageName as a parameter? | 15:10 |
| sinzui | abentley: I do not think so. Any logged in user can do it | 15:10 |
| abentley | sinzui: That's a bit surprising. Okay. | 15:11 |
| sinzui | abentley: are you thinking that if the distroseries is not specified, we choose the current series for the distribution? | 15:12 |
| abentley | sinzui: No, I just see that some operations use SourcePackageName/DistroSeries, and others use SourcePackage, and I don't know what's The Right Way. | 15:12 |
| abentley | sinzui: e.g. ProductSeries.setPackaging takes SourcePackageName+DistroSeries, but the inverse operation is SourcePackage.setPackaging, which is a method of SourcePackage. | 15:14 |
| sinzui | abentley: okay, this related to the surprise in permissions. Lp does not know who is qualified to state what is packaged from where. User have made really stupid mistakes in the past. 1/3 of all packaging links were bogus... | 15:14 |
| abentley | sinzui: eeps. | 15:14 |
| abentley | sinzui: I just assumed it was restricted to DistoSeries or ProductSeries admins. | 15:16 |
| sinzui | ...user could/can link from the PS to a DS in Ubuntu or Debian. We actually do not trust them since 90% of the time project contributors do not understand packaging. The form suggest the current distroseries. They really do not have choice... | 15:16 |
| sinzui | We believe distro contributors have a better understanding, The SP is badly names. It is a DistributionSeriesSourcePackage. It knows its distro and series. We only need to PS. | 15:18 |
| abentley | I don't understand "We only need to PS". | 15:18 |
| abentley | sinzui: Agreed about the poor naming. | 15:19 |
| sinzui | abentley: Context is SP (disto and distroseries). PS provides product and productseries. We know the user | 15:20 |
| sinzui | We know the time, so we have the 6 pieces of information | 15:20 |
| sinzui | abentley: I think some of the underly trouble we have is that if you have an SP or DSP, we know the SPN. we often only know the SPN, so we need the distro and series clarification to know what obj to get | 15:21 |
| sinzui | abentley: We may be able to factor this out... | 15:22 |
| sinzui | abentley: User once could create a packaging link with no more than an SPN. We did not care if it was real or if it was ever published. We enforce that now, so maybe we could require an SP in the methods | 15:23 |
| abentley | sinzui: I think that if we decided to favour SourcePackage over SourcepackageName+DistroSeries, we would be able to work backwards to the point where the SourcePackageName+DistroSeries were retrieved. But it would take some effort. | 15:23 |
| abentley | sinzui: Aha! I did not realize that. | 15:24 |
| sinzui | yes. since the SP and DSP are mostly virtual, we are always working with an SPN | 15:24 |
| sinzui | (that is a lie though, DSP does have a schema representation now) | 15:25 |
| abentley | sinzui: Do you know why? I've been looking around this area, and it seems that SourcePackage was once a real database object. | 15:25 |
| sinzui | abentley: packaging links have a sordid history. I should have blogged about the issue when I started fixing the bugs because people did not realise that we had started bridging-the-gap the same we were assigned it | 15:26 |
| abentley | sinzui: Anyhow, ISTM that SourcePackageName is not a good identifier of a SourcePackage, because it's not required to provide the same software across all distroseries. | 15:28 |
| sinzui | abentley: the sp and dsp is really a pointer to a place and a moment in time. The real data is an SPR that can be in several distros and series. We use the dsp and sp to look up what is this moment. | 15:28 |
| sinzui | abentley: that is very true | 15:29 |
| abentley | sinzui: Though I suppose the problem is more that packages get renamed from time to time and so we miss associations. | 15:30 |
| sinzui | abentley: so we removed the DB backing to normalise the data. we put some dsp back in the db because denormalised data can be fast | 15:30 |
| sinzui | abentley: yes that too has happend. gaim -> pidgin | 15:30 |
| abentley | sinzui: bazaar -> baz | 15:31 |
| abentley | sinzui: Okay, so I think we should favour SourcePackage when writing new functionality. Client that have DistroSeries+SourcePackageName can easily acquire a SourcePackage. | 15:33 |
| sinzui | agreed. | 15:34 |
| abentley | sinzui: The reason why it mattered this morning was because I was going to expose ProductSeries.setPackaging over the API, but now I think SourcePackage.setPackaging will be enough. | 15:34 |
| sinzui | abentley: oh, sorry that I misunderstood the point from the start. I prefer SourcePackage.setPackaging when I write tests. ProductSeries.setPackaging could be factored out at this time. | 15:35 |
| sinzui | abentley: I think PackagingType was the historical reason they were different | 15:36 |
| abentley | sinzui: Sure. Going into this, I assumed that they would have different permissions, so both might be needed. | 15:36 |
| sinzui | We are ignoring that at this time | 15:36 |
| abentley | sinzui: right. | 15:37 |
| exarkun | Launchpad bug imports use some xml format | 15:40 |
| exarkun | What should I do with a bug comment that includes \x1b? | 15:40 |
| sinzui | exarkun: maybe convert non-unicode to the (?) character | 15:41 |
| * sinzui looks for code | 15:41 | |
| exarkun | it's only a couple places, I can do it manually | 15:42 |
| exarkun | let's call that the "destroy some data" option | 15:42 |
| exarkun | are there other options? | 15:42 |
| sinzui | exarkun: deduce the charset that was used, look up the character, replace it with the unicode char | 15:43 |
| daenney | did someone just nuke launchapd? | 15:43 |
| daenney | I'm getting a strange amount of 503's and the Please Try Again page | 15:44 |
| exarkun | sinzui: It's really \x1b | 15:44 |
| nigelb | Is loggerhead down? | 15:44 |
| CoffeeIV | I'm getting the "Try Again" message that says "Try reloading this page in a minute or two. If the problem persists, let us know in the #launchpad". It is in trying to view a merge proposal and it has been happening for at least 10 minutes. The project is private, but for what it's worth here is the url: https://bazaar.launchpad.net/~economist-magic/economist-magic/austin-janus-210-pretty-up-search-results/revision/3492 | 15:44 |
| daenney | CoffeeIV: same here | 15:44 |
| exarkun | sinzui: ie, it's not character data | 15:44 |
| sinzui | oh escape | 15:45 |
| sinzui | exarkun: I would replace the instances with ESC or <ESC> | 15:51 |
| daenney | and launchpad is still 503'ing :| | 15:52 |
| nigelb | Is it launchpad or codebrowse that's 503-ing/ | 15:52 |
| exarkun | sinzui: okay, thanks | 15:52 |
| daenney | nigelb: bazaar. so I'm guessing codebrowser | 15:55 |
| nigelb | yeah, loggerhead (the code browse thingy) has been crashing for me too. | 15:56 |
| === zyga is now known as zyga-food | ||
| === losing is now known as pifantastic | ||
| MTecknology | File tdc_1.0.orig.tar.gz already exists in TDC PPA, but uploaded version has different contents. <-- GRRR!! | 16:20 |
| === matsubara is now known as matsubara-lunch | ||
| MTecknology | I almost feel like this is a bug more than a feature.. | 16:20 |
| MTecknology | I know the contents changes.. I changed it. Now I need to somehow figure out how to grab the original and do the changes as a patch.. or idk.. unless I change version numbers and I don't want to go to 1.1 | 16:21 |
| MTecknology | Actually... the only change was a couple man page fixes and adding a changes file. | 16:25 |
| maxb | Change == new version | 16:30 |
| maxb | Don't lie to yourself about that and you'll never hit this error :-) | 16:31 |
| maxb | Just picture yourself having to ask someone "Do you have the first 1.0 or the second 1.0 version?" and it should be easy to see why this constraint is made | 16:31 |
| === beuno is now known as beuno-lunch | ||
| bigjools | maxb: that's one of the best ways of explaining it I've ever seen | 16:45 |
| maxb | :-) | 16:46 |
| MTecknology | makes sense | 16:47 |
| MTecknology | I still don't like it :P | 16:47 |
| bigjools | your apt client will also barf if it sees the same file with different contents | 16:48 |
| maxb | s/barf/silently do wrong stuff/ | 16:48 |
| bigjools | heh | 16:48 |
| maxb | barfing would be preferable | 16:49 |
| maxb | (Not something I thought I'd ever say :-) ) | 16:49 |
| bigjools | I've often felt that way :) | 16:49 |
| MTecknology | I wonder if this thing will ever make it to a 1.1 release.. | 16:51 |
| MTecknology | This will be 1.0.1 | 16:52 |
| === mdeslaur_ is now known as mdeslaur | ||
| === beuno-lunch is now known as beuno | ||
| === jussi01_ is now known as jussi | ||
| === matsubara-lunch is now known as matsubara | ||
| === yofel_ is now known as yofel | ||
| === tubadaz_ is now known as tubadaz | ||
| === JayFo is now known as JFo | ||
| === pifantastic_ is now known as pifantastic | ||
| === pifantastic is now known as losing | ||
| === losing is now known as pifantastic | ||
| === leonardr__ is now known as leonardr | ||
| Meths | I'm getting duplicate emails from LP at the moment - is this a known issue? | 19:10 |
| abentley | Meths: I don't believe so. The most common cause of this is mailing lists that receive the same email as you. | 19:15 |
| abentley | Meths: can you post full headers of two duplicate emails? | 19:15 |
| Meths | Two emails here: http://pastie.org/private/qgzyjuaozlpvgiklfrcea | 19:21 |
| Meths | Seems LP has suddenly started including me separately. Before I got emails with just the mp+<id>@code.lp.net in the To field. | 19:24 |
| Meths | That first post seems a bad example of that. This is the example of the new, duplicated merge message I'm getting with the two entries in the To field: http://pastie.org/private/jcldgzspbnxsrrpivb2zw | 19:28 |
| abentley | Meths: That is nuts. Tim Bentley is my father's name. | 19:29 |
| Meths | Ah, so it's worse than duplication - it's cloning! ;) | 19:30 |
| === apachelogger_ is now known as apachelogger | ||
| abentley | Meths: This is more of a duplicate than I was expecting. The only differences I can see are timestamps. | 19:34 |
| Meths | Does that mean you want a bug filed or if I told you it's only been happening as far as I can see for about the last 1.5 hours has anyone made changes that it could be linked to? | 19:36 |
| Meths | I've also got 3 OOPS IDs for failing to email a code review comment | 19:38 |
| abentley | Meths: I probably want a bug filed. This has been consistent for the last 1.5 hours? Is it all code review mail? | 19:39 |
| abentley | Meths: I expect the oopses are unrelated. | 19:40 |
| Meths | Yes it's all code review email, yes all code review email for the last 1.5 hours is duplicated but on closer inspection I hadn't got any code review email for quite a while before then so couldn't pin the time. Bug email seems fine but unhelpfully I don't have any bug emails during the time period I have duped code emails! | 19:43 |
| Meths | I'll file the bug and let you guys ponder it. | 19:43 |
| Meths | Ah, just got bug email (non-duped) and code email (duped) so it's definitely just the code emails. | 19:44 |
| abentley | Meths: okay. Please tag it "code-review". | 19:45 |
| Meths | Do you want me to include the contents of the pastebins? | 19:49 |
| abentley | Meths: yes please. | 19:53 |
| Meths | abentley: Done. Bug #728659 | 19:59 |
| ubot5` | Launchpad bug 728659 in Launchpad itself "Getting duplicate code review emails" [Undecided,New] https://launchpad.net/bugs/728659 | 19:59 |
| === _thumper_ is now known as thumper | ||
| === losing is now known as pifantastic | ||
| === popey_ is now known as popey | ||
| === cody-somerville_ is now known as cody-somerville | ||
| === marienz_ is now known as marienz | ||
| === matsubara is now known as matsubara-afk | ||
| === Lcawte is now known as Lcawte|Away | ||
| ti4mi | hello? | 21:38 |
| ti4mi | may someone help me to debug an upload error to a PPA? | 21:38 |
| ti4mi | I do not understand: | 21:38 |
| ti4mi | http://launchpadlibrarian.net/65476693/upload_2296710_log.txt | 21:38 |
| spiv | ti4mi: have you seen the advice on https://help.launchpad.net/Packaging/UploadErrors about that error? | 21:43 |
| spiv | (search for the phrase "already exists" on that page) | 21:44 |
| ti4mi | yes, but my error says that the package is already in the PPA but in the PPA there is none | 21:44 |
| ti4mi | https://code.launchpad.net/~grass/+archive/grass-devel/+packages | 21:45 |
| ti4mi | Error msg: File grass_7.0.0+0ubuntu1+23002~maverick1.tar.gz already exists in GRASS Development Packages | 21:46 |
| spiv | Ok, at this point I'm out of my depth... hopefully someone more knowledgable will turn up. | 21:47 |
| wgrant | ti4mi: You can't have two different files of the same name in a PPA. | 21:48 |
| wgrant | Well, that was good timing. | 21:48 |
| ti4mi | so I will put this question to launchpad QA | 21:49 |
| spiv | ti4mi: You just missed: <wgrant> ti4mi: You can't have two different files of the same name in a PPA. | 21:49 |
| ti4mi | ok got it. there were hidden super seeded files from previous uploads that failed to build | 22:00 |
| ti4mi | i increased the ~ubunutX version number in the recipie | 22:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!