[08:13] <nigelb> jml: :( you lost the spot on dev week
[08:44] <geser> StevenK: Hi, I tried to upload a package with SFTP to the main archive and got "open failed" (http://paste.ubuntu.com/456269/). Uploading to PPA with sftp worked. Is there an error in my dput config?
[08:59] <wgrant> geser: Shouldn't you be uploading to /ubuntu?
[09:00] <wgrant> Ah, hmm, upload.ubuntu.com FTP doesn't require it.
[09:00] <wgrant> That's odd.
[09:01] <geser> wgrant: I don't know. bigjools told me that it's like the ubuntu stance but with a different method and login
[09:01] <lifeless> whats an upload between friends
[09:20] <StevenK> geser, wgrant: I've not debugged what's going on there, but yes, you need /ubuntu
[09:25] <geser> StevenK: still got an "open failed" error with "incoming = /ubuntu"
[09:26]  * StevenK looks at geser's dput config
[09:27] <wgrant> StevenK: We really should update the default dput.cf to include /ubuntu.
[09:27] <wgrant> Because that's how it should be done.
[09:27] <StevenK> wgrant: Fix it? :-)
[09:30] <StevenK> geser: Just a hunch, try "incoming = ubuntu"
[09:31] <StevenK> But the SFTP server side code ought to strip leading slashes
[09:31] <geser> StevenK: yeah, that worked
[10:30] <hrw> hi
[10:31] <maxb> hi
[10:33] <hrw> if upstream keeps project/code in LP and package is in Ubuntu only then is there a way to have package/bugs page linked to code/bugs? to have just one place for reporting bugs
[11:24] <SeySayux> Hi. My build failed: http://launchpadlibrarian.net/50999786/buildlog_ubuntu-lucid-amd64.libsylph-class_0.1alpha4-1_FAILEDTOBUILD.txt.gz . However, it compiles fine over here. What could be the problem?
[11:26] <maxb> /usr/bin/ld: ../deps/binreloc/libbinreloc.a(binreloc.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
[11:26] <maxb> SeySayux: ^ The error message hints at the issue
[11:27] <SeySayux> maxb: Yea, I found that line.
[11:27] <bigjools> beat me to it
[11:27] <maxb> This sort of error is architecture dependent - e.g. it's not a problem on i386
[11:27] <SeySayux> So, I should just disable amd64 builds or what?
[11:28] <maxb> However, if you aim to write portable code, it is always a mistake to link non-PIC code into a shared library
[11:28] <tsimpson> as far as I can see, it is compiled with -fPIC
[11:28] <SeySayux> Okay, so I need to make it PIC. Isn't the build system (cmake) supposed to do that for me? I hate messing with CMake's internals...
[11:29] <maxb> tsimpson: The thing not compiled with -fPIC is libbinreloc.a
[11:29] <maxb> SeySayux: right, this is a bug in the upstream project
[11:30] <SeySayux> maxb: I happen to be the developer of the upstream project, so...
[11:30] <maxb> Given the problem is in "deps/binreloc/" I would not be entirely surprised if it was an embedded dependency using a separate buildsystem
[11:30] <tsimpson> ah, yes
[11:31] <SeySayux> maxb: nope, it's just a cmake file invoked with subdir()
[11:31] <maxb> I know nothing about cmake, so I can only speak of generalities
[11:32] <maxb> Generally the ideal thing to do is to build the dependent library as a shared one too
[11:32] <maxb> Or if that's not a viable approach, compile the static library's objects with -fPIC
[11:32] <SeySayux> binreloc requires static linking to function
[11:32] <maxb> static linking to what?
[11:33] <SeySayux> to whatever it's supposed to be linked, in this case the main library
[11:35] <SeySayux> Okay, so I guess the best thing for now is to restrict building to i386 and file a bug report telling that -fPIC should be included. Okay, thank you.
[11:58] <SeySayux> Hi. I deleted my ppa. How long does it take before I can recreate it?
[11:59] <bigjools> you can't re-create the same PPA after it's deleted, there's a small bug that needs fixing
[12:01] <SeySayux> wtf
[12:01] <SeySayux> I can't reupload a package, I can't recreate a ppa, wtf is this thing?
[12:01] <bigjools> a free service?
[12:03] <SeySayux> So, if I get this right, it's 10 times more easier just to get a http host somewhere and put my files on there?
[12:04] <bigjools> Put it like this, I'm happy to help you and explain how to do stuff, but if you starting complaing then you forfeit your help
[12:04] <bigjools> s/starting/start/
[12:04] <SeySayux> Okay, I'm sorry, I'm just very fustrated....
[12:05] <SeySayux> So, if I accidentially upload the wrong package, is there any way to delete it?
[12:05] <bigjools> yes
[12:05] <bigjools> click on "delete packages"
[12:06] <SeySayux> okay, that button is nonexistent over here...
[12:06] <bigjools> which page are you at?
[12:07] <SeySayux> Okay, never mind, I found it
[12:08] <bigjools> bear in mind though that you cannot re-upload the same versions of files again
[12:08] <bigjools> but it's easy to bump versions
[12:09] <SeySayux> How do you mean? E.g. there's a mistake in the file, it failed to build, and now the failed version just stays on there?
[12:11] <bigjools> LP remembers the versions of every file you uploaded and won't allow them to be re-uploaded with different contents than before because it will seriously confuse apt clients
[12:12] <bigjools> so you upload a higher version that builds
[12:12] <bigjools> and the previous version is automatically superseded and removed
[12:12] <spiv> https://help.launchpad.net/Packaging/PPA/Deleting has some details.
[12:12] <spiv> (Basically what bigjools just said)
[12:12] <bigjools> yeah, I wrote that page :)
[12:13] <bigjools> well, a lot of it
[12:14] <SeySayux> So, I need to modify the version number?
[12:16] <bigjools> yes
[12:18] <SeySayux> Heh? Why does it put .so files in the -dev package?
[12:21] <SeySayux> okay, let's try this again... I'll keep you in touch if there are any problems...
[12:48] <hartym> Hi.
[12:50] <hartym> Not sure it's the right place to ask, but trying to install launchpad on an up2date lucid, and after having my "rocketfuel-setup" finished as instructed on the wiki, I did run the database setup script and getting stuck with the "make schema command" which complains about zc.buildout distribution not being found (in fact it's while running the buildout bootstrap.py script). The strange stuff (at least for me) is that I can import zc.buildout w
[12:50] <hartym> ithout any problem if I run a standalone python shell. Any idea ? the exact error message is "pkg_resources.DistributionNotFound: zc.buildout"
[13:28] <FC34> does any people payed with cluster filesystem, san and ubuntu ?
[13:28] <FC34> s/payed/played/
[13:30] <jpds> FC34: You might be better off in #ubuntu-server.
[13:30] <FC34> jpds thank you
[18:15] <jcastro> abentley: how's dailies looking? do I need to be ready this week?
[18:30] <abentley> jcastro, we will probably support dailies on edge in the next release.  I need to confirm this with thumper.
[18:32] <jcastro> abentley: target date for that is ... ?
[18:32] <abentley> jcastro, July 6
[18:33]  * jcastro nods
[18:34] <abentley> jcastro, we are delaying our release to reduce conflicts with Ubuntu, or it would be this week.
[18:34] <jcastro> abentley: no worries, I just want to know how much time I have
[19:34] <tormod> what package selection do the buildd chroots for Ubuntu have?
[19:42] <maxb> tormod: You can download the chroot tarball to see for yourself with a command like: wget -O - -q https://edge.launchpad.net/api/devel/ubuntu/lucid/i386/chroot_url | xargs wget
[19:43] <tormod> maxb, thanks I would more like to know what's behind that selection, i.e. what seed
[19:47] <maxb> tormod: lp:~lamont/launchpad-buildd/chroot-scripts may be semi-informative, but I suspect the canonical answer is "Ask lamont"
[19:50] <aalex_laptop> hello
[19:51] <aalex_laptop> Can I build a package on a PPA that depends on some packages which are only found on that same PPA?
[19:51] <getxsick> can i kill a current build? it's broken
[19:51] <micahg> aalex_laptop: yes
[19:51] <maxb> aalex_laptop: Yes. It should just work.
[19:51] <maxb> getxsick: Only by getting someone with admin powers to do it for you
[19:52] <getxsick> anyone with the power? :)
[19:52] <maxb> The help contacts have been scarce of late.
[19:52] <maxb> What's broken about it?
[19:53] <getxsick> i just forgot to update some stuff in the upstream. and my builds take few hours. so you know
[19:56] <tormod> maxb, thanks, been looking over chroot-scripts but no dice
[19:56] <maxb> getxsick: Since there's no help contact on duty, I guess you should just be content that you tried. There's lots of buildds, after all, it's not a big deal
[19:56] <maxb> tormod: Yes, I expect the true answer lives in lamont's head
[19:56] <tormod> if lamont is around, what I really wanted to found out is why they have libdrm (plymouth?)
[19:57] <getxsick> ok
[20:18] <MTecknology> it's 240/yr for a private project, right?
[20:18] <maxb> I recall seeing 250
[20:18] <MTecknology> or that
[20:20] <lifeless> bac: ^
[20:21] <bac> yes, MTecknology it is US$250/year/proj
[20:24] <MTecknology> bac: so if I have a private project and a team that owns it - is it possible to have another user that can read from those branches but not push to them?
[20:24] <lifeless> MTecknology: yes
[20:24] <MTecknology> how do you do that?
[20:25] <MTecknology> just saubscribe that person/team to the branch?
[20:25] <lifeless> yes
[20:26] <MTecknology> thanks
[20:26] <lifeless> we're working on a an acl system separated from subscriptions
[20:26] <lifeless> but its not here yet
[20:26] <MTecknology> my company is getting tir4ed of running code on internal servers
[20:27] <MTecknology> the down time and usability is fine - but LP offers much much nicer usability - and blueprints
[20:29] <MTecknology> Any ideas how much the bugs and other features will cost when they're no longer part of the private project cost?
[20:43] <bac> MTecknology: private bugs and codes have been offered for commercial subscribers for a long time now.  it is guaranteed not to change for the term of the subscription.
[20:44] <bac> MTecknology: i see you have created your project.  let me know if you have questions regarding purchasing the subscription voucher, etc.
[20:44] <MTecknology> bac: oh- it was just written in a way that made it sound like it could change
[20:45] <MTecknology> bac: yup - I was walking through it - I'll be making the money decision today - we're having a meeting over some projects that will involve many sprints
[20:45] <bac> MTecknology: ok, great.
[20:45] <MTecknology> thanks :)
[21:17] <lamont> tormod: while maybe semi-informative, lp:~lamont/launchpad-buildd/chroot-script is definitive, especially with "-d maveric --lp" as arguments
[21:22] <tormod> lamont, hmm IIRC it runs debootstrap but then what? is it defined by debootstrap then?
[21:23] <lamont> it runs debootstrap and then installs some packages
[21:24] <lamont> frankly, I'd have to walk through the script to be more accurate than that
[21:25] <lamont> tormod: it starts with debootstrap --variant=buildd, does some stuff to keep (at least well behaved) daemons from starting, and etc, etc.
[21:26] <tormod> lamont, I guess I was hoping for a higher-level answer, not how the script works
[21:26] <tormod> I see "minbase" in there...
[21:29] <tormod> man debootstrap: 'buildd,  which installs the build-essential packages'
[21:30] <tormod> but it looks like (from build logs) that more than build-essential is installed