=== rmcbride__ is now known as rmcbride === MTecknology is now known as MTeck-ricer [06:05] should not this build be killed? https://edge.launchpad.net/~chromium-daily/+archive/ppa/+build/1583899 [06:05] looks stuck to me [06:09] xnox: Probably. But the i386 build queue is short now, so it can probably wait until Monday. [06:09] wgrant, hmmmmm looks like the build recovered.... nevermind =) [06:10] wgrant, it's just like there 9 out 10 chances that openening builders page you see chromium or firefox building ;-) [06:10] xnox: At this time of day, yeah. [06:10] We're about to start working on a solution to that -- to keep the daily builds on a separate set of builders. [06:11] So they can't cause 30 hour build queues for everyone else. [06:11] wgrant, what is this time? is 6AM UTC special? [06:11] wgrant, aha =) that would be nice [06:11] xnox: Whatever time the manual daily build scripts run. [06:12] wgrant, hmmmm =/ they should randomise or at least pick the time which is less busy [06:12] Also, daily builds should soon be done entirely within LP itself (currently there's an external script that uploads them at the same time every day), so it will be able to schedule them more sanely. [06:12] well now it's not that busy [06:12] This is the time which is less busy. [06:13] yeah =) well I hope I'll be awake to build my packages cause they depend on each other so I can't just upload now and come back tomorrow [06:13] xnox: Have you considered using versioned build dependencies? [06:13] LP will automatically retry builds once their dependencies become available. [06:13] hmmm interesting =) should have done that [06:14] thanks for the tip [06:14] I'll go and create source packages again then [06:21] wgrant, also it might be interesting to prioritise development release builds vs current & supported [06:22] xnox: Which would be preferred? [06:23] development release of course [06:23] Why? [06:23] hi all [06:24] I created my PGP key and published it to keyserver.ubuntu.com [06:24] because it means people are testing their software to work with development release ubuntu and hence newer gcc and etc. So by doing this you help upstream to develop & ubuntu to be better [06:24] but still it says that Launchpad could not import your key [06:24] unless PPA is considered a user for users place [06:25] any help? [06:25] chirag, you need to copy & paste your public key into launchpad box [06:25] chirag: What is your key's fingerprint? [06:25] as far as I remember [06:25] xnox: No; it just needs the fingerprint. [06:25] wgrant, ok =) [06:25] xnox: yes I copy pasted the fingerprint in the box [06:25] * xnox will shut up now and let the expert talk [06:26] wgrant: D521 C39A 8166 DA96 6C5A DE2D 8D6D 8AC2 0651 18B0 [06:28] wgrant: I published the key in keyserver.ubuntu.com 30 minutes ago [06:28] still it is not taking the fingerprint [06:28] wgrant@magrathea:~/dev/hello-2.4$ gpg --recv-key 0x065118B0 [06:28] gpg: requesting key 065118B0 from hkp server keyserver.ubuntu.com [06:28] gpg: key 065118B0 was created 5218 seconds in the future (time warp or clock problem) [06:28] Your clock is wrong, so your key is bad. [06:29] It might work if you try again in two hours, however. [06:29] wgrant: so I need to create it again? [06:29] chirag: How did you create it? [06:30] Applications>Accessories>Password and Encryption keys [06:30] It appears to be both created in the future and be 768-bit D/g, which is probably not valid. [06:30] yes my system clock is wrong [06:31] chirag: Did you change any of the settings in the key generation process? Which version of Ubuntu are you using? [06:31] wgrant: I am using 9.10 [06:31] No I didn't change any settings [06:37] wgrant: done! :) [06:37] wgrant: thanks for the help :-) [06:38] chirag: What's done? [06:38] wgrant: I successfully imported the key [06:39] chirag: http://keyserver.ubuntu.com:11371/pks/lookup?search=Chirag%20Jain&op=vindex shows that you have four active keys. You should probably revoke the three that you're not using and push them to the server. [06:39] Particularly the oone that was created in the future, since that's actually newer than the latest one you've just created. [06:40] wgrant: how to do that? [06:42] chirag: See http://www.hackdiary.com/2004/01/18/revoking-a-gpg-key/ [07:15] Hello everyone looks like loggerhead is not working [11:14] I have added ssh-key on my LP page and I can't work with bzr [11:14] Permission denied (publickey). bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. [11:20] ari-tczew: You've run 'bzr launchpad-login' and specified the correct username? [11:21] wgrant: my username is correct with LP [11:22] ari-tczew: SSH is using the correct public key file? [11:22] Er, private key file. [11:22] wgrant: should be OK [11:23] private key? [11:23] public is correct [11:23] ari-tczew: You have the matching private key on that machine, right? [11:25] wgrant: I think yes, private key is in file ~/.ssh/ssh-launchpad [11:25] ari-tczew: You've configured SSH to use that file? [11:26] It should only use id_rsa and id_dsa by default. [11:26] wgrant: I don't know o_O [11:26] wgrant: I don't have files id_rsa or id_dsa [11:27] ari-tczew: Try renaming ssh-launchpad to id_rsa. [11:27] wgrant: does ssh-launchpad.pub file need renaming as well? [11:28] ari-tczew: It's not important to SSH, but it's good to keep consistency. [11:30] wgrant: it works! thanks! [11:30] ari-tczew: Excellent. [11:31] wgrant: second question: actually I have 2 ssh-keys on my LP page - old and fresh, can I delete old key? [11:32] ari-tczew: If you no longer use it, you can delete it. [11:36] thanks [12:26] It looks like in http://launchpadlibrarian.net/42144045/buildlog_ubuntu-lucid-ia64.debian-edu-artwork_0.0.30-4_FAILEDTOBUILD.txt.gz the package built but the buildd failed on dpkg-genchanges, with a " cannot read files list file: No such file or directory" error. === lfaraone|really is now known as lfaraone [13:48] anyone here use tarmac? I could use some advice [14:41] Hi ... I'm having trouble uploading a PPA, but all the possible problem reports I see suggest an unknown GPG key (the key is listed in my lp profile) or missing signature (the .changes file verifies with that key using gpg --verify); the symptom is that an uploaded package neither generates a launchpad email nor shows up on the PPA. Does anyone know what I might be doing wrong? [14:52] Quick question, how do i stop Launchpad from notifiying me when I change something in a subscribed thing? I mean... seriously now, i changed it, i know that I did, no need for notifications [15:12] if I'm not mistaken, you can't currently but IIRC there is also a wishlist bug about it [15:13] OK, I think my problem is sort-of-solved; it appears that the selection of launchpad notification email address matters (?) [15:15] elb: does your LP page list that gpg key belong to you? [15:15] geser: yes, the key is listed as belonging to me, as I said in the original question, and the address on the key is also listed on my LP page [15:15] it was not, however, my selected contact address [15:16] when I selected it and re-uploaded, I immediately got an email [15:16] that's not ideal, but I can work with it [15:16] interesting [15:16] now ... I created this PPA on hardy, so I set its distro to hardy [15:16] but it should build on everything >= hardy [15:17] will the PPA system do so for me, or do I need to upload different versions for each distro, or what? [15:18] it's likely that any distro >= hardy can install the hardy packages directly, actually, in this case [15:18] elb: the later, you need to bump the version slightle (e.g. by appending karmic or similar to the version) and reupload (the .orig.tar.gz can be reused and doesn't need re-uploading) [15:18] depending on the type of application you have, it might be also enough to copy source+binaries to the other releases [15:19] it's binutils [15:19] and the only dependencies are libc and libz [15:20] but the resulting dependencies will most likely be different [15:21] the only way to know is to test if the package works as-is in >= hardy and if yes then copy else reupload [15:21] yeah, I'll test it [15:21] binutils doesn't use anything super fancy [15:21] since it does the whole compile-my-own-support-crap-as-.a thing [15:22] next time I have an upload, I'll also try changing my email back to my preferred contact email, and see if the upload succeeds [15:22] I'd rather not have to dance my contact info to use different PPAs etc. === yofel_ is now known as yofel [16:14] I've got a problem. When i trie to change settings e.g. try to accept the BSD license, or choose prefered language, it just say "Launchpad doesn't understand the form data submitted in this request. " [16:15] why? [16:36] Hi. Something seems to have gone wrong with my launchpad account. Whatever I try to do, even when I try to log out I get this error message: "Unexpected form data". [16:37] I'm Matias Särs, msevens. [16:46] Nobody here who can help me with my problem? [16:51] it's the weekend, so many people are offline [16:52] Ah, I guess I could try again later then. [18:53] any launchpad API hacker knows how to form URI for this? https://edge.launchpad.net/+apidoc/1.0.html#languages [18:54] wgrant: ^ if you are free [19:11] there is a serious bug i rekonq 0.4 lucid, which was fixed upstream, i would like to know if itl be fixid in lucid final release? This bug makes rekonq unusable for productive. https://bugs.launchpad.net/ubuntu/+source/rekonq/+bug/534630 [19:11] Ubuntu bug 534630 in rekonq "on browsing google, unable to switch between google search/maps/videos : failed to load" [Unknown,Confirmed] [19:13] its not just google but nearly every website could be affected. (even ubuntu wiki showed "failed to load" and this adblock stuff in terminal. [19:20] Hi, I dumped too much useless packages to my PPA and reached 100% quota. Then I deleted them. How long it takes until I can use space again or should I just make new PPA? [19:30] manish: I'm not really an LP API hacker, but perhaps I can still help you. You want to directly load an LP object for a specific language without going through the collection object? [19:31] geser: I am trying to connect to https://api.edge.launchpad.net/1.0/languages?ws.op=getAllLanguages [19:31] since this is a GET operation mentioned [19:31] plus I am passing all the oauth related information in the Authorization header of the HTTP request [19:32] geser: the way I am connecting to URI's it works for other collections [19:32] geser: I get a 404 for https://api.edge.launchpad.net/1.0/languages?ws.op=getAllLanguages [19:37] manish: try with '+' before languages: https://api.edge.launchpad.net/1.0/+languages?ws.op=getAllLanguages [19:37] geser: trying [19:38] geser: wohohoho [19:38] geser: \o/ [19:38] geser: works. Thanks a lot *hugs* [19:39] manish: hint: when doing "import httplib2; httplib2.debuglevel=1" before importing the launchpadlib module, you can see the HTTP requests launchpadlib uses [19:42] geser: actually am not using launchpadlib [19:42] geser: instead reading the hacking document and writing a .NET wrapper over it [19:42] i.e. a .NET client proxy for Launchpad API ( a library initially) [19:44] manish: it was meant as a hint to see what launchpadlib sends, so you know you have to send in your .NET client proxy [19:44] geser: thanks a lot. will do so.. [20:18] Can I enable people who are not members of my LP team to subscribe to my team mailing list? [20:19] so, suppose I have a bogus .orig.tar.gz file, and I want to replace it ... am I entirely out of luck? [20:19] do I need to create a new PPA? [20:23] elb: delete the old orig.targz [20:23] and how do I do that [20:24] I deleted the packages, but the librarian still knows about it, and uploads fail [20:53] lfaraone, elb: You cannot upload a different orig.tar.gz with the same name. [20:53] That would be a very confusing lie, so LP forbids it. [20:53] right, that makes sense [20:53] except the first one is wrong [20:53] and I want to destroy it forever [20:54] Why has your orig.tar.gz changed? [20:54] That should be impossible, unless it wasn't really an original upstream tarball. [20:54] bingo [20:54] it contained the original upstream source, but is re-tarred [20:54] so the checksums don't match [20:54] because the dpkg tools wouldn't package a .bz2 [20:55] however, upstream provides a .gz [20:55] so it makes more sense to use that .gz, which can be verified against upstream's signatures/checksums [20:55] Retarred, or just recompressed? [20:57] retarred [20:57] basically, the deal is, I screwed this up [20:57] because this is the first time I've made a deb in about fifteen years [20:57] and this one requires a little bit of dancing to not conflict with distro-supplied files and package names [20:58] I then *fixed* the screwup, by correcting my packaging mistakes, but launchpad has these ghost files hanging around preventing me from updating the PPA [20:59] which literally nobody has (or should have) downloaded yet [20:59] because of that, I'm not married to this one, so I can just throw it away and create another entire PPA archive if I need to, but that seems wasteful [20:59] Why not just append +repack1 to the version of the new orig tarball? [21:00] or +real, or something. [21:00] if that's the best we can do, I can do that [21:00] I was really hoping for a way to tell lp that the first upload was an abortion, though [21:01] There is one bug that lets you clobber the orig.tar.gz, but it will result in some slightly strange behaviour and we're about to fix it, so I'd highly recommend just about any other solution in the world. [21:02] ok [21:02] that's kind of unfortunate [21:02] not a huge deal, I guess [21:02] Is it really that much of a problem to add an extra string to the orig tarball until upstream does another release? [21:02] That's what we do in Ubuntu when this happens. [21:02] it's not a problem, no [21:02] it's just dirty [21:02] Well, what has happened is dirty. [21:03] yes, it is [21:03] but it can be cleaned up [21:03] or rather, logically it can [21:03] its sounds like technically it cannot [21:03] and that's fine, I understand that things like that happen [21:04] I'll figure out how to put a fake version tag on the upstream, and we'll move on [21:04] the next release could very well be years, though, we're talking about binutils ;-) [21:04] Oh. Ew. [21:05] yeah [21:05] They seem to release roughly yearly. [21:05] well, sort of [21:05] for embedded platforms, once you get one working, you tend to not change things if you don't have to [21:07] for example, it looks like I'm going with GCC < 4.4.3, since 4.4.3 doesn't currently build successfully to target this platform ;-) [21:08] Hmmm. [21:08] (ARM Cortex-M3) [21:08] but, I see that right now there's actually a binutils-2.20.1 that came out since I fetched 2.20 [21:08] that seems unlikely to blow anything up, let me give it a stab [21:09] So, the moral of the story: never recompress tarballs. if you do have to, make sure that you give gzip '-n'. [21:10] right [21:10] If you ever change an orig tarball in a non-trivial way (ie. just about anything other than gzip -n), note that in the version string. [21:10] I was pretty disgusted about the whole thing [21:10] I idn't realize that debsource was quite as smart as it is [21:10] did some jiggering around that I didn't really have to do [21:10] Also: Karmic and Lucid support the new 3.0 (quilt) and 3.0 (native) formats, which support bz2. [21:10] I've used debian-based distros off and on for *years*, but I've hardly packaged at all [21:11] what with almost everything always being packaged for me [21:11] and it's ... kind of a complicated process ;-) [21:13] and, yeah, I see that the newer distros have better support for various things, but I'm packaging from hardy for now [21:17] elb: Why are you basing on Hardy? [21:17] because some of my machines are LTS [21:17] they'll become lucid at some point [21:18] Lucid will be out in a month, and already has an ARM port, and it's even thumb2. [21:18] right, the machines aren't ARM [21:18] they're x86 [21:18] 08:08:05 < elb> (ARM Cortex-M3) [21:18] in a month, that will be relevant to me ;-) [21:18] this is a cross-compiler for uCs [21:19] Ah. [21:19] the CM3 is a 6 to 64kB of RAM sort of affair ;-) [21:19] Shh. [21:19] Ubuntu will run fine in that :P [21:19] and yes, I LOVE it that the Cortex A9 is also thumb2 [21:19] because it means the tools get a good wring out [21:20] just a couple of years ago, getting the gnu tools going on thumb2 was a bit of a kill-a-chicken-and-stand-on-one-foot proposition [21:20] now, most releases work without any trouble at all [21:20] or at least compile and produce some sort of binary ... whether they're 100% correct or not I can't say ;-) [21:20] elb: Have you reused the packaging of other binutils or gcc cross-compilers? [21:21] There are several of each already in Ubuntu, IIRC. [21:21] no [21:21] I looked at them, and they're all done differently [21:21] mostly with more-or-less hideous kludges, as best I could tell [21:21] so rather than use someone else's hideous kludge, I built my own [21:21] in true NIH fashion ;-) [21:21] Hmm. [21:22] the avr port is probably the "most correct" of the ones I looked at [21:22] I've not looked at the h8300-hms toolchain's packaging, but the user experience isn't bad. [21:22] it uses the system binutils-source package [21:22] (it's the only one I've used) [21:22] Ah. [21:22] h8300-hms re-tars the upstream sources [21:22] I think without change, but I'm not sure [21:23] frankly, I wouldn't even make packages, except I'm giving this toolchain to some people who aren't so unix-savvy [21:23] and any administration I can do for them will reduce my own burden significantly [21:31] and let me tell you what [21:31] not *one* of the existing official binutils packages is even close to correct in the copyright department [21:31] and I'm not convinced about licensing, either [21:32] (in hardy, that is) [23:35] geser: i fixed that issue with architectures. [23:36] geser: the solution was simple, upgrade dpkg-dev to newer version :) it's broken in 9.04 [23:42] getxsick: It's not broken in 9.04. [23:42] wgrant: it is [23:42] wgrant: do you know the issue i'm talking about? [23:43] getxsick: I don't. [23:43] wgrant :) [23:43] But unless you are doing something incredibly obscure, it's probably not dpkg-dev's fault. [23:44] wgrant: in debian/control i use only i386 and all architectures, however in .dsc file there is "any" [23:44] in 9.10 there is no problem with it [23:45] not really "broken". just a slightly different and well-known behaviour. [23:46] wgrant: ok. i didn't know about it, and geser suggested that maybe it's a bug. whatever :) [23:46] Why did you want to restrict it to i386? [23:47] wgrant: cause we currently only support i386 [23:47] Ah, *there's* the real bug! [23:47] wgrant ? [23:47] Why only i386? [23:48] wgrant: cause it's not easy to support other architectures and seems there are more important priorities [23:48] It is easy to support other architectures unless you're doing something very special. [23:49] wgrant: i'm doing something very special [23:49] Ah. [23:49] :-) [23:50] wgrant: http://pypy.org [23:50] Oh, right. [23:50] You could just not build the JIT on other archs. [23:50] uff, innocent? :) [23:50] But yay, PyPy packages will be awesome. [23:50] wgrant: that's what i'm gonna add tomorrow [23:51] just try to avoid of rebuild everything (which takes ~2hours) [23:51] Yeah, I've built it quite a few times myself. [23:52] It likes its RAM and CPU time. [23:52] yeah, 1.5GB of RAM is like a minimum [23:52] https://launchpad.net/~pypy/ [23:53] btw. we would like to introduce nigthly (or weekly) builds as well, however i have currenly problem with name versioning... [23:53] what i mean is rejection due to *orig.tar.gz eleready exists [23:54] getxsick: You should name the orig.tar.gz something like pypy_1.2+svn20100328.orig.tar.gz [23:55] wgrant: what about debian/changelog? should i add extra line every build? [23:56] getxsick: You don't necessarily need to preserve all the old entries, but you will need to add a new one for every build. [23:57] LP will soon be able to do nightly builds itself. But that relies on having a bzr import of the project, and bzr-svn can't deal with svn:externals yet. [23:57] And PyPy seems to love svn:externals. [23:57] yeah [23:58] so i can simple replace the entry from the last build by the newer version number and a new date, right? [23:58] Exactly.