[11:04] <ari-tczew> give-back didn't build packages succefly
[11:05] <persia> That's often the case of mass-give-backs.
[11:05] <ari-tczew> successfully
[11:05] <persia> usually *some* packages build successfully, and the rest fail (because they are failing for real reasons)
[11:06] <ari-tczew> this page is nice: http://qa.ubuntuwire.org/debcheck/debcheck.py?dist=natty&list=ALL
[11:06] <ari-tczew> developers/contributors can look where package couldn't be installed
[11:07] <persia> Well, kinda.  There's still some gaps here ad there.
[11:07] <persia> Especially for packages that have arch-specific issues.
[11:09] <Madkiss> good morning.
[11:10] <ari-tczew> good morning Madkiss
[11:11] <Madkiss> I am a little bit puzzled about the ubuntu motu stuff ... I'm interested in helping out with Ubuntu better than I have done so before; i've been a debian developer since 2003, many of the packages I maintain in Debian are in Ubuntu, too, and maintained there with my help, although I have not done any uploads yet.
[11:12] <Madkiss> I'm mostly working on Linux High Availability clustering stuff, which is partially in ubuntu universe right now, but which is supposed to make it into the ubuntu core system soon
[11:12] <Madkiss> so I have no idea how to go on ... ;)
[11:12] <Madkiss> Thought i'd better ask somebody more clueful on this than I am.
[11:12] <ari-tczew> Madkiss: we have to do stuff like: merges/syncs, security updates, SRUs, FTBFS fixes, install issues
[11:13] <persia> Madkiss, So, there's been a reorganisation of Ubuntu development some time back, and the documentation is still catching up.
[11:13] <ari-tczew> Madkiss: https://wiki.ubuntu.com/MOTU#MOTU%20Processes
[11:13] <persia> "MOTU" is basically the QA catch-all, because most packages don't have dedicated maintenance groups in Ubuntu.
[11:14] <persia> (and we never have individual maintainers, or exclusive maintenance).
[11:14] <persia> If you're interested in HA stuff, there's basically two ways that are probably easiest:
[11:14] <persia> 1) work with the Ubuntu Server team (assuming they are planning to include the HA stuff that interests you in their flavour), and potentially become an Ubuntu Server developer.
[11:15] <persia> 2) Work on the HA stuff that interests you directly, and eventually apply for upload rights for those packages to no longer need a sponsor (as a DD and maintainer for some of the packages, you'll mostly be expected to get sponsorship to learn processes, rather than many technical changes).
[11:16] <persia> So, let's look at some concrete stuff: what do you want to do?
[11:17] <Madkiss> I have never actually done an upload into some Ubuntu release myself, I have just done all the according packages for Debian and the ubuntu-packages are 98% equal to the Debian one's.
[11:17]  * ari-tczew would rather ask, which area Madkiss is interested to work for?
[11:18] <persia> We generally encourage changes to happen in Debian to support both distributions, unless there is some strong reason not to do so.
[11:18] <persia> Do you have some pending issues with some of the Ubuntu HA packages that you want to address?  For future releases?  For stable releases?
[11:20] <Madkiss> I would like to be in a position where I can directly influence the packages from a technical point of view. Right now, I do changes in the Debian packages (of drbd, pacemaker, heartbeat, cluster-glue, corosync) or have them introducted by upstream (LINBIT, which I happen to work for), but it takes weeks until these changes trickle down into Ubuntu
[11:21] <Madkiss> from an HA point of view, given that current Linux-HA development is progressing quite quickly and delivers substantial improvements regularly, Ubuntu is way more suitable for HA servers than Debian Stable is, and yet, 10.04 does not have all the cool stuff it could have (and neither does 10.10), because there was some sort of release blocker which I only learned with some delay about
[11:22] <persia> OK.  So I think your target should be upload access to the packages of interest to you.
[11:22] <Madkiss> I fixed that release-blocker in Debian Unstable, but these packages are in NEW now, and it will take ages to get them processed
[11:22] <persia> Now, you mention they are "supposed to make it into the ubuntu core system soon".  Am I correct that this reflects plans of the Ubuntu Server team?
[11:23] <Madkiss> I think so. I have to admit the last time that I talked with Ubuntu people about this, they told me they would want to "get this whole stuff into the core system"
[11:23] <persia> Do you happen to know with whom you talked?
[11:23] <Madkiss> but it would definetely make sense to have cluster-stuff in the Server distribution, yes
[11:24] <Madkiss> RoAkSoAx.
[11:24] <Madkiss> and ivoks
[11:24] <Madkiss> ;)
[11:25] <ari-tczew> Madkiss: if you are interested in QA stuff, I'd like to encourage you to help us reducing merges (different between ubuntu and debian) and fixes FTBFS
[11:25] <persia> Yeah, you probably want to talk to the Server folk.
[11:25] <persia> I doubt many are on IRC much for that sort of discussion until November (lots of folks have started travel to UDS, and will be spending the week discussing natty plans).
[11:26] <Madkiss> ari-tczew: I have just restructured the Debian packages of pacemaker and cluster-glue to release ubuntu-people from the burden of having an utterly big delta between ubuntu<->debian
[11:26] <ari-tczew> aha, nice
[11:27] <persia> I'd recommend dropping by #ubuntu-server in very early November, mentioning that you're working on HA in Debian, and want to work with HA also in Ubuntu, and help integrate it with Ubuntu Server.
[11:28] <Madkiss> that sounds like a plan. will do so, then.
[11:28] <persia> Those folk would be the best to sponsor your changes until you get familiar with the procedures, and to nominate you to be a Server Developer to be able to upload server stuff  if you get closely integrated with the team.
[11:28] <persia> And they ought be happy to lead you through procedures, discuss differences to Debian, etc.
[11:29] <ari-tczew> persia: what is HA?
[11:30] <persia> ari-tczew, High Availability.
[11:30] <persia> Imagine you manage a bundle of servers (even just 10).
[11:30] <persia> Imagine you want your users to never experience downtime.
[11:31] <persia> Imagine you want your users to never experience downtime when someone walks into the data centre and takes out three pieces of equipment with an axe.
[11:31] <persia> This is possible, but it requires careful organisation of services and redundant configurations.
[11:32] <persia> "High Availability" is the catch-all name for balancing, clustering, service migration, heartbeat monitoring, replication, etc. that allows this sort of thing to be done.
[11:32] <Madkiss> I like that Axe metaphor.
[11:32] <persia> (but Madkiss can surely tell you more than I)
[11:32] <ari-tczew> IIRC ttx is also Server developer
[11:33] <ari-tczew> he is very helpful sponsor
[11:33] <Madkiss> i'll be happy talking to these people soon
[11:33] <persia> Madkiss, comes from a customer requirement for the first DC I installed.
[11:33] <Madkiss> persia: ah. guess they have a good working climate. ;)
[11:34] <Madkiss> thank you for your help. need to leave now, gotta get an axe.
[11:34] <Madkiss> (to test our own HA setups, obviously)
[11:34] <persia> Clearly.  Just be careful to get one with a rubber handle in case you select the power conditioning system for testing.
[12:16]  * Laney is US-bound
[15:12] <ScottK> Madkiss: You want to find (IIRC) RoAkSoAx or ivoks and chat with them as they are the people who I think are most interested in HA.
[15:20] <devildante> hello everyone :)
[15:20] <devildante> is there a page explaining how to do merges and syncs?
[15:21] <devildante> (wiki page)
[15:21] <geser> !merges
[15:22] <geser> devildante: https://wiki.ubuntu.com/UbuntuDevelopment/Merging and https://wiki.ubuntu.com/SyncRequestProcess hopefully help you further
[15:23] <devildante> thanks geser :)
[15:23] <nigelb> geser: singular, for future reference
[15:23] <geser> ah, didn't want to try again (and fail)
[15:24] <nigelb> heh :)
[15:51] <bdrung> i have setup a poll. please vote: http://overbenny.wordpress.com/2010/10/23/poll-how-to-call-the-library/
[16:01] <devildante> hmm, the instructions on https://wiki.ubuntu.com/UbuntuDevelopment/Merging doesn't work for me
[16:01] <devildante> either they are outdated, or I'm doing something wrong
[16:01] <devildante> can someone guide me?
[16:01] <devildante> please :)
[16:04] <ScottK> bdrung: Is there any discussion with major upstreams about adopting this?
[16:05] <bdrung> ScottK: not yet. i first tried to get glib changed, but it ended with an bikeshed. some people think that this doesn't belong to glib.
[16:07] <ScottK> Without some upstream plan, IMO, this is full of fail.  Doing this kind of thing at the distro level isn't going to work.
[16:07] <bdrung> ScottK: current idea: create this library and change the upstream projects to optional build against the library.
[16:07] <ScottK> Have you done an analysis of what is OK and what needs fixing?
[16:07] <ScottK> IIRC, for example, KDE already DTRT.
[16:07] <ScottK> (fsvo right)
[16:08] <bdrung> DTRT?
[16:08] <ScottK> do the right thing.
[16:08] <ScottK> (or does)
[16:09] <bdrung> whit whom should i discuss the KDE part? having one place for selecting the size would be nice.
[16:10] <bdrung> ScottK: i have patched nautilus and brasero locally. diff for nautilus: http://pastebin.com/vemgPg7i
[16:11] <bdrung> ScottK: i have created a list of applications that needs to be fixed.
[16:11] <ScottK> For KDE, I think it's all done in kde4libs, but I don't think there's anything to change (and in fact a proposed patch to use non-revisionist units as on option was rejected)
[16:12] <bdrung> ScottK: yes, kde4libs provides the functions.
[16:12] <ScottK> So I think you can call it "done".
[16:13] <bdrung> ScottK: what do you mean with " use non-revisionist units as on option"?
[16:14] <ScottK> bdrung: I new what a kilobyte was until people started changing stuff.
[16:14] <ScottK> new/knew
[16:15] <bdrung> ScottK: i still not get what you wanted to say.
[16:15] <bdrung> the current kde4libs allow tweaking the units by changing a value in $KDEHOME/share/config/kdeglobals
[16:16] <ScottK> Interesting.  I guess the patch got in then.
[16:16] <ScottK> I thought it didn't.
[16:16] <bdrung> ScottK: it did one year ago.
[16:17] <ScottK> I think the whole kibi/mibi thing is an awful idea.  It confuses the heck out of me.  I lived for decades knowing exactly what a kilobyte was and now I don't.
[16:18] <bdrung> ScottK: the library will have an way to configure the preferred unit. you can select base2 there. base2 will avoid confusion.
[16:20] <bdrung> ScottK: we have to choices: do nothing and keep the ambiguous meaning of "MB" and co. or we change the applications to avoid the ambiguity, but make some people unhappy.
[16:20] <xteejx> Afternoon all
[16:21] <xteejx> If something contains LDFLAGS = @LDFLAGS@ how do I add linker flags? Can they be passed in
[16:21] <xteejx> debian/rules?
[16:21] <ScottK> bdrung: There was no ambiguity before.  You just had to understand context.  Pretending there is, is just giving in to hard disk manufacturer marketing.
[16:22] <bdrung> ScottK: in which country do you live?
[16:22] <ScottK> bdrung: US.
[16:22] <ScottK> I'm also older.
[16:22] <ScottK> I spent years unconfused on this topic.  Decades.
[16:23] <bdrung> ScottK: that's the "US" problem - you are probably not familiar with the SI units like we Europeans.
[16:23] <xteejx> Try living in the UK and using both :P
[16:24] <ScottK> bdrung: No.  I'm quite familiar with them.  The problem is that we are pretending these are SI units.  They aren't.
[16:24] <ScottK> (if you think they are, find me a microbyte)
[16:25] <xteejx> Can someone help me with the binutils-gold ftbfs with fossology please?
[16:25] <bdrung> ScottK: we use the SI prefixes for everything and not only for SI units.
[16:25] <xteejx> Not quite sure where to insert stuff to make the linker link :)
[16:26] <ScottK> xteejx: It's very build system dependent.  There isn't a generic answer.  When I've solved it, I generally had to grep the source to figure out where it was hiding the linking commands.
[16:26] <ScottK> Sometimes (once so far) it's nicely in debian/rules.
[16:27] <xteejx> ScottK: I can't see any 'obvious' answer apart from LDFLAGS = @LDFLAGS@, but it's in one file, not releated to a Makefile or configure file :(
[16:27] <ScottK> bdrung: A kilobyte of RAM has been 1024 bytes since the dawn of the computer age.  Changing it over half a century into that age and then pretending it was wrong all along is just silly.
[16:28] <bdrung> ScottK: there will be an option for you too, which makes the application behave like before.
[16:28] <ScottK> xteejx: Right, so now figure out where that gets set.  If it's a CDBS application you'll need the CDBS source and grep that too.
[16:28] <xteejx> The Imperial units vs SI debate has been going on for years
[16:28] <ScottK> xteejx: That's an unrelated issue.
[16:28] <xteejx> ScottK: I did what-patch and it said patchless
[16:28] <ScottK> 1024 bytes in a kilobyte of RAM is just what is is.
[16:29] <geser> I guess making it configurable is the only sane options as no choice will make both sides happy
[16:29] <ScottK> xteejx: CDBS is build system, not patch system.  Look in build-depends.
[16:29] <xteejx> Ahh :)
[16:29]  * bdrung is going to the release party. See you later.
[16:29] <ScottK> geser: Fixing it upstream for whatever version of fix would make me happiest.
[16:29] <xteejx> ScottK: Nope, no cdbs deps
[16:30] <ScottK> (of the potentially available options - kibibyte going away would make me happiest, but that isn't happening)
[16:30] <ScottK> xteejx: depends or build depends?
[16:31] <xteejx> ScottK: Both
[16:31] <ScottK> OK.  Don't worry about CDBS then.
[16:33] <xteejx> Hmm, I do see "CFLAGS_DB=-I`pg_config --includedir` -I$(DBPATH) -L$(DBPATH) -lfossdb" in Makefile.conf...those "-l"'s look a bit configurable...but are they linkers?
[16:34] <ScottK> If you add the missing one after -lfossdb it ought to work.
[16:34] <xteejx> Hmm, fingers crossed its a big build :)
[16:34] <xteejx> -lrpmio for /usr/lib/librpmio.so.1 sound right?
[16:35] <ScottK> Yes
[16:35] <xteejx> Cool thanks Scott :)
[16:47] <xteejx> If a pkg is patchless, when making a change in the source should be use one like quilt?
[16:48] <geser> no
[16:48] <xteejx> So just straight edit and debdiff?
[16:48] <geser> yes
[16:48] <xteejx> geser: Ok, thank you :)
[16:55] <xteejx> Hmm...something very strange in the build for fossology
[16:55] <xteejx> I make the -lrpmio fix, but it's running a python script and doing nothing
[16:56] <xteejx> http://paste.ubuntu.com/518783/
[16:56] <xteejx> It's been like that for nearly 20 mins
[17:00] <xteejx> 0.986837732674 has just come up...wth?? Is it trying to run whatever it is during build??
[17:00] <xteejx> i.e. the package
[17:01] <xteejx> Sod it, I'll try another package
[17:32] <ScottK> xteejx: Is that a test suite running (running those during build is a good thing)
[18:04] <Danri> Hello, I don't know if this is the correct place to ask but, do you know if it is correct to make a deb file if I do the following? First->./configure Second-> make -j 2 and Third->make deb. Thank you.
[18:05] <crimsun> generally you should not pass concurrency flags to make
[18:05] <crimsun> also, you should not assume there is a 'deb' Makefile target
[18:06] <crimsun> so, for the general case, the latter two steps would be largely incorrect
[18:06] <Danri> crimsun: I've seen different ways of compiling a source code into deb, and I think this way would be the easiest one.
[18:07] <Danri> crimsun: ¿How can I change the concurrancy_level?
[18:07] <crimsun> Danri: "easiest" for whom?
[18:08] <Danri> crimsun: The easisest way for me to make a .deb file.
[18:09] <crimsun> Danri: I don't have enough context to make a recommendation
[18:09] <crimsun> are you referring to a specific source tarball, or are you attempting to create a generalized framework for yourself?
[18:10] <Danri> crimsun: Exactly, that is what I would like to have.
[18:13] <crimsun> Danri: sorry, but to which choice does "Exactly" refer?
[18:14] <Danri> crimsun: I am attempting to create a generalized framework.
[18:14] <crimsun> Danri: I wonder if this question isn't better addressed to the UDD developers
[18:15] <Danri> crimsun: ¿Could you please tell me which channel would be the best to ask my question? Thank You.
[18:18] <crimsun> Danri: I don't know offhand if there is a better one.  The process you're describing is similar to packaging recipes
[18:19] <crimsun> (which I suppose is closer to #launchpad than any UDD channel per se)
[18:21] <Danri> crimsun: Thank you crimsum, I'll try at #launchpad.
[19:24] <ari-tczew> coolbhavi: bug 584385, are you on it?
[19:25] <coolbhavi> no ari-tczew doing some other work feel free to take it
[19:29] <kklimonda_> has enyone managed to set pbuilder to use eatmydata?
[19:31] <ari-tczew> debfx: ping
[21:54] <c_korn> the build of tellico 2.3 fails. does someone have an idea where the problem could be? http://pastebin.com/6Tu1vmW1
[22:04] <xteejx> Hi all, if a ftbfs package only needs 1 change in debian/rules to fix it, does that need upstreamed? And also, we just use that change without patches etc right?
[22:06] <c_korn> xteejx: you don't patch files inside debian/ correct. of course you send the debdiff at the end. what fix is it?
[22:07] <xteejx> It's a simple add: added LDFLAGS=-lX11 to debian/rules to make "dh_auto_configure --  --with-buildtype=release LDFLAGS=-lX11"
[22:08] <xteejx> in override_dh_auto_configure:
[22:08] <kklimonda_> xteejx: if you have to add an explicit library reference then you should upstream it (and actually find the right way to do it and not set it in d/rules)
[22:08] <kklimonda_> xteejx: other distributions are going to switch to the new linker behaviour at some point and they will face the same problems.
[22:09] <xteejx> That's the problem, I can't find it :S
[22:09] <kklimonda_> xteejx: at least report a bug that the program should link to X11 expicitly so they can fix it.
[22:10] <xteejx> I would rather fix it in the source if poss so it's easier to provide a decent debdiff, but I really can't see where it needs to be fixed
[22:10] <kklimonda_> what build system does it use?
[22:11] <xteejx> standard configure, make make install I think
[22:11] <xteejx> not cdbs or anything
[22:11] <xteejx> It's vmware-view-open-client in multiverse
[22:13] <kklimonda_> xteejx: you should add it to the right Makefile.am
[22:13] <kklimonda_> or maybe it's Makefile.inc in this case
[22:14] <kklimonda_> can you paste a buildlog somewhere or give me a link to one?
[22:14] <xteejx> Sure
[22:14] <xteejx> http://launchpadlibrarian.net/58067942/buildlog_ubuntu-natty-i386.vmware-view-open-client_4.5.0-271013%2Bdfsg-1_FAILEDTOBUILD.txt.gz
[22:14] <xteejx> I don't see anything obviously configurable in Makefile.am :(
[22:18] <kklimonda_> xteejx: I'd try adding a vmware_view_LDADD += -lX11 in vmware-view-open-client-4.5.0-264434+dfsg/Makefile.inc after line 201 (after if VIEW_GTK and before endif).
[22:19] <kklimonda_> but I can't test it right now so that's just an educated guess
[22:20] <xteejx> How do you see these things!? :)
[22:20] <xteejx> PS thank you!
[22:22] <kklimonda_> xteejx: btw, by changing Makefile.inc you actually make it harder for yourself in the short term. You have to make package build-depend on dh-autoreconf and call dh with --with autoreconf argument
[22:22] <xteejx> it already build-deps on debhelper, is that not enough?
[22:23] <kklimonda_> no, you have to regenerate the project files after you make changes in Makefile.am (or, as in this case, in Makefile.inc, which is included by Makefile.am)
[22:24] <xteejx> Ahh I see
[22:24] <xteejx> So it's a control and rules change?
[22:24] <kklimonda_> yes
[22:24] <xteejx> I think I've got it
[22:24] <xteejx> Thank you :D
[22:25] <kklimonda_> see for example my debdiff to bug 658069
[22:25] <xteejx> Will do
[22:27] <xteejx> The debdiffs do make sense to me (makes a change) heeh
[22:27] <xteejx> So making it %:	dh --with autoreconf --with quilt ${@}    (adding the --with autoreconf) should be ok?
[22:28] <kklimonda_> it should be dh --with quilt,autoreconf
[22:28] <kklimonda_> at least that's what man says :)
[22:28] <xteejx> :)
[22:30] <xteejx> Hmm, I get this error http://paste.ubuntu.com/518921/
[22:30] <kklimonda_> have you added dh-autoreconf to build-deps?
[22:31] <xteejx> Yup
[22:31] <kklimonda_> hmm
[22:31] <xteejx> I'm doing debuild -S so I can build it with pbuilder
[22:31] <kklimonda_> try adding include /usr/share/cdbs/1/rules/autoreconf.mk to the top of d/rules
[22:32] <xteejx> before #!/usr/bin/make -f ?
[22:32] <kklimonda_> no, wait - it doesn't make sense
[22:32] <xteejx> It doesn't use cdbs
[22:33] <kklimonda_> yeah
[22:33] <kklimonda_> it works fine here
[22:33] <xteejx> http://paste.ubuntu.com/518923/ that's the rules file
[22:33] <kklimonda_> do you have dh-autoreconf installed? debuild should complain if you don't but that's the only reason I can think of
[22:33] <xteejx> Ohhh, I have to have it installed locally?
[22:34] <kklimonda_> yes
[22:34] <xteejx> oops :P
[22:34] <xteejx> Yep, that's worked ;)
[22:35] <kklimonda_> when you create a source package the clean target is invoked so you need all packages that are required for it to complete
[22:35] <xteejx> Ohhhh, I didn't know about that
[22:36] <xteejx> Time to test the build, can quilt it afterwards :)
[23:21] <ivoks> persia: ivoks is server folks :p
[23:21] <ivoks> :)
[23:26] <ivoks> Madkiss: well, actually, cluster stack in ubuntu has some features upstream is still merging ;)