[05:38] <meoblast001> hi
[05:38] <mwhudson> meoblast001: hello
[05:39] <meoblast001> i filed this bug a few days ago https://bugs.launchpad.net/launchpad/+bug/363217
[05:39] <meoblast001> can i just be unbanned from my mailing list
[05:39] <meoblast001> i don't think i can remain banned until the bug is fixed
[05:39] <meoblast001> i'd just have to ditch launchpad mailing lists and find someone new if that happens
[05:41] <mwhudson> not by me
[05:41] <mwhudson> meoblast001: can you ask a question at answers.launchpad.net/launchpad ?
[05:41] <meoblast001> mwhudson: wouldn't that be comparable to filing 2 bugs though?
[05:42] <mwhudson> meoblast001: not really
[05:42] <mwhudson> we use answers more for actions and bugs for defects
[05:43] <spm> meoblast001: the last mesage on that list was sent by you on the 15th of April. Have you tried sending any more since? even a test one? far as I can see, you're still active and working.
[05:43] <meoblast001> spm: i could try
[05:45] <meoblast001> spm: oh.. nice.. it worked
[05:46] <meoblast001> spm: is there a limit on how many emails i can send?
[05:46] <spm> meoblast001: what do you mean? to a list? as fast as you can type I'd suggest.
[05:46] <meoblast001> spm: oh.. it told me i was banned because i sent too many emails
[05:47] <meoblast001> that was the reason when it banned me
[05:47] <spm> actually no it doesn't say that. it suggests you would be disabled for excessive bouces. different problem.
[05:47] <meoblast001> ahh.. ic
[05:47] <meoblast001> what are bounces?
[05:49] <mwhudson> basically mailman thought it sent you mail that got rejected by your mail server
[05:49] <meoblast001> mwhudson: ic
[05:50] <meoblast001> i'm so happy i filed that feature request on Ubuntu's Idea Pool (back when it was called that) to add screenlets.... so much easier to install now
[05:51]  * meoblast001 thinks there should be a #launchpad-offtopic
[09:07] <RAOF> Hm.  Is it possible to build a kernel flavour in the PPA build system?  It seems to die with make error 2, which IIRC is "you've run out of disc space".
[09:07] <RAOF> http://launchpadlibrarian.net/25777812/buildlog_ubuntu-jaunty-amd64.linux_2.6.28-11.43~ppa2_FAILEDTOBUILD.txt.gz
[09:08] <cprov> RAOF: let me check.
[09:11] <cprov> RAOF: I don't remember if error 2 is disk space, but 'Build needed 00:34:08, 3071656k disk space ' indicates it might be.
[09:12] <RAOF> 3GB?  Neat.
[09:12] <RAOF> Does this mean I can't build that in the PPA system?
[09:13] <cprov> RAOF: other people have been building kernels in PPA, let me check for something different.
[09:13] <RAOF> Thanks.
[09:16] <cprov> RAOF: what about https://edge.launchpad.net/~next-kernel/+archive/ppa/+build/847711 ?
[09:16] <cprov> RAOF: it uses 11GB
[09:16] <RAOF> Wow.  So, why doesn't mine build then :)
[09:17] <cprov> RAOF: the builder itself, I guess
[09:17] <wgrant> Error 2 is ENOENT, IIRC.
[09:17] <wgrant> Oh. *make* error. I fail.
[09:27] <cprov> RAOF: I've retried your build, this time it went to a 'older' virtual build, let's see how it goes.
[09:27] <RAOF> cprov: Thanks.
[09:29] <cprov> RAOF: what's was the name of the builder where it was previously built ? (lost the browser tab by mistake)
[09:29] <cprov> RAOF: it is in the build-failure-notification.
[09:39] <RAOF> cprov: platinum.  Sorry for the delay.
[09:39] <cprov> RAOF: np, thanks.
[10:39] <Hobbsee> gmb: thanks :)
[10:39] <gmb> Hobbsee: Welcome. Now we need to find some time to include it a cycle...
[10:39] <Hobbsee> gmb: how long would it realistically take?
[10:40] <gmb> Hobbsee: < 1 day, including tests, based on the last time I added a header to emails.
[10:40] <gmb> Hobbsee: Trouble is that we're all working on really complex stuff at the minute.
[10:40] <gmb> So we're pretty pressed for time.
[10:40] <Hobbsee> gmb: heh.  Like always :)
[10:40] <gmb> Hobbsee: Yeah. UI is hard :/
[10:40] <mwhudson> yeah, i yearn for the days when i got to work on really easy stuff!
[10:40] <Hobbsee> although is looking much nicer :)
[10:58] <cprov> RAOF: almost forgot of our test build, https://edge.launchpad.net/~raof/+archive/ppa/+build/954694, it failed again. Apparently in the same place.
[10:59] <cprov> RAOF: so, it's probably something in the source itself. Can you please seek assistance with the kernel-team ?
[11:03] <Whoopie> cprov: Hi, is this bug fixed on the live launchpad system? -> https://bugs.launchpad.net/soyuz/+bug/357034
[11:03] <RAOF> cprov: Urgh.  Sorry.  I thought it had built locally.
[11:05] <cprov> Whoopie: no, it will be fixed in the next rollout (2.2.4)
[11:05] <Whoopie> cprov: ok, thanks
[11:05] <Whoopie> just wanted to be sure as I try to build a custom kernel ;)
[11:05] <cprov> Whoopie: is it affecting your workflow badly ?
[11:06] <Whoopie> cprov: no, I know the workaround.
[11:06] <cprov> Whoopie: okay.
[11:08] <cprov> RAOF: maybe it does, someone from the kernel-team would know for sure what's going on with our virtual buildds.
[11:11] <wgrant> cprov: Why have I(D)SPR not been exposed through the API? And how are builds internally associated with source packages - by archive and SPR? I'd ideally like to be able to get more complete data.
[11:16] <cprov> wgrant: right, I'm about to confirm your branch.
[11:16] <wgrant> cprov: s/branch/bug/?
[11:16] <cprov> wgrant: ISPPH.getBuilds & getPublishedBinaries will be exposed
[11:17] <cprov> wgrant: yes, *bug* ;)
[11:19] <wgrant> cprov: Ah, ISPPH.getBuilds is already there. I missed that.
[11:19] <cprov> wgrant: cool, but SPPH.getPublishedBinaries -> IBPPHs isn't
[11:20] <wgrant> Right.
[11:20] <cprov> wgrant: also, the root problem is not been about to access SPR/BPR attributes (build-deps, deps, etc)
[11:21] <wgrant> cprov: Doesn't a Build only know about its BPRs, not any BPPHs?
[11:21] <wgrant> Given that a build is somewhat publishing-agnostic.
[11:21] <cprov> wgrant: yes, builds are publishing-agnostic
[11:22] <cprov> but SPPH should expose SPR attributes, same for BPPH (BPR)
[11:22] <wgrant> Why not expose the real [BS]PR?
[11:23] <cprov> maybe ... but they would need a new traversal, because they are also pub-agnostic ;)
[11:23] <wgrant> Although I suppose my main use for them will be fulfilled by methods that deal in publishings instead. They're just not all there yet.
[11:23] <wgrant> Mmmm, true.
[11:23] <wgrant> Forgot that.
[11:24] <cprov> wgrant: anyway, baby-steps, let's expose SPPH.getPublishedBinaries first, it's simple
[11:24] <wgrant> cprov: That sounds good.
[11:25] <cprov> wgrant: confirmed, will be in edge tonight
[11:25] <wgrant> cprov: Is (archive, name, version) for an [SB]PR really a unique key? I thought I saw a bug somewhere about duplicate binary versions causing problems, which would indicate it was ambiguous.
[11:26] <cprov> wgrant: (archive, name, version, Published) is unique
[11:26] <wgrant> (that key is the only one we have to distinguish the actual package referred to by a publishing)
[11:26] <wgrant> cprov: Right, but we don't have that last bit.
[11:27] <wgrant> I guess it's a tiny corner case that I can live with.
[11:27] <cprov> wgrant: that 4-elem key defines the publishing record, then SPPH.spr
[11:27] <wgrant> cprov: SPPH.spr doesn't exist to normal people.
[11:27] <cprov> wgrant: exactly :)
[11:28] <cprov> wgrant: that's why we can either export SPR as /+source/$ID or incorporate its attributes in SPPH
[11:28] <cprov> wgrant: I will investigate what's the best approach when I come back from lunch.
[11:29] <wgrant> cprov: Thanks!
[11:29]  * cprov goes
[15:08] <cr3> bug #175782 appears in my own personal bugs but I get a "lost something" page when trying to reach it
[15:15] <james_w> just https://launchpad.net/checkbox-desktop exhibits the problem as well (OOPS-1206ED125 for the same on edge)
[15:16] <noodles775> james_w: strange... wfm?
[15:16] <mthaddon> james_w: the project has been made inactive
[15:17] <james_w> that'll probably be why then :-)
[15:17] <noodles775> yup!
[15:18] <noodles775> cr3: all good then?
[15:22] <wgrant> IIRC there is a bug filed that bugs filed only in an inactive project should be hidden.
[15:28] <cr3> noodles775: I wouldn't qualify "lost something" as "all good", no
[15:29] <cr3> james_w: the project was deleted but it seems the bugs were left dangling
[15:29] <noodles775> Sorry cr3: I meant to communicate: "did you see the reason discussed here causing your problem" but did so poorly.
[15:30] <cr3> mthaddon: could all the related bugs be deleted or reassigned then? leaving them dangling is not optimal :)
[15:31] <cr3> this sounds like the equivalent to leaving the database in an inconsistent state, isn't there somekind of foreign key constraint which should kick in here?
[15:31] <wgrant> cr3: The project isn't deleted.
[15:31] <wgrant> Projects are only ever deactivated, which is sometimes called deletion.
[15:31] <wgrant> So it's not *really* gone.
[15:31] <cr3> wgrant: aha! inactive, so inaccessible, so constraint wouldn't kick in
[15:31] <mthaddon> yeah, what he said
[15:31] <wgrant> Right.
[15:32] <wgrant> So, the bug should not be shown in listings, nor should the redirect at /bugs/123456 work. Those are bugs.
[15:32] <cr3> ok, so I need to report a bug against launchpad then :)
[15:33] <wgrant> I know there's one already for the latter, but I'm not sure about the former.
[15:33] <cr3> wgrant: I was going to report a but against the former but I will mention the latter side effect
[15:35] <cr3> err, s/but/bug/
[15:52] <kwah> hi all
[15:53] <noodles775> Hi kwah
[15:53] <kwah> is reactivation feature for maillists broken in launchpad?
[15:53] <noodles775> barry ^^^
[15:54] <kwah> this morning I finally wanted to activate again mailing list for ~ubuntu-ru-users group
[15:54] <kwah> and since then I see message: This team's mailing list will be available within a few minutes.
[15:54] <kwah> since then == approx 05:30 UTC tosay
[15:54] <kwah> *today
[15:54] <kwah> any comments on this?
[16:10] <barry> kwah: it should be working but there may be a problem with your list.  please file a question and we'll look into it
[16:18] <kwah> barry, will do. May you give an indication how long it might take?
[16:19] <noodles775> kwah: if you add a question, it'll generally be assigned and answered within a 24hr period.
[16:19] <kwah> ok
[16:27] <kwah> noodles775, barry https://answers.launchpad.net/launchpad/+question/68038
[16:28] <noodles775> Thanks kwah, I'll assign it...
[16:28] <kwah> thanks
[16:52] <ripps> Strange, a package has building in the gmpc-trunk for 7 hours. It takes about 10 minutes to build normally. https://edge.launchpad.net/~gmpc-trunk/+archive/ppa
[16:59] <cprov> ripps: the builder that was building it was disabled, I will fix it for you in a minute.
[17:07] <ripps> cprov: Thanks
[17:15] <cprov> ripps: it will be dispatched in a bit, the problem will be fixed by bug #343683
[17:49] <barry> kwah: it should take at most 5-10 minutes to reactivate your list, so the fact that it hasn't yet is a problem
[17:52] <kwah> barry, yep, I kinda noticed ;)
[17:52] <barry> kwah: i'm try  to get a losa's attention and have them help me look into it
[17:53] <kwah> barry, thanks
[20:39] <adrian15b> Hi. I have recently created a new repository (ppa) in launchpad. http://ppa.launchpad.net/adrian15/fai/ . Now an user asks me how it can be build amd64 versions of the packages from my repository. So after checking my repository I see that all the packages architecture is "all". I thought that "all" was only for images (i.e. themes) packages. Did I do something wrong? Is it ok? How do I answer the amd64 question? Thank you.
[20:40] <LarstiQ> adrian15b: all is for platform independent, images qualify, or say pure python packages.
[20:40] <LarstiQ> adrian15b: that's part of your packaging though
[20:40] <adrian15b> LarstiQ: I already know that. So I made a mistake when I build my packages?
[20:41] <LarstiQ> adrian15b: specifically with debian/control, yes
[20:42] <LarstiQ> adrian15b: I'm assuming it isn't actually an Architecture: all package?
[20:46] <adrian15b> adrian15b: No, it is not.
[20:46] <adrian15b> LarstiQ: :)
[20:47] <LarstiQ> adrian15b: well then, change it to 'any' instead :) Or a relevant list of architectures if that may be the case.
[20:48] <adrian15b> LarstiQ: I am going to check the control contents from the repository and copy it into a pastebin.com like site.
[20:49] <LarstiQ> adrian15b: k
[20:49]  * LarstiQ goes search for mail from his bank he displaced
[20:51] <adrian15b> LarstiQ: Well the package is all.
[20:51] <adrian15b> LarstiQ: Because it is main script made. I had not realised it till now.
[20:51] <adrian15b> LarstiQ: So I tell the guy that it is platform indepedent and that's it.
[20:53] <LarstiQ> adrian15b: well yes, in that case nothing wrong with it
[20:53] <adrian15b> LarstiQ: Althoug I do no know if live-initramfs and initramfs-tools are platform independent.
[20:53] <LarstiQ> adrian15b: you could check what Debian/Ubuntu do?
[20:54] <adrian15b> LarstiQ: Yes, they are.
[20:54] <karim> hi, I have an upload problem on launchpad ppa,  it fails at the end v4l-dvb-dkms_1.20090413-ppa3.tar.gz: 4226k/4227k
[20:54] <adrian15b> LarstiQ: Ok. It was easier than I thought. Thank you for your help.
[20:54] <LarstiQ> adrian15b: np, I didn't do much :)
[20:54] <karim> I mean it's stuck just before the last bites are sent
[20:55] <karim> this happens to last packages I tried to sent
[20:55] <karim> with no error message, they are of course not on the ppa at all
[20:55] <LarstiQ> karim: does this happen with other hosts too?
[20:55] <karim> LarstiQ: what other host ?
[20:55] <LarstiQ> (ie, isolate where the problems lie)
[20:56] <LarstiQ> karim: random other ftp server?
[20:56] <karim> ???
[20:56] <karim> what other ftp server
[20:56] <LarstiQ> karim: you're uploading with dput, right?
[20:56] <karim> fqdn			= ppa.launchpad.net
[20:56] <karim> method			= ftp
[20:57] <karim> I only ave this
[20:57] <LarstiQ> karim: no incoming defined?
[20:57] <karim> where else can I upload ?
[20:57] <karim> incoming		= ~mirak-mirak/ubuntu
[20:57] <karim> login			= anonymous
[20:57] <karim> plus [mirak] for the section
[20:57] <LarstiQ> karim: mentors.debian.net for dput
[20:58] <LarstiQ> karim: but the main point is trying to find out where the problem lies
[20:58] <karim> I can't upload there I guess
[20:58] <karim> it was a hassel already to upload on launchpad ^^
[20:59] <LarstiQ> karim: you could also employ strace and tcpdump for more diagnostics
[21:00] <LarstiQ> karim: have you waited a while to see if it would complete?
[21:00] <cprov> karim: I've seen it happen with other big files like that
[21:01] <cprov> karim: let me check what the log files says in the server.
[21:01] <karim> cprov: thanks
[21:01] <karim> I also tried to upload nvidia drivers 2 times
[21:01] <karim> it failed at the end also
[21:01] <karim> LarstiQ: yes
[21:01] <cprov> karim: try now, please
[21:02] <karim> the upload ?
[21:02] <karim> ok
[21:02] <cprov> karim: yup
[21:02] <cprov> karim: is your uplink *fast* enough ?
[21:03] <karim> 1Mbit
[21:04] <karim> cprov: it's sending
[21:04] <karim> I had a checksum issue, I needed to rebuild the sources
[21:04] <cprov> karim: it already failed on the server side, apparently.
[21:04] <karim> what version ?
[21:04] <karim> cprov: it's still uploading on my side
[21:05] <karim> 2717k/4227k
[21:06] <cprov> karim: you upload is long dead, you can try it again,
[21:07] <karim> it started
[21:08] <karim> cprov: is it working ?
[21:08] <karim> cprov: maybe I should use passive or active ftp ?
[21:09] <cprov> karim: there are few simultaneous sessions in progress
[21:09] <karim> stuck again
[21:13] <cprov> karim: it should be stuck on your side ?  server side it's fine and will be processed in 2 min
[21:13] <karim> the server got the full archive ?
[21:14] <cprov> karim: yes
[21:16] <cprov> karim: no, I lied ;/
[21:16] <LarstiQ> cprov: any idea what's going on?
[21:17] <cprov> karim: the tarball is there, MD5 and size matches, the upload is missing the .changes (which makes it pretty much useless)
[21:18] <cprov> LarstiQ: not exactly, but is likely to be something client-side.
[21:21] <cprov> karim: I've download your source and re-uploaded with dput and it was fine.
[21:26] <karim> that's weird
[21:27] <karim> cprov: I don't see them on my ppa though
[21:27] <karim> cprov: are you sure you got the whole archive ?
[21:27] <cprov> karim: yes, I vaguely remember of cisco/linksys routers doing something bad for long ftp sessions
[21:28] <karim> it's a buffalo
[21:28] <karim> there is no other method to upload ?
[21:28] <cprov> karim: https://edge.launchpad.net/~cprov/+archive/ppa?field.name_filter=v4l&field.status_filter=published&field.series_filter=any
[21:28] <karim> cprov: what is the md5sum on it ?
[21:30] <karim> cprov: it doesn't show up on my ppa
[21:30] <cprov> karim: I can't upload to your ppa, so I've uploaded to mine
[21:31] <karim> cprov: yes, but if you got my file entirely, why isn't it proceced ?
[21:31] <cprov> karim: because the .changes was never uploaded.
[21:32] <karim> cprov: so the .changes might be the problem ?
[21:32] <karim> I have a strange issue here
[21:32] <cprov> karim: dsc and tar.gz were fine and the md5 matched, but apparently your dput never found out that the tarball had finished
[21:32] <karim> I create a deb from source, and build it, however sometime it says the checksum isn't correct
[21:32] <cprov> karim: no, you files a probably correct, the problem is something in the connection
[21:53] <jcole> how can i cross compile a debian package on ubuntu to x86_64/amd64 from an x86/i386 machine?
[21:53] <jcole> before i upload to ppa
[21:54] <cprov> jcole: you don't need to build the binaries, upload the source and the PPA will build the binaries for you.
[21:56] <jcole> cprov: understood, but i have some packages im not "allowed" to upload to ppa :/
[21:56] <cprov> jcole: oh, I see
[21:58] <cprov> jcole: `debuild -b -aamd64` (works for i386, I'm on amd64)
[22:00] <jcole> cprov: did you dpkg -x the .deb file and do a "file" on a .so file? the bits still compile to local arch even though the package says the specified arch
[22:01] <cprov> jcole: no, I didn't
[22:01] <jcole> cprov: your .so files in that created .deb are probably 64 bit
[22:01] <geser> jcole: build for amd64 on i386 won't work (at least not that easy) as the i386-kernel can't run amd64-binaries (like e.g. gcc)
[22:02] <cprov> jcole: which would obviously go boing in a 32bit system
[22:02] <jcole> geser: understood, but ive seen people cross compile on debian to strange arches like hppa on an i386 box
[22:03] <geser> they probably use qemu
[22:03] <jcole> geser: no, its something with a gcc cross compile toolchan
[22:03] <karim> jcole: you better use qemu
[22:04] <karim> jcole: cross compilation is really not easy, and if you want to do packages it will be hell certainly
[22:04] <geser> jcole: but you also need an upstream source that builds correctly with a cross-compiler (good luck with that)
[22:04] <karim> geser: yes ^^
[22:05] <karim> can I upload a .deb on ppa ?
[22:05] <cprov> karim: no, it's not allowed.
[22:06] <karim> cprov: I use dput locally
[22:06] <karim> I found a way to upload to a local repository
[22:06]  * jcole finds http://www.emdebian.org/tools/crossdev.html
[22:06] <karim> I do that to upload to my own repository
[22:07] <jcole> that says how to cross compile to arm without qemu
[22:07] <karim> jcole: I tried once to do a cross compiler for gentoo, to build for ppc on x86 it was very hard, even on gentoo
[22:07] <karim> I managed to do distcc on a different arch though
[22:08] <jcole> karim: there is some "debian" way of doing this
[22:08] <jcole> maybe i should pop over to deb dev
[22:08] <karim> my upload still fail on ppa :(
[22:09] <karim> I don't know what to do
[22:09] <karim> I will try without the router
[22:09] <jcole> karim: its a basic ftp upload
[22:10] <jcole> karim: first validate the ftp connection and an "ls"
[22:10] <jcole> karim: could be something with ftp active/passive
[22:10] <karim> I am in
[22:11] <karim> jcole: I tryed active
[22:11] <karim> passive_ftp             = 0
[22:11] <karim> ls gives nothing
[22:12] <jcole> karim: set the DMZ ip in your router to point to your upload machine
[22:13] <cprov> karim: `ls` will return nothing until will upload something, each upload session is isolated from the rest of the system
[22:16] <karim> cprov: I am tryng to put the files manually
[22:16] <karim> seems stuck also
[22:16] <karim> on the big one
[22:16] <jcole> karim: did you try DMZ setting?
[22:16] <karim> jcole: don't know how to do that
[22:16] <karim> I use a buffalo with ddwrt
[22:18] <geser> karim: do you have a shell account somewhere where you could try to copy the files there first and dput/ftp from there?
[22:19] <karim> I found it
[22:19] <karim> geser: no
[22:19] <karim> a remote computer maybe, but it's probably powered off
[22:23] <karim> jcole: dmz stuff worked
[22:23] <karim> jcole: so I maybe need to find what port allowed that
[22:24] <karim> I even uploaded .debs ... ^^
[22:25] <jcole> karim: its a dynamic set of ports that connect "back" to you... dmz basically lets all prots in
[22:25] <jcole> ports*
[22:26] <karim> there is a setting caalled spi firewall, maybe this is dissrupting
[22:27] <karim> or port trigering maybe
[22:35] <karim> jcole: I found a page where it says it the fault of a too short tcp timeout
[23:25] <syke> hi
[23:25] <bittin__3> hi
[23:25] <syke> I noticed a bug introduced in the diffs for pmccave-2.5
[23:25] <syke> pmccabe, rather
[23:25] <syke> http://launchpadlibrarian.net/19404556/pmccabe_2.4%2Bnmu1_2.5.diff.gz
[23:25] <syke> -echo "\nAnalyzing $newdir ...\c" >&2
[23:25] <syke> +prnitf "\nAnalyzing %s ..." "$newdir" >&2
[23:26] <syke> the second line should be "printf"
[23:27] <syke> are there any contributos who can check in a fix?
[23:50] <ripps> What the hell is up with the Launchpad builder? It telling me it's going to take 16  hours until it starts building?
[23:54] <spm> ripps: 235 builds waiting in the queue? I'd assume that it'll take a while to get through all that first.