| nellery | What email interface command can be used to add a bug watch? | 00:23 |
|---|---|---|
| Hobbsee | brilliant. Found a way to make launchpad load as quick, or quicker! | 00:34 |
| jml | oh? | 00:34 |
| * wgrant would like it accessible over IPv6, as his IPv6 routing is much better. | 00:34 | |
| Ursinha | Hobbsee, how? | 00:38 |
| Hobbsee | Ursinha: running a socks proxy to the US, and loading pages thru that. | 00:38 |
| Ursinha | hmm | 00:38 |
| Ursinha | interesting | 00:39 |
| Hobbsee | a whole lot of pages are loading in 5 seconds. | 00:39 |
| Hobbsee | the minimum i normally get to au is 7. | 00:39 |
| jml | Hobbsee: that's surprising | 00:39 |
| jml | Hobbsee: I guess you look mostly at bugs pages? | 00:39 |
| Hobbsee | jml: yeah, although i was browsing around at random with the proxy | 00:39 |
| Hobbsee | https://edge.launchpad.net/ubuntu/intrepid/+builds?build_text=&build_state=pending loads in 4.381 seconds. | 00:40 |
| jml | Hobbsee: I find the code pages tend to load faster (although still too slowly) | 00:40 |
| james_w | hey, all, I'm trying to use the api, and a bug has an "unsubscribe" operation, but it doesn't take a parameter, so I don't see how to un-subscribe a team that I am on. | 00:41 |
| Hobbsee | hmmm | 00:41 |
| james_w | am I missing something? Would I report a bug against launchpad to get a parameter added so that I can do this? | 00:42 |
| * Hobbsee wonders if someone's written a greasemonkey script to not load the google maps. | 00:46 | |
| elmo | adblock plus works well | 00:48 |
| Hobbsee | elmo: that's true, but i'd prefer to only block it on LP. | 00:54 |
| elmo | you can | 00:54 |
| elmo | block on http://maps.google.com/maps?file=api&v=2.121&key=ABQIAAAAd8GIgO6pcskVE20WMo0tMRRkABWjM-HFSmcaZJwi4T_L_gqd8hQZWt328aH2TFAi3x2jCPoCqCaLIQ | 00:54 |
| elmo | (that's LP's key, obviously - so other maps will work fine) | 00:55 |
| Hobbsee | oh :) | 00:55 |
| Hobbsee | elmo: thanks, I got that to work :) | 00:58 |
| === salgado-afk is now known as salgado | ||
| paolettopn | Vado via alle Fri Oct 10 02:10:01... ci si rivede alle prossime! | 01:10 |
| === salgado is now known as salgado-afk | ||
| Peng_ | jml: Oh. Never mind about my ping earlier. | 02:18 |
| jml | Peng_: tbh, I'd forgotten :) | 02:19 |
| jml | Peng_: was it about branch mirroring? | 02:19 |
| Peng_ | jml: Heheh, as always. :) | 02:19 |
| jml | Peng_: yeah, we had some teething problems with our new server, which have since been fixed. | 02:20 |
| Peng_ | jml: So it should work now? | 02:21 |
| jml | Peng_: 'should' is such a slippery word. | 02:22 |
| jml | Peng_: I would be surprised if it didn't work :) | 02:22 |
| Peng_ | I'm sure you were surprised when it didn't work before. :P | 02:25 |
| Peng_ | Anyway, it works. Yays! | 02:25 |
| Peng_ | bug 280059 -> fixed? | 02:26 |
| ubottu | Launchpad bug 280059 in launchpad-bazaar "mirroring branches is broken" [High,Triaged] https://launchpad.net/bugs/280059 | 02:26 |
| jml | mwhudson: ^^ | 02:26 |
| Peng_ | And I've finally converted a bunch of branches to packs, so they might actually be mirrored this time! | 02:28 |
| jml | heh heh | 02:28 |
| mwhudson | ah, yes, it probably is fixed | 02:32 |
| Peng_ | LP even managed to mirror one of my knit branches that IIRC should've caused a revision not found error. | 04:35 |
| Peng_ | One of my branches failed to mirror due to a KeyboardInterrupt? | 04:37 |
| mwhudson | Peng_: that means the puller process didn't see any activity for 15 minutes or something | 04:43 |
| Peng_ | I hit the try again button and it worked. | 04:44 |
| mwhudson | i guess we may have been mirroring more than one branch from your server at once or something | 04:44 |
| Peng_ | Yeah, you were. | 04:44 |
| mwhudson | (we should probably stop doing that) | 04:45 |
| Peng_ | I don't mind. :) | 04:45 |
| mwhudson | jam does :) | 04:45 |
| Peng_ | My web server dropped one readv, eventually giving up after 360 seconds. Maybe that helped cause it to time out. | 04:45 |
| ziroday | Hi, I am having issues logging in. I go to the login page, type in username and password. Click login, get directed back to original page but _have | 09:12 |
| ziroday | not logged in | 09:12 |
| wgrant | ziroday: Are you being redirected to edge, perhaps? | 09:17 |
| wgrant | Or do you have cookies disabled? | 09:17 |
| ziroday | wgrant: sorry, not being redirected to edge, and yes cookies are enabled | 09:23 |
| ziroday | wgrant: cleared cache and cookies, still there | 09:24 |
| === jamesh_ is now known as jamesh | ||
| persia | Is there a safe way to interrupt a bzr push to LP? It's been over two hours for a 1k update (although pushing a new branch of 433 revisions). I do have an open connection to crowberry. | 11:52 |
| wgrant | persia: A new branch means pushing the whole lot unless it's stacked. | 11:57 |
| persia | "stacked"? | 11:58 |
| wgrant | A nice new bzr feature which makes new branches much less tedious to push. | 11:59 |
| wgrant | Branches can refer to another branch in which revisions can be found. | 11:59 |
| wgrant | So you only have to push the new revisions, even for a new branch. | 11:59 |
| persia | Hrm. Sounds nifty. I think I'll want to use that next time. | 12:09 |
| === mrevell is now known as mrevell-lunch | ||
| === salgado-afk is now known as salgado | ||
| persia | Now 4 hours still in Transferring 0/4. If I Ctrl-C, and try to repush, is LP going to think I'm not pushing any revisions? | 13:07 |
| wgrant | persia: I doubt it, but you'll probably have to tell bzr to overwrite the target because it's a new branch. | 13:17 |
| persia | So I probably want to Ctrl-C, and try again with --stacked-on and --overwrite? | 13:23 |
| wgrant | persia: Likely. And you then need a three-line Python hack to get LP to like the stacking - I believe this will be fixed in 2.1.10. | 13:25 |
| wgrant | But it makes pushes so much faster. | 13:26 |
| wgrant | It is actually usable. | 13:26 |
| persia | I can probably skip the stacking if I upgrade the repo. I'm not entirely comfortable hacking bzr at my current comfort level with using it at all. | 13:27 |
| persia | Hrm. 1/4. Still, I don't want to wait another 6 hours. | 13:27 |
| wgrant | Is it a knit branch? | 13:28 |
| persia | Yes. | 13:28 |
| wgrant | That would do it. | 13:29 |
| persia | It's supposed to be that slow? | 13:30 |
| wgrant | I hope not. | 13:30 |
| wgrant | But I'm fairly sure that LP is slower with knit branches than it used to be. | 13:30 |
| wgrant | Packs are much, much faster. | 13:31 |
| persia | Hrm. I wonder what happens if a format becomes not only deprecated, but no longer supported, and the server upgrades. Will branches become non-useful? | 13:31 |
| wgrant | bzr hasn't dropped support for any formats yet, has it? | 13:33 |
| james_w | at least nothing that anyone could conceivably be using. I know the format support extends back to at least version 0.8 formats. | 13:34 |
| wgrant | I remember weaves... was anything before that? | 13:36 |
| persia | james_w, I suspect that as long as bzr supports all the formats ever used by LP, LP should be OK. Otherwise, LP probably needs to grow some means of bringing the old code forward. | 13:37 |
| persia | Hrm. Despite upgrading, now bzr is downgrading on push because of the previous push (even with --overwrite). Does LP have some button to let me change the format stored in LP, or should I just pick a new name, and delete the old branch? | 13:38 |
| wgrant | LP does really need a server-side upgrade button. | 13:38 |
| wgrant | persia: No need to pick a new name - if it's a new branch, just delete it and repush. | 13:38 |
| persia | Ah. "Delete" was the step I missed. Thanks. | 13:39 |
| wgrant | There's probably a better way to do it in bzr, but the button in LP is the one I know of. | 13:40 |
| persia | Well, it definitely worked for me : it's at 3/5 already. Thanks. | 13:44 |
| wgrant | Excellenmt. | 13:45 |
| wgrant | -m | 13:45 |
| wgrant | +sleep | 13:45 |
| === gary_poster changed the topic of #launchpad to: https://launchpad.net/ | Channel logs: http://irclogs.ubuntu.com | https://help.launchpad.net/HelpRotation | Community help contact: gary_poster | ||
| === mrevell-lunch is now known as mrevell | ||
| * wgrant doesn't think he's seen gary_poster around these parts before. | 13:51 | |
| === Guest52963 is now known as jelmer | ||
| * gary_poster thinks wgrant is right :-) | 13:51 | |
| laga_ | so, the community help contact. do you guys just draw straws or is there a schedule? ;) | 13:52 |
| gary_poster | heh | 13:52 |
| gary_poster | there's a schedule, which is swapped around | 13:52 |
| gary_poster | as needed | 13:52 |
| Hobbsee | gary_poster: what do you work on normally, then? | 13:52 |
| gary_poster | Launchpad foundations | 13:52 |
| Hobbsee | ahhh | 13:53 |
| gary_poster | so...the underlying goop :-) | 13:53 |
| gary_poster | (in a good way :-) ) | 13:53 |
| Hobbsee | mmm...goop.... | 13:53 |
| gary_poster | :-) | 13:53 |
| Hobbsee | we should hit you up for all the foundation bugs, then. | 13:53 |
| gary_poster | oh joy ;-) | 13:53 |
| wgrant | Foundations including Registry, or are the teams actually split now? | 13:53 |
| Hobbsee | you feel like fixing mail headers? :) | 13:53 |
| gary_poster | wgrant: split up now | 13:54 |
| wgrant | Aha. | 13:54 |
| wgrant | ~launchpad is positively massive now. | 13:54 |
| gary_poster | Hobbsee: not particularly. ;-) what's the bug, though? I'm curious. | 13:54 |
| gary_poster | wgrant: yup, pretty big | 13:54 |
| Hobbsee | gary_poster: https://lists.ubuntu.com/archives/launchpad-users/2008-September/004228.html | 13:55 |
| Hobbsee | no X-Message-rationale, etc. | 13:56 |
| wgrant | And a fake from address. | 13:56 |
| gary_poster | Hobbsee: gotcha. did you file a bug? | 13:56 |
| Hobbsee | gary_poster: no, but i'm not sure if anyone else did. | 13:57 |
| gary_poster | Hobbsee: heh, ok, well, I can at least dig around and check, and add it if I don't find it. I'll ping you and put the bug # here in case you want to subscribe. | 13:58 |
| Hobbsee | gary_poster: cool, OK. | 13:59 |
| Hobbsee | gary_poster: does that imply fixing it too, or just reporting it? | 13:59 |
| gary_poster | Hobbsee: given other tasks for today, just reporting it I'm afraid | 13:59 |
| gary_poster | ...unless the solution falls down to me like an apple on my head... | 14:00 |
| Hobbsee | gary_poster: how hard is it to get headers added to mails? Everything else manages to have headers.... | 14:00 |
| gary_poster | Hobbsee: If one knows the code that is generating the email, and the reason for the missing header, presumably rather easy. I know neither, and as I said, I have other tasks today. I'll add the bug, and see if someone else has an immediate pointer. | 14:03 |
| gary_poster | Again, given the schedule, even if I fixed it today, it's doubtful that the fix would be in the next release. | 14:03 |
| Hobbsee | fair enough. | 14:05 |
| Hobbsee | no, but i'd hope it gets done in the next 6, tbh. | 14:05 |
| Hobbsee | or even 12, as most people probably don't care much about it. | 14:05 |
| gary_poster | understood | 14:07 |
| zachtib | is the PPA service running slow today? I uploaded packages ~15 minutes ago and haven't gotten an email from it yet | 15:02 |
| zachtib | usually, I get an email within a couple minutes | 15:02 |
| gary_poster | Hobbsee: appears to be new bug. Assigned to registry team. See bug 281293. | 15:02 |
| ubottu | Launchpad bug 281293 in launchpad-registry "X-Launchpad headers missing from user deactivation email" [Undecided,New] https://launchpad.net/bugs/281293 | 15:02 |
| cprov | zachtib: let me check. | 15:02 |
| zachtib | thanks | 15:03 |
| cprov | zachtib: source name ? | 15:03 |
| zachtib | deluge-torrent_1.0.1 | 15:03 |
| cprov | zachtib: you've signed the upload with a unknown GPG key | 15:05 |
| zachtib | really? that's odd | 15:05 |
| zachtib | it should be the same key i've been using in that repo since i started it | 15:05 |
| cprov | zachtib: key id ? | 15:05 |
| zachtib | i think it's this: 1024D/C1CB9387 | 15:06 |
| cprov | zachtib: yes, it's signed with C1CB9387 | 15:09 |
| zachtib | debuild did spit out some warnings when i signed it... | 15:11 |
| zachtib | wonder why | 15:11 |
| zachtib | hmm... it didn't do it this second time | 15:12 |
| cprov | zachtib: you have email | 15:13 |
| cprov | zachtib: I've reprocessed your uploads and they were accepted. | 15:13 |
| zachtib | ok, cool | 15:13 |
| zachtib | both the zachtib and deluge-team ppa? | 15:13 |
| cprov | zachtib: it looks like a keyserver temporary failure. | 15:13 |
| zachtib | ah | 15:14 |
| zachtib | awesome, they're building now | 15:14 |
| zachtib | thanks | 15:14 |
| cprov | zachtib: apparently I've just re-processed the ones to the team PPA. | 15:15 |
| cprov | zachtib: there was only one upload to your PPA (hardy) and it was accepted. | 15:16 |
| zachtib | right, ok | 15:16 |
| zachtib | thanks again | 15:16 |
| cprov | zachtib: np, you did well warning about the acceptance email delay. | 15:19 |
| cprov | zachtib: it should never take more than 10 minutes. If it does, something is wrong. | 15:20 |
| synic | how do I get rid of this message? | 15:44 |
| synic | Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this) | 15:44 |
| persia | synic, That's an unfortunate error message, that should read "Server is too new for streaming pull, reconnecting. (Upgrade the client to avoid this). | 15:45 |
| persia | For the most part, just ignore it, or upgrade bzr. | 15:46 |
| synic | ah | 15:46 |
| synic | oh nice, there's a ppa. | 15:46 |
| === matsubara is now known as matsubara-lunch | ||
| === gary_poster is now known as gary_poster-lunc | ||
| === salgado is now known as salgado-lunch | ||
| kirkland | is it possible for me to blacklist launchpad users that i no longer want to hear from? | 16:48 |
| kirkland | i'd like their comments on bugs, when sent to me, to be simply dropped. and when in the web interface, hidden or collapsed | 16:48 |
| kirkland | also, what about a way to politely refer impolite users to the Code of Conduct? perhaps a low-numbered bug that you could subscribe someone to | 16:50 |
| kirkland | or a button that says "Remind this person about the Ubuntu Code of Conduct" | 16:50 |
| persia | kirkland, There's no easy way, but perhaps you could use a mail filter? Also, not all users are signatories to the CoC : you can check for "Ubuntutero: Yes" in their profile. | 16:57 |
| kirkland | persia: gotcha | 16:59 |
| persia | kirkland, I understand your pain, I'm just not sure there's any sane solution currently available from Launchpad. I think the only tool available is the big hammer of suspending an account, but that's pointlessly trivial to work around. | 17:00 |
| persia | (and there have been past cases where attempts at restrictions have resulted in new users) | 17:00 |
| kirkland | persia: account suspension might be extreme | 17:00 |
| kirkland | persia: but i've reached wit's end with a few users | 17:01 |
| persia | procmail is your friend. | 17:01 |
| === gary_poster-lunc is now known as gary_poster | ||
| kirkland | persia: yeah, i suppose | 17:01 |
| === matsubara-lunch is now known as matsubara | ||
| === abentley1 is now known as abentley | ||
| === salgado-lunch is now known as salgado | ||
| chx | hi. please compare https://code.launchpad.net/~vcs-imports/drupal/main and http://drupal.org/project/cvs/3060 | 18:18 |
| chx | it seems that the import ... broke? or something | 18:18 |
| Odd_Bloke | gary_poster: ^ | 18:23 |
| gary_poster | chx, Odd_Bloke: thanks, looking | 18:26 |
| gary_poster | chx: have not forgotten you. trying to find someone who would know more than I about it. | 18:31 |
| chx | gary_poster: thanks. | 18:34 |
| gary_poster | chx: a dev on that team has looked into the problem, put it into launchpad as a bug, and triaged it. If you'd like to subscribe to the bug report, here's the URL: https://bugs.launchpad.net/launchpad-bazaar/+bug/281382 | 18:59 |
| ubottu | Launchpad bug 281382 in launchpad-cscvs "Drupal CVS import failing mysteriously" [Medium,Triaged] | 18:59 |
| ahasenack | guys, I uploaded some packages to a PPA in LP. Then I requested their deletion and I'm watching the repository. Once the files are gone from it, will I be able to upload a package with the same name-version-release to it? | 19:00 |
| cprov | ahasenack: no | 19:00 |
| ahasenack | cprov: and a lower version? Also not? | 19:00 |
| ahasenack | I'm switching from 1.1.1-0ubuntu0.8.04.1 to 1.1.1~bzr20081010-0ubuntu08.04 | 19:00 |
| ahasenack | but the ~ one is lower | 19:01 |
| cprov | ahasenack: yes, a lower, but new, version will be accepted. | 19:01 |
| ahasenack | cprov: oh, so that one (with ~) would probably be accepted? | 19:01 |
| cprov | https://help.launchpad.net/Packaging/PPA#Deleting packages | 19:01 |
| cprov | ahasenack: only if you don't have any other version like '1.1.1-.*' published in the same series | 19:03 |
| ahasenack | cprov: ok, thanks | 19:03 |
| ahasenack | cprov: do I have to wait for the packages to disappear from the repository? | 19:03 |
| cprov | ahasenack: no, if it's DELETED you can upload a lower version. | 19:04 |
| ahasenack | cprov: ok, thanks again | 19:04 |
| cprov | ahasenack: np | 19:04 |
| persia | cprov, A lower, but different version is accepted? If you're blocking the same version, surely that's a bug, no? | 19:05 |
| cprov | persia: no, it's not a bug. | 19:07 |
| cprov | persia: version blacklist avoid binaries to get rebuilt with the same version (and surely with different contents). | 19:07 |
| persia | cprov, Then I'm confused. I thought the rationale for not accepting the same version was to make sure any users of the PPA would be upgraded if a new version appeared. Is this incorrect? | 19:07 |
| persia | Yes, but if a lower version is accepted, then I don't see the point of doing that. | 19:08 |
| cprov | persia: lower versions will just require the user to remove the old binaries if he wants a update. | 19:08 |
| persia | So why not allow the same version then? | 19:08 |
| cprov | persia: the lower version is only accepted when the old (but higher) version gets deleted. | 19:08 |
| persia | I understand. I just don't see the distinction in use cases. | 19:09 |
| cprov | persia: currently we are not spread binaries with the same versions but with different contents. | 19:10 |
| cprov | s/spread/spreading. | 19:10 |
| persia | From the same PPA. I can certainly do that with multiple PPAs. | 19:10 |
| cprov | persia: yes, but the whole point is to not keep diverging binaries cached on clients and those are aware of repository location, right / | 19:11 |
| persia | But the Packages file will have changed, which means the signatures change, which mean the client downloads it again anyway. | 19:12 |
| persia | s/signatures/checksums/ | 19:13 |
| cprov | persia: yes, the checksum will change and apt will re-install the binaries | 19:13 |
| persia | Right, so client cache doesn't matter. | 19:13 |
| cprov | persia: but how do you know which version a user has installed ? | 19:14 |
| persia | Why do you care? | 19:14 |
| cprov | persia: always suggest an upgrade or ask for the bin checksum | 19:14 |
| persia | Presumably you want the user to have the latest version you released installed. If you have a repo intended for end-users, you need to have incrementing version numbers anyway. | 19:14 |
| cprov | persia: because I like PPA users and don't want to see them suffering ;) | 19:15 |
| persia | I just don't see any value to the blacklist if one can work around it by deleting it and uploading a *lower* package. | 19:15 |
| cprov | persia: well, there is a value in forcing users to always provide distinct versions, specially because deleted/superseded binaries can be downloaded and installed for testing purpose if necessary. | 19:16 |
| persia | But they will! See, routinely people ask "what can I do to work around having uploaded 1.2.3rc4-0ubuntu1~ppa1 to my repo". They are told they have to do something ugly, like 1.2.3release-0ubuntu1~ppa1". | 19:16 |
| persia | If they delete and upload 1.2.3-0ubuntu1~ppa1, which you've just said is possible, the users won't see the upgrade, and wil lbe unhappy. | 19:16 |
| persia | Explaining this to uploaders is significantly easier than explaining to users why they haven't been upgraded to the newest version. | 19:17 |
| persia | cprov, Well, there's no reason that the version number needs to be used to track that. If it's just a matter of internal convenience, that's fine, but that should be explicit, and issues should be considered bugs. | 19:18 |
| cprov | persia: not entirely a internal issue at this point, we are just trying to keep versions distinct w/o forcing unnecessary version bumps. | 19:20 |
| persia | Hrm? | 19:20 |
| cprov | persia: I agree, allowing old version is potentially wrong and will block updates | 19:20 |
| cprov | persia: but it's better then saying "you cannot do it, activate a new PPA." | 19:21 |
| persia | At the current point, a PPA is not very useful for someone trying to package something for review, because they can't recover from mistakes without mangling the version number. Apparently, it's not very useful for end-user distribution because it's easy to upload a version that won't get distributed. | 19:21 |
| persia | I'm not concerned which, but I'd like at least one of these use cases to work. | 19:21 |
| persia | The workaround for old versions for distribution is to use 1.2.0+really 1.1.7-0~ppa14 or something, just like for a normal archive. | 19:23 |
| persia | (or 1.2.0release to work around 1.2.0rc4) | 19:23 |
| persia | This enforces good practice in packagers who might later work with a distribution archive that enforces things. | 19:24 |
| persia | Alternately, drop the blacklist, and those that intend end-user distribution will have to take care to get it right. | 19:24 |
| cprov | persia: yes, both relaxed behaviour could work in the PPA context, I agree | 19:24 |
| cprov | persia: but look from the perspective of end-users, not really familiar with those nuances. | 19:25 |
| persia | I am. That's why I want *one* of the two use cases to work. | 19:25 |
| * persia looks up the relevant bug numbers for context | 19:26 | |
| cprov | persia: if you are really keen I prefer the later (simpler) use-case to work and thus avoiding poll overrides entirely | 19:27 |
| persia | Hmm. I can only find one of them. | 19:27 |
| cprov | persia: but in this case we would have to said a big *sorry* for ahasenack. | 19:28 |
| persia | cprov, which is the response he would have gotten if he asked in #ubuntu-motu (which happens a couple times a week) | 19:28 |
| persia | So, if we want to be end-user friendly, bug #263301 should be Won't Fix, and the blacklist should extend to all previous versions as well. | 19:29 |
| ubottu | Launchpad bug 263301 in soyuz "Can't re-upload a package with a different src tarball after deletion in PPA" [Undecided,New] https://launchpad.net/bugs/263301 | 19:29 |
| persia | If we want to be uploader friendly, that bug should be fixed, and end-users will suffer. | 19:29 |
| persia | I'm not sure which is the right answer : it depends on the goal for PPAs. I'm just annoyed at the current state. | 19:30 |
| cprov | persia: I agree, let's say 80% ;) | 19:31 |
| persia | cprov, And to be fair, I should say that most of the time I'm not annoyed at PPAs, and they can be very useful. | 19:31 |
| cprov | persia: I'd prefer a solution allowing bot use-cases to happen w/o being a configuration nightmare for users. | 19:32 |
| persia | In fact, the rumor that PPAs would only be available for developers is the primary reason I applied to be a developer. | 19:32 |
| persia | cprov, That would be ideal, but it's *really* hard. The only way I thought it might be done is to have it be selectable on a per-PPA basis, and try to have some warning to end-users when using a development PPA. | 19:33 |
| persia | Not sure how to implement that : if PPA signing worked, maybe by only signing PPAs that followed a strict versioning scheme? | 19:33 |
| cprov | persia: all PPA will be signed when signing-support is ready (fyi) | 19:34 |
| persia | I know that's the plan, I was just thinking of a possible variation to support both use cases. | 19:34 |
| cprov | persia: I've moved that bug to the soyuz pending milestone, so next week it will be discussed/scheduled | 19:35 |
| cprov | persia: maybe a clearer configuration option would be the best solution. | 19:35 |
| persia | I've been instructing uploaders who aren't sure to use 1.2.3~ppa4-0~ppa5 as a version when uploading to PPAs to be safe, but that's not ideal either. | 19:35 |
| persia | For the uploaders, I think configuration works. On the other hand, I think it's important to have some way of warning downloaders that a given PPA may not be a reliable distribution repository due to version skew. | 19:36 |
| persia | (unless it is decided that end-users don't matter, but that's not really ideal) | 19:37 |
| cprov | persia: ehe, no that's not good | 19:37 |
| persia | The only thing I can think of that will provide an alert to users that something is unreliable is not signing it, which is why I suggested not signing binaries from PPAs that didn't turn on version restrictions. | 19:39 |
| persia | For package review, the signatures aren't so important, as the reviewer is typically interested in the source package, rather than the binaries. | 19:39 |
| cprov | persia: let's discuss this with property next week. There are other issues in this area (archive behaviour configuration) that could be improved. | 19:39 |
| persia | (and the sources are signed anyway, to be accepted for upload) | 19:39 |
| persia | OK. Any specific timing? | 19:40 |
| cprov | persia: we will do a triage round on pending next week, and I will point that bug as a MOTU-concern. | 19:41 |
| persia | Which bug? 263301? | 19:42 |
| cprov | persia: yup | 19:42 |
| persia | I'm not at all certain that's a MOTU concern, as few MOTU are likely to take the set of actions required to be in that state (having experience with the regular archive). | 19:43 |
| persia | It's more of a concern for those just learning packaging. | 19:43 |
| cprov | persia: which usually end up requesting MOTU help to solve their issues, right ? | 19:44 |
| persia | Yeah, but MOTU have zero sympathy for anyone wanting to create a lower version, and most are likely to suggest the same workarounds that would be used in a normal repo, as those are the ones they use when in the same situation. | 19:45 |
| persia | As much as I'd like to have some sane workflows for review, I'm personally fairly happy with the idea of setting 263301 to Won't Fix, and enforcing the blacklist also for all previous versions. | 19:46 |
| cprov | persia: right, let's advocate that idea then. I'm also happier doing it. | 19:47 |
| persia | cprov, OK. Again, I'm not sure it's a "MOTU Concern", but I'm certainly happy to defend that viewpoint. | 19:48 |
| cprov | persia: great, let's do it :) | 19:49 |
| persia | OK. When? Where? | 19:50 |
| cprov | persia: comment the bug, I'll ping you next week. | 19:50 |
| persia | Beyond my already overlong diatribe? | 19:51 |
| cprov | persia: you haven't said you want it won't-fix, have you ? | 19:53 |
| persia | Well, no, because when I complained about it here last time, I was told that supporting developers trying to learn to package was a sufficiently important goal : that's why my comment is about balance. | 19:54 |
| persia | On the other hand, my last paragraph is fairly negative. | 19:55 |
| bryce | can I ask launchpadlib questions here? | 20:30 |
| persia | bryce: leonardr usually has the answers | 20:30 |
| bryce | leonardr: I want to print the source packages that a team is subscribed to. I.e., the left column at https://edge.launchpad.net/~ubuntu-x-swat/+packagebugs | 20:32 |
| bryce | leonardr: how might I do this with launchpadlib? I'm browsing the api doc but it's not evident what to do | 20:32 |
| leonardr | bryce, i don't think that has been published yet. if it were published it would show up as a link from the team | 20:37 |
| leonardr | maybe bac has more info | 20:37 |
| bac | leonardr, bryce: sorry, not off the top of my head. | 20:39 |
| * bac digs | 20:39 | |
| leonardr | bac: it's possible it's not a relationship expressed in the schema | 20:39 |
| leonardr | only expressed in the ui, so we didn't pick up on it | 20:39 |
| persia | Are there many relationships like that? | 20:40 |
| leonardr | persia, i don't know, since by definition it's something we missed | 20:40 |
| bryce | hrm, pitty | 20:40 |
| leonardr | but it has to show up somewhere in the code | 20:41 |
| persia | leonardr, heh. Understood :) | 20:41 |
| bac | bryce, leonardr: not to pass the buck, but these are methods we'll need to get the bugs team to export to the API | 20:47 |
| bac | bryce if you could open a bug stating the need it would be helpful. | 20:48 |
| bryce | bac: ok, against launchpadlib, or a different project? | 20:58 |
| bac | bryce: just launchpad | 21:28 |
| bryce | bac: lp #281443 | 21:34 |
| ubottu | Launchpad bug 281443 in launchpadlib "Need api call to get source packages a team is subscribed to" [Undecided,New] https://launchpad.net/bugs/281443 | 21:34 |
| bac | thanks | 21:34 |
| bryce | yep thanks too. back to the drawing board for me... | 21:35 |
| bryce | cya | 21:35 |
| bryce | I posted the screenscraper I'm using to 281443. I'll try using that for now. | 21:47 |
| cprov | matsubara: alright, PQM have another non-loom branch with my changes. | 21:59 |
| matsubara | cprov: thanks | 22:01 |
| cprov | matsubara: thank you | 22:01 |
| === gary_poster changed the topic of #launchpad to: https://launchpad.net/ | Channel logs: http://irclogs.ubuntu.com | https://help.launchpad.net/HelpRotation | Community help contact: - | ||
| exarkun | Hey, can someone tell me about https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/18885 | 23:31 |
| ubottu | Launchpad bug 18885 in twisted "documentation lacks a TDD example." [Low,Confirmed] | 23:31 |
| beuno | exarkun, what's up with it? | 23:32 |
| exarkun | It's associated with a bug in an upstream tracker, twistedmatrix.com/bugs/, #1148 | 23:32 |
| exarkun | and it says "auto-twistedmatrix.com #1148" | 23:32 |
| exarkun | and if I expand the Twisted bug, then there's a nice pink error dialog | 23:32 |
| exarkun | http://twistedmatrix.com/bugs/ is actually a years out of date URL to our issue tracker | 23:33 |
| beuno | exarkun, so you've moved somewere else? | 23:33 |
| exarkun | beuno: yes, and we're even running the launchpad/trac integration plugin | 23:34 |
| beuno | exarkun, can you change the URL to the new tracker? | 23:35 |
| exarkun | Sure, if that's the best thing to do | 23:35 |
| beuno | yeap, it's just still associated with the old bug tracker | 23:36 |
| exarkun | and then for my own edification, what's the significance of something like "auto-twistedmatrix.com #1148" in "Remote bug watches"? (specifically the "auto" part) | 23:37 |
| beuno | that's a great question | 23:38 |
| beuno | I don't know :) | 23:38 |
| beuno | it's friday evening, all the developers have fled | 23:38 |
| exarkun | heh, alright :) | 23:39 |
| wgrant | exarkun, beuno: auto just means that it was automatically created by somebody adding a bug watch with an unknown URL. | 23:42 |
| beuno | there ya' go, good old wgrant to the rescue | 23:43 |
| exarkun | wgrant: thanks | 23:43 |
| wgrant | np | 23:43 |
| === cj is now known as da_man | ||
| === da_man is now known as cj | ||
| Rinchen | exarkun, I'm aware of the issue | 23:52 |
| Rinchen | exarkun, there's a patch for it already but I'll pass this example up | 23:53 |
| Rinchen | exarkun, as far as the lp-trac import failures. Do you need help changing the location? | 23:54 |
| exarkun | I think I succeeded in changing the location | 23:54 |
| exarkun | I just entered a new URL and it seems to be using that now | 23:54 |
| Rinchen | exarkun, I forwarded it over to another dev to peek at on Monday. If it's still broken he'll investigate | 23:56 |
| exarkun | Rinchen: Cool, thanks | 23:57 |
| Rinchen | if you've readjusted the import location though exarkun then it should be fixed overnight as your batch jobs run | 23:58 |
| wgrant | Isn't that much more frequent now? | 23:58 |
| Rinchen | it is | 23:59 |
| Rinchen | oh exarkun btw, I think this is bug 278276 | 23:59 |
| ubottu | Launchpad bug 278276 in malone "Launchpad drops the trac-auth cookie when authenticating with LP Plugin enabled Tracs" [High,Fix committed] https://launchpad.net/bugs/278276 | 23:59 |
| wgrant | Or is that only for new ones, not changed? | 23:59 |
| Rinchen | bugs vs imports wgrant ... bug checks are run at regularly intervals | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!