| === lifeless_ is now known as lifeless | ||
| === bjf is now known as bjf[afk] | ||
| treaves | If I've created a branch from a project from within launchpad, how do I pull that down to my local machine? | 01:47 |
|---|---|---|
| treaves | If I use 'bzr branch lp:~path/to/branch' I get an error: 'bzr: ERROR: Not a branch:' | 01:48 |
| wgrant | treaves: The 'Register branch' option will create a new empty branch -- probably not what you want. | 01:49 |
| treaves | Ah. | 01:49 |
| treaves | Um... | 01:49 |
| wgrant | Normally you just 'bzr branch lp:PROJECT', then do some work, then 'bzr push lp:~USER/PROJECT/BRANCH' | 01:49 |
| treaves | what use is an empty branch to anyone? | 01:49 |
| wgrant | It will create the branch if it doesn't exist. | 01:49 |
| wgrant | Right, many feel that the option should be removed. | 01:49 |
| wgrant | But it's occasionally useful. | 01:50 |
| treaves | Will PROJECT be treated as a shared repository? | 01:50 |
| wgrant | But normally you shouldn't be using that. | 01:50 |
| wgrant | Launchpad doesn't do shared repositories. It uses stacking instead. | 01:50 |
| wgrant | So you'll only have to upload revisions that aren't already in the project's development focus branch. | 01:50 |
| treaves | So all of the data gets uploaded, with full revision history? | 01:50 |
| wgrant | No. It shares data with the development focus branch, so you normally only upload your new revisions. | 01:51 |
| wgrant | (the full revision history is still accessible. it's just accessed through a reference to another branch) | 01:52 |
| treaves | So if I create a local branch in a new repository, and push with no changes made, what gets uploaded? | 01:52 |
| wgrant | Not much. | 01:52 |
| treaves | I'm getting more than 70 thousand objects uploaded! | 01:52 |
| wgrant | Probably just a reference to the development focus branch, and a specifier of the latest revision. | 01:52 |
| wgrant | No actual revision data. | 01:52 |
| wgrant | Which project? | 01:52 |
| treaves | stellarium | 01:52 |
| treaves | We just switched from svn. | 01:52 |
| treaves | :) | 01:52 |
| wgrant | Ah, so it's possible you haven't quite got it set up properly yet. | 01:53 |
| wgrant | Lets see. | 01:53 |
| treaves | Ya, I wouldn't be surprised at all. | 01:54 |
| treaves | We're trying, but, learning curve and all. | 01:54 |
| wgrant | How did you create the local branch? | 01:54 |
| wgrant | bzr branch lp:stellarium? | 01:54 |
| treaves | On my local machine, | 01:55 |
| treaves | I created a shared repository with the init command. | 01:55 |
| wgrant | init, or init-repo? | 01:55 |
| treaves | I pulled down trunk (bzr branch lp:stellarium) | 01:55 |
| treaves | init-repo | 01:55 |
| treaves | then, in the shared directory, I did 'bzr branch trunk mybranch' | 01:55 |
| wgrant | Which version of bzr are you using? | 01:56 |
| treaves | On my local machine? | 01:57 |
| wgrant | Yes. | 01:57 |
| treaves | 2.2b3 | 01:58 |
| treaves | The first push I do gives an error: | 01:58 |
| wgrant | Ah. | 01:58 |
| wgrant | Different repository formats, maybe. | 01:58 |
| treaves | Yes. | 01:58 |
| treaves | We need to upgrade launchpad's version. | 01:58 |
| treaves | Could that be the issue? | 01:58 |
| wgrant | I noticed that your LP trunk is using an old format, pack-0.92. | 01:59 |
| wgrant | 2a is much faster and smaller, and it's the default in newer versions. | 01:59 |
| treaves | So if I just click upgrade on the site, that'll take care of that part? | 01:59 |
| wgrant | If everyone is using a recent version of bzr (2.0 or later is good), you should upgrade to that. Particular before you start getting lots of branches in the old format. | 01:59 |
| wgrant | It should, yes. | 01:59 |
| wgrant | If you've just recently changed and nobody is using it much yet, now is probably a perfect time. | 02:00 |
| treaves | Let me give that a try... | 02:00 |
| treaves | Does the process take long? | 02:00 |
| wgrant | It really depends on the branch. | 02:01 |
| wgrant | How big is it? | 02:01 |
| wgrant | I've checked out 100MB so far. | 02:01 |
| treaves | It's not too much bigger... | 02:01 |
| treaves | Not sure off the top of my head. | 02:01 |
| wgrant | So you said the first push failed with a repository incompatibility error? | 02:01 |
| wgrant | That would explain why it's pushing it all up. | 02:02 |
| treaves | O.K. | 02:02 |
| wgrant | So once it's upgraded on LP, you should be able to push up a new branch quickly. | 02:02 |
| wgrant | And everything should be a heap faster. | 02:03 |
| treaves | Thanks for your help. Here's hoping! | 02:03 |
| treaves | When someone is subscribed to a branch in lp, what does that mean? | 02:05 |
| wgrant | You can get notifications about merge proposals and new revisions (with diffs, if you want them). | 02:06 |
| wgrant | How long did it take to branch lp:stellarium into your shared repo? | 02:08 |
| wgrant | That was doing a conversion on-the-fly, so it will give us some idea of how long it will take. | 02:08 |
| treaves | A few seconds. | 02:10 |
| treaves | Will the local branches upgrade when a pull is done? (to the new format) | 02:10 |
| wgrant | Your branches are already 2a. | 02:11 |
| treaves | Ah. | 02:11 |
| treaves | O.K. | 02:11 |
| treaves | Done on the server. | 02:11 |
| wgrant | Anybody else should probably either 'bzr upgrade' or branch it again. The latter will probably be quicker. | 02:11 |
| treaves | trying new push... | 02:11 |
| treaves | Wow! | 02:11 |
| wgrant | Make sure you push to a new location, or delete the old branch first. | 02:11 |
| treaves | I deleted the old one. | 02:12 |
| treaves | That was lightning fast! | 02:12 |
| wgrant | Yeah, it works better when you don't have to upload a couple of hundred megabytes. | 02:12 |
| treaves | Exactly. | 02:12 |
| treaves | Again, thanks for your help. I really appreciate it. | 02:12 |
| wgrant | Let's see how much smaller the 2a version is... | 02:15 |
| bullgard4 | Damn! Timeout error: "Sorry, something just went wrong in Launchpad. We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience. Trying again in a couple of minutes might work. (Error ID: OOPS-1631L143)" | 03:08 |
| ubot5 | https://lp-oops.canonical.com/oops.py/?oopsid=1631L143 | 03:08 |
| cutout | Hello is it possible to install launchpad on a local server for private use? if yes how? is ithere .deb package or something? | 05:44 |
| cutout | anyone here? | 05:50 |
| mmc | if I dput in my ppa, I am told that it has been already uploaded (and I agree), yet I don't see any package on the web page (of the PPA). | 10:04 |
| wgrant | mmc: That's just a local check that dput performs (it looks for the *.upload file). It doesn't mean that it was accepted into your PPA. | 10:17 |
| wgrant | Do you have an email about it? | 10:17 |
| wgrant | If you signed the package properly, you should have received an email of acceptance or rejection within five minutes of the upload. | 10:18 |
| mmc | wgrant: ok, I have now configured ~/dput.cf and now I get: " {checks on pgp key....} Successfully uploaded packages." Ok, I will wait for the email | 10:22 |
| eagles0513875 | wgrant: how can i disable a key which is linked to my profile on lp | 10:45 |
| Kangarooo | how can i read in LP some teams email List archive? | 10:48 |
| wgrant | eagles0513875: Visit https://launchpad.net/people/+me/+editgpgkeys | 10:50 |
| wgrant | Select the key, and click 'Deactivate Key'. | 10:50 |
| eagles0513875 | wgrant: i get a page not found | 10:50 |
| wgrant | Er. https://launchpad.net/people/+me/+editpgpkeys | 10:50 |
| eagles0513875 | wgrant: strange cuz they moved the link to do that from my profile for some reason | 10:51 |
| wgrant | eagles0513875: The edit link next to the keys on your profile page. | 10:51 |
| eagles0513875 | i didnt have that | 10:52 |
| wgrant | There's no link there? | 10:52 |
| eagles0513875 | no | 10:52 |
| eagles0513875 | which tbh wiht you wgrant i found super odd as well | 10:53 |
| geser | you don't have a pencil next to "OpenPGP keys" in your LP profile page? (you need to be logged in) | 10:58 |
| eagles0513875 | geser: i am logged in and no i dont | 10:59 |
| eagles0513875 | geser: and wgrant turns out its a bug in konqueror | 11:00 |
| wgrant | Ah, yes, Konqueror. | 11:01 |
| gspr | I can't find my way back to the help page that says which licenses are OK for software in PPAs. Can anybody point me in the right direction? I know this page existed when the PPAs were announced... | 11:01 |
| wgrant | It fails to render the icons sometimes. | 11:01 |
| wgrant | gspr: https://help.launchpad.net/PPATermsofUse | 11:01 |
| gspr | wgrant: Thanks man | 11:02 |
| eagles0513875 | wgrant: i normally use firefox but sometimes ff is a pita | 11:03 |
| geser | is https://edge.launchpad.net/ubuntu/+source/mozart/1.4.0-5build1/+build/1776421 broken? it started 4 hours ago and still no "live" buildlog? (the last mozart build on sparc took only 32 min) | 12:02 |
| === bdrung__ is now known as bdrung | ||
| mmc | how should I mark, that my modification of base package is dependendent on another my modification of another base package? Can it be done only by using suitable version strings? | 13:54 |
| mmc | let's say I have input drivers for Xorg, which can compile only with my modification of Xorg server. | 13:55 |
| mmc | (and my plan was to use them by giving priority the my PPA repo.) | 13:55 |
| tsimpson | mmc: the version is the correct way, just add a Depends: you_package (= your_specific_version) | 13:58 |
| tsimpson | mmc: you're better off asking in #ubuntu-motu though | 13:58 |
| === G is now known as Nigel | ||
| Kangarooo | how can i read in LP some teams email List archive? | 17:19 |
| === yofel_ is now known as yofel | ||
| geser | lamont: dare you to kick artigas? It looks stuck: https://edge.launchpad.net/builders/artigas | 17:41 |
| KungFuJesus | Why on earth does a fix upstream cause the bug to close in launchpad? | 20:09 |
| KungFuJesus | it doesn't make any sense if the fix doesn't collect downstream | 20:19 |
| === EdwinGrubbs changed the topic of #launchpad to: http://launchpad.net/ : PPA publishing is back up | Read https://help.launchpad.net/ for help | Help contact: - | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/ | ||
| MrKanister | KungFuJesus: Which bug do you mean? | 20:27 |
| KungFuJesus | one sec | 20:45 |
| KungFuJesus | MrKanister: this bug: https://bugs.launchpad.net/kdegraphics/+bug/596327 | 20:45 |
| ubot5 | Launchpad bug 596327 in KDE Graphics "Digikam imports images taken with Nikon Cameras extremely slow, takes a large amount of time processing exif data (affected: 1, heat: 6)" [Undecided,New] | 20:45 |
| KungFuJesus | as you can see, it's been fixed upstream and the remote bug tracker finds that. "Fixed Released" I'm assuming means that it knows the bug is fixed upstream. That however does not correspond to downstream, as Ubuntu is still using the broken and data version of that library | 20:46 |
| KungFuJesus | So I went ahead and added another affected package (which needs to be recompiled against the newer libraries, anyway) and left it as "new" not "Fix Released" | 20:46 |
| MrKanister | It seem you accidentally set the downstream status to "Fix Released" by yourself | 20:49 |
| KungFuJesus | no, I did that for upstream. That doesn't apply to upstream? | 20:50 |
| MrKanister | "exiv (Ubuntu)" represent the downstream package and with comment #4 you changed its status | 20:50 |
| KungFuJesus | ahhh, gotcha | 20:50 |
| === easter_egg is now known as ayrton | ||
| MrKanister | the two others tasks "KDE Graphics" and "digiKam" represent upstream tasks and one of those has an upstream link which updates the status from upstream | 20:51 |
| KungFuJesus | well how do I indicate that it has been fixed upstream and just needs the packages to be synced to a newer version? Is there anyway to convince them to do it outside of debian's packages? The debian version contains bugs as well | 20:51 |
| MrKanister | The appropriate status for the ubuntu task is "Triaged" | 20:52 |
| KungFuJesus | ok so change exiv2's status to triaged? | 20:52 |
| MrKanister | this means it has all information for a developer to fix a bug and it stays that way until the fix is released to ubuntu | 20:52 |
| MrKanister | yes | 20:52 |
| MrKanister | you might lack the right to do that. If so I can do it | 20:53 |
| KungFuJesus | triage is greyed out | 20:53 |
| KungFuJesus | plz do :) | 20:53 |
| MrKanister | done | 20:53 |
| KungFuJesus | been wanting to import images for a while but can't do so without it taking 8 hours | 20:53 |
| MrKanister | by the way, if there is already a bug report upstream, there is no need to open another report in launchpad | 20:54 |
| KungFuJesus | then how will the Ubuntu team know that it is a problem that affects them in their currently dated version? | 20:54 |
| MrKanister | ok, if your aim is to get the update into an already released version of Ubuntu, then it's correct to open a bug report | 20:55 |
| KungFuJesus | yep :). Man I hope they fix this bug soon | 20:56 |
| KungFuJesus | err well update the libs in the current package repo, anyway. libkexiv is not an easy drop in upgrade if you try to use the package manager. The only solution I can think of is to recompile all of kdegraphics into /usr/local/lib and then force a new ldpath when loading digikam. But that is a pretty painful task | 20:57 |
| MrKanister | well, there are updates of greater importance, but you might have luck and someone feels this is important enough to get fixed | 20:57 |
| === ayrton is now known as easter_egg | ||
| KungFuJesus | it's just such an easy fix, if I had commit access I'd do it myself. I'd even build the packages assuming they don't inject any special patches | 20:58 |
| MrKanister | It does not depent on whether it's easy or not, but (especially for a LTS release that Ubuntu 10.04 is) whether it's safe to upgrade | 21:00 |
| MrKanister | A bug introduced by a stable update is often worse than the bug itself | 21:00 |
| MrKanister | * the original bug | 21:00 |
| KungFuJesus | well considering how many cameras this affects it makes kde based applications which utilize exif data to be pretty unbearable | 21:02 |
| KungFuJesus | I say if the tool becomes useless it's a pretty big problem. Now granted there should be some careful testing of the security implications of an update, but I would hardly say that the current libexiv2 in the package repo is "stable". Prior versions of that package would often introduce random crashes, even | 21:04 |
| KungFuJesus | I've always liked Ubuntu because they didn't stick 8 package versions behind like redhat does in order to ensure what they call stability. There should be auditing and testing of course, but to stick to a given version just because it works for so long causes other problems down the line, especially if that version doesn't work particularly well | 21:07 |
| MrKanister | I am more into GNOME so I can't judge the stability of it :) but I don't think 10.04 will get the stable update before 10.10 even has it | 21:08 |
| KungFuJesus | lamesauce. What am I to do in the meantime? | 21:08 |
| MrKanister | There is not that much you can do. In the moment there is the package sync process from Debian. So if Debian gets it in the next time, Ubuntu 10.10 will have it quickly, too. | 21:09 |
| KungFuJesus | it sounds like I'm going to have to grab the source code to kdegraphics and do some magic on ./configure to point to where the locally built exiv2 libs are | 21:09 |
| KungFuJesus | that should be the only other thing I have to compile by hand to ensure no API breakage I think | 21:10 |
| MrKanister | After the import phase you may help on getting exiv 0.20 into Ubuntu by packaging it and updating your bug report with that infos | 21:10 |
| KungFuJesus | could I do that? That would make life a lot easier than waiting 6+ months | 21:11 |
| MrKanister | you may want to have a look at https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate for updating Ubuntu packages | 21:13 |
| KungFuJesus | can you tell me where Ubuntu's sources are to the kdegraphics package? | 21:14 |
| MrKanister | You can get the source of a package by executing "apt-get source PACKAGENAME" | 21:14 |
| MrKanister | At the end of the update process you get a diff file which you should attach to your bug report and subscribe the sponsors (https://wiki.ubuntu.com/SponsorshipProcess) | 21:15 |
| MrKanister | that's basically it | 21:15 |
| KungFuJesus | hmmm, I almost want to search for an exploit in the current versions to "motivate" the devs to patch, lol | 21:20 |
| KungFuJesus | it's that frustrating | 21:21 |
| MrKanister | hehe | 21:21 |
| MrKanister | helping to get a package in ubuntu really is not that difficult | 21:21 |
| MrKanister | if you follow the two links and prepare it well, they will be glad you did the job and savef their time | 21:22 |
| KungFuJesus | I've done some work upstream before, though, it generally takes a lot of hounding on the testers and maintainers to actually commit it | 21:22 |
| KungFuJesus | depending on the size of the project, of course | 21:23 |
| MrKanister | that's great. The problem is always that they got a 24 hours day, too. | 21:23 |
| KungFuJesus | not sure how I'm going to create a package from basically new source code. I guess I could diff between .19 and .20 and say those are the patches, but that somehow doesn't seem proper | 21:24 |
| MrKanister | there is a "debian" directory in the source of a package that is in Ubuntu. You can extract the new source code and copy the directory to there. Then you adjust it a little (changelog, maybe other depences) and then you can already try building it | 21:26 |
| MrKanister | It's all documented in the first link | 21:27 |
| KungFuJesus | also what about forward dependencies? How do I go about possible problems with API changes? | 21:27 |
| KungFuJesus | something like a library isn't exactly a leaf in a dependency tree | 21:28 |
| MrKanister | In the depency list, you can specify the required version numbers of certain packages (e.g. "exiv2>=0.2") | 21:29 |
| MrKanister | this will prevent the application from installing if the depency is not met | 21:29 |
| MrKanister | in that case the matching package would need to be installed first | 21:30 |
| KungFuJesus | what about another package which relies on exiv2. Won't that package having been compile against .19 possibly suffer from a break due to an API change? | 21:30 |
| MrKanister | If there are still packages that actually NEED version 0.19 and can't go with 0.20 then the appropriate way ould be either not updating to 0.20 or dropping the packages (if not too many) | 21:32 |
| MrKanister | that what the current development version is for | 21:33 |
| KungFuJesus | it's possible they may not need it as much as the dynamic library's symbol table may change a bit between versions | 21:33 |
| MrKanister | updates may brakes things for a while, but after all packages have been adjusted to new version of other packages, everything works fine again | 21:33 |
| KungFuJesus | oh ok, so wait for everyone else to catch up | 21:34 |
| KungFuJesus | mainly I'm referring to these problems: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN135 | 21:36 |
| MrKanister | ok, the exiv2 changelog (http://www.exiv2.org/changelog.html) lists an API change | 21:40 |
| MrKanister | * "Remove FindMetadatum* from API" | 21:40 |
| KungFuJesus | I guess for now I'll build localized versions and force the symlink of libkexiv to go to the localized version. Then I'll probably build a new package in a VM or something | 21:40 |
| MrKanister | the question is if this API change has a high impact? | 21:40 |
| KungFuJesus | depends on what's calling it I guess | 21:41 |
| MrKanister | And even if it has, the depending applications will have to adjust to that if it want's to stay updated | 21:41 |
| KungFuJesus | possibly, if it uses that functionality, anyway. Luckily this problem only runs two libraries deep | 21:42 |
| MrKanister | There is another info when following the link: "These classes are only used internally" | 21:43 |
| MrKanister | so no need to worry | 21:43 |
| KungFuJesus | I'll just rebuild libkexiv for now, install it to /usr/local and since it's the same version assuming that it will build I can change /usr/lib's symlink for the *.so | 21:43 |
| KungFuJesus | then I'll work on a package to push upstream, but for now that seems a safe and appropriate fix that can easily be undone. Some things done with apt are much more difficult to fix in my experience | 21:44 |
| MrKanister | I just tested building exiv2 on Ubuntu 10.10 and it looks good. | 21:46 |
| MrKanister | Hm, I don't think it's a good candidate for a stable update. | 21:51 |
| MrKanister | I created a debdiff and it's about 200.000 lines long and 5.6 MB big | 21:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!