[22:33] <bkerensa> wxl: I could do one in the summer at some point if its Mozilla focused :)
[22:33] <wxl> bkerensa: would love it. pick a first tuesday and give me a topic.
[22:34] <wxl> bkerensa: did i tell you lars came and told us all about socorro?
[22:35] <bkerensa> wxl: June 2nd: Firefox Dev Edition on Ubuntu? :)
[22:35] <wxl> bkerensa: sounds quite possible. i'm sure we know how to install it. :) what about showing it's true value in development. you could start by hacking the euglug.org website and make it something that doesn't suck XD
[22:36] <bkerensa> wxl: oh the Larsalope is a mystic creature
[22:37] <wxl> bkerensa: no kidding! i like that guy!!
[22:37] <bkerensa> wxl: yeah that was the plan :) show why its awesome
[22:37] <bkerensa> wxl: https://twitter.com/2braids/status/541379592414433282
[22:37] <bkerensa> the Larsalope
[22:37] <wxl> i know i saw XD
[22:37] <bkerensa> Mystic Oregon Creature :)
[22:37] <wxl> i thought i favorited that
[22:38] <wxl> i'll push it through the ranks and confirm with you later, bkerensa
[22:39] <bkerensa> wxl: cool and I can see about Mozilla buying lunch or dinner
[22:39] <wxl> neat bkerensa :) we don't usually even have so much as snacks so that would be super great
[22:40] <wxl> bkerensa: might be interested to talk about contributing to mozilla, too. e.g. how we might make firefox dev even better :)
[22:40] <bkerensa> right
[22:40] <wxl> okie dokie, i'll let you know. thanks very much!!!
[22:41] <bkerensa> sgclark: when are you doing a Ubuntu Hour in Hillsboro/Portland?
[22:41] <wxl> yeah, sgclark! when? :)
[22:41] <sgclark> when I get have breathing room
[22:41]  * wxl is >> almost there << with regards to having a global jam set up
[22:41] <bkerensa> Mm its been so long since a Oregon Global Jam
[22:42] <sgclark> I took on a project much larger than I can swallow
[22:42] <sgclark> oops
[22:42] <bkerensa> uh
[22:42] <wxl> bkerensa: did you see in the backlog sgclark may do a talk for us, too? well, when she's not drowning.
[22:42] <wxl> bkerensa: let it go. :)
[22:42] <bkerensa> cool
[22:42] <sgclark> so I hope to be able to breath soon
[22:42] <bkerensa> understandable
[22:43] <bkerensa> sgclark: well if you ever want to do one at Mozilla's office let me or bkero know and I'm sure we can sort it out
[22:44] <bkerensa> bkero: so what is the protip for install Ubuntu Server on the minis without Keyboard/Mouse?
[22:44] <bkerensa> I just had to order a USB keyboard today because I realized I couldn't do an install without a keyboard
[22:45] <bkerensa> wxl: also you know if we ever get colo space slangasek has the LoCo's server
[22:45] <bkero> bkerensa: a preseed file I would suppose
[22:45] <bkero> bkerensa: there's a wireless keyboard/mouse in my cube that you're welcome to take and use
[22:45] <bkero> You might have to hunt for the pieces a bit :)
[22:45] <bkero> There's a USB receiver so they should be transparent to the system
[22:46] <bkerensa> bkero:  ah I got them coming tomorrow morning Amazon Prime but just was wondering if I had missed something
[22:46] <bkerensa> bkero: looking into preseeding now
[22:47] <bkerensa> bkero:  now if I can figure out a good way to have one power source for four minis
[22:47] <bkerensa> :D
[22:47] <bkero> bkerensa: Good luck. They're not just simple power sources.
[22:47] <bkero> Not simple DC consumers, they have multiple DC voltages.
[22:48] <sgclark> ok thank you, most of the current work I am doing involves continuous integration, aka docker/jenkins etc
[22:49] <wxl> bkerensa: naw, haven't looked into it yet. i'm almost feeling like i should.
[22:49] <bkerensa> bkero: So I saw mrz did something early on in the DC to get the minis to use one supply but it looked like some janky electrical work that could burn down a a house :)
[22:50] <bkerensa> bkero: https://blog.mozilla.org/mrz/2007/11/05/how-do-you-rack-50-mac-minis-and-use-only-one-power-cord/
[22:50] <bkerensa> :D
[22:51] <bkero> Yeah
[22:53] <bkero> If I had a few days I could probably figure something out
[22:54] <bkerensa> bkero: so one interesting thing is Portland is looking at adding electric bike charging stations
[22:54] <bkerensa> :D
[22:54] <bkero> bkerensa: Portland office or Portland city?
[22:54] <bkero> Electric bikes don't have a standardized charging plug/format
[22:55] <bkerensa> bkero: City of Portland... I am on a innovation advisory panel for the city and its one idea they have proposed to use innovation funds on in 2015
[22:55] <sgclark> neat!
[22:55] <bkerensa> bkero: yeah idk all the moving parts but I just know its a proposal
[22:55] <bkero> bkerensa: Yes, do it.
[22:55] <bkero> bkerensa: also be sure to push forward the bikeshare agenda
[22:55] <bkerensa> bkero: also everytime they talk about new software or dashboards.... I say "Can this be open source"
[22:55] <bkerensa> :D
[22:55] <bkero> and perhaps even an electric bikeshare agenda :3
[22:56] <sgclark> :)
[22:56] <bkerensa> the only other technical person on the team is from Intel
[22:56] <bkerensa> otherwise its all business people
[22:56] <bkero> Aww
[22:56] <sgclark> :(
[22:56] <bkero> Do you need some stalwart souls alongside you to push the innovation agenda?
[22:57] <bkero> I'm sure we could conscript from among the ranks of #pdxtech.
[22:57] <bkerensa> bkero: heh well its an appointed position so its not open to uninvited people
[22:57] <bkerensa> tbh no idea how I got picked
[22:58] <bkerensa> I just got a call and a city director had me on their short list... yet i had no idea who they were
[22:58] <bkerensa> and despite it being an advisory panel.... The city's Chief Administrative Officer steers the conversations in certain ways
[22:59] <bkero> That's probably their job
[22:59] <bkerensa> there were some really common sense yet non-innovative things proposed
[22:59] <bkerensa> like
[22:59] <bkerensa> most city agencies have security or rangers
[22:59] <bkerensa> and someone proposed merging them to one city wide force
[22:59] <bkerensa> they had projects it would save the city a million a year
[23:00] <bkerensa> and I was thinking why is this not in the general budget
[23:00] <bkerensa> also warehousing of old houses that are set for demolition was an interesting idea
[23:00] <bkerensa> they wanted to literally use land by the airport
[23:00] <bkerensa> and move houses there to be warehoused
[23:00] <bkerensa> until someone could find a plot to move them too
[23:01] <bkero> Old houess typically don't stand moving very well :/
[23:01] <bkero> Foundations and all
[23:02] <bkerensa> also apparently the city does not have any bureau specific or city wide way of tracking its assets
[23:02] <bkerensa> so they want software for this
[23:02] <bkerensa> so they don't lose assets
[23:02] <bkerensa> :d
[23:03] <bkero> Isn't there software for this alrady?
[23:03] <bkero> CiviCRM?
[23:04] <bkero> bkerensa: time to go rob the city of Portland. They won't know it's gone. :/
[23:05] <bkerensa> bkero: I imagine there is but they also made a case that by paying someone to make new software they would be supporting new tech jobs
[23:06] <bkero> It would
[23:06] <sgclark> tht is nice to hear
[23:06] <bkero> You could make the case that 1) it exists already, 2) can still leverage the existing pdxtech community, and 3) if they were to pay someone to make it, you'd have to wait until it's done to use it
[23:09] <bkero> I wonder what other cities are using to manage their assets
[23:10] <bkero> Do they all have homebuilt solutions?


[15:35] <DJones> Heya, just noticed a nick join & quit #ubuntu that might be worth watching out for "wtf-omg" on a virginmedia connection


[15:00] <barry> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is barry.
[15:00] <barry> hello and welcome to this week's ameu reviewers meeting.  who's here today?
[15:00] <rockstar> me
[15:00] <EdwinGrubbs> me
[15:00] <adeuring> me
[15:01] <flacoste> me
[15:02] <rockstar> That's it?
[15:02] <barry> wow, light attendance today <wink>
[15:02] <barry> allenap: ping
[15:02] <allenap> me
[15:02] <barry> bac_uds: hopeful ping
[15:02] <barry> bigjools: ping
[15:02] <barry> BjornT: ping
[15:02] <barry> cprov: ping
[15:02] <bigjools> me
[15:02] <barry> gmb: ping?
[15:03] <barry> intellectronica: ping
[15:03] <barry> mars: ping
[15:03] <barry> salgado: ping
[15:03] <bigjools> it's 7 in the morning for cprov at UDS
[15:03] <intellectronica> me
[15:03] <BjornT> me
[15:03] <barry> bigjools: what's his cell #?  let's wake him up :)
[15:03]  * barry is not sure who's at uds
[15:03] <rockstar> Ooh, that's bad...
[15:03] <bigjools> 1-800-EAT-SHIT
[15:03] <rockstar> !
[15:03]  * barry dials
[15:03] <mars> me
[15:04] <barry> bigjools: hey, waiiittt a minute!
[15:04] <bigjools> :)
[15:04] <barry> [TOPIC] agenda
[15:04] <MootBot> New Topic:  agenda
[15:04] <barry>  * Roll call
[15:04] <barry>  * Printing strings in doctests (barry)
[15:04] <barry>  * Gavin's `pretty()` function (allenap)
[15:04] <barry>  * Do we need a standard cover letter template for merge proposals? (barry)
[15:04] <barry>    * [[attachment:cover-quick.txt]]
[15:04] <barry>    * [[attachment:cover.txt]]
[15:04] <barry>  * Peanut gallery (anything not on the agenda)
[15:04] <barry>  * If there's time, the old boring script
[15:04] <barry>    * Next meeting
[15:04] <barry>    * Action items
[15:04] <barry>    * Mentoring update
[15:04] <barry>    * Queue status
[15:04] <barry> [TOPIC]  * Printing strings in doctests (barry)
[15:04] <MootBot> New Topic:   * Printing strings in doctests (barry)
[15:05] <barry> so, i mentioned this in a couple of reviews as well as in the asiapac meeting, with some positive feedback
[15:05] <barry> the idea is that in docstrings, you should (usually) be printing the value of strings instead of returning them
[15:05] <sinzui> me
[15:05] <barry> the advantage of that is that you usually don't care if its unicode or str, and you're not saddled with extraneous noise like u' and '
[15:05] <barry> e.g.
[15:05] <barry> instead of
[15:05] <barry> >>> foo['key']
[15:05] <barry> u'baz'
[15:06] <barry> you'd do
[15:06] <barry> >>> print foo['key']
[15:06] <barry> baz
[15:06] <barry> thoughts?
[15:06] <salgado> me!
[15:06] <salgado> sorry, I'm late
[15:06] <intellectronica> yes, i also prefer printing
[15:06] <bigjools> barry: +1
[15:07] <sinzui> Unless we fix/hack the the testrunner, translations and answers tests will fail
[15:07] <barry> sinzui: right.  hence the "usually" :)
[15:07] <rockstar> barry, +1
[15:08] <barry> so, as reviewers just be aware of that in code you review and suggest conversion to printing strings
[15:08] <barry> any objections?
[15:08] <adeuring> none, just a questin:
[15:09] <barry> adeuring: go4it
[15:09] <EdwinGrubbs> I think that the bug really needs to be fixed in the testrunner, since it doesn't tell you which line the error is on when you try printing out a unicode character, the whole doctest just fails, so you end up commenting out half your test  to find the offending line.
[15:09] <adeuring> what, if we want to test, if we want to check that we have for eaxmpale a string object, but not a unicode object?
[15:09] <adeuring> print repr(foo)
[15:09] <rockstar> EdwinGrubbs, +1
[15:09] <barry> EdwinGrubbs: totally agree.  it's not like we don't actually have proposed fixes either :)  iirc it's a bug in zope upstream
[15:10] <adeuring> I mean, whould we use explicity the print statment,
[15:10] <barry> adeuring: in that case you can either return the value and show the u''
[15:10] <adeuring> or should we allow the simple >>> foo
[15:10] <barry> adeuring: or, use isinstance(foo, unicode)
[15:10] <barry> adeuring: or even print foo.encode('utf-8')
[15:10] <rockstar> I'd prefer the second choice.
[15:11] <barry> rockstar: for a pure type test, i agree
[15:11] <rockstar> barry, yea' and if you want the value, you'd use print.
[15:11] <adeuring> barry: OK, though explicit encoding can make things more difficult to read
[15:11] <barry> rockstar: right
[15:12] <barry> adeuring: yep.  if we had a fixed testrunner we could just print it
[15:12] <barry> flacoste: can we ask gary to look into fixing this upstream for us?
[15:12] <adeuring> barry: ...or use repr(u'äüö')
[15:12] <flacoste> barry: gary doesn't have on the testrunner
[15:12] <adeuring> slightly better to read than the encoded string
[15:12] <flacoste> barry: but he can send emails
[15:12] <flacoste> barry: but anyway, we are way behind upstream here
[15:13] <flacoste> barry: so we should just fix our stuff for now
[15:13] <rockstar> flacoste, +1
[15:13] <barry> flacoste: maybe when we move to 2.6 :)
[15:13] <barry> and zc.buildout :)
[15:13] <flacoste> 2.6 is crack!
[15:13] <barry> :-D
[15:13] <barry> anyway for now, just be aware of this in reviews and make friendly suggestions
[15:14] <barry> [TOPIC]  * Gavin's `pretty()` function (allenap)
[15:14] <MootBot> New Topic:   * Gavin's `pretty()` function (allenap)
[15:14] <barry> allenap landed a branch with a nice pretty() function in doctest globals
[15:14] <flacoste> don't use it for API tests btw!
[15:14] <barry> although i've since heard that lazr has something similar, right flacoste ?
[15:14] <sinzui> zope.testing.doctest:1486
[15:14] <sinzui>     sys.stdout = self._fakeout
[15:14] <sinzui> Becomes
[15:14] <sinzui>     from codecs import EncodedFile
[15:14] <sinzui>     sys.stdout = EncodedFile(self._fakeout, "ascii", "utf-8")
[15:14] <allenap> flacoste: too late.
[15:14] <barry> flacoste: why?
[15:14] <barry> sinzui: yes, excactly
[15:14] <flacoste> because there is pprint_entry and pprint_collection
[15:15] <flacoste> that does that + other stuff
[15:15] <barry> flacoste: ah
[15:15] <flacoste> for example, it omits the etag key
[15:15] <flacoste> so pretty() is fine for non-API stuff
[15:15] <barry> flacoste: do we need a dev/reviewer style guide for apis?
[15:15] <flacoste> yeah, we probably do
[15:15] <allenap> flacoste: Yeah, agreed, the pprint_* functions are better for API. I'll clean up my API stuff that uses pretty().
[15:15] <flacoste> salgado started something if i recall
[15:16] <flacoste> or maybe it was for the coder perspective
[15:16] <flacoste> but yes, i'll do a API reviewer cheatsheet
[15:16] <barry> [ACTION] flacoste to do an API reviewer cheatsheet
[15:16] <MootBot> ACTION received:  flacoste to do an API reviewer cheatsheet
[15:16] <barry> flacoste: thanks!
[15:16] <flacoste> or add a section to the reviewer cheet sheet
[15:17] <barry> btw, rs=barry for any cleanup that consolidates pretty() and lazr's pretty printer
[15:17] <salgado> flacoste, barry, https://launchpad.canonical.com/API/StyleGuide is what I wrote
[15:18] <barry> salgado: nice, thanks
[15:18] <barry> [TOPIC]  * Do we need a standard cover letter template for merge proposals? (barry)
[15:18] <MootBot> New Topic:   * Do we need a standard cover letter template for merge proposals? (barry)
[15:18] <barry> i mentioned this last week.  this week i have two examples.  one a quick outline and the other more detailed, with examples
[15:19] <barry> https://dev.launchpad.net/ReviewerMeetingAgenda?action=AttachFile&do=view&target=cover-quick.txt
[15:19] <barry> https://dev.launchpad.net/ReviewerMeetingAgenda?action=AttachFile&do=view&target=cover.txt
[15:19] <barry> putting aside the issue of tool support for this, what do you think about encouraging devs to use this in mps?
[15:19] <barry> the thing i like about it is that everything's in one comment
[15:20] <barry> so when you get the mp email, you've already got the description, the lint, and the diff
[15:20] <barry> and it makes it very easy to respond in email
[15:20] <barry> i really hate it when i have to review a branch, but it's spread out over several emails
[15:21] <rockstar> barry, I don't like that either.
[15:21] <rockstar> I usually try and consolidate it into one reply.
[15:21] <barry> rockstar: right, which isn't always easy depending on your mua :)
[15:22] <rockstar> Yea.
[15:22] <rockstar> (vim ftw)
[15:22] <barry> rockstar: claws + emacs + emacsclient :)
[15:22] <bigjools> jeez, copy and paste ffs :)
[15:22] <barry> anyway.  +1, -1  for the cover standard?
[15:22] <bigjools> +0
[15:23] <rockstar> barry, which one is would be the standard?
[15:23] <barry> rockstar: they're the same except for the explanatory text and examples in the long one
[15:23] <barry> rockstar: so cover-quick.txt is the template most people would use
[15:24] <bigjools> how much of the stuff in the template should we / can we put in the MP form?
[15:24]  * sinzui has been pasting it all
[15:25] <barry> sinzui: right.  the idea is that you begin filling out the form right when you start working on the branch.  lots will be empty, but you fill it in as you think about the fix, get a pre-imp, hack the code, etc
[15:25] <barry> when you're ready for the mp, you paste the whole thing
[15:25] <rockstar> barry, why do we need bug XXXXXX section?
[15:25] <barry> rockstar: as the longer example says, it's to translate the bug description into human
[15:26] <sinzui> barry: correct. I do,
[15:26] <barry> from the native "user" :)
[15:26] <rockstar> Hm.  I think if I read the bug itself, and then read the solution, I could deduce the issues myself.
[15:27] <barry> rockstar: remember, we're trying to make things fast and easy for reviewers
[15:27] <bigjools> doesn't the branch link to the bug if you say --fixes?
[15:27] <barry> rockstar: so the dev should do more work upfront (imo)
[15:27] <rockstar> bigjools, yes
[15:27] <barry> rockstar: the idea is.  i'm going to review your branch in 5 minutes.  i should have everything i need right there in that one email
[15:27] <rockstar> barry, I'm all for people making the reviewer's life easier.
[15:27] <barry> rockstar: don't make me go looking around the world unless i want to
[15:27] <bigjools> I think that doing that and having the reviewer follow a link is better than the dev re-writing the bug description
[15:28] <barry> bigjools: the problem is that many bug have poor descriptions, or long conversational threads
[15:28] <barry> bigjools: i think it's the dev's resposibility to boil it down to: "Bug XYZ describes this very specific problem"
[15:28] <rockstar> barry, so why can't that translation to human be in the bug.
[15:28] <bigjools> barry: so I would rather the root cause was fixed then - lets update the bug
[15:29] <barry> i guess the point is that i don't want to have to hunt around in the bug.  i want to read my email, do my review and be done with it
[15:29] <rockstar> barry, maybe that would make sense as a sentence in the pre-implementation of implementation section.
[15:30] <bigjools> I hear we've got this funky tool called Launchpad that stores all this stuff for us ;)
[15:30] <barry> i should try to find a real-world example to show you what i mean.  it's really just a 2 sentence summary
[15:30] <barry> and you can just cut-n-paste the bug description if it's in human readable form
[15:30] <rockstar> If there's good information about the bug itself, I feel it really belongs in the bug, not the merge proposal.
[15:31] <barry> but if it's not, or the bug has a long conversational thread that eventually gets around to the real bug, then 2 sentences, boom you're done, and you've helped reduce reviewer friction
[15:31] <rockstar> It may be just two lines, but it's still segmentation of information.
[15:31] <bigjools> let me propose this:  if the bug's description was included in the branch page (is it already?) and the email, and the description was updated if it's inaccurate, would that suffice?
[15:31] <barry> rockstar: this isn't a big detailed thing, it's a summary.  the cover can always say there are important details in the tracker issue
[15:32] <rockstar> QA might not know to go look at the merge proposal for the actual explanation.
[15:32] <sinzui> rockstar: I summarize the bug because I don't want to make you spend 20 minutes reading all the comments that were not relevant to diagnosing the root cause
[15:32] <barry> bigjools: sure.  if it were included in the email that would help
[15:32] <barry> sinzui: exactly
[15:33] <rockstar> sinzui, I understand that, and I agree it's helpful.  I just think that we have all these buckets where certain types of information go.
[15:33] <bigjools> barry: great - I just hate the idea of re-writing the bug description and not including it in the bug report!
[15:33] <barry> this is all about reducing reviewer friction
[15:33] <rockstar> barry, and I agree it needs to happen.
[15:33] <rockstar> I also like to make sure that the branch is linked to the appropriate bugs it fixes.
[15:33] <sinzui> rockstar: secondly, I may land five branches to fix a bug, each branch focuses on an aspect of the bug that is strictly scoped so that I have small branches
[15:33] <barry> bigjools: i have no problem if the workflow is: dev updates the bug description to accurately reflect the root cause of the problem being reported, then cut-and-pastes that into his cover letter :)
[15:33] <BjornT> i think we should rename 'Bug XXX' to 'Summary', and concentrate on describing what the branch contains, rather than what the bug was.
[15:34] <barry> sinzui: excellent point!
[15:34] <rockstar> BjornT, +1
[15:34] <intellectronica> +1, and we already have that in the submission form, so the only thing is to make sure that it's displayed conveniently both on the web and in email
[15:34] <bigjools> BjornT: again, I think that should be recorded in LP, with the branch.  It can be sent with the email.
[15:34] <barry> BjornT: Summary of Bug XXXXX and i'm on board with that
[15:35] <bigjools> barry: not all branches are bug fixes though
[15:35] <barry> bigjools: hmm. okay
[15:35] <BjornT> barry: well, as sinzui said, he might land five branches to fx
[15:35] <barry> but they should be, right? :)
[15:35] <BjornT> fix a single bug
[15:35] <bigjools> barry: blueprints? :)
[15:35] <rockstar> barry, two lines in of the faur line Summary can be devoted to it.
[15:35] <BjornT> barry: should he include the same bug description in all five merge proposals?
[15:35] <rockstar> s/faur/four
[15:35] <barry> bigjools: i've heard it's a great way to increase your karma
[15:36] <bigjools> barry: you get more for blueprints! :)
[15:36] <barry> BjornT: when i've done that, the first sentence is the same, but then the rest of that summary section goes on to explain the sub-issue this branch is addressing
[15:36] <barry> but i'm okay with Summary
[15:37] <BjornT> barry: right. in that case you're not summarizing the bug report; you're summarizing your branch
[15:37] <barry> as long as i don't have to guess which bug it's addressing
[15:37] <barry> BjornT: cool, i'm convinced.  Summary sounds good
[15:38] <barry> i'll make that change and take it to the ml
[15:38] <BjornT> i do agree that the summary should explain in words what issue was fixed, rather than just saying 'fixes bug xxx'.
[15:38] <barry> btw, i really appreciate all the good feedback.  ultimately this is about making things easier for us reviewers!
[15:38] <barry> you should work harder when your dev hat is on :)
[15:39] <barry> BjornT: +1
[15:39] <bigjools> as someone once said to me, we're being worked like camels already :)
[15:39] <barry> bigjools: :)  reducing dev friction is a whole 'nuther topic
[15:40] <barry> but not for today :)
[15:40] <bigjools> 5 mins left!
[15:40] <barry> [TOPIC] # Peanut gallery (anything not on the agenda)
[15:40] <MootBot> New Topic:  # Peanut gallery (anything not on the agenda)
[15:40] <barry> bigjools: what a great straight man you are!
[15:40] <barry> so, the floor is open.  do you have anything not on the agenda?
[15:41] <rockstar> How are merge proposals going?
[15:41] <rockstar> We're fixing bugs to get things easier to use.
[15:41] <bigjools> I think they're great, but I think they could prompt us for the info that barry wants :)
[15:41] <rockstar> Is anyone noticing?
[15:41] <flacoste> bigjools: honestly, i don't think so
[15:42] <flacoste> form filling is boring
[15:42] <barry> rockstar: you had me at "PendingReviews is dead".  i think they're great
[15:42] <bigjools> flacoste: you'd rather copy & paste a template?
[15:42] <sinzui> flacoste: but note taking is safe and satisfying.
[15:42] <rockstar> barry, Hurray!
[15:42] <flacoste> yeah, free form text FTW!
[15:42] <barry> tool support would definitely make it easier
[15:43] <barry> rockstar: plus i want a button to re-send me the mp email :)
[15:43] <bigjools> I like being reminded of things, I'm not getting any younger!
[15:43] <BjornT> flacoste: +1
[15:44] <barry> flacoste, rockstar how much of the mp stuff is exposed in the api?
[15:44] <BjornT> bigjools: you should be able to use 'bzr send' and have the template come up in your text editor.
[15:44] <bigjools> BjornT: bzr send creates MPs?
[15:44] <rockstar> barry, the basic read only stuff landed last week.
[15:44] <barry> BjornT: though of course, you've already started the template when you began to think about the bug, had your pre-impl, etc. <wink>
[15:44] <BjornT> bigjools: well, somehow you should be able to submit MPs from bzr
[15:44] <rockstar> bigjools, it will, as soon as abentley gets back from UDS.
[15:45] <barry> BjornT: big +1 there
[15:45] <rockstar> BjornT, yea, that's the idea.
[15:45] <bigjools> BjornT: agree
[15:45] <bigjools> rockstar: that would be very cool!
[15:45] <intellectronica> personally, i would rather have web forms (and perhaps the ability to bypass them using the API)
[15:45] <intellectronica> and i think they would be very good for are users too
[15:45] <bigjools> well both - choice is good
[15:45] <rockstar> So diffs and bzr send are the big ones for mp right now then?
[15:46] <barry> rockstar: i think so
[15:46] <barry> oops, look at the clock.  we're the time go?
[15:46] <rockstar> Cool.  I'll bring that up in the meeting.  I know the code has been landing, just don't know the specifics.
[15:46] <barry> anything else before we break?
[15:46] <barry> 5
[15:46] <BjornT> rockstar: especially the possiblity to attach diffs (rather than having them generated automatically, which is also nice of course)
[15:47] <barry> 4
[15:47] <barry> 3
[15:47] <rockstar> BjornT, agreed
[15:47] <barry> 2
[15:47] <barry> 1
[15:47] <rockstar> Break!
[15:47] <barry> #endmeeting
[15:47] <MootBot> Meeting finished at 09:47.
[15:47] <barry> thanks everyone!
[15:47] <allenap> Thanks barry.
[15:48] <rockstar> BjornT, technically, bzr send uses attachments to send the diff.  Is that what you're saying?
[15:49] <BjornT> rockstar: kind of. what i want is to have the diff attached to the outgoing e-mail notification (not appended as normal text). this is for both new merge proposals, and for replies, where the coder is attaching a diff of his changes.
[15:50] <rockstar> Ah, so when you receive a mp email, the diff is an attachment?
[15:51] <BjornT> rockstar: yes, that is what i want. that way it's easy to get to the diff. it's easier to go to the next attachment, rather than paging through the comment to find the beginning of the diff.
[15:51] <rockstar> BjornT, okay, noted.  I'll see what I can do.
[15:52] <BjornT> rockstar: cool, thanks.


[00:04] <broder> Rcart: hmm, i think i actually disagree with that bug report. if i was maintaining that package, i would tell the user to configure the package to not start automatically (using policy-rc.d - see http://manpages.ubuntu.com/manpages/precise/en/man8/invoke-rc.d.8.html#contenttoc6), which would keep the postinst from trying to start the daemon
[00:04] <broder> but i can't actually find anything in the debian policy manual to back me up on that
[00:11] <broder> Rcart: ok, just uploaded mpd
[00:15] <Rcart> broder: I think that the second comment is right, it would be easier for the user to just receive a warning and not a critical error that stops the update/install procedure
[00:16] <broder> Rcart: that would be different behavior than almost every other postinst script i've seen
[00:16] <broder> the standard postinst snippet for starting an initscript exits with an error if the start fails
[00:18] <Rcart> I see. He said that will fix it (on 5 Jul 2008) and seems like he didn't X:
[00:18] <Rcart> should I add a bug watcher linking that (debian) bug report?
[00:19] <broder> to what?
[00:19] <Rcart> the LP bug report
[00:19] <broder> which bug report?
[00:19] <Rcart> (that you mentioned)
[00:20] <Rcart> #778571}
[00:20] <broder> ah. no - the one i mentioned is a different bug from the one described
[00:20] <Rcart> Ah, ok
[00:21] <Rcart> I'll add a bug watcher to the bug you reviewed
[00:21] <broder> huh?
[00:22] <Rcart> xD
[00:22] <broder> no, i don't think there's any bug in lp right now that matches the debian bug you linked to
[00:22] <broder> you should only link bugs if it's the same bug being reported in two places
[00:23] <Rcart> the bug I was working on you uploaded it, I'll report it to debian and link it to LP
[00:23] <broder> ah, yes. that would be excellent :)
[00:23] <broder> sorry for the confusion
[00:23] <Rcart> :D
[00:24] <Rcart> Think I need to read carefully the scripts post-pre-etc and try to work on bugs like that
[00:34] <Rcart> Thanks for your help broder, I'm leaving. o/
[00:35] <broder> Rcart: no problem! thanks for stopping by and contributing!
[00:36] <Rcart> (:
[01:45] <akrogames> Thanks jtaylor for your help
[01:46] <akrogames> hi broder
[01:46] <broder> akrogames: hey, what's up?
[01:47] <akrogames> I live in France and I'm tired and you ?
[01:47] <akrogames> I learned to fix bugs
[01:57] <akrogames> good night, so later
[04:23] <mfisch> jtaylor: I found out the fix for live-manual, it's not pulling a new version.  I'm still trying to figure out the right way to actually make the change.  Ping me when you're around and I'll explain
[04:42] <mfisch> jtaylor: strike that, I have the debdiff ready to go, just need to know where to put it so that a MOTU can take it from there
[05:26] <tumbleweed> !sponsorship| mfisch
[05:45] <mfisch> tumbleweed: thanks, I'll take a look in the morning
[08:12] <tumbleweed> Changed-By: Ubuntu Merge-o-Matic<EMAIL_ADDRESS>[08:12] <tumbleweed> ^ we should have a noisy lintian check for that
[08:13] <micahg> heh
[08:33] <vibhav> It is possible to sync a Ubuntu package to Debian?
[08:34] <tumbleweed> vibhav: there's no automated proces for it
[08:34] <tumbleweed> it generally works better to maintain the packgae in Debian and sync to Ubuntu
[08:35] <vibhav> I prefer to upload it to Ubuntu first, since I am not experienced in the Debian process
[08:36] <tumbleweed> all the tools (and people) assume that Debian is the upstream
[08:36] <tumbleweed> and I think Debian is a better place to maintain packages (the stronger maintainership makes sense for packages you care about)
[08:38] <vibhav> I still can upload it to Ubuntu first?
[08:38] <tumbleweed> nothing stops you from doing that
[08:40] <bkerensa> tumbleweed: Assuming he has upload privileges or gets a package sponsored
[08:40] <tumbleweed> did something change in apport? There's hardly any information in bug 940800
[08:45] <Ampelbein> tumbleweed: bug 944078
[08:47] <tumbleweed> hrm, probably it
[10:00] <pkt> what is the process of fixing these http://qa.ubuntuwire.com/bugs/rcbugs/
[10:00] <pkt> Is there a document about this?
[10:02] <pkt> I mean I can download the debian source, get the relevant patch etc, then where and how do I submit the result?
[10:03] <micahg> pkt: either request a sync if appropriate or submit a patch for sponsorship either through a bug or bzr branch
[10:04] <pkt> how do I request a sync?
[10:04] <pkt> ok I found, sorry for that question
[10:04] <micahg> pkt: use requestsync from ubuntu-dev-tools (use the -e flag if the new version has new features since we're past feature freeze)
[10:04] <pkt> http://qa.ubuntuwire.com/bugs/rcbugs/
[10:05] <pkt> ok, thanks :)
[11:31] <pkt> I tried requestsync -e radare but it doesn't work since it says the versions are the same (in reality they aren't)
[11:33] <micahg> pkt: if it's only in unstable you'll need -d unstable
[11:33] <tumbleweed> pkt: -d unstable
[11:34] <pkt> thanks :)
[11:34] <pkt> (and sorry for the newbie questions)
[11:34] <tumbleweed> np, that's an issue that only comes up with LTS releases where we sync from testing by default
[11:38] <Pikkachu> this is confusing http://developer.ubuntu.com/packaging/html/packaging-new-software.html
[11:39] <tumbleweed> Pikkachu: what are you finding confusing? let's fix it
[11:41] <Pikkachu> it's entirely confusing, but gtg now
[11:45] <pkt> I think I succeeded (https://bugs.launchpad.net/ubuntu/+source/radare/+bug/946269)
[11:46] <pkt> Is this correct?
[11:46] <tumbleweed> pkt: that doesn't need an FFe, it's only a bug fix
[11:46] <pkt> uff, I understood wrong then
[11:47] <pkt> should I close the bug?
[11:47] <tumbleweed> if the upstream part (before the dash) of the version hasn't changed, it is unlikely to need the FFe
[11:47] <pkt> It shouldn't need
[11:47] <pkt> it is a trivial bug fix
[11:47] <tumbleweed> no, lets leave it as a sync request, it just doesn't need an FFe
[11:47] <pkt> so, what did I do wrong?
[11:47] <tumbleweed> there, done
[11:48] <tumbleweed> it didn't need -e
[11:48] <pkt> ah, ok :)
[11:48] <pkt> Thanks :)
[11:53] <pkt> So the correct command would have been requestsync -s radare -d unstable
[11:53] <pkt> I will learn slowly slowly :)
[11:53] <tumbleweed> yes
[11:54] <tumbleweed> if you have a recent requestsync (using LP API) you don't need -s either, it'll wor that out itself
[11:54] <pkt> I 'm using latest precise so I guess it is recent enough
[11:54] <tumbleweed> yes
[11:55] <pkt> great, continuing to the next package :)
[16:43] <Pikkachu> I have source code for which compilation is like $apt-get install build-dep other; $apt-get source other; cp here/patched other/foo/bar; cd other; ./configure; cd foo/bar; make patched.so
[16:44] <Pikkachu> how would I make a bin deb and how to put this on a recipe?
[16:45] <pkt> first of all instead of cp here/patched other/foo/bar you should have a proper patch
[16:45] <pkt> in the form of a unified diff
[16:46] <pkt> if the package you are patching has source format 3.0 (quilt) then it is very easy to add a patch
[16:47] <pkt> https://wiki.ubuntu.com/PackagingGuide/Complete
[16:48] <Pikkachu> "first of all instead of... " -- you don't really understand what's that
[16:49] <Pikkachu> I will explain what it is
[16:49] <pkt> please do :)
[16:49] <Pikkachu> sorry for calling it patch, it's a new plugin for pidgin called ircaway
[16:50] <pkt> From the process you described it looks as if you want to patch pidgin to include it
[16:50] <Pikkachu> it's a single ircaway.c for which I need to create the .so, instructions in pidgin website suggested me to put the source under pidgin-source/pidgin/plugins and run $make ircaway.so
[16:51] <pkt> Does pidgin provide a way to build plugins out of tree?
[16:52] <pkt> If it doesn't you need to convince them to add it, or add the source file as a patch
[16:52] <Pikkachu> so I use pidgin's build infrastructure which is able to build arbitrary plugins if they're under that folder, I did this because it just works and I don't want to waste time trying to figure out how to build it alone
[16:52] <pkt> sure
[16:53] <pkt> but this can't work for packaging I think
[16:53] <pkt> either it needs a way to be built standalone
[16:53] <Pikkachu> please this has nothing to do with patches unless they decided to add the plugin to upstream
[16:53] <Pikkachu> from the pidgin docs, the plugin author would provide the way the plugin needs to be built
[16:54] <pkt> fair enough
[16:54] <Pikkachu> but I'm reading the docs themselves for that
[16:54] <pkt> but pidgin should provide a way to build plugins against it
[16:54] <Pikkachu> which don't explain how to build them alone
[16:54] <pkt> i.e., libraries etc
[16:55] <pkt> are there any pidgin plugins distributed as standalone packages?
[16:55] <Pikkachu> I suppose because it's a plugin it somehow would require most or much of the original infrastructure to build pidgin itself
[16:55] <Pikkachu>  https://wiki.ubuntu.com/PackagingGuide/Complete -- is totally confusing
[16:56] <Pikkachu> sorry I mean the new guide
[16:56] <Pikkachu> I just know of purple plugin pack, a set of plugins, distributed as a separate package
[16:59] <pkt> apt-cache search pidgin shows a few extra packages
[16:59] <pkt> you can check if any of them are small enough to be used as examples
[17:00] <tumbleweed> Pikkachu: does libpurple-dev or pidgin
[17:00] <tumbleweed> -dev have wha tyou need?
[17:01] <pkt> I would propose pidgin-extprefs
[17:01] <pkt> it is also a single .c file from what it seems
[17:01] <pkt> so maybe you can reuse its build infrastructure
[17:01] <Pikkachu> tumbleweed: does what?
[17:02] <pkt> He asks if it provides the needed libraries etc
[17:02] <pkt> but I think the problem is to figure out the build system
[17:02] <Pikkachu> pkt: sorry I'm not in Ubuntu right now, but does extprefs stand itself as a pidgin plugin?
[17:02] <pkt> yes it seems so
[17:03] <Pikkachu> pkt: yeah it's a problem -dev x build-dep
[17:03] <Pikkachu> first of all I don't get why can't one put the build deps as deps of the -dev packages
[17:04] <Pikkachu> anyway, libpurple-dev and pidgin-dev contain just headers iirc
[17:04] <Pikkachu> and build-dep for pidgin is really big
[17:04] <pkt> Pikkachu: again, I think you can try extprefs plugin as a template to build from
[17:04] <Pikkachu> pkt: ok will try to take a look at extprefs
[17:05] <pkt> if you are not on ubuntu you can get the source package from the web
[17:05] <pkt> It has some extra stuff for installing on win32 and such, you can just ditch those
[17:06] <pkt> and just copy the linux-related infrastructure
[17:09] <Pikkachu> ok
[17:10] <pkt> great :)
[17:10] <tumbleweed> Pikkachu: if it's a single c file, it can't be that hard to build, right?
[17:10] <pkt> not true
[17:11] <pkt> a kernel module is also a single file
[17:11] <pkt> s/is/can be/
[17:11] <tumbleweed> and they are fairly straight forward to build
[17:11] <pkt> not without the kernel's build infrastructure
[17:11] <Pikkachu> yeah
[17:11] <pkt> you can't just call gcc on it by hand and expect a working module
[17:12] <pkt> Pikkachu's issue is that he is trying to figure out the corresponding build system for pidgin plugins
[17:12] <Pikkachu> I just don't get why build-dep is not reversible like normal deps with autoremove
[17:12] <tumbleweed> I'm saying that that may be more effort than it's worth
[17:13] <tumbleweed> Pikkachu: use mk-build-deps, then they are easy to remove
[17:13] <Pikkachu> I think you don't really understand the problem, tumbleweed
[17:13] <Pikkachu> I have no idea how would I "use mk-build-deps"
[17:14] <tumbleweed> Pikkachu: of course I don't, I haven't seen the source[6~
[17:14] <tumbleweed> it has a manpage
[17:14] <tumbleweed> but basically, mk-build-deps -ir inside an extracted source package
[17:14] <Pikkachu> are you trying to sound cool? it's not working
[17:15] <tumbleweed> Pikkachu: I'm trying to be helpful
[17:15] <pkt> Pikkachu: yes
[17:15] <tumbleweed> and you don't appear to want help, so I'm not entirely sure why I'm bothering
[17:15] <pkt> I think there is a misunderstanding
[17:15] <pkt> tumbleweed's advice is useful
[17:15] <Pikkachu> of course, those standard responses, please I disregard your help, right now, ignore me PLEASE
[17:16] <pkt> Pikkachu: mk-build-deps solves the problem of being able to unistall the stuff apt-get build-dep brought in
[17:16] <tumbleweed> Pikkachu: sorry, I tend to not give complete hand-holding instructions, but rather point you in useful directions, and expect you to do some research yourself
[17:17] <Pikkachu> tumbleweed: sorry I stopped at 'sorry'. I'm not really interested in your help, sorry
[17:17] <tumbleweed> np
[17:18] <Pikkachu> pkt: well but it will just output the package names, which is mostly the same as saving build-dep's output :(
[17:18] <pkt> Pikkachu: not just that
[17:18] <pkt> it will also make a binary package that depends on them
[17:19] <pkt> so you can install this package to install the build-deps
[17:19] <pkt> and then remove it and they will become removable through autoremove
[17:19] <pkt> of course I don't know how useful this is now (if you have already installed them by build-dep)
[17:20] <pkt> but for future reference
[17:21] <Pikkachu> I'd have to do it for every package I want the build deps, I'm just saying there should be something like 'autoremove --build-deps'
[17:21] <pkt> It is the same number of commands
[17:22] <pkt> I.e., instead of "apt-get build-dep <foo>" you do "mk-build-deps -ir"
[17:22] <pkt> and this way the build deps are instantly autoremovable
[17:22] <pkt> I didn't know about this script myself to be honest, I had hacked my own solution for this problem :P
[17:53] <akrogames> hi all
[17:56] <mfisch> I'm making a change on a package that has no branches in launchpad, can I just attach a debdiff to the bug and leave it at that?  Or, should I make an initial branch and then commit on top of that to show the diffs?
[17:57] <tumbleweed> debdiffs are fine. Nobody requires you to use bzr
[17:57] <tumbleweed> however, why does i tnot have any branches in LP?
[17:58] <mfisch> tumbleweed: because, I think, until now it was just, uh, pure debian, no ubuntu changes
[17:58] <tumbleweed> mfisch: no, it should still have branches
[17:58] <tumbleweed> what package is it?
[17:58] <mfisch> let me confirm that assumption
[17:58] <mfisch> okay nevermind :(
[17:58] <tumbleweed> :)
[17:58] <mfisch> I just wasn't looking in the right place
[18:00] <pkt> still the information that bazaar is not really needed is useful
[18:01] <tumbleweed> I still find it easier to not use bzr, but bzr is certainly becoming more appealing
[18:01] <mfisch> I prefer bzr myself
[18:02] <ral> As someone who has only done a small amount of packaging I found modifying a package with bzr very straightforward.
[18:04] <mfisch> when I do the merge proposal don't i need to add ubuntu-sponsors as a reviewed?
[18:04] <mfisch> reviewer i mean
[18:04] <tumbleweed> orrect
[18:04] <tumbleweed> err, you don't need to
[18:04] <mfisch> mind if i add that to the wiki?
[18:04] <mfisch> hmm ok
[18:05] <mfisch> tumbleweed: how will it end up in sponsor queue?
[18:06] <tumbleweed> the sponsorship queue includes all merge proposals against ubuntu pcakages
[18:06] <mfisch> alright, I'll see if this shows in the queue in a bit
[18:07] <ESphynx> hey guys... Would anyone be able to assist me? I'm having really bad troubles with Precise. It fails to build our software in the most silly way...
[18:08] <tumbleweed> ESphynx: this isn't really a support channel, but those kind of thinsg we can probably help with. Also, don't ask to ask, just ask :)
[18:08] <mfisch> tumbleweed: thanks for the ifno, I attached a debdiff and did a merge-prop
[18:09] <ESphynx> It builds fine on Oneiric, which is GCC 4.6.1 .  I was trying to install the 'standard' GCC 4.6.2 on Precise to see if it would build fine (Seeing that GCC/MinGW 4.6.2 on Windows works fine), but then my Precise VM died on me =(
[18:09] <tumbleweed> mfisch: so it'll show up twice :)
[18:09] <ESphynx> tumbleweed: you the man.
[18:10] <tumbleweed> ESphynx: can you pastebin the error?
[18:10] <ESphynx> I don't know what happened to my VM.. last night I went to sleep after the GCC build was going on... this morning the Vbox interface is just jammed, even cloning the machine jams taking 0% CPU
[18:10] <ESphynx> tumbleweed: the errors won't really help you, it's my compiler doing really silly stuff that it normally doesn't
[18:11] <pkt> ESphynx: do you have a hardware problem or something?
[18:11] <ESphynx> The only thing I can't think up is a messed up GCC
[18:11] <tumbleweed> ESphynx: you sure your hard drive isn't going? check dmesg...
[18:11] <pkt> or zero free disk space?
[18:11] <mfisch> tumbleweed: eh, should I nuke my merge proposal then?
[18:11] <ESphynx> pkt: no hardware problem, this is on Launchpad PPA building machines as well
[18:11] <mfisch> tumbleweed: not sure if I can remove the attachment from the bug
[18:11] <ESphynx> pkt: no, dynamic vdi drives with plenty of space
[18:11] <tumbleweed> mfisch: I can unsubscribe sponsors from the bug
[18:11] <mfisch> tumbleweed: bug #831392
[18:12] <ESphynx> tumbleweed: https://launchpadlibrarian.net/95143170/buildlog_ubuntu-precise-i386.ecere_201203031148-0~446~precise1_FAILEDTOBUILD.txt.gz  -- the build log, but like I said it won't help much
[18:12] <mfisch> my bug-day contrib, 48 hours late ;)
[18:12] <tumbleweed> mfisch: thanks
[18:12] <ESphynx> tumbleweed: It is virtual machines, and PPA building machines! no HW issue.
[18:12] <ESphynx> I was suspecting a bug in the Ubuntu GCC 4.6.2 patches.
[18:12] <pkt> mfisch: is it 48-hours late? hehe I thought the Jam was during the weekend as well
[18:13] <mfisch> pkt: oh well I'm good then!
[18:13] <pkt> I still haven't finished my contribution :S
[18:13] <mfisch> pkt: you're running out of time there in Greece!
[18:13] <tumbleweed> ESphynx: the ppa build failed for a very clear reason
[18:14] <ESphynx> tumbleweed: Which reason is that?
[18:14] <pkt> mfisch: true, just a few hours more :P
[18:14] <tumbleweed> error: unresolved identifier publicAccess; expected ecere::com::Module
[18:14] <pkt> but can't I say that my personal clock is in pacific timezone :P
[18:14] <ESphynx> tumbleweed: that is not supposed to happen.
[18:15] <ESphynx> tumbleweed: also consider "warning: incompatible expression "ecere::sys::FileAttribs FileExists(char * fileName)" (byte *); expected pe"
[18:15] <ESphynx> there's no such thing as "pe" anywhere in our software...
[18:15] <ESphynx> the compiler (the bootstrap eC compiler) is all messed up
[18:16] <ESphynx> none of this happen on any other Ubuntu versions...
[18:16] <mfisch> tumbleweed: how often is the sponsor queue updated?  hourly or so?
[18:17] <ESphynx> My Precise VM is dead :| will have to reinstall everything... So much for trying to build my own GCC 4.6.2 :|
[18:17] <tumbleweed> mfisch: I think every 10 mins or so. Maybe 30. depends how big it is (the script that produces it takes forever to run)
[18:17] <tumbleweed> ESphynx: sorry, I thought you were saying tha tthe build had killed your VM
[18:17] <ESphynx> tumbleweed: building GCC killed my VM.
[18:18] <pkt> ESphynx: how much RAM did you give to your VM?
[18:18] <ESphynx> ah the hw errors, is what you were talkign about :) hehe, on a Windows host though
[18:18] <ESphynx> pkt: 2gb
[18:18] <ESphynx> sorry I thought you guys were blaming the failed build on hw hehe
[18:18] <pkt> And still it died
[18:18] <pkt> hehe
[18:18] <ESphynx> yes :(
[18:18] <pkt> Interesting
[18:19] <ESphynx> you guys have other flavors of Gcc installed on Precise?
[18:19] <ESphynx> we could give that a try?
[18:19] <pkt> I have a VM here with precise (kvm)
[18:19] <pkt> if you want I can install a version of gcc
[18:19] <ESphynx> pkt: I would greatly appreciate taht.
[18:20] <pkt> But know that I can't build gcc on this VM
[18:20] <pkt> it has just 256MB ram
[18:20] <ESphynx> pkt: I gave up on building GCC :P
[18:20] <ESphynx> pkt: but I couldn't figure out out to try 4.6.1, for example, without building it
[18:20] <ESphynx> if you do know how ;)
[18:20] <pkt> I can try to find out
[18:20] <pkt> just a sec
[18:20] <tumbleweed> ESphynx: w still have a gcc-3.5 package in precise
[18:20] <tumbleweed> err 4.5
[18:21] <ESphynx> i decided to try building 4.6.2 , since it built our software fine on Windows
[18:21] <ESphynx> tumbleweed: ah yes... I guess we could try that. but that's quite far from 4.6.2 :|
[18:21] <ESphynx> but it would help narrow down the problem
[18:21] <pkt> I see 4.6.3 as default here
[18:21] <tumbleweed> yeah
[18:21] <ESphynx> See, our first open source release on Ecere was 0.44 draft 1, on Dec 25, 2008.... and this coming Wednesday is finally the official 0.44 ;)
[18:22] <ESphynx> And I would like to build on Precise, at least when it comes out :)
[18:22] <pkt> 4.4, 4.5, 4.6 are all available
[18:22] <ESphynx> pkt: 4.6.3 now ? is it a newer VM?
[18:22] <pkt> which one do you want?
[18:22] <pkt> It has latest precise on it
[18:22] <ESphynx> pkt: maybe i'm out of date hehe...
[18:22] <ESphynx> pkt: care to try 4.6.3 first ?
[18:22] <pkt> sure why not
[18:23] <ESphynx> guess i'll link you to the source package?
[18:23] <pkt> but if lp failed probably it was with  4.6.3
[18:23] <pkt> sure
[18:23] <pkt> do you have it on a ppa?
[18:23] <ESphynx> yes
[18:23] <ESphynx> https://code.launchpad.net/~jerstlouis/+recipe/ecere-daily-multiarch
[18:24] <ESphynx> gcc-4.6 i386 4.6.3-1ubuntu2 [7576 kB]
[18:24] <ESphynx> right, lp failed on 4.6.3 as well :(
[18:25] <ESphynx> so the easy thing would be to try 4.4 ? to establish whether GCC is to blame or not?
[18:25] <ESphynx> since 4.5 is dev right, so latest dev might have the bug as well?
[18:25] <pkt> I think 4.5 should be release as well, not dev
[18:26] <ESphynx> ah right osrry
[18:26] <ESphynx> it's the middle number
[18:26] <ESphynx> hmm.
[18:26] <ESphynx> my only worry... when installing side by side... our build system just invokes 'gcc'
[18:27] <pkt> I think gcc is selected using alternatives
[18:27] <ESphynx> so you can try 4.5
[18:27] <ESphynx> please =)
[18:28] <pkt> sure but you will need to wait a few mins
[18:28] <ESphynx> np
[18:30] <ESphynx> I gues another thing to try would be to disable -O2 ...
[18:30] <pkt> that you can also try yourself
[18:30] <ESphynx> guess I could try that on a new Precise machine
[18:30] <ESphynx> yes. i'll brb, logging out to kill stalled VBox
[18:33] <Pikkachu> hi pkt, not much help http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/pidgin-extprefs/oneiric/view/head:/debian/control
[18:34]  * Pikkachu rebooting to ubuntu
[18:40] <pkt> Pikkachu: fwiw I didn't understand what you meant
[18:40] <Ampelbein> Pikkachu: There are lots of pidgin plugins in ubuntu, have you had a look at how they accomplish the build?
[18:40] <pkt> what was the problem with pidgin-extprefs?
[18:46] <Pikkachu> Ampelbein: and this is what you call "a lot"? http://i.imgur.com/Q5hAT.png
[18:46] <PaoloRotolo> Hi all!
[18:46] <pkt> Pikkachu: try from the command-line
[18:46] <pkt> there are several
[18:46] <pkt> apt-cache search pidgin
[18:46] <ESphynx> That .vdi was so locked down, even "Restart" wouldn't work... i had to press the Reset button :|
[18:47] <pkt> Pikkachu: but still what was the problem with extprefs, I chose it for you because it is also a single .c file
[18:48] <Pikkachu> pkt: I have no idea whether its Build-Depepndencies field matches?
[18:48] <Pikkachu> pkt: can we start from the beginning?
[18:48] <pkt> sure
[18:49] <pkt> for starters, where is ircaway.c ?
[18:49] <Ampelbein> Pikkachu: I count 24 plugins, that is a lot.
[18:49] <ESphynx> well the good news is I miraculously kept that .vdi (because it was locked! i had done "delete all files"), and it works
[18:50] <pkt> nice :)
[18:50] <ESphynx> so now I can try taking out -O2 :P
[18:50] <Pikkachu> Ampelbein: ignore me from now on, and I'm serious
[18:50] <Pikkachu> hi ESphynx, how's eC going :)
[18:50] <Pikkachu> pkt: well, I will stand it in a simple way then
[18:51] <pkt> sure, simple always helps
[18:52] <Pikkachu> I have a Bazaar branch for a new plugin for pidgin, I want Launchpad building the deb and putting it available, that simple. I tried and read docs about recipes, ppa, packaging, and they're just confusing, so I wanted to start from this simple point with human help
[18:53] <pkt> can you give the link to that branch?
[18:54] <Pikkachu> fwiw I can generate the .so by ./configuring the pidgin host and $making plugin.so from within pidgin-source/pidgin/plugins (that is, this build thing I used is from pidgin)
[18:54] <pkt> Pikkachu: sure, but this won't help you produce a package
[18:55] <Pikkachu> pkt: https://code.launchpad.net/~renatosilva/pidgin/ircaway
[18:55] <pkt> Pikkachu: great
[18:56] <Pikkachu> pkt: yeah I just mentioned that because I'm not sure how to build the plugin at all except by reusing pidgin infrastructure, which is sort of overkill for a small plugin I think
[18:56] <pkt> it is not just overkill
[18:56] <pkt> it is also not going to be accepted
[18:57] <pkt> so, you need to figure out how to build it standalone
[18:57] <pkt> this doesn't just mean the debian/ part
[18:57] <pkt> it also means the makefile etc
[18:58] <pkt> In fact, the first thing you need to figure out is what to put to the makefile
[18:58] <pkt> you can start simple, assuming that you don't ever want to build for other platforms, so you don't need the autoconf stuff
[18:59] <Pikkachu> do I really need a makefile? because I think that even that is overkill, no?
[18:59] <pkt> no
[18:59] <Pikkachu> why not, just to understand
[18:59] <pkt> Because you need to ensure you are building against the proper headers / libraries
[19:00] <pkt> you could also write a bash script but a Makefile is the standard way to do it (TM)
[19:00] <pkt> so at the very minimum you need the .c file and a Makefile
[19:01] <pkt> and most likely a README
[19:01] <pkt> once you have those, you can also make the debian/ folder with the right contents
[19:03] <tumbleweed> +1 to Ampelbein's suggestino of looking at other plugins, and yes, writing a simple Makefile is probably the easiest way to get a working package
[19:09] <Pikkachu> pkt: ok so let's leave the deb thing for a separate stage. I'm new to make, I've just used it, how would I figure out the dependency tree for the source file compiling?
[19:09] <Pikkachu> tumbleweed: I'm looking right now, will take a look at their makefile
[19:11] <pkt> Pikkachu: typically you use pkg-config
[19:11] <pkt> Pikkachu: here is my suggestion
[19:11] <pkt> go to the extprefs plugin
[19:11] <pkt> do the mk-build-deps -ir thing
[19:12] <pkt> and now do a debuild -uc -us 2>&1 | tee -a ../build.log
[19:12] <pkt> this will show you which commands the makefile of this plugin called
[19:12] <pkt> it is much easier than trying to analyse its source
[19:12] <pkt> because the source is obfuscated a lot by the automake infrastructure that you don't need
[19:13] <Pikkachu> I'm trying to process what you said
[19:13] <pkt> btw, I hope this advice is ok and not considered as spamming the channel
[19:14] <tumbleweed> sure, nothing else going on right now. (weekends are quiet)
[19:14] <tumbleweed> Pikkachu: no tee reqd, debuild writes a log to ../$pkg.build
[19:14] <pkt> even better
[19:15] <tumbleweed> err pkt
[19:15] <Pikkachu> I'm really annoyed by all this word salad I've been through in the docs, I'm really lost
[19:16] <jtaylor> :O why have I been using tee all the time?!
[19:16] <Pikkachu> I'm looking in pidgin-facebookchat now
[19:16] <pkt> This is why trying to help on IRC is helpful
[19:16] <pkt> most time you learn new stuff yourself
[19:17] <pkt> Pikkachu: sure, pick the simplest you can find
[19:18] <tumbleweed> Pikkachu: the solution to that is to improve the docs, so it helps if you can tell us where you are getting stuck / confused
[19:19] <pkt> facebookchat looks much more complicated
[19:19] <Pikkachu> pkt: I'm having to install devscripts for mk-build-deps, I hope I don't need any more word-salad packages since it has already a salad of dependencies itself :(
[19:19] <tumbleweed> devscripts is certainly something you want. Any sane packaging documentation should have told you that pretty early on
[19:19] <tumbleweed> I'd also recommend ubuntu-dev-tools
[19:22] <Pikkachu> tumbleweed: the docs are confusing to the point you don't know where it's confusing, but I'd say write something to someone like "I have source code to give people, I want Launchpad to build and publish the .debs for me". Something straighforward to follow for that kind of developer like me
[19:23] <pkt> Pikkachu: the thing is that you need to know the basics of open source development before you start caring about packaging
[19:23] <tumbleweed> Pikkachu: I'm afraid there's a bit of stuff you need to learn along the way, debian packaging has quite a lot going on in it
[19:23] <Pikkachu> pkt: I don't like these standard unclear responses, please
[19:24] <Pikkachu> pkt: any sane developer would hate the whole toolset, to begin with
[19:24] <pkt> I 'm trying to make it specific (searching for a link to a howto)
[19:25] <tumbleweed> Pikkachu: please don't insult our build systems, that doesn't motivate people to help you
[19:25] <Pikkachu> I've read the docs pkt, they're confusing
[19:25] <Pikkachu> tumbleweed: please ignore me, right now, and I'm serious
[19:26] <Pikkachu> pkt: I think the core problem is
[19:26] <tumbleweed> Pikkachu: if you can't have a civil conversation in this channel, could you please move it elsewhere
[19:26] <Pikkachu> pkt: how to know what packages are needed to build the source code
[19:27] <pkt> Pikkachu: what tumbleweed says is true (it is not nice to insult people that try to help you)
[19:27] <pkt> about the build dependencies
[19:27] <pkt> just pick a random plugin (facebookchat)
[19:27] <pkt> and do mk-build-deps -ir in its directory
[19:27] <Pikkachu> tumbleweed: I said kindly to ignore me, and I was serious, I'm not offending you so if you're willing to do something without any reason, I don't really care at all except you're in my way to publish software to people
[19:28] <Pikkachu> pkt: yeah I will concentrate in that point now
[19:28] <pkt> or apt-get build-dep pidgin-facebookchat
[19:28]  * tumbleweed wanders off
[19:28] <Pikkachu> pkt: if I get anything relevant and I'm still here I'll let you know
[19:28] <pkt> ok
[19:29] <Pikkachu> pkt: oh that's even better I can see the packages before confirming, a second...
[19:29] <ESphynx> sorry guys, I was cooking my breakfast ;)
[19:29] <ESphynx> Pikkachu: quite good! if we can only get it working on Precise :) we're releasing the official 0.44 this wednesday
[19:29] <pkt> Hehe, you are lucky it is already night here ...
[19:30] <Pikkachu> pkt: debhelper gir1.2-json-1.0 html2text libdbus-1-dev libdbus-glib-1-dev libglib2.0-dev libjson-glib-dev libpurple-dev po-debconf zlib1g-dev
[19:30] <Pikkachu> pkt: so your idea is eliminating from above what seems unnecessary?
[19:30] <pkt> I would also install pidgin-dev just to be on the safe side
[19:31] <pkt> my idea is to manage to build your plugin out of tree first
[19:31] <pkt> then you can care about removing stuff
[19:31] <pkt> your first objective should be to build the .so successfully from outside pidgin's directory
[19:32] <pkt> by installing the build-deps from another plugin at least you know that the headers/libs you need are available to begin with
[19:32] <pkt> now you need to write your Makefile correctly
[19:35] <Pikkachu> ESphynx: glad to know you got your way on PPas
[19:36] <ESphynx> Pikkachu: almost there, hehehe
[19:36] <ESphynx> Pikkachu: just Precise failing to build :(
[19:39] <ESphynx> pkt: well, taking out -O2 doesn't seem to help!!
[19:42] <Pikkachu> pkt: the makefile from that plugin is 137 lines long, should I read it and amke mine based on that?
[19:43] <ESphynx> Would anyone know how different the Ubuntu patches for GCC are, and how likely they are to cause memory corruption issues? :|
[19:44] <pkt> The short answer is that nothing is impossible with gcc ...
[19:44] <ESphynx> hehehe
[19:45] <jtaylor> what is the problem?
[19:45] <ESphynx> now that i've ruled out the -O2... i'm pretty sure it's a bug in either 4.6.2 on linux, or the ubuntu patches...
[19:46] <ESphynx> jtaylor: My compiled bootstrap eC compiler is going nuts.
[19:46] <ESphynx> jtaylor: it works fine on oneiric and all previous Ubuntus.
[19:47] <pkt> ESphynx: https://code.launchpad.net/~ecere-team/+archive/ppa/+files/ecere_201203031148-0~446~precise1.dsc
[19:47] <pkt> should I try this with gcc-4.5?
[19:47] <jtaylor> does valgrind help?
[19:47] <ESphynx> pkt: yes, please :)
[19:48] <pkt> Ah, btw, I just remembered one of the nuances of gcc 4.6
[19:48] <ESphynx> jtaylor: it could. I usually use my own memory protection tool called 'memoryguard', but since the thing doesn't build yet :P
[19:48] <pkt> (the ubuntu version)
[19:48] <ESphynx> pkt: Ah? (Note it works fine in Oneiric, 4.6.1 ...)
[19:49] <pkt> the $CFLAGS should be in the end of gcc command
[19:49] <pkt> e.g., gcc $FLAGS -c foo.c -o bar.o won't link
[19:49] <pkt> gcc -c foo.c -o bar.o $CFLAGS will work
[19:49] <ESphynx> it won't ? :S
[19:50] <pkt> the reason is a bit esoteric
[19:50] <pkt> and it will work in previous versions AFAIK
[19:50] <ESphynx> love how this word keeps popping up lately.
[19:50] <Ampelbein> pkt: Nothing to do with CFLAGS.
[19:50] <jtaylor> -c does not linking
[19:50] <pkt> yes sorry
[19:50] <pkt> it is actually the linker flags
[19:50] <ESphynx> ok, i'm all confused here... but here it's not something that won't link
[19:51] <ESphynx> every gcc command compiles and links
[19:51] <ESphynx> it just produes horrible results.
[19:51] <Ampelbein> The problem in many packages was that libraries were added in LDFLAGS, which is the wrong place to put them. They belong in either LDADD or LIBADD.
[19:51] <pkt> exactly
[19:51] <pkt> and because ubuntu has a patch to make the linker stricter
[19:52] <Ampelbein> pkt: Ubuntu uses --as-needed by default.
[19:52] <pkt> yep
[19:52] <pkt> gcc-as-needed.diff
[19:52] <ESphynx> I put them in $(LIBS): $(TARGET): $(SOURCES) $(RESOURCES) $(SYMBOLS) $(OBJECTS) | objdir
[19:52] <ESphynx> 	$(CC) $(OFLAGS) $(OBJECTS) $(LIBS) -o $(TARGET) $(INSTALLNAME)
[19:52] <pkt> A friend of mine got burned by this but his source was technically broken anyway
[19:53] <pkt> http://lists.debian.org/debian-devel-announce/2011/02/msg00011.html
[19:53] <ESphynx> Ampelbein: Could this particular difference have any impact on memory corruption?
[19:54] <Ampelbein> ESphynx: Unlikely.
[19:54] <ESphynx> downloading Valgrind.
[19:54] <ESphynx> it's just a matter of linking with -lvalgrind , is it?
[19:54] <jtaylor> no
[19:55] <jtaylor> running your application under valgrind
[19:55] <ESphynx> No linking necessary?
[19:55] <jtaylor> no
[19:55] <ESphynx> Guess I can try that.
[19:55] <ESphynx> it used to be just linking with it right? :)
[19:56] <pkt> no
[19:56] <ESphynx> In the early days?
[19:56] <pkt> it was always running it under valgrind
[19:56] <pkt> there were other projects that required linking
[19:56] <pkt> e.g. electricfence etc
[19:56] <ESphynx> ah. electric fence is the one I was thinking of.
[19:56] <pkt> valgrind works in a different way
[19:57] <ESphynx> k.
[19:57] <jalcine> viva la valgrind.
[19:57] <pkt> your program sees valgrind "as the cpu" sort of
[19:57] <ESphynx> eC's memoryguard works by using another version of libecere.so :)
[19:57] <ESphynx> k
[19:57] <ESphynx> it's surely nowhere as good as valgrind, but usually works great :P Can you run Valgrind on MinGW/Windows?
[19:58] <ESphynx> ok guys. What is wrong with bash's tab completion???
[19:58] <pkt> works here
[19:59] <ESphynx> It's trying to be too intelligent, and won't let me complete files!
[19:59] <ESphynx> e.g. doing make obj/ doesn't autocompelte... it will only give me 'rules', but what if I want to specify an object target?
[20:04] <pkt> you can use shopt -u progcomp I think
[20:04] <pkt> this will disable programmable completion
[20:04] <ESphynx> prog-and-args -- how does that work? I did  'valgrind obj/ecc myargs here' but my app doesn't seem to be getting any args?
[20:04] <pkt> then you can enable it again
[20:05] <ESphynx> hehe k, thanks!
[20:06] <ESphynx> sorry, I had a space where I shouldn't have. works now
[20:07] <ESphynx> ok, under Valgrind, it seems to compile fine!
[20:07] <ESphynx> I get a bunch of 'Source and destination overlap in strcpy(0xbea45aeb, 0xbea45aeb)'
[20:09] <pkt> Hehe great, how I always manage to get more than I sign up for :P
[20:09] <pkt> I started with the simplest RC bug, it seemed to be "just a resync request"
[20:09] <pkt> now it seems that the package actually needs surgery
[20:10] <ESphynx> pkt: Which package is that? :P
[20:10] <pkt> radare
[20:10] <pkt> I picked it from the list of rc bugs
[20:10] <ESphynx> hehe
[20:10] <pkt> since it was among the few that I knew about :P
[20:11] <ESphynx> So these strcpy things... I'm not really worried about :|
[20:11] <pkt> ESphynx: the friend that had the problem with linking because of as-needed
[20:12] <pkt> he also had a memory corruption
[20:12] <pkt> because he had a double free bug in his code
[20:12] <pkt> i.e., he free'd a var without making it NULL and then he free'd again
[20:12] <ESphynx> but his double free bug was unrelated to the as-needed, right?
[20:12] <pkt> yes
[20:12] <ESphynx> yeah, no such thing as double free in my code ;P
[20:12] <ESphynx> and it works fine in Valgrind!
[20:12] <pkt> I only mention because this problem also only showed in gcc 4.6
[20:13] <ESphynx> maybe I should replace calls to ecc in the package by 'valgrind ecc' for Precise :P
[20:13] <pkt> *with
[20:13] <pkt> It seems you are dealing with a "heisenbug"
[20:13] <ESphynx> hehhe
[20:13] <ESphynx> is than an uncertainty principle?
[20:14] <pkt> It is a term used for a bug that doesn't want to reproduce under debugging infrastructure
[20:14] <pkt> like gdb or valgrind
[20:14] <ESphynx> hehe. let me try simple gdb.
[20:15] <pkt> So, about radare. I got the package from debian, but it wouldn't build
[20:15] <pkt> then I discovered that the version in precise shouldn't build either
[20:15] <pkt> (it has the same bug)
[20:15] <ESphynx> great, under gdb, it goes nuts.
[20:16] <pkt> and now that this is fixed as well, lintian decides to reject it
[20:16] <pkt> because of the decision in debian to reject waf binaries :P
[20:17] <tumbleweed> well, at least yo uare half way there
[20:18] <pkt> I hope more than half hehe
[20:18] <pkt> But this could probably be characterised a "hydra bug"
[20:19] <pkt> every subbug I fix 2 others are revealed :P
[20:19] <ScottK> The new minc in Unstable looks like we might want it, if someone has time to investigate...
[20:20] <ESphynx> jtaylor: Any idea why something would work on Valgrind (without seeing any error), but behaves nuts on GDB?
[20:20] <jtaylor> valgrind runs under a very different environment
[20:20] <jtaylor> which is often more resistant to issues
[20:20] <jtaylor> did it output any errors?
[20:20] <ESphynx> jtaylor: only those strcpy overlap errors (strcpy(string, string))
[20:21] <jtaylor> thats your issue
[20:21] <jtaylor> libc has changed
[20:21] <jtaylor> this will now crash
[20:21] <ESphynx> jtaylor: you sure?
[20:21] <jtaylor> yes
[20:21] <jtaylor> memcpy's are now done backwards
[20:21] <jtaylor> that breaks overlaps
[20:21] <ESphynx> i.e. you're positive something changed between oneiric and precise ?
[20:21] <jtaylor> but is faster
[20:21] <ESphynx> ugg. on x86?
[20:21] <jtaylor> its something that changed recently
[20:22] <ESphynx> I can understand on some exotic platform
[20:22] <ESphynx> but on x86?
[20:22] <jtaylor> use memmove for overlaps
[20:22] <jtaylor> on x86
[20:22] <ESphynx> it's not even 'overlap' is the same string :|
[20:22] <akrogames> hi jtaylor
[20:22] <ESphynx> well. if you say so!! I'll go and hunt those down.
[20:22] <ESphynx> thanks for clarifying this
[20:22] <jtaylor> not sure how that will work
[20:22] <jtaylor> but its 100% an issue that must be fixed
[20:22] <ESphynx> jtaylor: you mean the same string?
[20:23] <jtaylor> there should be a flag for libc hhat disables the feature
[20:23] <jtaylor> read the README
[20:23] <ESphynx> jtaylor: i'd love to try out that flag...
[20:23] <ESphynx> to be sure before I invest the time to fix this
[20:23] <jtaylor> let me check
[20:23] <ESphynx> thanks
[20:23] <ESphynx> (So it would be libc rather than gcc?)
[20:24] <jtaylor> yes
[20:25] <jtaylor> LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-preload.so /path/to/binary
[20:26] <jtaylor> though that change should already be in oneiric
[20:26] <broder> ESphynx: regardless of whether it fixes *the* problem you're trying to track down, strcpy(string, string) is definitely *a* problem and you should not be doing it
[20:27] <ESphynx> I understand and respected that for memcpy...
[20:27] <ESphynx> But to me strcpy(string, string) should just work :P
[20:27] <jtaylor> no it should not
[20:27] <jtaylor> and never should have
[20:27] <ESphynx> Why not :)
[20:27] <jtaylor> the manpage clearly says the memory regions *must* not overlap
[20:28] <jtaylor> ok it only says may not :O
[20:28] <ESphynx> too bad Dennis isn't among us anymore to discuss it :P
[20:28] <jtaylor> that should be fixed
[20:33] <jtaylor> why do you do that copy in the first place?
[20:34] <ESphynx> jtaylor: i use it e.g. for left trimming purposes
[20:34] <ESphynx> strcpy(string, string + x) , where x sometimes is 0
[20:35] <ESphynx> From Valgrind's output, it seems to happen in 3 spots: LoadTranslatedStrings, ChangeExtension, and TrimLSpaces
[20:35] <broder> ESphynx: it would be better to strcpy(string + x) and then free(string)
[20:35] <broder> assuming you're using a heap buffer
[20:36] <broder> err, sorry, strdup
[20:36] <ESphynx> right.
[20:36] <ESphynx> I have my own memory manager though... so I have CopyString()
[20:36] <ESphynx> but I generally try to avoid heap allocs...
[20:38] <ESphynx> thanks guys. since I only have 3 spots should be easy to try it out
[20:38] <jtaylor> did the wrapper work?
[20:39] <ESphynx> jtaylor:  LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-preload.so /path/to/binary  --> this is to revert to the previous way?
[20:39] <jtaylor> yes
[20:39] <ESphynx> let me try that
[20:39] <jtaylor> there is also a version that dumps to syslog
[20:39] <jtaylor> LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-syslog-preload.so /path/to/binary
[20:40] <ESphynx> hmm x86 here, not 64 bit
[20:40] <jtaylor> hm the change is only in amd64
[20:41] <ESphynx> yeah I don't seem to have this memcpy-preload.so
[20:43] <ESphynx> nor a /i386-linux-gnu/libc directory :|
[21:18] <pkt> Hmm, ok now the package builds, so the problem becomes how to push the fixes
[21:19] <pkt> It isn't just a sync request anymore since there is an extra patch
[21:20] <pkt> And I think maybe it would be good to push to debian as well
[21:24] <micahg> pkt: is this for radare?
[21:24] <pkt> yes micahg
[21:24] <jtaylor> can I see the diff?
[21:25] <jtaylor> the package looks in bad shape
[21:25] <jtaylor> lots of uncaught errors in the logs
[21:25] <jtaylor> as needed issues
[21:25] <jtaylor> requires py2.5
[21:25] <micahg> and we have radare2 already
[21:26] <jtaylor> can we just remove radare then?
[21:26] <micahg> no reverse dependencies, we could remove it
[21:26] <pkt> I 'm fine with removing it as well
[21:26] <pkt> my fix is just for the FTBFS
[21:27] <jtaylor> I looked at it too, fixing one issue just uncvered another issue later ...
[21:27] <jtaylor> etc etc
[21:27] <pkt> hehe exactly
[21:27] <jtaylor> I'm for nuking it
[21:27] <micahg> well, the explicit python2.5 dep isn't expressed in the packaging
[21:27] <pkt> this is what I fixed
[21:28] <pkt> and for lua as well
[21:28] <pkt> the build deps are implicit in the Makefile
[21:28] <jtaylor> ruby is needed too
[21:28] <pkt> it seems to build without it here
[21:29] <jtaylor> can you pastebin your diff
[21:29] <pkt> sure
[21:29] <ESphynx> jtaylor: I'll be damned.
[21:29] <ESphynx> jtaylor: The build is working now. Thank you!!!
[21:30] <pkt> http://pastebin.ubuntu.com/868973/
[21:30] <jtaylor> you didn't fix the as needed issue?
[21:30] <pkt> no
[21:31] <pkt> I didn't see that one
[21:31] <jtaylor> my not working "fix": http://paste.ubuntu.com/868975/
[21:31] <jtaylor> src/rsc/gtk/Makefile needs fixing
[21:31] <jtaylor> that worked pre oneiric
[21:32] <pkt> when you say not working what do you mean?
[21:32] <pkt> FTBFS?
[21:32] <pkt> or not working result?
[21:32] <ESphynx> Now I have a question guys regarding the multiarch stuff... Adding ia32-libs-multiarch fixed the build on oneiric, but on Precise it doesn't.
[21:32] <ESphynx> I realize that people can just install the i386 build on their Precise amd64 install... But what about people wanting to build from source on amd64?
[21:32] <jtaylor> it does not link, but the error is noon fatal
[21:32] <jtaylor> but its an regression
[21:33] <pkt> I see
[21:33] <pkt> I can look at it
[21:33] <pkt> unless the package is to be dropped of course
[21:34] <jtaylor> I don't really now the difference between the two
[21:36] <ESphynx> Alt-F "Search" shortcut ? how can I disable that? :|
[21:38] <ESphynx> ah no, it's just 'alt / released' :| how annoying!!
[21:51] <ESphynx> the hud :| disabled that...
[21:51] <ESphynx> E: Package 'ia32-libs-multiarch' has no installation candidate --> where should I ask about this?
[21:52]  * Pikkachu tired
[21:52] <ESphynx> when tired, sleep :)
[21:53] <ESphynx> "This may mean that the package is missing, has been obsoleted, or is only available from another source"
[21:56] <pkt> micahg fwiw I think I fixed the as-needed issue as well
[21:56] <pkt> Sorry for taking so long but compiles take long time here
[21:58] <ESphynx> tumbleweed: you remember this amd64 issue I had? =)
[22:08] <pkt> http://pastebin.ubuntu.com/869020/
[22:08] <pkt> these are my changes
[22:08] <ESphynx> pkt: Any idea about multiarch? :| where should I ask about this? :\
[22:09] <pkt> sorry, not much experience with this
[22:09] <ESphynx> I basically want to know how one is meant to build a 32 bit app on a 64 bit machine :|
[22:09] <pkt> ah ia32-libs-multiarch
[22:09] <pkt> it reminds me of something
[22:09] <JanC> multiarch allows you to install i386 packages on an amd64 system
[22:10] <pkt> wine was broken a little time ago because of this I think
[22:10] <ESphynx> adding this fixed the build on Oneiric (i.e. just ia32-libs, which works on Natty, wasn't enough)
[22:10] <pkt> there was a change for precise IIRC
[22:10] <JanC> so no more need for ia32-lib*
[22:10] <ESphynx> JanC: I understand that. but what about 'building' on a 64 bit machine
[22:10] <JanC> (in theory)
[22:10] <ESphynx> a 32 bit app?
[22:11] <JanC> well, I guess you would need the right 32-bit compiler & -dev packages
[22:11] <ESphynx> JanC: which are all specified in my package dependencies... So I would wish my package builds on a 64 bit machine as well
[22:12] <ESphynx> But I get this error: Package ia32-libs-multiarch is not available, but is referred to by another package.  This may mean that the package is missing, has been obsoleted, or is only available from another source. E: Package 'ia32-libs-multiarch' has no installation candidate
[22:12] <JanC> ESphynx: one option is to use a chroot or similar
[22:12] <JanC> pbuilder can do that...
[22:12] <ESphynx> JanC: On Oneiric, which also uses multiarch, it 'just works'
[22:13] <ESphynx> (My makefiles all have -m32 to build in 32 bit)
[22:13] <JanC> BTW: you probablmy don't need/want any ia32-lib* packages anymore
[22:14] <JanC> as a dependency
[22:14] <ESphynx> JanC: but I do need the 32 bit dev packages to be installed! how can I let the package manager know about that?
[22:14] <ESphynx> for the build to work...
[22:14] <pkt> btw I think the package is now ia32-libs-multiarch:386
[22:15] <ESphynx> pkt: that might work :)
[22:15] <JanC> maybe specify dependencies as libfoo-dev:i386 ?
[22:15] <ESphynx> JanC: I got all those coverd (well not with :i386... I just learned about that :P)
[22:15] <ESphynx> i'm downloading Precise 64 so I will give that a try
[22:16] <JanC> what I mean is: don't use the ia32-* stuff anymore  ;)
[22:17] <ESphynx> JanC: right. use :i386 instead ?
[22:17] <JanC> I think so
[22:17] <ESphynx> that's basically my question :P hehe, what should I do :P
[22:18] <JanC> I think you should build them on a 32-bit system/chroot and then install using :i386 on the amd64 system  ;)
[22:18] <ESphynx> JanC: that's not easy for people downloading my software as source :P
[22:18] <JanC> at least, I think that's how it's done officially
[22:18] <ESphynx> I want them to just do 'make' and it works
[22:18] <JanC> PPA?
[22:18] <pkt> JanC's way seems the right way to go
[22:19] <ESphynx> ESphynx: i mean, right from a git clone... I want them to just do 'make' even if they are on amd64
[22:19] <ESphynx> pkt: :i386 ?
[22:19] <pkt> I mean to build in 386 chroot
[22:19] <ESphynx> pkt: that's a pain for users.
[22:19] <JanC> ESphynx: why would you need to build 32-bit only anyway?
[22:19] <pkt> :i386 seems to be for depending on i386 libraries
[22:20] <ESphynx> JanC: 'cuz my software doesn't support 64 bit yet :P (i hope it will later this year...)
[22:20] <pkt> not for dev tools, at least if I understand correctly
[22:21] <ESphynx> pkt: those ia32-libs / ia32-libs-multiarch did get things building on oneiric though :P
[22:21] <JanC> ESphynx: make a daily build PPA on Launchpad for those who want the latest version, but really, you should fix your software first instead of trying to set up weird build systems  :P
[22:22] <Pikkachu> amazing, I installed libglib2.0 and it succeeded to install, but now thinks removing it is too dangerous???
[22:22] <ESphynx> JanC: yes, but I still think it should be possible to build in 32 bit on a 64 bit system.
[22:22] <pkt> Unfortunately I have to leave now
[22:22] <ESphynx> I mean, it was easy before
[22:22] <ESphynx> thanks for all your help pkt. good night and take care :)
[22:23] <pkt> I will put radare in my ppa and look into how to merge it tomorrow
[22:23] <RAOF> It *is* possible to build 32bit binaries on a 64bit system, but it's non-trivial.
[22:23] <pkt> thanks ESphynx: I hope you will solve the build problems
[22:23] <ESphynx> JanC: and it's not weird :P
[22:23] <JanC> ESphynx: it is possible, but the recommended way is to use a chroot or a VM  ;)
[22:23] <ESphynx> RAOF: Any advice?
[22:23] <ESphynx> pkt: I solved the i386 one!
[22:23] <pkt> cheers, goodnight everyone :)
[22:23] <ESphynx> pkt: it was the stricter libc regarding strcpy overlap...
[22:23] <pkt> ah, that makes sense yes :)
[22:24] <RAOF> ESphynx: Multiarch gets you *most* of the way there, but -dev packages aren't multiarched yet.
[22:24] <ESphynx> as jtaylor pointed out ;P
[22:24] <JanC> building binaries is one thing, building packages complicates it somewhat more
[22:24] <Pikkachu> if I didn't recover the additional files the system would be compromised: libglib2.0-0-dbg libglib2.0-0-refdbg libglib2.0-cil-dev libglib2.0-doc
[22:24] <ESphynx> RAOF: it was working on oneiric ... with ia32-libs and ia32-libs-multiarch
[22:24] <ESphynx> RAOF: but on precise now I get this weird E: Package 'ia32-libs-multiarch' has no installation candidate
[22:24] <ESphynx> RAOF: https://launchpadlibrarian.net/95113396/buildlog_ubuntu-precise-amd64.ecere_201203031148-0~446~precise1_MANUALDEPWAIT.txt.gz
[22:24] <Pikkachu> anyone using pidgin help me testing a thing?
[22:25] <ESphynx> Pikkachu: What's your pidgin plugin do?
[22:25] <RAOF> ESphynx: Oh!  That's very simple - don't build an amd64 package :)
[22:26] <RAOF> ESphynx: Your i386 package will show up on amd64 packages, and the multiarch support will pull in the relevant dependencies.
[22:26] <ESphynx> RAOF: I understand that. but I'm worrying about people ON a 64 bit machine, wanting to build my source.
[22:27] <ESphynx> I want 'make' to work for them.
[22:27] <Pikkachu> ESphynx: changes nick when you are away (can't be tested within this channel :(, but you could use some other network )
[22:28] <ESphynx> Pikkachu: hehe sorry I don't use pidgin, I use Ecere Communicator and mIRC :P was just curious
[22:28] <RAOF> ESphynx: Ah.  That's no longer possible without some manual work on their side (creating dev symlinks).  It only accidentally worked with ia32-libs, too :)
[22:31]  * Pikkachu brb
[22:32] <ESphynx> RAOF: I wish it would accidentally work again.
[22:32] <EvilResistance> is CDBS still supported/used?
[22:32] <EvilResistance> for packaging
[22:32] <EvilResistance> oh nevermind
[22:32] <ESphynx> RAOF: it worked till Oneiric ...
[22:32] <EvilResistance> but perhaps a MOTU could discuss with me how this could be improved: https://wiki.ubuntu.com/PackagingGuide/Basic#rules
[22:32] <EvilResistance> erm
[22:33] <RAOF> ESphynx: Well, it can *kinda* work now; you'd need to instruct the user to install libfoo-dev:i386.  That'll work, as long as they don't have libfoo-dev:amd64 installed.
[22:33] <EvilResistance> ermhttps://wiki.ubuntu.com/PackagingGuide/Basic
[22:33] <EvilResistance> BLEH
[22:33] <EvilResistance> https://wiki.ubuntu.com/PackagingGuide/Basic <-- this even
[22:33] <ESphynx> RAOF: ugg!!!
[22:33] <jtaylor> RAOF: aren't many -dev packages coinstallable?
[22:33] <ESphynx> RAOF: but it does 'skipping incompatible' , doesn't it?
[22:33] <ESphynx> RAOF: the linker ignores wrong architecture...
[22:33] <EvilResistance> MOTUs: https://wiki.ubuntu.com/PackagingGuide/Basic <-- doesnt this ignore the 'install' file, which defines "Where to put built files"?
[22:34] <ESphynx> RAOF: really it's only an apt-get being stubborn here that's the problem
[22:34] <jtaylor> ESphynx: you have to pass -m32 of course
[22:34] <RAOF> ESphynx: Right.  But the *correct* architecture is available.  As long as you pass -m32.
[22:34] <ESphynx> i.e. it works in oneiric, with both pacakges installed
[22:34] <ESphynx> jtaylor: I do (always)
[22:35] <ESphynx> RAOF, jtaylor: So should I just try chanigng the ia32-libs dependencies for libbla-dev:i386 ? might that work ?
[22:35] <jtaylor> I don't think that works yet
[22:35] <RAOF> ESphynx: Yes, that will probably work.
[22:35] <micahg> no, that won't work on the buildds
[22:35] <RAOF> Oh, that's right.
[22:35] <jtaylor> or it will ^^
[22:35] <ESphynx> love it ;)
[22:35] <RAOF> You can't have a package dependency on :i386.
[22:36] <RAOF> You can *tell* people to install :i386, but there's no syntax for doing that in debian/control.
[22:36] <ESphynx> But will it work for the user
[22:36] <ESphynx> to do apt-get install with :i386 ?
[22:37] <ESphynx> and I'll just disable the PPA build for amd64 on Precise.
[22:37] <EvilResistance> micahg:  jtaylor:  can i get your input on the packaging guide?
[22:37] <EvilResistance> it appears to be missing things
[22:37] <EvilResistance> (the basic guide)
[22:37] <RAOF> Yes.  It should work for the user (assuming they don't have :amd64 installed)
[22:37] <ESphynx> RAOF: Even if they do, I think? (hope)
[22:37] <Pikkachu> hi, I'm willing to have launchpad compiling and building a plugin I wrote to pidgin onto a PPA, I have created the Makefile based on another plugin, does it look good? http://pastie.org/3521901. I wanted to remove the unnecessary flags tough.
[22:37] <jtaylor> RAOF: most -dev packages should be coinstallable?
[22:38] <jtaylor> I tried it once with one of mine
[22:38] <jtaylor> worked flawlessly
[22:38] <ESphynx> jtaylor yes I would think so.
[22:38] <RAOF> jtaylor: I'm pretty sure it's a policy violation to have -dev coinstallable.
[22:38] <micahg> EvilResistance: install file not needed for basic packaging (i.e. one binary)
[22:38] <jtaylor> really?
[22:38] <jtaylor> I have seen a couple of -dev pacakge declaring MA: same
[22:38]  * ESphynx beats the policy
[22:38] <jtaylor> why would it violate policy?
[22:39] <micahg> well, coinstallable dev packages isn't required by multiarch policy yet
[22:39] <ESphynx> yes, why? :O
[22:39] <ESphynx> I vote it should be _o/
[22:39] <jtaylor> when the checksums match it works fine
[22:39] <ESphynx> thanks for all the help guys. appreciate it.
[22:39] <jtaylor> but I recall the huge discussion on that on d-d
[22:40] <ESphynx> got to run for now ;) cheers.
[22:40] <jtaylor> is there a result of that yet? I haven'T read everything
[22:40] <RAOF> jtaylor: http://wiki.debian.org/Multiarch/Implementation#What_does_the_end_result_look_like.3F
[22:40] <RAOF> Hm, actually, on closer inspection... no.
[22:40] <jtaylor> RAOF: multich same -dev package conform to that
[22:41] <RAOF> That doesn't prohibit multiarch -dev packages.
[22:41] <ESphynx> successful i386 PPA build on Precise =) https://code.launchpad.net/~jerstlouis/+recipe/ecere-daily-multiarch
[22:50]  * Pikkachu brb
[23:05] <tumbleweed> ESphynx: my recommendation was to not bother building on amd64, in the multi-arch world
[23:18] <ESphynx> tumbleweed: right, I think i'll go that way, I was just worried about people 'building' on an amd64 system...
[23:18] <ESphynx> but as RAOF and jtaylor pointed out, they can probably install the :i386 packages
[23:18] <ESphynx> (which unfortunately we cannot do from the package system)


[13:06] <chetan105in> Heh Guys , new to ubuntu and ARM working on a Tegra 2 development board
[13:07] <chetan105in> ogra : had a few questions please do help if possible ,
[14:38] <rsalveti> chetan105: please post your question, and later someone can answer you
[15:21] <jacquesdupontd> HAPPY NEW YEAR
[15:21] <jacquesdupontd> (JAPAN)
[17:21] <Kamondelious> what changes have there been in the past month or so that would change the output video resolution on me when I upgraded?
[19:30] <Jerok> Hello
[19:32] <Jerok> Having problems with rootstock. Trying to build a rootfs with a kernel but it stops after downloading the kernel without building the rootfs.
[23:29] <ogra> happy new year everybody !
[23:57] <prpplague> ogra: whatever
[23:57]  * prpplague says "bah humbug"


[00:23] <CIA-28> ubiquity: superm1 * r4404 ubiquity/ (d-i/manifest debian/changelog):
[00:23] <CIA-28> ubiquity: Automatic update of included source packages: flash-kernel
[00:23] <CIA-28> ubiquity: 2.28ubuntu10.
[00:24] <CIA-28> ubiquity: superm1 * r4405 ubiquity/debian/changelog: releasing version 2.4.2
[00:34]  * persia worriedly looks for ogra's user-setup-apply changes
[00:35] <persia> Oh, heh, never commited to user-setup: clearly don't belong in ubiquity yet.
[00:37] <superm1> i think he should be able to switch to the user 'oem' now after all the above, i don't see any more problems running oem-config like now
[00:39] <persia> I'm not sure he will, given the last discussion about running as "oem" with him led to a patch to run as root OR oem depending on whether oem had been created (and jasper doesn't).
[00:39] <persia> I just thought he had a fix for bug #646421, but apparently not.
[00:39] <ubot2> Launchpad bug 646421 in user-setup (Ubuntu Maverick) (and 3 other projects) "oem-config process that zero's swap broken on armel preinstalled images (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/646421


[00:59] <optrusty> Hey Guys!!
[00:59] <optrusty> I just got the good news
[01:00] <optrusty> But WHere do I create the wiki page and What do I put
[01:17] <rww> what good news?
[01:59] <optrusty> rww Open positions
[02:00] <rww> oh, for the IRCC
[02:01] <rww> generally, that would go on http://wiki.ubuntu.com/FirstnameLastname or http://wiki.ubuntu.com/LaunchpadID
[04:27] <rww> optrusty: I note that one of the requirements for Ubuntu's IRC Councilmembers is that they be Ubuntu Members already, and you don't seem to be one, so you'd need to get that first.
[04:27] <rww> !membership
[04:29] <rww> (this is mentioned on the wikipage that the ubuntu-irc@ email suggests you should read ;)
[04:52] <Unit193> Oh wow.  And for reference: https://lists.ubuntu.com/archives/ubuntu-irc/2014-October/001751.html
[23:27] <fomenko> hi
[23:27] <fomenko> are anyone here?
[23:28] <fomenko> hello