[00:00] <jelmer> verterok: hi
[00:17] <mwhudson> spiv: doing it over http is the hard bit i guess
[00:23] <spiv> mwhudson: *nod*
[00:23] <mwhudson> in some sense anyway
[00:24] <mwhudson> i'd secretly like to server bzr branches over http using twisted.web, not apache
[00:24] <mwhudson> but there are reliability and performance issues there i guess
[00:26] <spiv> I'd kinda like that too.
[00:27] <spiv> But I share your concerns :)
[00:28] <mwhudson> i think it would probably be fine on both counts, it's not like the load is that high for apache
[03:47] <micahg> so, any changes I make on staging won't affect the live LP, right?
[03:47] <wgrant> micahg: Right.
[03:47] <micahg> wgrant: thanks
[03:53] <lifeless> unless we've really messed up :)
[03:54] <nigelb> hehe
[03:55] <micahg> well, if I get yelled at for adding a random tag, I'll know
[03:55] <micahg> BTW, are there any ACLs on tag addition
[03:56] <lifeless> no
[03:58] <lifeless> poolie: lynne says you could also do gold class in bondi, its the newest such cinema
[04:11] <RedSingularity> Hi all.  I am having a problem adding tags to bugs.  Is there currently a known problem in launchpad regarding this?
[04:13] <wgrant> RedSingularity: It worked fine for me an hour ago. What sort of issue are you seeing?
[04:15] <RedSingularity> wgrant:  I type in the tags I want and hit the green check mark.  The little Grey wheel spins and stops but the tags are never added.
[04:15] <wgrant> RedSingularity: Which browser are you using?
[04:15] <RedSingularity> wgrant:  firefox
[04:16] <wgrant> RedSingularity: Which version?
[04:16] <RedSingularity> 3.6.13
[04:19] <RedSingularity> wgrant:  3.6.13
[04:22] <wgrant> RedSingularity: I've tried in both Chromium 8.0.552.215 and Firefox 3.6.13, and both work OK for me.
[04:23] <RedSingularity> wgrant:  Very odd.  I tried under a fresh firefox profile as well with no luck.
[04:25] <RedSingularity> wgrant:  64 bit firefox?  Thats what I am running.
[04:25] <lifeless> RedSingularity: I run 64 bit ff, no issues
[04:26] <RedSingularity> lifeless:  thanks for confirming :)  Must be an issue on my end.
[04:28] <RedSingularity> wgrant:  seems to be an issue over here.  I will play around a bit since i know its not the site now.  Thanks!
[04:29] <wgrant> RedSingularity: I haven't heard others complaining about it, and it was indeed 64-bit Firefox, so it seems that it might be something at your end, yeah.
[04:29] <wgrant> Odd.
[04:29] <micahg> would trying a middle click on the edit link to bring up the old page help?
[04:30] <RedSingularity> micahg:  middle click the "add tags"?
[04:31] <micahg> RedSingularity: yeah
[04:33] <RedSingularity> micahg:  interesting.  I get The tag "distro-upgrade" hasn't been used by update-manager (Ubuntu) before.  It gives me an option to "create the new tag" though.
[04:33] <micahg> RedSingularity: that's not an official tag
[04:34] <RedSingularity> micahg:  correct
[04:34] <micahg> that might be a bug in the AJAX UI WRT new tags
[04:35] <micahg> although that didn't affect me on staging either
[06:04] <stalcup> hello, how in the world do I get a ppa on a new project?
[06:05] <poolie> stalcup, hi there
[06:05] <stalcup> hello
[06:05] <poolie> the key thing is that ppas are owned by teams not projects
[06:05] <poolie> so typically you should make a project team
[06:06] <stalcup> ah, okay
[06:06] <poolie> like ~tribunal-dev or whatever it's called
[06:06] <poolie> then, create the ppa under that
[06:06] <stalcup> thanks!
[06:59] <israfil> hello
[06:59] <israfil> i need libdc1394-22 and libeigen2-dev for hardy heron, can you advise something?
[08:50] <alf> Hi all! Any idea why https://launchpad.net/~afrantzis/+archive/cairo-gl/+build/2126247 hasn't been published yet, although it was built 8 hours ago?
[08:50] <wgrant> alf: Something has gone wrong in the upload from the builder.
[08:51] <wgrant> Let me check the logs.
[08:51] <alf> wgrant: thanks!
[08:58] <apw> <apw> is there something wrong with the launchpad build farm?  i have builds which claim to have finished 9 hours ago which are still 'uploading build'
[08:58] <apw> <apw> https://launchpad.net/ubuntu/+source/linux/2.6.37-12.26/+build/2125799
[08:59] <apw> https://launchpad.net/ubuntu/+source/linux/2.6.37-12.26/+build/2125796 as well
[08:59]  * apw reads scrollback, a general problem huh ...
[09:00] <apw> wgrant, seems to be more wide spread than just one
[09:00] <wgrant> apw, alf: Yeah, all uploads since the deployment this morning are stuck in the queue.
[09:00] <wgrant> We are trying to work out exactly what's wrong.
[09:01] <apw> there was a deployment this morning?
[09:02] <wgrant> We deploy a couple of times a week now. Normally without downtime, except when we need DB changes.
[09:05] <apw> wgrant, is there any way for a mortal to know what in broad brush these deployments contain to know what areas are at risk ?
[09:05] <wgrant> apw: Not really. Even this breakage is a side-effect of an indirect change.
[09:22] <apw> wgrant, any idea as to the scope of the fix?  how long i should go away for ?
[09:24] <wgrant> apw: We will hopefully be able to unblock the queue by moving the problematic build away. But we haven't worked out the cause of the bug yet, so it's possible that a subsequent build will blow things up again.
[09:24] <wgrant> So it could be fixed in just a few minutes.
[09:50] <wgrant> apw: It looks like things are moving OK now.
[09:50] <apw> wgrant, how lon will the queue take to drain?
[09:51] <wgrant> apw: Not sure. But your build is done.
[09:52] <apw> wgrant, well one of the ones on that source upload, another is not
[09:52] <apw> https://launchpad.net/ubuntu/+source/linux/2.6.37-12.26/+build/2125796
[09:52] <apw> i guess i'd better check with you its not the bad one!
[09:53] <wgrant> It's not.
[09:53] <wgrant> The bad one was a recipe build.
[09:53] <eugenesan> Hi, is upload issue solved? Should I re-upload my builds or they will be uploaded after being stuck?
[09:53] <apw> not sure i know what a recipe build even is, so i guess not
[09:54] <apw> eugenesan, i believe in general things will unstick themselves
[09:56] <eugenesan> apw: :-)
[09:57] <apw> eugenesan, yep confirmed all of my pending upploads are in now, took over 10 mins to do the two so it may take some time yet
[09:58] <eugenesan> apw: Good news, thanks!
[09:59] <wgrant> The backlog was not small.
[10:04] <eugenesan> Interesting, several builders, on which my "stuck" builds are, is now at "Disabled for Enablement" state, is that expected?
[10:05] <wgrant> eugenesan: The builds get stuck after they are pulled off the builder, so that's fine.
[10:06] <eugenesan> wgrant: I see, thanks.
[10:12] <maxb> The publisher is going to have fun processing its own backlog as these flow through, isn't it :-)
[10:12] <wgrant> Oh yes.
[10:18] <fta2> hi, is there a problem with the ppa uploader (post build)?
[10:18] <fta2> https://launchpad.net/~chromium-daily/+archive/ppa/+packages
[10:18] <fta2> 6h
[10:18] <maxb> yes, fixed, backlog is being processed
[10:19] <fta2> i'm getting some ftbfs right now "State: Failed to upload"
[10:19] <maxb> oh, different problem then
[10:22] <fta2> -ftbfs+rejects
[10:22] <fta2>  * State: Failed to upload
[10:22] <fta2>  * Duration: ten hours
[10:22] <fta2>  * Build Log: https://launchpad.net/~chromium-daily/+archive/ppa/+build/2125948/+files/buildlog_ubuntu-maverick-amd64.chromium-browser_10.0.629.0%7Esvn20110105r70535-0ubuntu1%7Eucd1%7Emaverick_BUILDING.txt.gz
[10:22] <fta2>  * Builder: https://launchpad.net/builders/promethium
[10:23] <fta2> Uploading build 20110106-011445-2139907-PACKAGEBUILD-2143389 failed.
[10:23] <fta2> nothing more
[10:24] <wgrant> fta2: Do you have a link to the build?
[10:24] <wgrant> fta2: Check the upload log on that page.
[10:24] <wgrant> fta2: Some KDE uploads failed because a newer version had been uploaded in the meantime.
[10:24] <geser> looks like the case here too
[10:24] <fta2> https://launchpad.net/~chromium-daily/+archive/ppa/+build/2125948
[10:25] <fta2> so http://launchpadlibrarian.net/61708234/upload_2143389_log.txt
[10:25] <wgrant> Oh, right, missed the link in the build log link.
[10:25]  * wgrant fails.
[10:25] <fta2> oh, it's the previous build
[10:25] <wgrant> Indeed, it is an old build.
[10:26] <fta2> superseded
[10:26] <bigjools> yay for fixes
[10:26] <fta2> why did it take 10h?
[10:26] <fta2> wgrant, btw, did you see my post wrt the ppa stats?
[10:27] <wgrant> fta2: Ah, I wondered what you'd pinged me about.
[10:27] <wgrant> Reading now.
[10:29] <maxb> terranova is sitting there not buildimg anything since 2010-12-11,
[10:29] <maxb> please can someone kixk it?
[10:33] <bigjools> fta: nice blog post
[10:34] <wgrant> maxb: It seems to be thoroughly dead. lamont: ^^ terranova is no-route-to-hosting.
[10:34] <bigjools> wgrant: it's stuck in ABORTING
[10:34] <wgrant> Oh.
[10:34] <wgrant> Wrong host.
[10:34] <wgrant> Yes.
[10:34] <wgrant> ABORTING.
[10:34] <bigjools> sigh.
[10:34] <wgrant> I was looking at terranova.buildd.
[10:34] <wgrant> Which still exists :/
[10:34] <bigjools> thought I'd fixed that little gem
[10:34] <wgrant> ABORTING != ABORTED
[10:35] <wgrant> Unless you think you made it reset virtual builders when it tries to abort them.
[10:35] <wgrant> Which I don't quite remember.
[10:35] <bigjools> I dunno
[11:01] <wgrant> fta2: Just read your blog post.
[11:01] <wgrant> fta2: Nice graphs.
[11:10] <apw> wgrant, this build seems to have been uploading for 17 mins, is it just in the queue or broken: https://launchpad.net/ubuntu/+source/linux/2.6.37-12.26/+build/2125797
[11:11] <wgrant> apw: The backlog was nearly 1000 builds. It's not quite done yet.
[11:12] <apw> wgrant, something for the launchpad monitoring to monitor and page people about
[11:12] <apw> to catc
[11:12] <apw> to catc
[11:12] <bigjools> fixed already
[11:12] <wgrant> apw: As of three minutes ago it does!
[11:12] <apw> to catch these things quicker
[11:12] <apw> heh cool
[11:12] <wgrant> It is being nice and noisy already :(
[11:13] <apw> heh not so cool if you have the pager
=== matsubara-afk is now known as matsubara
=== yofel_ is now known as yofel
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[12:11] <shankao> hi, I am having some problems uploading into my ppa with dput:
[12:12] <shankao> shankao@emilia:~/dev$ dput -o ppa:shankao/shankao-test apache2_2.2.16-6ubuntu2~shankao1.changes
[12:12] <shankao> D: Host ppa found in config.
[12:12] <shankao> Traceback (most recent call last):
[12:12] <shankao>   File "/usr/bin/dput", line 944, in <module>
[12:12] <shankao>     main()
[12:12] <shankao>   File "/usr/bin/dput", line 793, in main
[12:12] <shankao>     unsigned_upload, debug)
[12:12] <shankao>   File "/usr/bin/dput", line 286, in verify_files
[12:12] <shankao>     changes = parse_changes(chg_fd)
[12:12] <shankao>   File "/usr/bin/dput", line 82, in parse_changes
[12:12] <shankao>     for a in changes.dict['files'].split('\n'):
[12:12] <shankao> KeyError: 'files'
[12:13] <shankao> I'm following the info at: https://help.launchpad.net/Packaging/PPA/Uploading
[12:15] <geser> shankao: can you please pastebin that changes files?
[12:16] <wgrant> shankao: How did you generate your changes file?
[12:16] <wgrant> It doesn't seem to have been generated by any of the normal tools, since the filename is strange.
[12:17] <shankao> debuild -S (signed)
[12:17] <shankao> and then:
[12:17] <shankao> debdiff prev.dsc new.dsc > changes
[12:18] <geser> shankao: debuild -S builds a new .changes file for you which you can (and should use)
[12:18] <geser> debdiff does something different
[12:19] <shankao> ahá
[12:19] <shankao> which one should I upload? the _source.changes one or the _i386.changes?
[12:19] <wgrant> _source.changes.
[12:20] <wgrant> Launchpad doesn't accept binary uploads.
[12:20] <shankao> ok, thanks. I'll try it
[12:20] <geser> the _source.changes (the other one would LP reject)
[12:20] <shankao> Umh, maybe the error with unknown file format should be a little bit clearer in dput anyway :S
[12:22] <shankao> it seems to be uploading now, thanks!
[12:41] <apw> apw@dm$ bzr push lp:~apw/debian-installer/kernel-update
[12:41] <apw> seems to be failing with 'different serializers', anyone know what one does about it
[12:44] <wgrant> apw: That normally means that one of the branches is 2a, and the other is not.
=== oubiwann is now known as oubiwann_
=== oubiwann_ is now known as oubiwann
[13:38] <pcjc2> Hi
[13:38] <pcjc2> are there any LOSA about who could help me with a bug import at some point today?
[13:38] <pcjc2> wgrant?
[13:39] <pcjc2> (/me knows wgrant is not a LOSA, but he was helping me before ;))
[13:39] <mthaddon> pcjc2: you don't typically ask a losa for help with bug imports - you typically work with an LP dev
[13:39] <pcjc2> fair enough
[13:40] <pcjc2> btw.. in case it is useful to anyone, I spent about a day of my life fixing mysery caused by SF's screwed up encodings in their output XML
[13:40] <pcjc2> http://pastebin.ca/2039456
[13:41] <pcjc2> smells of kludge, but saves one HECK of a lot of manual fixups
[13:41] <pcjc2> are there any LP devs about?
[13:41] <deryck> pcjc2: did you file a question against launchpad for the bug import yet?
[13:41] <pcjc2> no - last time I was importing to staging, just asked here
[13:41] <pcjc2> Do you need the XML file attached there, or can I host it temporarily somewhere
[13:42] <deryck> pcjc2: who helped last time?  We always need the question to track the request.  And you can just provide link to the XML.
[13:42] <pcjc2> seems abusive to users to list all their data in such an archivable way (believe the original SF data contains IPs etc.)
[13:42] <pcjc2> wgrant was helping
[13:44] <deryck> pcjc2: you can send it privately in email as well.  File the question and we can assign someone and you can email that person.
[13:44] <pcjc2> I'm not quite done with my local testing yet anyway.. was just getting a feel for when someone would be about to help
[13:45] <pcjc2> I've disabled the project's SF tracker to do my final export and manual fixups on the conversion data, so was hoping to get an idea roughly how long it would be before I can point people at the new shiny LP tracker
[13:45] <pcjc2> Btw.. SF were vaguely helpful with the export XML (I opened a few tickets about their encoding issues). They suggested trying their beta to see if it suited our needs better - Got to love developed in secret, closed source, once in a blue-moon roll-outs
[13:46] <pcjc2> so glad LP updates are continual
=== leonardr changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | On-call help contact: leonardr | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/
[14:11] <fta2> wgrant, thanks for the comment. does this mean this bug won't be fixed in lp, ever?
=== matsubara is now known as matsubara-lunch
[14:36] <ttx> Hey guys -- I've been trying to propose a fix for bug 690712, but I'm a bit stuck... If any good soul could have a look at the apparently insufficient solution I posted on the bug, I'd appreciate it.
[14:36] <ubot5> Launchpad bug 690712 in Launchpad itself "Need to export blueprint-branch links" [Low,Triaged] https://launchpad.net/bugs/690712
[14:41] <leonardr> ttx: are you testing this with launchpadlib running against launchpad.dev? if so, you should clear out your launchpadlib cache
[14:41] <ttx> leonardr: yes I am, and no I haven't cleared cache. Trying now
[14:42] <leonardr> ttx: you should try writing a doctest and see if it works there
[14:43] <ttx> leonardr: it works! that was it.
[14:43] <leonardr> great
[14:43] <ttx> leonardr: many thanks.
[14:44] <leonardr> ttx: np
[14:44] <ttx> leonardr: is there a way to only run "some" tests ? test_on_merge.py takes a bit long
[14:47] <leonardr> ttx: yeah. is this in a launchpad context? you can use the -t argument to bin/test
[14:47] <leonardr> eg. bin/test -vvt webservice
[14:47] <ttx> leonardr: cool, will use that. thanks again
[14:47] <leonardr> it does a regexp match against filenames and against the function names of unit tests
[14:57] <jmehdi> hi, I'm trying to copy packages in my ppa (from maverick series to natty) and I get error id "OOPS-1832M1167"...
[14:57] <ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1832M1167
[15:00] <micahg> bug 575450
[15:00] <ubot5> Launchpad bug 575450 in Launchpad itself "Archive:+copy-packages nearly unusable due to timeouts" [High,Triaged] https://launchpad.net/bugs/575450
[15:07] <pcjc2> where should I file the question about bug import?
[15:07] <pcjc2> Launchpad its self?
[15:13] <leonardr> pcjc2: yes
[15:16] <pcjc2> https://answers.launchpad.net/launchpad/+question/140410
=== matsubara-lunch is now known as matsubara
[15:28] <shadeslayer> jelmer: can you move https://code.launchpad.net/~neon/hupnp/trunk to the correct project?  https://launchpad.net/hupnp
[15:28] <shadeslayer> or if anyone else can do it ^^Z
[15:29] <shadeslayer> hmm ... interesting that the url says neon but the lp branch says lp:hupnp
[15:29] <micahg> shadeslayer: neon is the owner/creator, hupnp is the project
[15:30] <shadeslayer> ohk
[15:30] <shadeslayer> aha
[15:30] <shadeslayer> bzr crash :P
[15:30] <shadeslayer> http://paste.kde.org/1905
[15:31] <jelmer> shadeslayer: sure, one moment
[15:31] <shadeslayer> new bzr in upgrades as well ... lets try those first then
[15:31] <micahg> shadeslayer: bug 696492
[15:31] <shadeslayer> jelmer: its fixed :)
[15:31] <ubot5> Launchpad bug 696492 in bzr (Ubuntu) "bzr crashed with TypeError in readheaders(): readline() takes exactly 1 argument (2 given) (dup-of: 693880)" [Undecided,New] https://launchpad.net/bugs/696492
[15:31] <ubot5> Launchpad bug 693880 in bzr (Debian) "_ReportingFileSocket.readline lacks size argument" [Undecided,New] https://launchpad.net/bugs/693880
[15:47] <pcjc2> Has Deryck gone home for the day?
=== zyga is now known as zyga-food
[15:55] <beuno> pcjc2, well, he's always home
[15:55] <beuno> but he may be at lunch or something
[15:55] <pcjc2> np, thank
[15:55] <pcjc2> s
=== beuno is now known as beuno-lunch
=== Ursinha is now known as Ursinha-lunch
[16:28] <duron23> ok, cya friends, taking off for now
[16:50] <fta> wgrant, where in the API can i find that a given (binary) package is an arch-all?
=== beuno-lunch is now known as beuno
=== benji is now known as benji-lunch
[17:25] <toabctl> how can i remove a debian-directory in a build recipe ?
[17:32] <jelmer> toabctl: you can't, as far as I know - why would you want to?
[17:33] <toabctl> jelmer, the software i want to build already has a debian-directory, but i want to use the debian-files from my bzr branch
[17:34] <toabctl> jelmer, and when i run: git://git.debian.org/collab-maint/syncevolution.git
[17:34] <toabctl> ups. sorry. wrong post
[17:34] <toabctl> when i run: bzr dailydeb syncevolution.recipe sync-test-daily/
[17:34] <toabctl> i get : Conflict adding file changelog.  Moved existing file to changelog.moved.
[17:35] <jelmer> toabctl: can you show the contents of syncevolution.recipe ?
[17:36] <toabctl> # bzr-builder format 0.2 deb-version {debupstream}+{revno}+{revno:packaging}
[17:36] <toabctl> lp:syncevolution
[17:36] <toabctl> nest packaging lp:~toabctl/+junk/syncevolution-packaging debian
[17:36] <jelmer> generally it is considered bad form for an upstream to ship their own debian/ directory
[17:36] <toabctl> jelmer, i know, but i can't change it...
[17:37] <jelmer> the best way to work around it is to derive your packaging branch from the upstream branch, and remove their debian/ directory there before adding yours
[17:37] <jelmer> you will need to resolve conflicts any time they change their debian/ directory though
[17:37] <toabctl> jelmer, but lp:syncevolution is an automatic import from git
=== Ursinha-lunch is now known as Ursinha
[17:43] <toabctl> jelmer, i'll ask upstream to remove the debian-dir.
[17:43] <toabctl> thanks for the help
=== benji-lunch is now known as benji
[18:31] <fta> OOPS-1832O1431
[18:31] <ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1832O1431
=== zyga-food is now known as zyga
[19:58] <Meths> Is it possible to change the columns that appear on bugs pages or is there another way to see at a glance which bugs are assigned and which are not?
[20:07] <flacoste> Meths: the columns are not yet configurable, although it's on our short-term queue to make them
[20:07] <thumper> Meths: it isn't possible to change the columns now
[20:07] <thumper> flacoste: snap
[20:07] <flacoste> you should be able to see the assignee of the bugs page
=== matsubara is now known as matsubara-afk
[20:31] <achiang> leonardr: hi, i've been experiencing an oops for the past few days: OOPS-1832CBB6802
[20:31] <ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1832CBB6802
[20:33] <lifeless> achiang: I've had a look and its not synced to our db yet, do you have one of the ones you experienced a few days back?
[20:34] <achiang> lifeless: no, sorry. i first saw one yesterday, and kinda moved on, hoping it was intermittent and would just go away on its own, so didn't save it
[20:34] <achiang> lifeless: i'll be better about that next time
[20:40]  * leonardr will keep an eye on it
[20:40] <leonardr> achiang: do you have a traceback or anything?
[20:41] <achiang> leonardr: no, it doesn't show a traceback
[20:41] <leonardr> ok
[21:01] <lifeless> achiang: this is the fault:
[21:01] <lifeless> NoSuchRevision: langpack-locales has no revision 64
[21:01] <achiang> lifeless: ha
[21:01] <achiang> lifeless: i guess that makes sense
[21:02] <achiang> lifeless: thanks for following up; i'll blame pitti for this. :)
[21:03] <achiang> it seems like lately, i am often getting "Server denied check_authentication" errors while trying to access http://bazaar.l.n urls
[21:03] <lifeless> there is a bug for that
[21:04] <lifeless> https://bugs.launchpad.net/launchpad/+bug/676372
[21:11] <achiang> thansk
[21:11] <achiang> thanks, even
=== JanC_ is now known as JanC
[21:55] <bdrung> does launchpad still have the upload problem from this morning? https://launchpad.net/~bdrung/+archive/ppa/+build/2128432
[21:55] <bdrung> Uploading build on osmium (virtual). Finished 49 minutes ago
[21:59] <lool> lamont: Hey, tgall_foo says a buildd is gone mad
[21:59] <tgall_foo> hi ... I've got a build in ppa:tom-gall/linaro-meego-n   that failed  but I'm getting emailed the failure message once per minute
[21:59] <lool> tgall_foo: a) how did you do it?  :)  b) do you have details to identify the builder?
[22:00] <tgall_foo> it's build #2128378
[22:00] <tgall_foo> lool, o iknow exactly how  Idid it
[22:00] <tgall_foo> I've got an updated build for the package submitted which I was hoping to clear out this repeating error ..  but it hasn't copied over the results yet
[22:01] <tgall_foo> lool, I had some extra crap in the debian/control file that I should have deleted
[22:01] <lool> tgall_foo: awesome, keep the testcase!
[22:02] <lool> https://launchpad.net/~tom-gall/+archive/meego-linaro-n/+build/2128378 ?
[22:02] <tgall_foo> yup
[22:02] <lool> it seems the build finished but didn't upload
[22:03] <lamont> neat
[22:04] <tgall_foo> so in the control file the gorp that was there I had commented out some extra Package:   foo   ...  I should have tossed it before I submitted the build
[22:05] <tgall_foo> I'm wondering if something in the works ignores the hash on ->  #Package:     and doesn't treat like it's commented out
[22:07]  * lamont wasn't aware that control files supported comments
=== thumper changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | On-call help contact: thumper | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/
[22:08] <tgall_foo> lamont, that could very well be the issue ...  /me is still new to debian packaging ...  I've seen Build-Depends  behind # successfully ignored so I presumed that was ok
[22:08] <lamont> In addition to the control file syntax described above, this file may also contain comment lines starting with # without any preceding whitespace. All such lines are ignored, even in the middle of continuation lines for a multiline field, and do not end a multiline field.
[22:08] <tgall_foo> least ok as you work with something locally via say pbuilder to validate things are kosher
[22:08] <lamont> policy says they're legal
[22:09] <tgall_foo> ok .. well let's not jump to conclusions ...
[22:09] <lamont> (specifically 5.2, final sentence)
[22:09] <lamont> if policy says "legal", then dpkg DTRT
[22:11] <lamont> interestingly, lakoocha has gone on to other things, so nothing to look at there
[22:15] <lool> tgall_foo, lamont: Would one of you file a bug on this with the diff before it expires?
[22:15] <lool> http://launchpadlibrarian.net/61802463/libsignoncrypto-qt_0.5-git.20101103t144805.3bfef55-0linaro1_0.5-git.20101103t144805.3bfef55-0linaro2.diff.gz is the debdiff
[22:15] <tgall_foo> I need to go pick up my son and daughter but I'll check in now and then if you need anything further
[22:15] <tgall_foo> lool, yes I'll file a bug .. for launchpad thingsl ike what what should I file against ?
[22:18] <lool> tgall_foo: I think it used to be soyuz, but now just launchpad
[22:19] <lool> tgall_foo: https://launchpad.net/launchpad
[22:20] <tgall_foo> ok thanks
[22:23] <tgall_foo> reported bug#698349
[22:23] <tgall_foo> reported bug #698349
[22:23] <ubot5> Launchpad bug 698349 in Launchpad itself "buildd failure notification is stuck" [Undecided,New] https://launchpad.net/bugs/698349
[22:24] <lool> thanks
[22:35] <wgrant> lool, tgall_foo: This is a bug that first showed up last night.
[22:35] <wgrant> We thought we'd worked around it, but apparently not.
[22:41] <wgrant> tgall_foo: The spam should have stopped now.
[22:42] <wgrant> tgall_foo: The build will be stuck UPLOADING until we work out what's going on, but it seems that a newer one has finished successfully anyway.
[22:48] <janimo> can package uploads, once built take an hour? I see openmpi is 'uploading on armel' for quite a long while
[22:50] <janimo> ah, finally done, never mind
[22:50] <wgrant> janimo: A bug has caused uploads to be stuck in the queue for the last couple of hours.
[22:50] <wgrant> It should be just about clear now.
[22:50] <janimo> wgrant, that explains it thanks
[23:34] <wgrant> Oh Python 2.x Unicode, I hate you so so much.
=== apachelogger is now known as gnomelogger
[23:50] <thumper> wgrant: :)
[23:50] <wgrant> thumper: It's all your fault, too :P
[23:50] <thumper> heh
[23:50] <thumper> why?
[23:50] <wgrant> Your logger changes.
[23:50] <wgrant> The buffer logger used to use cStringIO.
[23:50] <wgrant> Now uses StringIO.
[23:51] <thumper> which is nicer about unicode
[23:51] <wgrant> If you write a unicode to a StringIO, it will return a unicode.
[23:51] <wgrant> If you write a unicode to a StringIO, it will return a str.
[23:51] <wgrant> Er.
[23:51] <wgrant> Second one should be a cStringIO.
[23:52] <wgrant> That all works fine, until you try to pass the value of one of those into a cStringIO. cStringIO's constructor, when given a unicode, fills it will the internal UCS-4 representation, just for fun.
[23:52] <wgrant> s/will/with/, argh.
[23:56] <alf> Company: /wc
[23:59] <yofel> hi, could someone please look what went wrong here? https://code.launchpad.net/~vcs-imports/scribus/trunk