| Ekushey | how do i upload to the PPA? i can't find the option to do that :( | 00:40 |
|---|---|---|
| cprov | Ekushey: https://help.launchpad.net/PPAQuickStart | 00:41 |
| === mwhudson__ is now known as mwhudson | ||
| Ekushey | cprov, i checked that, but it didn't help. i activated my PPA earlier, but i can't see any option to upload. | 00:48 |
| cprov | Ekushey: are you familiar with debian/ubuntu upload systems and the tools (`debuild` & `dput`) ? | 00:50 |
| Ekushey | cprov, no i'm not... do i need to do it from shell? | 00:51 |
| cprov | Ekushey: yes, you have to install and configure the tools to build and upload a source package. | 00:52 |
| Ekushey | oh! | 00:52 |
| cprov | Ekushey: check the ubuntu-package-guide reference. | 00:53 |
| Ekushey | sorry cprov, i thought there will be an upload button somewhere | 00:53 |
| Ekushey | alright, thanks | 00:53 |
| cprov | Ekushey: np | 00:53 |
| poolie | thumper: ping? | 00:55 |
| poolie | thumper: re bug 239958, maybe the instructions should have a "help" link or somethnig which could give more detail | 00:56 |
| ubottu | Launchpad bug 239958 in launchpad-bazaar "UnlockableTransport error when using lp: instead of bzr+ssh" [Medium,Incomplete] https://launchpad.net/bugs/239958 | 00:56 |
| poolie | i'm not sure if it would really help | 00:56 |
| === salgado is now known as salgado-afk | ||
| thumper | poolie: yeah, not sure | 01:03 |
| genii | How can I change my ppa to Hardy from the current Intrepid ? | 01:13 |
| cprov | genii: do you mean 'upload' to hardy or just change the UI widget to render hardy sources.list entry ? | 01:15 |
| genii | cprov: Both would be informative, if possible | 01:16 |
| cprov | genii: set the right distroseries in the debian/changelog entry (man dch) | 01:17 |
| genii | cprov: I'm currently trying to update pdfedit from 0.3.2 to 0.4.1 but Intrepid has this already, would be for Hardy | 01:17 |
| cprov | genii: to see a different sources.list entry, select a new series in the first dropdown box in your PPA page. | 01:18 |
| cprov | genii: sorry, I don't understand exactly what you mean. | 01:19 |
| genii | cprov: 8.10 has version 0.4.1 (latest) of the application pdfedit, however it's only up to 0.3.2-something in general for 8.04 . So I already successfully built from source (i386) on my box here with checkinstall. | 01:22 |
| cprov | genii: okay, fine, but how is it related with PPAs ? Do you want to upload and build the intrepid source for hardy in your PPA ? | 01:23 |
| genii | cprov: Ideally to just upload the lates sources (0.4.1) but for Hardy. The confusion I'm having seems to be that by default it wants it to be Intrepid | 01:25 |
| cprov | genii: yes, that's what is pointed by the last entry in the debian/changelog | 01:26 |
| genii | OK, have git-buildpackage and examining the dch manpage now | 01:27 |
| cprov | genii: lot s of options for you. | 01:27 |
| genii | cprov: I think I need a "Launchpad for Dummies" book :) | 01:27 |
| cprov | genii: 1 )you can copy the source and binaries from intrepid to hardy in your PPA | 01:27 |
| cprov | genii: 2. you can create a new source package version of the same source pointing to hardy | 01:28 |
| genii | cprov: Number 2 looks most prudent | 01:29 |
| cprov | genii: probably. | 01:30 |
| genii | cprov: There pre-exists here a Changelog | 01:35 |
| cprov | genii: ? | 01:35 |
| genii | cprov: In reading the dch manpage it seems it examines the Changelog for naming which would be something like "PDF Editor 0.4.1" (likely with underscores added or so). But recommended naming for ppa seems to me would be along line of: PDFEditor_0.4.1-0ubuntu1~ppa1 | 01:41 |
| cprov | genii: yes, that's the safest way to have a intrepid version rebuilt in hoary, because 0.4.1-0ubuntu1~ppa1 < 0.4.1-0ubuntu1, so your system would dist-upgrade fine. | 02:00 |
| persia | genii: Be warned that if you are working towards something that will become a backport, the official backport will be 0.4.1-0ubuntu1~hardy1, which is less than that string. You might want to use ~0ppa1 so that if there is later an official backport, users are upgraded to the official backport. | 02:03 |
| genii | Hm | 02:04 |
| genii | Sorry for lag, currently reading https://wiki.ubuntu.com/PackagingGuide/Howtos/PackagingFromScratchHelloDebhelper to get a grasp on how to do a diff from orig.tar.gz kind of thing. Building locally doesn't usually require all this etc | 02:06 |
| genii | Quite dry reading I may add | 02:07 |
| genii | Whats an acceptable substitution for a tilde in the packagename? | 03:05 |
| genii | eg: dpkg-source: error: source package name `pdfedit-0.4.1-0ubuntu1~ppa1' contains illegal character `~' | 03:06 |
| jamesh | genii: perhaps it is only after the "pdfedit" bit? | 03:07 |
| jamesh | you can definitely have a "~" in the version number | 03:07 |
| genii | Perhaps I just need to remove it for now | 03:08 |
| jamesh | genii: you generally want just the source package name in the debian/control file, and the version number in debian/changelog | 03:11 |
| genii | jamesh: The original source name didn't have the -0ubuntu1~ppa1 ending, but then dh_make groaned and I renamed it to fit. In the control file may be the issue? | 03:13 |
| jamesh | genii: in the usual case, you should leave the package names in debian/control as is | 03:14 |
| jamesh | genii: include your suffix in the version number for the most recent changelog entry | 03:15 |
| jamesh | (that is where the package version is picked up from) | 03:15 |
| genii | OK. So If I have Package: namehere~ppa1 in control this reverts to same as source name? | 03:17 |
| jamesh | why do you want ~ppa1 in the package name? | 03:20 |
| jamesh | don't you want that in the version number? | 03:20 |
| genii | jamesh: I'm trying to understand this. | 03:21 |
| jamesh | genii: if you want the package in your PPA to upgrade whatever is provided in Ubuntu, you should use the same package name, but a higher version number | 03:22 |
| genii | jamesh: I've managed to successfully locally compile this app for Hardy (pdfedit-0.4.1) from the source at Sourceforge. There seems to be an earlier Hardy version (0.3.2) in the repos already. I'm painfully trying to understand step by step how to do the dh_make, debuild, dput process. The ppaquick start suggests to name packages with an ending of ~ppa# | 03:26 |
| genii | (as detailed here https://help.launchpad.net/PPAQuickStart ) | 03:27 |
| jamesh | genii: it recommends that as a suffic on the version number | 03:28 |
| jamesh | not the package name | 03:28 |
| genii | Hmm | 03:28 |
| jamesh | suffix, even | 03:28 |
| genii | So version number is only in Changelog? | 03:29 |
| jamesh | right. | 03:29 |
| jamesh | you can't actually produce a new version of a debian package without touching the changelog | 03:29 |
| genii | OK I'm gonna go delving in there again | 03:31 |
| jamesh | genii: https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate <- this might help you | 03:31 |
| genii | jamesh: I've been working a bit from https://wiki.ubuntu.com/PackagingGuide/Howtos/PackagingFromScratchHelloDebhelper but it seems to give conflicting info compared to the ppa page | 03:32 |
| genii | If not conflicting then at least confusing | 03:33 |
| jamesh | genii: if you are updating a package to a new version, you probably don't want to do your packaging from scratch | 03:33 |
| jamesh | otherwise you're throwing away all the work others have done on it (as well as making a lot more work for yourself) | 03:34 |
| genii | jamesh: So if I just did something like dh_make in the original source code dir without doing the .orig stuff likely would have worked? | 03:35 |
| genii | If nothing else I'm seeing how the debian/control and so on functions anyhow :) | 03:36 |
| jamesh | genii: packaging from scratch is worth doing as a learning exercise, sure. | 03:41 |
| jamesh | [I should probably do it some day too ...] | 03:42 |
| genii | Heh | 03:42 |
| jamesh | but if you want a usable package, it is better to try and update an older packaging | 03:42 |
| jamesh | besides: upgrading packages is a more common operation than packaging something from scratch | 03:43 |
| genii | jamesh: So in this case, getting the source for 0.3.2 then doing some diff for 0.4.1 ? | 03:45 |
| jamesh | genii: right. If you have the deb-src lines in your sources.list, you should be able to do "apt-get source pdfedit" | 03:46 |
| jamesh | download the newer tarball, and there is some command you can run to move the existing packaging over to it | 03:46 |
| genii | I think I'm gonna need more Advils | 03:46 |
| jamesh | The Debian packaging howto is worth reading if you haven't already | 03:47 |
| genii | I've been basically working off the packaging guide I mentioned earlier | 03:48 |
| genii | I think what may be giving me grief is that the original sources are not debian to begin with (that I've been working with) | 03:49 |
| genii | What eludes me is how something locally done like ./configure;make;sudo checkinstall to end up with a deb package gets so convoluted when trying to get basically the same thing onto my PPA | 03:53 |
| lifeless | because checkinstall is fundamentally broken | 03:57 |
| lifeless | and it is giving you a very false idea of what packaging entails | 03:57 |
| genii | lifeless: Would the dh_make/debuild method more educational to use when compiling sources if I wanted to get a better understanding ? | 04:00 |
| genii | (as well as dch I imagine) | 04:01 |
| lifeless | I recommend you use the MOTU teaching materials | 04:03 |
| lifeless | #ubuntu-motu is the IRC channel | 04:03 |
| lifeless | the team there are dedicated to teaching people about packaging as part of their tasks | 04:04 |
| genii | lifeless: Thanks. | 04:05 |
| genii | lifeless: They've actually ben pretty helpful there | 04:33 |
| genii | *been | 04:33 |
| persia | We aim to please :) | 04:34 |
| * genii slides persia a coffee | 04:36 | |
| genii | Need to get back now to my usual channels :) | 04:36 |
| === persia_ is now known as persia | ||
| mpt | Gooooooooooooooooooood morning Launchpadders! | 07:30 |
| Hobbsee | afternoon mpt! | 07:33 |
| mpt | Hey, I got here before midnight this time | 07:35 |
| Hobbsee | \o/ | 07:41 |
| === RAOF_ is now known as RAOF | ||
| \sh | moins | 11:21 |
| \sh | gmb: ping :) | 11:22 |
| \sh | gmb: you offered me some help regarding leonov and launchpad malone ;) | 11:22 |
| gmb | \sh: Sure! Just give me a few minutes; I'll ping you when I'm free. | 11:23 |
| \sh | gmb: cool...if you are free :) please join #leonov , thx :) | 11:24 |
| === kiko is now known as kiko-afk | ||
| === jt1 is now known as jtv | ||
| === mrevell_ is now known as mrevell | ||
| === salgado-afk is now known as salgado | ||
| === mrevell_ is now known as mrevell | ||
| Dauerbaustelle | Hey guys, got a question: Why does code.launchpad.net need so long for displaying new revisions in preview (code.launchpad.net/~mytool/mybranch) ? | 14:08 |
| Dauerbaustelle | Also known as "recent revisions" | 14:09 |
| Dauerbaustelle | Anyone there? | 14:13 |
| jamesh | Dauerbaustelle: after you upload your changes via bzr+ssh or sftp, there are two processes that need to run | 14:14 |
| jamesh | the first does the equivalent of "bzr push" to transfer your changes to the publicly published area of the server (ensuring that it is a real bzr branch and that corrupt data isn't published) | 14:15 |
| jamesh | the second scans the data from the public location for use within Launchpad itself (e.g. for the code.launchpad.net pages) | 14:15 |
| jamesh | the delay should not be too long (usually just a few minutes), but can take longer if a lot of other data has also been pushed around the same time | 14:16 |
| Dauerbaustelle | oh, ok | 14:17 |
| Dauerbaustelle | is there a page where i can see new revisions after process #1? | 14:17 |
| jamesh | http;//bazaar.launchpad.net/~user/project/branch/changes should reflect it | 14:19 |
| jamesh | (that'll be loggerhead running against the published version of your branch) | 14:19 |
| jamesh | this is the "browse revisions" link from the code.launchpad.net page | 14:19 |
| Dauerbaustelle | Oh | 14:20 |
| Dauerbaustelle | yeah, you're right | 14:20 |
| Dauerbaustelle | thank you! | 14:20 |
| === EdwinGrub is now known as EdwinGrubbs | ||
| \sh | dear lp admins, what do I need to do to get a mailing list approved? :) | 14:52 |
| === salgado is now known as salgado-brb | ||
| === salgado-brb is now known as salgado | ||
| === kiko-afk is now known as kiko | ||
| === _neversfelde is now known as neversfelde | ||
| === thekorn_ is now known as thekorn | ||
| === salgado is now known as salgado-lunch | ||
| === matsubara is now known as matsubara-lunch | ||
| doctormo | I'm trying to intergrate with launchpad for our loco website using the openid system | 18:34 |
| doctormo | If I direct people to login to launchpad, how can I get them back onto our site? is there a redirect? | 18:35 |
| doctormo | Does anyone frequent here? | 18:40 |
| beuno | doctormo, that's not how openid works | 18:47 |
| beuno | people don't have to login into Launchpad | 18:48 |
| beuno | doctormo, http://en.wikipedia.org/wiki/OpenID#Logging_in | 18:48 |
| doctormo | beuno: People don't have to log into my website either, but if I know they are logged into launchpad I can identify them. | 18:51 |
| doctormo | Thanks for the link btw | 18:54 |
| beuno | :) | 18:54 |
| beuno | I don't follow what you want/need then | 18:55 |
| doctormo | beuno: A website, run by a LoCo team, where the intity management is tied to launchpad. We don't really want people with users on the website that are not on launchpad. | 18:58 |
| doctormo | Perhaps I will just create a link to the logon openid and feed it the login.launchpad.net address | 18:58 |
| beuno | doctormo, well, if people are using their LP openid, then it means they have a LP account | 19:01 |
| beuno | so they should just login with their LP openid into your site | 19:01 |
| beuno | and you can avoid going through LP itself | 19:02 |
| === matsubara-lunch is now known as matsubara | ||
| doctormo | beuno: that is the hope... | 19:14 |
| schierbeck | hi guys | 19:24 |
| schierbeck | is there any kind of authentication of revision committers as shown on the code pages, or do you simply match by the committer email address? | 19:24 |
| schierbeck | as far as i can see, only the pusher is authenticated | 19:25 |
| schierbeck | eh, the one pushing the revisions... | 19:25 |
| * beuno bets on the "only matching email theory" | 19:26 | |
| * schierbeck agrees, but sees potential spoofing issues | 19:26 | |
| beuno | in fact, if you upload revisions with an email that's not in LP, it doesn't recognize it | 19:27 |
| schierbeck | that sounds like a clear sign to me :) | 19:27 |
| beuno | that's true, although, I suppose you already trust the people you allow to upload to the branch | 19:27 |
| schierbeck | true | 19:28 |
| beuno | sounds like a bug that will get some discussion :) | 19:28 |
| schierbeck | you *could* however match by their gpg signature to be sure :) | 19:28 |
| beuno | *if* people sign their commits | 19:29 |
| schierbeck | they probably would if it added any real benefit | 19:29 |
| schierbeck | currently, the semantics seem ill-defined | 19:29 |
| beuno | and, I'm not sure, but I think you can't really verify the signed commits, can you? | 19:29 |
| schierbeck | well, undefined | 19:29 |
| === salgado-lunch is now known as salgado | ||
| schierbeck | beuno: you can | 19:29 |
| beuno | ah, cool. I don't know why I thought that you couldn't currently | 19:30 |
| schierbeck | you can verify the signature itself and compare the signature owner's name and email against the commit's | 19:30 |
| beuno | nobody from codebrowse seems to be around :/ | 19:30 |
| beuno | it'll be a few hours before mwhudson wakes up, and I don't know who else works on it. abentley maybe? | 19:31 |
| schierbeck | beuno: i'm actually doing it in bzr-gtk, although it's disabled right now -- we still need to match the signed text against the revision to avoid spoofing | 19:31 |
| schierbeck | perhaps | 19:31 |
| schierbeck | i'll add a bug for it | 19:32 |
| beuno | cool, let me know what # so I can subscribe :) | 19:32 |
| abentley | beuno: I don't do lots on codebrowse, but I'm reasonably familiar with it. | 19:32 |
| beuno | abentley, do you happent to know if what schierbeck is saying is true? It uses a simple email matching on the committer's email? | 19:33 |
| abentley | beuno: I can't say offhand. I would imagine the performance hit of doing so would be unpleasant. | 19:35 |
| beuno | abentley, ok, thanks. We'll see what comes out of the bug | 19:36 |
| schierbeck | beuno, abentley: i've filed bug #240756 | 19:36 |
| beuno | it does seem like a potential security problem | 19:36 |
| ubottu | Launchpad bug 240756 in launchpad-bazaar "Authentication of revision committer" [Undecided,New] https://launchpad.net/bugs/240756 | 19:36 |
| abentley | schierbeck: Are you talking about the loggerhead-style view or launchpad-styled view? | 19:39 |
| beuno | lp-style view which links to the user's page | 19:40 |
| beuno | which is what would make it a LP security issue I suppose | 19:41 |
| abentley | beuno: It would be a security issue if it allowed someone to do something with the permissions of that user. I don't think that's the case. | 19:42 |
| beuno | abentley, right. Spoofing risk then. If I upload a revision of bzr as <aaron.bentley@canonical.com>, then LP will show it as you would have made that revision | 19:44 |
| abentley | beuno: We also, for example, don't require authentication when commenting on bugs. | 19:44 |
| beuno | abentley, you do have to have a LP account to comment on bugs. And that user is attached to that comment. Not so for revisions | 19:45 |
| beuno | bzr's nature will make this a tricky one | 19:45 |
| beuno | but gpg sounds like one solution | 19:45 |
| abentley | beuno: The mail interface does not require a GPG signature for commenting. | 19:47 |
| beuno | ah, then that's not so good either :) | 19:47 |
| cr3 | how can I have a ppa for multiple releases? must I create different branches and have the build release in the changelog? | 19:47 |
| abentley | Sure it is. | 19:47 |
| abentley | It would be worse if we required every message to be GPG signed. Would prevent lots of people from participating. | 19:47 |
| beuno | agreed. Make it optional, and clear that the specific revision hasn't been verified | 19:48 |
| abentley | Similarly, many people don't bother signing their revisions. But where they are signed, we ought to be able to verify the signature. | 19:48 |
| schierbeck | beuno, abentley: i think the verification indeed should be optional -- i'm not sure how to do that in the ui, though | 19:50 |
| abentley | schierbeck: One option is to specially mark verified revisions, like browsers specially mark SSL web sites. | 19:52 |
| abentley | But even if you have a signed revision, you don't know that the author is accurate, only that the committer really does claim that to be the author. | 19:53 |
| schierbeck | abentley: this is kind of what i've been working on in bzr-gtk | 19:53 |
| schierbeck | my idea is that if the signature email matches the committer email, then we regard that revision as being signed by its committer, i.e. authenticated | 19:54 |
| abentley | btw, I've looked at the code now, and I'm reasonably certain we're doing no testament verification. | 19:54 |
| schierbeck | the testament also needs to match, of course | 19:54 |
| schierbeck | abentley: yeah, that's our main issue with the verification code -- i'm not quite sure if there's an easy way to solve it | 19:55 |
| schierbeck | i would be very interested if there was | 19:55 |
| abentley | What's the problem? | 19:56 |
| schierbeck | abentley: well, i can get the cleartext from the signature, which is the testament, but i need to get a testament from the repository, too | 19:58 |
| schierbeck | couldn't find anything in the docs, although it's been a while since i worked on it | 19:59 |
| abentley | It's not hard to generate a testament. | 19:59 |
| schierbeck | abentley: please enlighten me :) | 19:59 |
| abentley | from bzrlib import testament; testament.Testament.from_revision(repository, revision_id) | 20:00 |
| schierbeck | abentley: i feel a bit foolish now... | 20:01 |
| abentley | Sorry. | 20:02 |
| schierbeck | not your fault | 20:02 |
| abentley | You'll want to invoke as_short_text, I believe. | 20:02 |
| schierbeck | ok | 20:02 |
| abentley | The result of that should match the signed text. | 20:02 |
| schierbeck | i think we just didn't make it for the release, and i lost focus | 20:03 |
| schierbeck | hmm, someone broke the seahorse integration bits in the meantime | 20:05 |
| abentley | schierbeck: Only fair. The seahorse integration bits broke lots of other things :-) | 20:07 |
| schierbeck | abentley: yup :) | 20:09 |
| schierbeck | guess it's karma | 20:09 |
| === fta_ is now known as fta | ||
| johan | mwhudson: ping | 21:44 |
| mwhudson | johan: hi | 21:45 |
| johan | mwhudson: remember the vcs-import issue I mentioned two weeks ago? | 21:45 |
| mwhudson | johan: yes | 21:45 |
| mwhudson | i fixed the bug, but we haven't had a roll out yet | 21:45 |
| johan | ah, excellent | 21:45 |
| johan | not even on on edge or staging? | 21:45 |
| mwhudson | there is a rollout next weekend | 21:45 |
| johan | [or perhaps vcs-imports isn't running there] | 21:45 |
| mwhudson | next week, rather | 21:46 |
| mwhudson | johan: there is a staging, but for boring reasons it's hard to test there | 21:46 |
| bdmurray | gmb: I'm still seeing "couldn't connect to OpenOffice.org issue tracker" with some openoffice.org bugs | 21:46 |
| mwhudson | the staging environment doesn't have access to the existing production import | 21:46 |
| mwhudson | so it starts from the beginning again | 21:46 |
| johan | mwhudson: sure, I'll just wait until the next rollout then. | 21:47 |
| mwhudson | johan: i _can_ test it on staging, but it's a fiddle | 21:47 |
| mwhudson | we can also cherrypick the fix onto production | 21:47 |
| mwhudson | but yeah, waiting a week is the easiest approach if you're not in a hurry | 21:47 |
| gmb | bdmurray: Yeah, it looks like the Bugzilla XML interface has been disabled on the OO.o bugtracker, so we're not able to fetch any bugs. | 22:35 |
| gmb | I've contacted the admins to see what the situation is. | 22:35 |
| bdmurray | gmb: they have an rpc interface? | 22:36 |
| gmb | bdmurray: Nope. Even if they did, the basic Bugzilla XML-RPC interface doesn't actually provide what we need to pull bug statuses in. | 22:39 |
| bdmurray | gmb: oh, okay. are they any rpc interfaces that you do use? I'm curious about other bug tracking systems. | 22:40 |
| gmb | bdmurray: Not at the moment. But we've done the work to enable working with Trac over an RPC interface (provided by a plugin on the Trac side) and I'm currently working on the same kind of functionality for Bugzilla (again provided by a plugin). | 22:41 |
| gmb | bdmurray: For most bugtrackers we either use XML (or CSV) exports. | 22:42 |
| bdmurray | gmb: I've heard about the plugins, thanks. | 22:42 |
| bdmurray | I've been thinking of ways to make it easier to setup bug watches. | 22:43 |
| gmb | bdmurray: If you've got any ideas, I'm all ears :) | 22:49 |
| bdmurray | gmb: I'll keep that in mind. I've been playing with the debbugs SOAP interface recently and searching bug bodies for strings. | 22:51 |
| === mthaddon changed the topic of #launchpad to: Launchpad is going down in from 22:00 UTC until 03:00 UTC for hardy server upgrades | https://launchpad.net/ | Downtime on June 17, 18, and 19: http://tinyurl.com/5bgye5 | Next meeting, all welcome: Thu 19 June 2008, 1800UTC #launchpad-meeting | Help: https://help.launchpad.net | Questions and spam reports: https://answers.launchpad.net/launchpad | Channel logs: http://irclogs.ubuntu.com | ||
| gmb | Cool. | 22:58 |
| === salgado is now known as salgado-afk | ||
| YokoZar | hmm launchpad ssl seems down | 23:14 |
| YokoZar | for the launchpad librarian I mean | 23:14 |
| mwhudson | YokoZar: the production machines are being upgraded to hardy | 23:14 |
| YokoZar | Yeah, I figured it was part of that. seemed odd that librarian was still up for a moment though | 23:15 |
| === barry is now known as barry-away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!