[16:00] <cmatsuoka> cjwatson: is there a call that lists the names of the snap files built by LP, or they're only in the web page for that build?
[16:00] <cjwatson> cmatsuoka: https://launchpad.net/+apidoc/devel.html#snap_build-getFileUrls
[16:01] <cmatsuoka> I just noticed that I can't really know the file names beforehand because version can be set dynammically during the build process
[16:01] <cmatsuoka> ah great, thanks
[17:23] <teward> is there an issue with the ppas and accepting uploads?
[17:26] <cjwatson> There was, but it should be mostly fixed now
[17:27] <cjwatson> What's the package whose upload you're waiting for?
[17:27] <teward> parted, to my build-tests PPA
[17:27] <teward> maybe 10 minutes ago?
[17:28] <cjwatson> Right, apparently one of the percentage that's still failing
[17:28] <cjwatson> We're having keyserver troubles today
[17:28] <teward> ah
[17:28] <teward> that explains it :P
[17:29] <teward> cjwatson: do I need to reupload or is it just sitting somewhere waiting for attention/fixing?
[17:29] <cjwatson> teward: To help with our investigations, what's the fingerprint of the key you signed this with?
[17:29] <teward> cjwatson: moment
[17:29] <cjwatson> teward: No need to reupload, for now at least
[17:29] <teward> 5B8AD6F4C26ADDDD
[17:29] <teward> or do you want the full fingerprint?
[17:29] <teward> rather than that 'shorter' keyid?
[17:29] <cjwatson> Full fingerprint would be better
[17:31] <teward> full fingerprint is 5792 F661 64D0 57EF C6D0  6FAF 5B8A D6F4 C26A DDDD
[17:31] <cjwatson> thanks
[17:31] <teward> and is a fairly 'recent' key - but it looks like keyserver.u.c can't find it o.O
[17:31] <teward> though I've used this key for some time now
[17:32] <cjwatson> Like I say, keyserver troubles
[17:32] <teward> yep
[17:32] <cjwatson> SKS, not even once
[17:32] <teward> i thought the keyservers switched to a different implementation, at least the last time I prodded IS about keyserver.u.c issues
[17:33] <cjwatson> Sorta kinda
[17:33] <cjwatson> There's one called hockeypuck that's involved in some requests, but not in this case
[17:33] <teward> ah
[18:05] <teward> cjwatson: let me know if you need me to do anything, otherwise I am just going to wait this out and see what happens...
[18:05] <cjwatson> Not for now, thanks
[18:06] <cjwatson> Currently in sysadmins' hands trying to repair that SKS node
[18:06] <teward> ack
[21:04] <teward> cjwatson: you might want to reach out to epk in #ubuntu-packaging for their key ID fingerprint, they seem to have the same issue if they want more testing evidence.  just noticed it while going through things.
[21:04] <teward> if you need more things for diagnostics, that is
[21:04] <teward> (or rather if IS needs it)
[21:04] <cjwatson> We don't, as far as I know
[21:05] <cjwatson> DB rebuild currently in progress
[21:05] <teward> ack
[21:12] <epk> Is this the right place to request support while working with the ppa infrastructure?  My PPA's key is seemingly no longer available on the keyservers. I'm wondering if I can get it republished or rekeyed
[21:12] <epk> https://launchpad.net/~epkugelmass/+archive/ubuntu/jsvc
[21:13] <teward> epk: cjwatson is already aware I poked informing them that you reported it :P
[21:14] <teward> and was told there's a DB rebuild in progress :)
[21:14] <teward> *hides* :P
[21:14] <teward> cjwatson: did IS give an ETA for the rebuild? and is that a Key Server rebuild or LP database rebuild?
[21:14] <epk> Thank you. Restating the context for those not in #ubuntu-packaging =]
[21:15] <cjwatson> teward: No
[21:15] <cjwatson> (on ETA)
[21:15] <cjwatson> teward: rebuild of some bit of one of the keyserver nodes
[21:15] <cjwatson> an LP database rebuild would be a very much more dramatic operation!
[21:15] <teward> ah, OK
[21:16] <epk> Is there an issue I can follow?   *WARNING: LP IS DOWN!* (in very LOUD volume heh)
[21:16] <cjwatson> epk: No, but I'll change the topic back here when it's fixed
[21:16] <epk> Much appreciated cjwatson
[21:17] <cjwatson> There's an internal ticket with our sysadmins, but you can't see that
[22:20] <jeremy31> What launchpad group do I have to apply to to be able to get rid of spam?
[22:44] <acheronuk> cjwatson: will the PPA uploads LP is eating without trace eventually happen, or will they need to be re-uploaded?
[22:45] <acheronuk> typical. as soon as I write that, they appear. lol
[22:52] <wgrant> jeremy31: Spam is handled primarily by automated systems, and anything missed should be reported to Launchpad staff. It's not something users can or should handle themselves.
[22:53] <jeremy31> wgrant: It seems plenty of spam is on the answers.launchpad.net/ubuntu site
[22:54] <wgrant> Hm, I see maybe a dozen questions in the last week?
[22:54] <jeremy31> I think I saw some of it reported on answers.launchpad.net/launchpad already
[22:55] <wgrant> Which is a problem, but hardly "plenty" :)
[22:55] <jeremy31> https://answers.launchpad.net/ubuntu/+source/linux-aws-edge/+question/679133 is one
[22:56] <wgrant> Not any more
[22:56] <wgrant> Thanks
[22:56] <jeremy31> more from March 11
[22:57] <wgrant> That's already gone
[22:59] <jeremy31> wgrant: find the adderall and taxi booking ones too?
[22:59] <wgrant> yep
[22:59] <jeremy31> good, thanks
[23:16] <jeremy31> wgrant: one more https://answers.launchpad.net/ubuntu/+question/678948
[23:21] <wgrant> jeremy31: Ah, thanks
[23:21] <wgrant> Removed
[23:23] <jeremy31> wgrant: thanks
[23:58] <mwhudson> i thought there was a trick to get packages to build on new architectures after they've been enabled in a ppa
[23:58] <mwhudson> copying the package over itself or something?
[23:59] <mwhudson> but copy-package won't let me do it
[23:59] <mwhudson> maybe i need to use the api directly...


[12:27] <rob1> mdke, https://wiki.ubuntu.com/DocteamCompIdeas
[12:38] <mdke> rob1, interesting stuff
[12:38] <mdke> i had in mind not so much a competition as such, but more general feedback initiatives. but the competition idea might work
[12:39] <mdke> also I think we should encourage users to submit what they would like to see answered, not necessarily the answers themselves
[12:39] <rob1> well the competition will get our name and work out there
[12:39] <mdke> but obviously, if they want to, then that is even better
[12:39] <rob1> sure
[12:39] <mdke> i thought we were dropping that "How can I" phraseology?
[12:40] <rob1> yeah
[12:40] <rob1> we should, but it doesn't really look like a question then
[12:40] <rob1> but we can trim that out
[12:40] <mdke> it seemed quite unamimous at the meeting
[12:41] <LaserJock> how is this different than what is already in place? Aren't people welcome to make patches?
[12:41] <mdke> sure
[12:41] <rob1> LaserJock, yes but they are in xml
[12:41] <mdke> LaserJock, we just want to give people some encouragement
[12:41] <mdke> publicity as it were
[12:41] <rob1> this is for plain english "patches"
[12:41] <rob1> and yes, publicity mainly
[12:42] <mdke> this "credit within the doc" I don't really like
[12:42] <mdke> I don't really like the idea of author attribution at all in fact, i'd rather just "Ubuntu Documentation Team" :)
[12:42] <rob1> well we could just list them on the Credits and Licence page below everything
[12:42] <LaserJock> ahh, that makes sense. what about something like a "patch of the week" kind of thing posted on the fridge or help.u.c or something
[12:43] <rob1> mdke, yes, but according to the licences we use we need to give some credit back to them
[12:43] <rob1> LaserJock, yeah kind of
[12:43] <rob1> LaserJock, that or one with an ending date
[12:44] <mdke> rob1, you're falling into the same trap as that guy on the mailing list
[12:44] <mdke> the licence defines how people can copy OUR doc, not how we attribute contributions
[12:45] <rob1> mdke, no I'm looking at it as if the submitter is the author, and we are using a derivative of it
[12:45] <mdke> rob1, correct. so the licence that applies is the one that THEY put on their contribution, not our licences
[12:45] <rob1> so we say everything that is submitted is public domain?
[12:46] <mdke> we could. but sadly people like attribution
[12:46] <mdke> including the docteam, hence our licences :(
[12:46] <rob1> I think a lot of people in the community would get a buzz out of having their name in something
[12:46] <mdke> yes
[12:46] <mdke> it is an incentive
[12:46] <rob1> which is kind of the whole thing that spurs this on
[12:47] <LaserJock> I like the idea of an author list in a comment of the xml file
[12:47] <rob1> unless we list them somewhere on doc.u.c as winners?
[12:47] <rob1> or yes, a comment of them?
[12:47] <rob1> but the comment kind of defeats the point still
[12:47] <mdke> yes
[12:48] <mdke> if you want attribution as part of the incentive, it has to be in the authors and licensing section
[12:48] <LaserJock> you can seperate acknowledgment on a webpage and authorship in the xml, right?
[12:48] <mdke> i don't have a problem with it on a separate page
[12:48] <rob1> yeah
[12:48] <mdke> given that docteam members are attributed
[12:48] <mdke> one more thing
[12:49] <mdke> that feedback initiative shouldn't only apply to the Ubuntu Desktop Guide
[12:49] <mdke> but to everything
[12:49] <rob1> sure, that page only dealt with the compatition though
[12:49] <rob1> s/compatition/competition
[12:50] <rob1> the other docs could follow in line if we continue it as a feedback only thing after the comp
[12:51] <rob1> the competition could just be a way of promoting the feedback system
[12:51] <rob1> cool
[12:52] <mdke> i am not sure I like the idea of a competition
[12:52] <mdke> i prefer rolling feedback initiatives
[12:52] <mdke> but I dunno
[12:54] <rob1> check the page now..
[12:54] <rob1> does that sound better?
[12:55] <mdke> send it out for discussion on the ML
[12:55] <rob1> ok
[12:56] <rob1> one question, should we limit the actual competition part of it to the desktop guide?
[12:56] <manicka> sorry, I've come in late.... which page?
[12:56] <mdke> it depends on the state of the documents
[12:56] <rob1> manicka, https://wiki.ubuntu.com/DocteamCompIdeas
[12:56] <manicka> thanks
[12:57] <rob1> well I have pretty much settled on the layout of the desktop guide, just need to work out that final olink issue
[12:57] <rob1> although that will only affect the release mainly
[12:57] <mdke> cool
[12:57] <mdke> i will probably start removing "how do I" soon :)
[12:58] <rob1> the guide should validate ok, just olinkdb.xml won't at this stage
[12:58] <mdke> rob1, the problem is, how can we validate the whole guide?
[12:58] <mdke> i liked it as one page :)
[12:58] <rob1> I'm pretty sure all the individual pages validate ok by themselves too
[12:59] <rob1> mdke, just validate desktopguide.xml
[12:59] <rob1> (I think)
[12:59] <rob1> or just validate as you go
[12:59] <mdke> rob1, didn't we have this discussion before, and we discovered that it only validates the individual file
[12:59] <mdke> or did that only apply to the entities
[12:59] <rob1> probably, but at least you get the right error line
[01:00] <rob1> entites were different, they were included as is
[01:00] <rob1> xincludes are more intelligent, they are individual documents in their own right
[01:00] <mdke> i seem to remember us coming to the conclusion that it only validated one file
[01:00] <rob1> most likely
[01:00] <rob1> hang on I'll check it
[01:01] <mdke> don't worry about it
[01:01] <mdke> the other thing I'm concerned about is the complexity of the Makefile, i dunno if it is possible to make that simpler
[01:01] <rob1> mdke, no by validating desktopguide.xml you validate the whole thing
[01:02] <mdke> wicked
[01:02] <mdke> must have just been entities that don't get validated then
[01:02] <rob1> and when you do, it give you the xml file that the error is in including which line in that file
[01:03] <mdke> good
[01:03] <rob1> yes, entities are like variables, xincludes are like classes
[01:03] <rob1> (in programming lingo)
[01:04] <rob1> or in other words, entities are included as is, xincludes are used but treated separate
[01:06] <rob1> and can have their own variables etc
[01:07] <mdke> yep
[01:08] <mdke> rob1, can the processing instructions in the makefile be simplified?
[01:08] <rob1> mdke, yes, check out the testing makefile I have in the desktopguide/C/ direcotry (called mk)
[01:09] <rob1> with a bit of shell scripting I might even be able to get it simpler still
[01:09] <mdke> that is quite good
[01:09] <mdke> if we had one of each of those in each language directory
[01:09] <mdke> the generic makefile could call each one
[01:09] <mdke> as necessary
[01:09] <rob1> yep
[01:09] <mdke> that way we wouldn't have to change the address for each entry in the generic makefile
[01:10] <mdke> that would be great
[01:10] <rob1> and it would be much less clogged
[01:10] <mdke> yeah defo
[01:10] <mdke> you can eliminate the /usr/share/ bollocks by setting a variable i think, like in the ubuntu/Makefile
[01:10] <rob1> yeah
[01:11] <mdke> great work dude, that has made me happy
[01:11] <rob1> cool, glad to be of service :)
[01:11] <mdke> :)
[01:16] <Burglaptop> Madpilot, ping
[01:16] <Madpilot> Burglaptop: hi
[01:17] <Liz> whats with this ping thing?
[01:18] <Burglaptop> Madpilot, I will not be coming over this evening. Going to spend the night with C
[01:18] <Burglaptop> Liz, if you are looking for someone, you ping them
[01:18] <Burglaptop> Liz, if they are there, they pong back, ala the program ping
[01:19] <Liz> so you arent actually 'pinging' them then
[01:19] <Liz> its just a way to get attention
[01:19] <rob1> umm no not using icmp
[01:19] <Burglaptop> yes
[01:19] <Liz> ok..fair enough
[01:20] <Madpilot> Burglaptop: OK - see you next week sometime, then
[01:20] <Burglaptop> Madpilot, sounds good
[01:29] <rob1> sent a quick email to the list
[01:32] <mdke> cool
[03:10] <mdke> any kubuntu docteam people around?
[03:41] <mdke> sure it did
[03:42] <rob1> hmm my email must be playing up then
[03:42] <mdke> the one with the competition?
[03:42] <rob1> yeash
[03:42] <rob1> umm yeah
[03:45] <mdke> http://help.ubuntu.com <- about kubuntu :D
[03:46] <rob1> looks very kubuntu-ish
[03:46] <rob1> no colours though
[03:47] <mdke> i used the kde css
[03:47] <rob1> are there suppose to be?
[03:47] <mdke> sort of grey and light blue
[03:47] <mdke> works here
[03:47] <rob1> only the text is coloured
[03:48] <mdke> ?
[03:48] <mdke> text should be black
[03:48] <mdke> headings grey, links light blue
[03:48] <rob1> headings are gray, links blue
[03:49] <rob1> and the text is whatever font
[03:49] <mdke> ok so that is how it should be
[03:49] <rob1> no kubuntu logo?
[03:49] <mdke> i don't think there is one in the document
[03:49] <rob1> ah
[03:58] <mdke> bed time
[04:01] <Madpilot> there's still a CSS error in both doc.u.c and help.u.c - the header graphic doesn't got right to the top & sides of the page in Opera...
[04:04] <rob1> night mdke
[04:05] <rob1> same in ff
[04:07] <Madpilot> really? they both look OK in FF for me
[04:07] <Madpilot> I haven't bothered viewing source, but I'm willing to bet that adding padding:0;margin:0 to the body tag would solve the problem
[04:08] <rob1> its about a mm off on the left side
[04:09] <Madpilot> yeah, you're right... odd error
[04:14] <rob1> blah I have cat5 all over the place
[07:42] <Burglaptop> rob1, you should be<EMAIL_ADDRESS>[07:42] <rob1> I would think so, yes
[07:45] <rob1> brb
[07:49] <rob1> Burglaptop, how did you go with that email?
[07:51] <Burglaptop> just sent it
[07:51] <rob1> I'm assuming it is forward to whatever is my email address in launchpad?
[07:51] <Burglaptop> just bounced
[07:51] <Burglaptop> yes
[07:52] <Burglaptop> oh wait, doh
[07:53] <rob1> ah I got the one from you just then
[07:53] <rob1> looks like I can't email myself however, but at least I know it works now, thanks :)
[07:54] <Burglaptop> yes, emailing yourself causes real problems
[07:54] <Burglaptop> apparently the ubuntu mail server doesn't like it
[07:56] <rob1> oh
[08:07] <Madpilot> gah... Stephen Hermann's blog is repeating itself to planet.u.c again... old posts being reposted
[12:27] <mdke> morning all
[12:29] <mdke> Madpilot, that's been going on for months, it's super annoying
[01:44] <highvoltage> ugh. the wiki is painfully slow again.
[01:46] <mdke> :)
[01:47] <mdke> good old wiki
[01:47] <highvoltage> :)
[11:01] <Burgundavia> grrr
[11:01] <Burgundavia> how do I tell OOo not to auto link my bloody email/urls?
[11:03] <HrdwrBoB> I think it's under autocorrect
[11:05] <Burgundavia> holy crap there are a lot of useless options under Tools
[11:05] <Burgundavia> like, Use OpenGL and how many undo functions to remember
[11:18] <Burgundavia> Madpilot, ping
[11:24] <Burgundavia> salut encore, kapputu
[11:24] <kapputu> hi Burgundavia
[11:25] <Burgundavia> you are interested in helping Ubuntu?
[11:25] <kapputu> salut is French?
[11:25] <kapputu> yes
[11:25] <kapputu> very much
[11:25] <mdke>  hello again kapputu :)
[11:25] <kapputu> hi mdke
[11:25] <kapputu> I have not been involved in any open-source project before
[11:26] <kapputu> if there is something I need to read up on, I can do that
[11:26] <Burgundavia> not really
[11:26] <Burgundavia> the biggest thing you need to be aware of of is how to work as a team, which some of us (including myself) fail at occasionaly
[11:27] <kapputu> ok
[11:27] <mdke> hehe
[11:27] <mdke> surely not
[11:27] <Burgundavia> remember that any text based medium is hard to convey lots of meaning, so misunderstandings can happen
[11:27] <kapputu> I feel I'm quite adept at that, but hey we surely lose our minds sometime
[11:27] <kapputu> yes, it's difficult to convey emotions
[11:28] <Burgundavia> what interests you?
[11:28] <kapputu> with Ubuntu?
[11:28] <Burgundavia> yes, but also with computers generally
[11:30] <kapputu> I like Natural Language Processing
[11:31] <Burgundavia> have you done much programming before?
[11:31] <kapputu> yes, but I have not really learnt a lot
[11:31] <Burgundavia> don't worry, I am very much in the same boat
[11:31] <kapputu> I have dabbled with different languages
[11:31] <Burgundavia> played at all with python?
[11:31] <kapputu> I work as a Perl developer
[11:31] <Burgundavia> ah
[11:32] <Burgundavia> Ubuntu is a little python mad
[11:32] <kapputu> yes I bought Learning Python and read a few chapters
[11:32] <kapputu> yes that's why I started learning python
[11:32] <kapputu> I have been reading and working on it here and there
[11:32] <kapputu> I played with Tkinter, wxPython
[11:32] <Burgundavia> an interesting project that might need somebody is the server/laptop testing stuff
[11:33] <kapputu> sure, I have a laptop with me and I'm building a spare machine to run a file server for personal use
[11:33] <Burgundavia> currently the laptop testing is done by hand and recorded on a wiki page
[11:34] <Burgundavia> for starters it would be nice if we could have a webform and database to handle this
[11:34] <kapputu> ok
[11:34] <Burgundavia> then we could hook up a front end that makes the testing easier
[11:34] <jjesse> isn't laptop testing stuff found at LaptopTeam
[11:34] <Burgundavia> jjesse, yes it is
[11:34] <kapputu> where would it be hosted?
[11:34] <Burgundavia> if you wrote something sane, it could easily be hosted on canonical servers
[11:34] <Burgundavia> kapputu, where in the world do you live?
[11:34] <kapputu> I live in Mountain View, CA
[11:34] <kapputu> USA
[11:35] <Burgundavia> ah, same timezone as myself
[11:35] <Burgundavia> I live in Victoria, Canada
[11:35] <kapputu> oh ok
[11:35] <kapputu> so the tests are run from the command-line
[11:35] <kapputu> and you want a front-end for it?
[11:35] <Burgundavia> currently the tests are run by hand
[11:35] <Burgundavia> do the keys work, etc.
[11:35] <kapputu> ok
[11:36] <Burgundavia> https://wiki.ubuntu.com/LaptopTestingTeam
[11:36] <kapputu> can I see an example of these tests?
[11:36] <mdke> lots :)
[11:36] <Burgundavia> click on any of the links there
[11:36] <Burgundavia> that is the information we need in a good form
[11:37] <kapputu> so this information is entered by hand now?
[11:37] <Burgundavia> yes
[11:38] <Burgundavia> so bitrot is easy
[11:38] <kapputu> bitrot??
[11:38] <Burgundavia> ok, wrong term
[11:38] <Burgundavia> lazy contributers is the bigger issue
[11:38] <Burgundavia> kapputu, is this somethign that interests you?
[11:38] <mdke> really?
[11:38] <kapputu> people don't enter the information?
[11:39] <Burgundavia> they do, but often they don't keep it up to date
[11:39] <mdke> do people with Canonical laptops not keep the pages up to date?
[11:39] <Burgundavia> mdke, the canonical people do
[11:39] <kapputu> so I'll be developing this in Python and running it on Zope
[11:39] <Burgundavia> the non-canonical people are the ones I am thinking of
[11:39] <Burgundavia> what ever you like
[11:39] <jjesse> hey  not all the non-canonical people don't update thier pages :)
[11:39] <Burgundavia> ultimately the person you need to laise with Matthew Garret
[11:39] <kapputu> what I'm not understanding is what kind of form do you want?
[11:40] <Burgundavia> there are two parts as I see it
[11:40] <Burgundavia> the first part would be to create a web form with a backend
[11:40] <kapputu> so you would want something like "Screen - Ok, Not Ok (radio buttons)"?
[11:40] <Burgundavia> yes
[11:40] <kapputu> ok
[11:40] <kapputu> Bug# would be generated automatically?
[11:41] <mdke> no, the user has to file the bug I think
[11:41] <Burgundavia> people would still have to file bugs, but that can be worked on later
[11:41] <kapputu> how does the database get populated?
[11:41] <Burgundavia> people go to the webpage, sign in and enter in their data
[11:41] <kapputu> you want to generate a form based on the product?
[11:42] <kapputu> or is it a standard form for all laptops?
[11:42] <Burgundavia> a standard form for all laptops
[11:42] <Burgundavia> there would need to be an area to extend it for special stuff like card readers, etc.
[11:43] <mdke> people would also need to be able to update the information easily, for example if a bug was fixed
[11:43] <Burgundavia> after the data is entered, Matthew needs to be able to pull it out in a good form, for use in Ubuntu (or any distro)
[11:43] <mdke> and ideally, it would have multiple distro version support
[11:43] <Burgundavia> yes
[11:43] <kapputu> hmm ok
[11:43] <mdke> kapputu, however, if you'd prefer to work on docs, we have some of those too ;)
[11:44] <kapputu> any cues on what the form should look like etc?
[11:44] <Burgundavia> very much like the current wiki form is good for now
[11:44] <kapputu> I'm
[11:44] <kapputu> oops
[11:44] <Burgundavia> if you don't want to do this or don't find it interesting, just ignore me
[11:45] <kapputu> no I'm interested
[11:45] <Burgundavia> cool
[11:45] <kapputu> 1 sec
[11:46] <Burgundavia> kapputu, there are some existing pieces you can tie into. Launchpad can handle all the authentication stuff
[11:47] <kapputu> I need to know more about Launchpad
[11:47] <kapputu> I can do this in Perl if it's needed urgently
[11:47] <Burgundavia> #launchpad is you resource for that
[11:47] <kapputu> else I can learn Python and do it
[11:47] <Burgundavia> kapputu, not needed urgently
[11:47] <Burgundavia> and to write it in python makes it far more likely to be persistant
[11:47] <Burgundavia> s/is you/is your/
[11:47] <kapputu> is there some documentation on launchpad?
[11:47] <Burgundavia> hmm, don;t know
[11:48] <kapputu> ok
[11:48] <mdke> a bit
[11:48] <kapputu> should I work on documenting Launchpad :-)
[11:48] <mdke> https://wiki.launchpad.canonical.com/
[11:49] <kapputu> Zope is the web server that Python uses?
[11:49] <Burgundavia> zope is an application server
[11:49] <Burgundavia> I am not the best person to ask about this
[11:49] <mdke> https://wiki.launchpad.canonical.com/LaunchpadAuthentication
[11:50] <kapputu> so this can be developed on Apache with mod-python?
[11:50] <kapputu> sorry if I'm asking silly questions
[11:50] <mdke> jjesse, i fixed the stylesheets
[11:50] <mdke> kapputu, no idea sorry
[11:51] <kapputu> I'm not sure what my development environment should be, for this application
[11:51] <Burgundavia> kapputu, talk to siretart about REVU
[11:51] <Burgundavia> it is another python app that will need to authenticate against LP
[11:52] <Burgundavia> and eventually will be absorbed into LP, just like I imagine this work happening
[11:53] <kapputu> hmm ok
[11:53] <Burgundavia> I am writing my ideas down now
[11:54] <kapputu> so I'll look into LaunchPad and start learning how to do this in Python
[11:55] <kapputu> is there any code that I can look at?
[11:55] <Burgundavia> for which part?
[11:55] <Burgundavia> LP?
[11:55] <Burgundavia> sadly LP is currently non-free
[11:55] <Burgundavia> https://wiki.ubuntu.com/BetterLaptopTesting
[11:57] <kapputu> is there any Python code written for web applications, so that I can get a better understanding?
[11:58] <HrdwrBoB> there's a massive lot of python out there
[11:58] <Burgundavia> talk with siretart about REVU
[11:58] <HrdwrBoB> there's load of tutorials
[11:58] <HrdwrBoB> heaps of documentatio
[11:58] <HrdwrBoB> n
[11:58] <Burgundavia> it is a python based tool for the MOTUS
[12:00] <kapputu> HrdwrBoB, tutorials in REVU?
[12:01] <HrdwrBoB> possibly not, but python in general
[12:01] <kapputu> ok
[12:02] <kapputu> Burgundavia, I'll get back to you soon on this
[12:03] <kapputu> I'll develop a prototype with Perl and SQLite
[12:03] <Burgundavia> kapputu, cool, thanks
[12:04] <kapputu> how should I contact you if I don't find you here?
[12:04] <mdke> you'll find him :)


[00:15] <danilos> henninge, tomorrow at 9am, ack if you read this
[00:15] <henninge> danilos: ack ;)
[00:17] <danilos> henninge, thanks
[00:38] <cjwatson> mwhudson: any news on the openssh import ticket?
[00:39] <mwhudson> cjwatson: :(
[00:56] <mwhudson> cjwatson: so keep an eye on https://code.staging.launchpad.net/~vcs-imports/openssh/main ?
[00:58] <cjwatson> mwhudson: ok
[00:58]  * mwhudson lunches
[00:58] <mwhudson> about two hours later than i wanted to oh well
[00:59] <mwhudson> cjwatson: the patches will stay there for about 24 hours, so hopefully a failure can be triggered before then
[02:40] <mwhudson> cjohnston: i see the openssh import failed, did it help you at all?
[02:42] <spm> mwhudson: cjwatson perhaps?
[02:43] <mwhudson> spm: bah, yes
[02:43] <mwhudson> cjwatson: i posted a link to the question
[04:31] <quotemstr> Say I want to host a feature branch of emacs on launchpad. Can I just create ~/+junk/emacs-foo and bzr push my branch there?
[04:32] <lifeless> well, ~quotemstr/+junk/emacs-foo, yes
[04:32] <lifeless> but better to push to
[04:32] <lifeless> ~quotemstr/emacs/foo
[04:32] <quotemstr> Doesn't that copy the *whole* repository? Isn't that a little wasteful?
[04:33] <lifeless> no, and no
[04:33] <lifeless> pushing to +junk would copy the whole repository, and be a little wasteful
[04:33] <quotemstr> Ah -- what's special about +junk? Also, does it matter that my branch's parent is a local checkout of the Savannah emacs bzr trunk and *not* lp:emacs?
[04:34] <lifeless> nothing special about +junk in this context, just that +junk != emacs
[04:34] <quotemstr> Oh, so it's not that +junk is magical, but that ~quotemstr/emacs is?
[04:35] <lifeless> ~user/project/branch - the project dir has a control file that tells bzr to use lp:project for common history
[04:35] <quotemstr> Ahhh, I see.
[04:35] <lifeless> lp:emacs is savannah emacs bzr trunk
[04:35] <quotemstr> lifeless: I noticed. :-) But will bzr share history even though my branch is derived from Savannah instead of lp:emacs?
[04:35] <lifeless> yes
[04:36] <lifeless> because they are the same thing
[04:50] <quotemstr> Thanks. :-)
[04:57] <zooko> Hey folks I hit a bug in launchpad so I tried to use launchpad to report a bug in launchpad, but that same bug prevents me from opening the new ticket.
[04:57] <zooko> I'm guessing this channel is a reasonable backup method of letting you know.
[04:58] <wgrant> zooko: What's the issue?
[05:01] <zooko> http://codepad.org/NXWcQMNc
[05:01] <zooko> wgrant: --^
[05:01] <zooko> Hm, I wonder how that weird URL got in gthere.
[05:02] <zooko> Corrected my but report.
[05:02] <zooko> I mean my bug report.
[05:02] <spiv> zooko: that's possibly because your browser isn't sending a Referer header
[05:02] <wgrant> Very probably.
[05:03] <wgrant> The error message sucks at the moment, but that's the most common cause.
[05:06] <zooko> Ah. Yes I think I've disabled Referer on my browser for security reasons.
[05:06] <zooko> Thinking back, I can't recall any other breakage since then.
[05:07] <zooko> I wonder if I can tell my firefox to send Referer headers only to launchpad.net...
[05:07] <zooko> Thanks folks.
[07:30] <glen> i was thinking maybe you can tell me why the import hasn't been done yet: https://code.launchpad.net/~glen666/smarty-gettext/trunk
[08:25] <knielsen> Hi, I need help with<EMAIL_ADDRESS>. I have the problem that some emails to the list got silently dropped
[08:25] <knielsen> (This is the main MariaDB development list, so silent drop of messages is really bad for us)
[08:25] <knielsen> I have the original message which got lost, don't know if there is anything else I can provide?
[08:29] <knielsen> https://knielsen-hq.org/maria/launchpad-email.txt
[08:30] <knielsen> this email was silently dropped, no request for moderation. Once the user added his email address in the launcpad account, a re-send was help for moderation (and subsequent messages went through without moderation)
[08:30] <knielsen> this seems wrong, we should have gotten a moderation message for the first message (when the correct email was not registrered), not a silent drop
[08:38] <buxy> wgrant: did you poke people about the support of new source formats?
[08:42] <buxy> and can you enable it for jaunty PPA too?
[08:44] <wgrant> buxy: It's been enabled in Karmic since yesterday.
[08:44] <buxy> cool :)
[08:45] <buxy> jaunty almost has the final version that went in lenny r0, I think is should be fine there too
[08:45] <buxy> s/is/it/
[08:46] <wgrant> buxy: Hmm, I guess.
[08:48] <buxy> (someone asked on debian-devel)
[08:49] <wgrant> Jaunty dies in a few months and we haven't tested is support, so it's less compelling. But it's trivial to enable and again will just result in build failures... so... hmm.
[08:49] <wgrant> s/is/its/
[08:51] <StevenK> buxy: And they didn't get killed for daring to mention Launchpad or PPAs?
[08:51] <buxy> StevenK: not yet (I did mention it first, but people are trying to kill me for other reasons)
[08:51] <wgrant> StevenK: Didn't you know we're all meant to use dak?
[08:51] <StevenK> wgrant: Oh. clearly
[09:05] <wgrant> buxy: Ah, so it was in *that* thread. I wasn't quite up to date there.
[09:06] <wgrant> bigjools: Morning.
[09:07] <wgrant> buxy says that Jaunty's dpkg isn't too bad either.
[09:07] <bigjools> moin
[09:44] <dspstv_> morgen
[09:45] <dspstv_> is theres a way to know the build times on the servers for today? i mean, i submitted a package 11hours ago and it still is in the queue
[09:46] <dspstv_> since this is my fisrt ever package i was wondering is those long waits are normal?
[09:49] <geser> dspstv_: see https://edge.launchpad.net/builders/, as several PPA buildds are being used for other tasks, it takes currently a little bit longer than usual
[09:50] <wgrant> dspstv_: Most of the build machines are currently testing the upcoming Ubuntu 10.04, so queues are much, much longer than normal. Normally things start building instantly, or within a few minutes.
[09:53] <dspstv_> https://help.launchpad.net/Packaging/BuildScores
[09:53] <dspstv_> thanks geser, wgrant
[11:51] <getxsick> in my debian/control file all packages have 'i386' or 'all' architecture, however PPA tries to build for amd64 and lpia. how to avoid it?
[15:39] <zookow> Dear people of #launchpad: I just get this pop-up dialog from http://launchpad.net: Error
[15:39] <zookow> The following errors were encountered:
[15:39] <zookow>
[15:39] <zookow>     * Server error, please contact an administrator.
[16:01] <zookow> okay I opened a ticket about this. Thanks!
[16:50] <mtaylor> launchpad should have a javascript implementation of emacs that will allow people to make a branch, edit it, commit, and submit for merge all within their web browser
[17:05] <cjwatson> LOSA: is it possible to cause another import attempt to run on https://code.staging.launchpad.net/~vcs-imports/openssh/main on strawberry (which I think is the one that had a patch cowboyed onto it)?
[17:09] <chex> cjwatson: err, strawberry is (not/no longer one) of the importd's..
[17:10] <cjwatson> huh, it was last night
[17:10] <cjwatson> this is with regard to https://answers.edge.launchpad.net/launchpad-code/+question/105130
[17:47] <KdaG> my build process got stuck since few hours now:
[17:47] <KdaG> https://launchpad.net/~alejoduque/+archive/ppa-alejo/+build/1581509
[17:48] <KdaG> almost 19 hours for a very small package,,, wonder if i did something worng..
[17:48] <KdaG> wrong
[17:49] <bigjools> KdaG: it's only been building for 4 hours
[17:49] <bigjools> how long does it usually take?
[17:50] <KdaG> bigjools: that takes a minute on my local machine
[17:51] <KdaG> bigjools: its been stuck on the same point for 3 hours now
[17:51] <bigjools> ok I'll take a look
[17:51] <KdaG> thanks
[17:51] <KdaG> i386 built just fine
[17:54] <bigjools> KdaG: I've killed the old build, it'll restart in a moment on a new builder
[17:54] <KdaG> bigjools: tx
[17:54] <bigjools> happens sometimes, dunno why :/
[17:55] <KdaG> yes, well since is my first pakage i feel guilty inmedately
[17:55] <KdaG> :)
[17:57] <bigjools> how are you finding things?
[17:58] <KdaG> well, yesterday it took me a good deal to find out that debuild was not able to overwrite the files
[17:59] <KdaG> it was reporting success
[17:59] <KdaG> but dput was failing cause of a problem with the signature on debian/changelog
[18:00] <KdaG> now, it seems the servers are to tired with 10.4 so 19hours to see the packages on the PPA is a bit of a wait
[18:10] <KdaG> bigjools: thanks see
[18:10] <KdaG> amd64 build of din <IP_ADDRESS>-0ubuntu0~alejoduque2 in ubuntu karmic RELEASE
[18:10] <KdaG> Build started 4 minutes ago on dubnium (virtual) and finished 1 minute ago taking three minutes
[18:10] <KdaG> ooh he quit
[18:38] <getxsick> in my debian/control file all packages have 'i386' or 'all'  architecture, however PPA tries to build for amd64 and lpia. how to  avoid it?
[18:52] <davidstrauss> Can I rename the URL for a project?
[19:36] <aapo> Hi, I just made my first PPA package for karmic. How I made same time for another releases too?
[19:37] <dspstv_> aapo: hi, i also finished one few hours ago
[19:38] <dspstv_> aapo: cant really understand your question
[19:39] <geser> aapo: you need to modify the version slightly (e.g. by appending ~jaunty or similar), update the distribution in debian/changelog and reupload
[19:40] <aapo> geser, ok. So there are no way to put hardy karmic lucid in same row on debian/changelog
[19:42] <geser> no
[19:43] <geser> as all build debs get stored in the same directory and the filename contains the version, but your upload with the same version to different releases will most likely produce different debs (e.g. linked against different library versions), this won't work
[19:44] <aapo> geser, ok. this is good reason why it doesn't work
[19:46] <aapo> Is there ready made script to handle this upstream code changing -> four different changelog/uploads
[19:47] <aapo> Or is somebody planning to change way how builder works? Maybe it could store files for different releases in own subdirectories?
[19:50] <geser> I don't know of any script for this
[19:50] <gnomefreak> was the "not sure what it is called" when you get upstream comments on Lp bugs turned off? or broken?
[19:50] <gnomefreak> nevermind
[19:52] <getxsick> geser: what about 'copy packages'?
[19:52] <getxsick> isn't a way to do it?
[19:54] <geser> you can only copy your own packages with source+binaries to a different release -> no rebuilds are done
[19:55] <getxsick> geser: right...i do only python packages, so mostly this is not a problem
[19:55] <geser> yes, for python packages this is an option
[19:56] <getxsick> however, i still have a problem with other architectures than i386, one of the package only supports i386..i set it in debian/control but PPA still tries to build for amd64 and lpia
[19:59] <geser> getxsick: what's the package and your PPA?
[19:59] <getxsick> geser: https://launchpad.net/~pypy/+archive/ppa
[20:05] <geser> getxsick: your debian/rules correctly only mentions i386 and all, yet the .dsc file contains "any" (which explains the build). But I don't know how the architecture field for the .dsc file is computed.
[20:06] <getxsick> geser: any idea where to investigate?
[20:06] <getxsick> geser: i run `debuild -S -sa` to build it
[20:07] <geser> which is correct, you might need to look at the source of dpkg-source
[20:28] <geser> lamont: it looks like the armel buildd "gourd" got hit by bug #1583047. The recent builds on this buildd for lucid failed with "dpkg-deb: control directory has bad permissions 700 (must be >=0755 and <=0775)"
[20:28] <lamont> geser: gar
[20:29] <geser> I mean bug #517802
[20:29] <lamont> geser: so, it's got the change in init.d to launch with 022
[20:30] <lamont> restarted the buildd, will retry the failed builds just to see
[20:38] <lamont> geser: not 700 now
[20:38] <geser> thanks
[20:39] <lamont> thank you.  brand new buildd and more reason for me to roll out a new launchpad-buildd package
[20:57] <aapo> I made initial script for modifying_changelog+debuild+dput for each release. At this moment all actual doing is only echo. Anybody interested in review it: http://cc.oulu.fi/~rantalai/for_ppa.txt ?
[20:58] <aapo> I know this has limited use, because releases have different libraries for dependencies and so on. But I think somebody else might use it too.
[21:06] <getxsick> depends from packages are not installed by buildbot right? only build-depends? i'm asking cause i would like to run testsuit and wondering if i should add some depends from packages straight to build-depends...
[21:07] <geser> right, only build-depends are installed
[21:32] <sirver_> Hi
[21:32] <sirver_> is there another way to upload files to launchpad than via web or ftp polling?
[21:32] <sirver_> web times persistently out for me (widelands packages are big...)
[21:33] <sirver_> and ftp polling can't be used because our versioning scheme is different then needed
[21:43] <aapo> sirver_, what you mean 'different than needed'? Can you use Build 15 rc 2 -> widelands_build15_rc2 ?
[21:45] <aapo> sirver, and I think widelands_bzr5123 is acceptable too
[21:49] <sirver_> aapo: I thought the versions would need to be 0.8.1 or therelike
[21:51] <aapo> I have only put 0.0.20100325-5~hardy to PPA, but with debuild -S -sa I can make build15_rc2 and bzr512 (just tested them)
[21:51] <sirver_> aapo: okay, thanks. So i'll try that ;)
[22:19] <aapo> Script for automating pushing sources for many releases: http://cc.oulu.fi/~rantalai/for_ppa.txt  It only needs your name and address of ppa.
[22:46] <snake007v> Prompt please, how to remove lauchpad project(ppa)?
[22:49] <wgrant> snake007v: A project, or a PPA? They are distinct entities.
[22:50] <snake007v> wgrant: project
[22:51] <wgrant> snake007v: Ask at https://answers.launchpad.net/launchpad/+addquestion, and an admin can do it for you.
[22:51] <snake007v> wgrant: thx


[05:16] <infinity> slangasek: Can you accept that telepathy-qt build fix of mine in the queue?
[05:17] <slangasek> let's see
[05:21] <slangasek> infinity: accepted
[05:25] <infinity> slangasek: Shiny.  Worked in a PPA, so here's hoping the no-determinstic world of C++ symbols doesn't break it again. :P
[05:25] <infinity> (I swear the list kept changing on every test build... Ridiculous)
[09:36] <ogra_> argl !
[09:37] <ogra_> please someone let the nux upload in, it has the same issue unity had
[09:37] <ogra_> (trivial one line fix to make arm work)
[09:42] <infinity> ogra_: Oops.
[09:44] <infinity> ogra_: Are we holding unity up on the bizarre .pot diff?
[09:46] <infinity> I guess queuebot answered that. :P
[09:51] <ogra_> infinity, nah, slangasek said thats no stopper
[09:57] <ogra_> GRRR
[09:57] <ogra_> seems thats not enough for a buildd ... needs fixes for the deps too
[09:58] <infinity> I take it you didn't test in sbuild?  Naughty Oli.
[09:58] <ogra_> (it built in my chroot but that had unity b-deps already, grumble)
[10:00] <ogra_> hmm, still doesnt work, i suspect we need a no-change upload for unity too after nux has built
[10:00] <ogra_> sigh, thats such a mess
[10:02] <infinity> ogra_: Look on the bright side.  You haven't wasted a long weekend with intense pain, foreign hospitals, and sitting in airports.
[10:02] <infinity> And uploading libreoffice...
[10:02] <ogra_> oh, yeah, tha latter is worst ...
[10:03] <infinity> At least it gave me time to sort out the geis and friends library rename in oneiric.
[10:03] <ogra_> no, i havent, but i promised my mom on friday to come back today ... so i dont have eternal time to hunt that mess down :/
[10:03] <infinity> That was the last round of NEW for it.
[10:05] <ogra_> i dont get why the packaging from precise was just carried over modulo the gles patch
[10:05] <ogra_> *wasnt
[10:22] <ogra_> infinity, now with fixed deps :)
[10:27] <ogra_> thx
[10:30] <infinity> NP.
[10:30] <infinity> I need someone to review that LibO for me.
[10:31] <ogra_> i can take a look for obvious stuff, but dont tryst my skills if it comes to C++
[10:31] <infinity> It's make/shell.
[10:31] <infinity> Just debian/rules.
[10:31] <ogra_> *trust even
[10:32] <ogra_> link ?
[10:32] <infinity> http://launchpadlibrarian.net/114393345/libreoffice_1%3A3.6.1~rc2-1ubuntu2_1%3A3.6.1~rc2-1ubuntu3.diff.gz
[10:33] <ogra_> well, looks sane ... what *is* ca-XV actually ?
[10:33] <ogra_> chinese canadian ?
[10:34] <infinity> Hahaha.  I have no clue. :P
[10:34] <infinity> ca is Catalan though, isn't it?
[10:34] <ogra_> oh, indeed
[10:35] <ogra_> its funny that the typo isnt in the rm line
[10:35] <infinity> The rm line was in the previous revision.
[10:35] <ogra_> heh, k
[10:35] <infinity> The 4 lines I changed were all new.
[10:36] <infinity> (Well, the previous previous... You know what I mean)
[10:36] <ogra_> we'll i'd say upload ... cant get worse anyway
[10:36] <infinity> It's uploaded. :P
[10:36] <infinity> But not accepted.
[10:36] <infinity> I suppose it's a given that we want libreoffice built on i386, so I can fudge release management to use your review to leverage my other hat...
[10:37]  * ogra_ wonders if slangasek's cats play with the cable
[10:38] <infinity> ogra_: I'll accept it and blame you.  Welcome to the release team for the next 10 seconds.
[10:38] <ogra_> haha, go ahead
[10:42] <ogra_> hmm, with the right b-deps nux takes significantly longer to build on arm
[10:45] <infinity> ogra_: Hahaha.
[10:45] <infinity> ogra_: I'd say that's likely a good sign. :P
[10:56] <Laney> oh, nice, I was just going to upload LO
[11:09] <infinity> Laney: Does your diff match mine?  That would be a nice sanity check.
[11:38] <infinity> ogra_: nux copied to -release
[11:45] <Laney> yeah, think so
[11:46] <infinity> Laney: So you caught the missing "cat" too? ;)
[11:46] <ogra_> infinity, yeah, i saw, thanks
[11:47] <Laney> I lined up the &&s for sanity, then it stood out
[11:48] <infinity> Laney: Fair enough. ;)
[11:49] <Laney> that's about as far as the sanity goes
[11:50] <Laney> probably enough libreoffice for the next year ;-)
[11:50] <infinity> Amen.
[11:56] <ogra_> infinity, one more unity upload and we're done ...
[11:56] <ogra_> (no change ... should be in the queue in a second)
[12:01] <ogra_> there it is
[12:02] <ogra_> while there is a flickering issue when moving windows around (which i'm happy to release B1 with) it seems to all work fine ... yay
[12:04]  * ogra_ will leave that bit to rsalveti :)
[12:17] <Laney> ogra_: why the diff?
[12:25] <ogra_> Laney, which diff ?
[12:26] <ogra_> Laney, http://paste.ubuntu.com/1181348/
[12:26] <ogra_> thats what i uploaded
[12:29]  * ogra_ has to go now else my mom will get angry
[12:29] <Laney> ogra_: check the diff on Launchpad
[12:29] <ogra_> url ?
[12:29] <Laney> sec
[12:30] <ogra_> i can only see approved stuff usually
[12:30] <Laney> https://launchpad.net/ubuntu/quantal/+queue?queue_state=1
[12:31] <Laney> https://launchpadlibrarian.net/114433172/unity_6.4.0-0ubuntu2_6.4.0-0ubuntu3.diff.gz
[12:31] <ogra_> oh, ignore the diff.gz, better check with debdiff
[12:31] <ogra_> 6.4.0 is a complete mess (accidentially uploaded as native etc)
[12:32] <ogra_> the debdiff should be fine (there is no orig.tar.gz anywhere, not even in the unity PPA so we have to live with that mess until someone re-packages)
[12:33] <ogra_> anyway, i'm hours late due to that sh*t and i'm out now
[12:34] <Laney> I see the same thing when I debdiff
[12:34] <Laney> yeah, gotta go fix my bike actually :P
[12:34]  * ogra_ really didnt plan to woth through for two days including a half nightshift
[12:34] <Laney> can look later
[12:34] <ogra_> F*CK !!!!
[12:34] <Laney> go away!
[12:34] <Laney> /kick
[12:34] <ogra_> why does LP show something different from what i see here
[12:35]  * ogra_ doesnt get that
[12:35] <ogra_> anyway, out now, if it isnt fixed tonight when i return i'll take another look ... its just a rebuild after all
[12:36]  * ogra_ waves
[15:32] <jbicha> is it intentional that the i386 quantal daily has the German language pack but amd64 doesn't?
[16:20] <Mirv> ogra_: the unity tarball was uploaded to https://launchpad.net/unity on Friday
[16:21] <Mirv> https://launchpad.net/unity/6.0/6.4/+download/unity-6.4.0.tar.bz2
[17:26] <stgraber> jbicha: yes
[17:26] <stgraber> jbicha: there's more room on 32bit images than on 64bit
[17:27] <jbicha> stgraber: what limit are we shooting for, for quantal? because if it's 800MB, we have room, right?
[17:28] <stgraber> jbicha: it's usually something we tweak around release but yeah, we'll likely fill some of the remaining space on all images with langpacks
[17:29] <stgraber> though i386 will still likely have more langpacks than amd64, just because the files tend to be smaller, leaving more room for langpacks
[17:29] <jbicha> ok, cool
[17:39] <Laney> ogra_: rejecting yours, mine has the expected diff
[17:39] <Laney> stgraber: could you maybe look at unity please? (no-change rebuild)
[17:47] <stgraber> Laney: sure
[17:48] <stgraber> accepted
[17:48] <slangasek> ogra_: nah; I seem to have been having some IPv6 routing problems last night
[18:46] <Laney> oh. argh.
[18:47] <Laney> https://launchpad.net/ubuntu/+source/unity/6.4.0-0ubuntu3
[21:02] <ogra_> Laney, thx, checking the log
[21:04]  * ogra_ scratches head
[21:04] <ogra_> that cant be ..
[21:06] <ogra_> it doesnt do that in a local build
[21:13] <ogra_> hmm, i wonder why
[21:14] <ogra_> given that dash/previews/CMakeLists.txt actually hadcodes the linker stuff
[21:14] <ogra_> *hard
[21:16] <ogra_> Mirv, any idea about https://launchpadlibrarian.net/114534081/buildlog_ubuntu-quantal-armel.unity_6.4.0-0ubuntu3_FAILEDTOBUILD.txt.gz woudl be appreciated
[21:17]  * ogra_ really isnt good at cmake
[21:18] <ogra_> i understand that -lGL -lGLU is hardcoded in dash/previews/CMakeLists.txt
[21:20] <ogra_> (i still dont understand why it builds locally ... i actually built that version twice successfully here )
[21:24] <iulian> Why are new versions of packages being uploaded without a bug reference number? The diff is huge and impossible to review. :-(
[21:25] <ogra_> what package are you referring to ?
[21:26] <iulian> ogra_: nemiver, caribou, genius.
[21:27] <iulian> They were uploaded just a few minutes ago.
[21:27] <ogra_> well, its universe, does FF apply there ?
[21:27] <Laney> FF certainly does, beta freeze not
[21:28] <ogra_> hrm, the cmale syntax doesnt seem to know "else"
[21:28] <iulian> They should've been approved first before uploaded.
[21:28] <ogra_> *cmake
[21:29] <rsalveti> ogra_: I'm working on trying to get the kernel in place for a fully working unity on panda now
[21:30] <ogra_> rsalveti, well, i would first like a working unity at all
[21:30] <jbicha> caribou is a GNOME micro-release on the way to the next stable release so that should be fine
[21:30] <rsalveti> ogra_: what is the issue still?
[21:30]  * rsalveti just got back from plumbers
[21:30]  * ogra_ already spent his whole weekend to sort that mess
[21:31] <ogra_> /usr/bin/ld: cannot find -lGL
[21:31] <ogra_> /usr/bin/ld: cannot find -lGLU
[21:31] <ogra_> https://launchpadlibrarian.net/114534081/buildlog_ubuntu-quantal-armel.unity_6.4.0-0ubuntu3_FAILEDTOBUILD.txt.gz
[21:31] <ogra_> some new code that hardcodes GL
[21:31] <rsalveti> I just the bug you sent me, but I believe it was all lack of the right build dependencies?
[21:31] <rsalveti> :-((
[21:31] <ogra_> funnily i can build it locally in a clean chroot on armhf without *any* issue
[21:32] <iulian> jbicha: I can't see any bugs mentioned in the changelog. How are we supposed to know that? :(
[21:32] <ogra_> rsalveti, looking at dash/previews/CMakeLists.txt ... there is  ....  set (LIBS ${CACHED_UNITY_DEPS_LIBRARIES} "-lunity-core-${UNITY_API_VERSION} -lm -lGL -lGLU") ...
[21:32] <rsalveti> oh, hardcoded
[21:32] <ogra_> i could just override that with an if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l") it seems ...
[21:33] <ogra_> but there is no "else" command and i'm not sure if one set just overrides a formerly set one
[21:33] <rsalveti> I believe there's a way to depend on when you're building for gl or gles
[21:33] <ogra_> read: i have not much clue about cmake
[21:33] <ogra_> that seems to be our last showstopper
[21:33] <jbicha> iulian: the NEWS entry in the caribou diff is rather small...
[21:34] <rsalveti> alright, will set my builders and machines so I can give it a try
[21:34] <ogra_> my locally build unity works just fine (apart from an off flickering bug but i'm willing to live with that for B1)
[21:34] <rsalveti> ogra_: at least we have all the right packages in place already, right?
[21:34] <rsalveti> I mean, the version which all supposes support gles
[21:34] <ogra_> rsalveti, yup, compiz and nux are fine now
[21:34] <rsalveti> yeah, cool
[21:34] <ogra_> and the current desktop image has PVR OOTB
[21:34] <rsalveti> that's great :-)
[21:34] <ogra_> right on first boot
[21:36] <rsalveti> ogra_: will take a look in a few
[21:37] <rsalveti> the kernel changes are also possible for b1, but not that critical I'd also say
[21:37] <rsalveti> and the changes are quite intrusive, so we'd probably need a few days for testing and such
[21:37] <ogra_> rsalveti, thx, i'm really getting exhausted after the second day with the same crappy stuff
[21:37] <ogra_> yeah, lets keep them for post beta
[21:37] <rsalveti> cool
[21:38] <ogra_> the current kernel is ok ... it boots and all devices seem to work :)
[21:38] <rsalveti> yeah :-)
[21:40] <ogra_> oh, if you touch unity, beware, it somehow turned into a native package with the last upstream dump
[21:40] <rsalveti> oh, ok
[21:41] <ogra_> and the clean target doesnt seem to properly clean up, check your debdiffs ;)
[21:41] <rsalveti> haha, ok :-)
[21:50] <iulian> jbicha: I've just noticed it's a bug fix upload. It would've made my life a lot easier if I had seen "bug fix release" somewhere in the changelog. I personally first read debian/changelog when I review things so I know what to expect.
[21:57] <micahg> Laney: with the new ubuntu-gnome, beta freeze might indeed apply to those packages
[21:59] <ogra_> micahg, why, does it apply to xubuntu or lubuntu (beyond what they define as freeze themselves)
[21:59] <ogra_> ?
[22:00] <jbicha> caribou is the only one out of that set that is part of ubuntu-gnome
[22:00] <micahg> ogra_: beta freeze applies to packages that affect all images (I was supposed to fix the wiki)
[22:00] <micahg> s/all/any/
[22:00]  * micahg does that now
[22:01] <ogra_> ah, k
[22:01] <ogra_> i thought its up to the flavours to decide that for their packagesets
[22:02] <micahg> ogra_: flavors can decide if something should get in or not if it only affects them
[22:02] <ogra_> yeah, thats what i remembered
[22:03] <micahg> but they still need to coordinate with the release team and not just blindly upload
[22:08] <micahg> if anyone wants to review https://wiki.ubuntu.com/BetaFreeze?action=diff&rev2=8&rev1=7 to make sure I didn't miscommunicate anything
[22:09]  * ogra_ finds it confusion that the wiki marks deletions in green
[22:10] <ogra_> *confusing
[22:10] <ogra_> micahg, i would add a line about flavurs
[22:10] <ogra_> i.e. "this also applies to derivative flavour images built in the ubuntu infrastructure" or some such
[22:10] <micahg> ogra_: saying what?  flavors ship images the same as anyone else
[22:11] <micahg> ok
[22:12] <micahg> done
[22:14] <ogra_> perfect :)
[22:17] <xnox> micahg: ogra_: my understanding was that we were meant to use proposed somehow....
[22:18] <ogra_> well, yes and no :)
[22:18] <micahg> xnox: yeah, I didn't include anything about that as the previous version didn't :)
[22:18] <ogra_> proposed in any case for sets of packages that have a dependency chain
[22:18] <micahg> proposed can be used during freeze to continue uploads as well
[22:19] <micahg> oh, hrm, maybe not this time around :)
[22:19] <micahg> wasn't included in the release announcement
[22:19] <ogra_> well, it will still work as last time :)
[22:46] <slangasek> ogra_: so in nux supposed to be fixed now in quantal?  compiz still segfaults for me here
[22:46] <ogra_> do you run compiz standalone without unity ?
[22:47] <slangasek> ogra_: I'm trying to use the default desktop
[22:47] <ogra_> (else its likely unity that segfaults ... unity being a set of compiz plugins somewhat hides where the crash actually comes from)
[22:47] <ogra_> (thats actually why i spent so much time in looking into compiz instaed of unity in the beginning yesterday
[22:47] <ogra_> )
[22:48] <ogra_> slangasek, i just updated bug 1044709
[22:48] <ubot2`> Launchpad bug 1044709 in unity "unity-6.4.0 from quantal-proposed crashed with SIGSEGV on omap4" [Critical,Fix released] https://launchpad.net/bugs/1044709
[22:48] <ogra_> slangasek, and rsalveti is looking into fixing it
[22:49] <ogra_> what i still dont get is why it builds properly in a local chroot on armhf here
[22:49] <ogra_> i could give you properly working binaries :) my panda desktop runs just fine over here
[22:55] <slangasek> ogra_: so that unity task should be reopened then?
[22:56] <ogra_> yes
[22:56] <ogra_> something like this should fix it i guess http://paste.ubuntu.com/1182513/
[22:57] <ogra_> (untested and not 100% sure since i dont speak cmake ...)
[22:57] <ogra_> but i guess rsalveti has a better and cleaner way
[22:58] <ogra_> (or will find one at least)
[22:58] <slangasek> well, the first part shouldn't be done that way... -fPIC should be the default, not the exception
[22:58] <slangasek> (and I wonder if they have a good reason for not using -fPIC on i386)
[22:59] <ogra_> it is like that in all other CMakeLists.txt files in the source
[22:59] <ogra_> that part i just took over from the others
[22:59] <slangasek> oh; then I guess unity is completely broken on powerpc
[22:59] <slangasek> because that sure isn't going to work on any !x86 arch :P
[23:00] <ogra_> well, as i said, it works fine on armhf (even without that fix) over here ... i must have a magic chroot or something ...
[23:01] <ogra_> i even re-rolled the chroot today to make sure its clean
[23:03] <ogra_> (several times)
[23:06]  * ogra_ sets the bug back to triaged
[23:25] <xnox> ogra_: cmake syntax looks valid, but it is not very CMake'ish way to set -fPIC
[23:26] <xnox> slangasek: while I agree that -fPIC should be the default, but little does CMake care....
[23:47] <ogra_> xnox, yeah, starting a testbuild now, i have set up my build env completely from scratch now, we'll see how it goes


[16:25] <balloons> tsimonq2, looking
[16:26] <balloons> tsimonq2, nice catch. I would report a bug against the testcase, and we'll remove it from the suite. I suppose I could just do it now . . .
[16:27] <balloons> Done. But now you know in the future
[18:51] <tsimonq2> ok :)