| === Ursinha is now known as Ursinhaway | ||
| milos_ | hi all :) | 01:29 |
|---|---|---|
| milos_ | i have a question about uploading translations to launchpad which is: | 01:31 |
| milos_ | is it better to translate a part of package and then upload it, and do that until the hole thing is done. Or The other way, translate the hole package and then upload it. | 01:35 |
| Rinchen | milos_, you mean translate locally vs in Launchpad? | 01:38 |
| Rinchen | milos_, btw you can also ask on #ubuntu-translators if it's an ubuntu package | 01:39 |
| Rinchen | btw I'm recycling bip so I'll be offline a bit | 01:39 |
| Rinchen | milos_, but basically, it probably doesn't matter either way. | 01:39 |
| milos_ | no, i mean just locally. I wanted to ask, is it better to translate the hole package and upload it when it's done, or upload it periodically as the translation goes. | 01:41 |
| Rinchen | milos_, doesn't really matter I suppose. The best way is probably to do it all at once | 01:43 |
| Rinchen | milos_, if you were using LP for translations then periodically is better since others might be helping you | 01:44 |
| Rinchen | milos_, so you could download the latest, translate, and then upload a revised version | 01:44 |
| Rinchen | milos_, but if you are doing it outside of LP then all at once will be easiest | 01:44 |
| milos_ | Rinchen, I am thinking about that because I am translating a huge package (dpkg) but I don't want to bore launchpad admins too much. So I like translate online on LP but if I do it a lot, the offline is the better way for me because LP is sometimes pretty slow. | 01:50 |
| Rinchen | milos_, ah. dpkg's translations are taken from upstream, in this case debian. https://edge.launchpad.net/dpkg is the local ubuntu package | 01:52 |
| Rinchen | so for dpkg, it's best to do that in debian | 01:52 |
| milos_ | Rinchen, ok thnx | 01:53 |
| milos_ | Rinchen, one time I was translating one bigger package with Gtranslator and after I uploading it, some developers told me that they can't use it because some data is missing. So later I have find out that there was a bug in Gtranslator which was responsible for that. That moved me to online translating. | 02:02 |
| Rinchen | milos_, yeah, me too. I ran the ubuntu esperanto translator group since inception until just a month ago | 02:03 |
| Rinchen | milos_, so online translating is the way to go | 02:03 |
| beuno | and you get to translate in multiplayer mode! | 02:04 |
| milos_ | beuno, that's magical :) | 02:04 |
| LaserJock | persia: so what exactly is the purpose of signing the archive? | 06:41 |
| LaserJock | is it just to say that the package came from the archive you think it did? | 06:41 |
| persia | LaserJock: If an archive is signed, and the user trusts the signing key, the user (and by proxy software on the user workstation) can verify checksums for the downloaded packages, making package substitution significantly more difficult. | 06:42 |
| persia | If the individual packages are signed, and the user trusts the signing key, the user can confirm that the downloaded package is certified as correct by the signer. | 06:42 |
| persia | This further makes package substitution more difficult. By combining the two, one ends up with a *very* difficult problem if an attacker wishes to insert e.g. rm -rf / in the preinstl. | 06:43 |
| LaserJock | hmm, but how could that be done in Launchpad? | 06:44 |
| persia | In most cases, it would be simpler to compromise the keys than work around the signing checksums. If the keys are sufficiently complex, this gets very, very expensive. | 06:44 |
| wgrant | LaserJock: If the archive is unsigned, you are trusting that nobody has managed to carry out attacks on DNS, your routing, your proxy, or anything else. | 06:44 |
| LaserJock | wgrant: right, I think I've got that part | 06:44 |
| persia | (it might not even be a real attack, just misconfiguration of a nameserver or proxy server) | 06:45 |
| wgrant | LaserJock: If you are relying solely on those and I happen to reroute your packets through me, I can insert my own evil package and you will be none the wiser... how is that not a big problem? | 06:45 |
| persia | Currently, apt refuses to follow 301 redirects due to issues with some proxy servers: this is componded in a network composed of many transparent proxies. | 06:45 |
| LaserJock | wgrant: well, I personally don't worry about that, but somebody should :-) | 06:46 |
| wgrant | LaserJock: You don't care that people can fairly easily get root access to your system? | 06:46 |
| LaserJock | I would guess that if somebody is rerouting my packets then they've got other things they can do besides whipping up an evil package | 06:47 |
| LaserJock | so while I'm not saying it's not a problem, it's currently something I'm willing to put up with until it gets fixed | 06:47 |
| wgrant | You're OK to do, say, Internet banking over plain HTTP? | 06:48 |
| LaserJock | not so much no | 06:48 |
| LaserJock | but I don't have to worry about that | 06:48 |
| wgrant | It's the same, except that if I have root on your systems I get all of your details and passwords, not just those you send over HTTP. | 06:49 |
| LaserJock | as my bank uses https and my browser handles it seamlessly | 06:49 |
| LaserJock | so *I* don't worry about it | 06:49 |
| LaserJock | *somebody* should | 06:49 |
| LaserJock | as an ordinary user I can't be tracking down every attack vector | 06:50 |
| persia | LaserJock: Right, somebody should, and they should mask the details from you. While https isn't foolproof, it makes it cost somewhere in the vicinity of $250,000 US to hack your connection, so it's generally not worth doing. This is the same thing for package control. | 06:50 |
| LaserJock | so I either unplug my computer from the net or I make a somewhat calculated risk | 06:50 |
| persia | Imagine the scenario where an ISP would like to get more information about a customer's internal plans to migrate to a different ISP. That's the sort of thing that this protects. | 06:51 |
| wgrant | LaserJock: Which is why service providers like Launchpad should give minimisation of attack vectors utmost importance. | 06:51 |
| LaserJock | wgrant: for sure, I'm not denying that | 06:51 |
| LaserJock | the original statement was about ddeb.ubuntu.com, which I've only installed maybe 3 packages from ever | 06:52 |
| wgrant | If they don't do that, you have to. | 06:52 |
| wgrant | This is true. | 06:52 |
| LaserJock | for Launchpad I do use it regularly so it is a much bigger issue to me | 06:52 |
| LaserJock | especially as it's centralized | 06:52 |
| LaserJock | you could cast a rather large net spoofing LP | 06:53 |
| wgrant | Mhm. | 06:53 |
| wgrant | You've just got to get one IP address or A record under your control, set up an appropriate HTTP server, and you win numerous systems easily. | 06:54 |
| persia | Not even that, you just need a proxy on a chunk of the trunk, or DNS control over some set of networks. | 06:55 |
| wgrant | True, but that won't get you everone. | 06:55 |
| wgrant | *everyone | 06:55 |
| persia | One rarely needs *everyone*. Just getting a couple thousand is often enough to do more interesting things. | 06:57 |
| LaserJock | now, unsigned PPAs was sort of sold in the beginning as a way to dissuade people from just installing random packages | 06:57 |
| persia | LaserJock: Hmm. Interesting point. | 06:57 |
| LaserJock | but we also use PPAs for more "official" uses | 06:58 |
| persia | Perhaps we oughtn't? | 06:58 |
| wgrant | ubuntu-mobile is one of the larger perpetrators, no? | 06:59 |
| LaserJock | so I've not been sure of the right balance between making PPAs easy/safe to use and not driving people away from getting packages into the Ubuntu archives | 06:59 |
| LaserJock | currently there about as many PPA source packages as Main source packages | 06:59 |
| persia | ubuntu-mobile moved the PPA stuff to the signed archive.mobile.ubuntu.com, after verifying the packages were clean. I'm fairly sure that the PPA experiment will not be repeated. | 07:01 |
| LaserJock | 983 active PPAs, 5391 published sources, 24290 published binaries | 07:01 |
| wgrant | persia: Good to know. | 07:01 |
| LaserJock | though a significant chunk is from the lang pack PPA | 07:01 |
| persia | That shouldn't be a PPA either :) | 07:02 |
| LaserJock | and lots of KDE4 packages :-) | 07:02 |
| LaserJock | well, why shouldn't they be in PPAs | 07:02 |
| LaserJock | <devil's advocate> if the technology exists, why not use it? </devil's advocate> | 07:03 |
| wgrant | The langpack PPA is just used for builds, isn't it? | 07:03 |
| LaserJock | and tests | 07:03 |
| LaserJock | then they get moved to -updates | 07:04 |
| persia | I'd think that if something was intended for the archives, it would make sense to upload it to the archives. | 07:07 |
| LaserJock | well, most of they time they're used for staging | 07:07 |
| LaserJock | or backporting | 07:08 |
| persia | Isn't that why there is -proposed and -backports? | 07:08 |
| LaserJock | not exactly | 07:08 |
| LaserJock | a lot of stuff won't make it into -backports | 07:09 |
| LaserJock | and the staging is often to get targeted testing before -proposed or development archive | 07:09 |
| persia | I thought anything that had two testers with positive reports and no negative reports went into backports. | 07:09 |
| LaserJock | no | 07:10 |
| LaserJock | library backports are often unlikely | 07:10 |
| LaserJock | at least that's my understanding and how I use my PPA | 07:10 |
| LaserJock | to either backport or let people test stuff on a stable release before putting it into the development release | 07:11 |
| === mcasadevall_ is now known as NCommander | ||
| qense | I've got a question about the authentication of an API connection. Does the user have to give acces everytime the software wants to connect? | 14:30 |
| kiko | qense, not exactly -- I believe you generate a token and can reuse that across sessions. | 14:37 |
| kiko | qense, have you looked at the howto? | 14:37 |
| qense | Yes I am, but I can | 14:37 |
| qense | 't | 14:37 |
| qense | find that much information about this. | 14:37 |
| kiko | qense, tell me more | 14:37 |
| qense | Can you store a key in the database and reuse it? | 14:38 |
| kiko | we do | 14:38 |
| qense | OK, that's nice. | 14:38 |
| qense | You just need to check if the user has already giver permission. | 14:38 |
| qense | How can the user change the permissions he gave to a client? | 14:39 |
| kiko | I'm not sure exactly what you mean | 14:39 |
| qense | When the user need to authenticate a client, (s)he gives rights to that client. | 14:40 |
| qense | How can the use change that? | 14:41 |
| qense | Do you have to authenticate the client again? | 14:42 |
| kiko | that's what I'm thinking | 14:43 |
| kiko | how else could it work? I mean, is there anything else you'd expect? | 14:43 |
| qense | not really now I think again | 14:44 |
| qense | Anyway, thanks for your help. | 14:44 |
| kiko | heh, not much help I could get you :) | 14:45 |
| qense | I'm working on a PHP lib to make accessing the API easier so we can use it with Ubuntu Wanted, which is going to use Drupal 5. | 14:45 |
| qense | There isn't a PHP lib yet, is it? | 14:45 |
| kiko | not yet! that's very neat. | 14:47 |
| kiko | is there a WADL library for php? | 14:47 |
| qense | Not that I know. | 14:50 |
| qense | Isn't that similar to JSON? | 14:50 |
| kiko | that would save a lot of effort! | 14:50 |
| qense | There is a JSON implementation for PHP by default. | 14:51 |
| kiko | well, WADL would allow you to auto-generate the library | 14:51 |
| qense | That would indeed be neat. | 14:51 |
| kiko | because it is a machine-readable description of the API | 14:51 |
| kiko | check out wadllib that leonardr wrote | 14:51 |
| kiko | you'll see how it works | 14:51 |
| kiko | and then launchpadlib just hooks into that | 14:51 |
| qense | I'm sure going to check it out! | 14:51 |
| kiko | real easy | 14:51 |
| kiko | the true advantage is that the library is always up to date | 14:51 |
| qense | yeah | 14:51 |
| kiko | no matter if you are talking to edge or lpnet or staging | 14:52 |
| qense | Using the current approach I'd need to update it often | 14:52 |
| kiko | (which may have different version of the API there) | 14:52 |
| kiko | right | 14:52 |
| persia | Also, it means you can likely deploy safely in a static environment and still track lpnet when it changes every month. | 14:52 |
| qense | Not all users want to update every month | 14:52 |
| persia | qense: lpnet updates on roughly the 20th of every month. | 14:53 |
| persia | (users don't really have the option) | 14:53 |
| qense | I meant users of the lib. | 14:53 |
| persia | RIght, which is why you want WADL :) | 14:53 |
| qense | yeah | 14:53 |
| qense | I think REST could be interesting for me, if I've understood the blog posts right it's some kind of compiler for functions that uses WADL | 15:17 |
| qense | Is there any known documentation for wadllib? | 17:27 |
| elmargol | I try to copy a package from my ppa to an other ppa. it fails "source has unpublished binaries, please wait for them to be published before copying" < status = published | 18:00 |
| elmargol | it works if you just wait a bit longer | 18:00 |
| mrooney | okay so I've done this before, I *should* be able to figure this out, but I can't :) | 19:14 |
| mrooney | when I create a new project on LP, how do I put code there | 19:14 |
| mrooney | I have https://code.launchpad.net/~michael/ecryptfs-gui/trunk | 19:14 |
| LarstiQ | bzr push? | 19:14 |
| beuno | mrooney, bzr push lp:~michael/ecryptfs-gui/trunk | 19:15 |
| beuno | mrooney, if you just push, the branch gets created automatically. You don't need to use the UI to create it | 19:15 |
| mrooney | you would think that! | 19:15 |
| mrooney | ooh wait I see | 19:15 |
| mrooney | I can't just push to lp:ecryptfs-gui | 19:16 |
| beuno | mrooney, you can, if you set that as the default branch for the project | 19:16 |
| mrooney | beuno: and I tried what you said before, but I had forgotten to commit my local version first | 19:16 |
| mrooney | thanks! | 19:16 |
| mrooney | beuno: yeah, I tried to do that, but it brings up a search dialog that searches all of launchpad I guess | 19:16 |
| mrooney | is there an easier way? | 19:17 |
| beuno | mrooney, unfortunately, not at the moment. We're working on it :) | 19:17 |
| LarstiQ | mrooney: you should be able to input ~michael/encryptfs-gui/trunk though? | 19:17 |
| beuno | yeah, punching in that will add the branch | 19:18 |
| beuno | the search is just if you need to hunt it down | 19:18 |
| mrooney | okay, I assume I need the --use-existing-dir option? | 19:18 |
| beuno | mrooney, yes, if you register the branch in LP first, you do | 19:18 |
| mrooney | beuno: oh okay, is a better way to just create the project and then push to it? | 19:19 |
| beuno | mrooney, yeap, less steps | 19:19 |
| mrooney | beuno: cool, thanks, I didn't know that | 19:19 |
| mrooney | thanks for your help! | 19:19 |
| beuno | mrooney, happy to help | 19:19 |
| mrooney | sorry I forgot everything :P | 19:19 |
| beuno | hahaha | 19:20 |
| mrooney | I did it for another project 6 months ago or so, but the process was probably different | 19:20 |
| mrooney | launchpad is evolving and improving at a pretty rapid rate | 19:20 |
| beuno | yeah, it's hard to keep up :) | 19:20 |
| === edcrypt1 is now known as edcrypt | ||
| gour | hello | 20:54 |
| gour | how can i relate team to the project? | 20:55 |
| gour | or vice versa | 20:55 |
| edcrypt | gour: there is a "Project Driver" where you can assign either a user or a team | 21:00 |
| edcrypt | gour: don't remenber if there is another way | 21:01 |
| jpds | gour: You can try the projects: /+edit-people people page and change the owner to the team. | 21:07 |
| gour | let me try... | 21:09 |
| gour | jpds: thanks. configured team as driver of the project | 21:12 |
| jpds | edcrypt: ^ | 21:12 |
| edcrypt | gour: you're welcome. | 21:15 |
| gour | thank you. LP is really great | 21:16 |
| edcrypt | indeed :) | 21:25 |
| mtaylor | sigh | 22:21 |
| * mtaylor wishes launchpad would mark merge requests as merged once they are merged automatically | 22:21 | |
| mrooney | Okay, now I'm back with a new project, and want to do it the "right" and easy way. I created a fresh bzr branch using "init" added the files and committed, but just doing "bzr push lp:projectname" doesn't seem to work | 23:04 |
| mrooney | I've tried lp:projectname/trunk, and lp:~michael/projectname, and lp:~michael/projectname/trunk | 23:05 |
| mrooney | now I am befuddled | 23:05 |
| Peng_ | Have you created the project on LP? | 23:05 |
| mrooney | correct, yes | 23:05 |
| mrooney | and I was told the easiest way is to have it auto-create the branch for me | 23:05 |
| Peng_ | What error do you get? | 23:05 |
| mrooney | Peng_: here is what I have tried: http://dpaste.com/71893/ | 23:07 |
| Peng_ | mrooney: You should use "lp:~michael/eeebotu/trunk", not "lp:~/michael/eeebotu/trunk" | 23:07 |
| mrooney | Peng_: ahh okay, and I do want to specify a branch name of trunk? | 23:08 |
| Peng_ | You can use whatever name you want. "trunk" is common. | 23:08 |
| mrooney | it won't autocreate it, autoname it, AND associate it as the default branch? :] | 23:08 |
| Peng_ | Yeah, you'll have to set it as the default branch yourself. | 23:09 |
| mrooney | it would be kind of slick if bzr push lp:~/michael/eeebotu created a branch with a default name, say 'trunk', set it as the default, and pushed | 23:09 |
| mrooney | but that might be too implicit | 23:10 |
| Peng_ | I agree on both counts. It would be slick, but it is pretty implicit. | 23:10 |
| Peng_ | You could see what the LP people think. | 23:10 |
| Peng_ | Anyway, I'm gonna go. Good luck. :) | 23:11 |
| mrooney | Peng_: okay, after fixing my dumb typo as you noticed, it worked great, thanks so much! | 23:12 |
| Peng_ | Great. :) | 23:12 |
| * Peng_ really leaves. | 23:12 | |
| mrooney | :] | 23:12 |
| === emgent is now known as emgent` | ||
| === emgent` is now known as emgent | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!