#ceph IRC Log

Index

IRC Log for 2011-03-23

Timestamps are in GMT/BST.

[0:00] <cmccabe> later we may consider allowing bucket names not suitable for virtual host style use, if anyone wants that as a feature.
[0:01] * verwilst_ (~verwilst@dD576FAAE.access.telenet.be) has joined #ceph
[0:27] * Yoric (~David@dau94-10-88-189-211-192.fbx.proxad.net) Quit (Quit: Yoric)
[0:34] <cmccabe> I just created a bucket named _really_crazy on our amazon account, and I can't seem to delete it :(
[0:34] <Tv> "Must start with a number or letter"
[0:34] <Tv> that you were able to create that was a bug on their part
[0:35] <cmccabe> sigh
[0:36] <cmccabe> it's so confusing because there are some actual requirements, but then there some recommendations
[0:36] <cmccabe> if you violate the recommendations, certain access methods will continue to work and some won't
[0:37] <cmccabe> /usr/bin/s3 just rejects certain bucket names without even talking to the s3 sever
[0:44] <cmccabe> ok, I was able to delete _really_crazy through libboto
[0:44] <cmccabe> just none of the other clients could do it :\
[1:01] * iggy_ is now known as iggy
[1:09] * Yuki (~Yuki@221.234.37.224) has joined #ceph
[1:09] * verwilst_ (~verwilst@dD576FAAE.access.telenet.be) Quit (Quit: Ex-Chat)
[1:15] * Tv (~Tv|work@ip-66-33-206-8.dreamhost.com) Quit (Ping timeout: 480 seconds)
[1:20] <josef> what is librados-config used for?
[1:22] <cmccabe> josef: librados-config is intended to give information about the configuration of the currently installed librados
[1:23] <josef> cmccabe: soo in the -devel package or the normal package?
[1:23] <cmccabe> josef: similar to /usr/bin/python2.6-config, /usr/bin/xft-config, /usr/bin/curl-config
[1:23] <cmccabe> josef: normal package
[1:23] <josef> ah ok yeah
[1:23] <cmccabe> josef: it should eventually hook into pkg-config
[1:23] <josef> now to figure out what to do with the python bindings
[1:24] <cmccabe> josef: that has been solved in master
[1:24] <cmccabe> josef: they're installed in the python modules directory
[1:25] * greglap (~Adium@166.205.137.252) has joined #ceph
[1:25] <josef> ooh i see the master .spec file is more correct
[1:26] * josef copies that
[1:26] <cmccabe> probably cherry-pick?
[1:29] <josef> yeah
[1:29] <josef> ok that should actually build
[1:30] <josef> thanks cmccabe
[1:32] <cmccabe> np
[1:45] * greglap1 (~Adium@166.205.136.138) has joined #ceph
[1:51] * greglap (~Adium@166.205.137.252) Quit (Ping timeout: 480 seconds)
[1:55] * greglap1 (~Adium@166.205.136.138) Quit (Quit: Leaving.)
[2:06] * joshd (~joshd@ip-66-33-206-8.dreamhost.com) Quit (Quit: Leaving.)
[2:20] * cmccabe (~cmccabe@208.80.64.121) has left #ceph
[2:38] * eternaleye_ (~eternaley@195.215.30.181) has joined #ceph
[2:38] * eternaleye (~eternaley@195.215.30.181) Quit (Remote host closed the connection)
[2:57] * greglap (~Adium@cpe-76-170-84-245.socal.res.rr.com) has joined #ceph
[4:26] * lxo (~aoliva@201.82.54.5) Quit (Read error: Connection reset by peer)
[4:26] * lxo (~aoliva@201.82.54.5) has joined #ceph
[4:56] * chip (~chip@brma.tinsaucer.com) has left #ceph
[6:39] * Yuki (~Yuki@221.234.37.224) Quit (Ping timeout: 480 seconds)
[7:08] * DanielFriesen (~dantman@S0106001eec4a8147.vs.shawcable.net) has joined #ceph
[7:14] * Dantman (~dantman@S0106001eec4a8147.vs.shawcable.net) Quit (Ping timeout: 480 seconds)
[7:48] * Jiaju (~jjzhang@222.126.194.154) has joined #ceph
[8:15] * allsystemsarego (~allsystem@188.25.132.91) has joined #ceph
[8:24] * Yoric (~David@dau94-10-88-189-211-192.fbx.proxad.net) has joined #ceph
[8:42] * neurodrone (~neurodron@cpe-76-180-162-12.buffalo.res.rr.com) Quit (Quit: neurodrone)
[9:00] * Yoric (~David@dau94-10-88-189-211-192.fbx.proxad.net) Quit (Quit: Yoric)
[9:04] * toluene (~toluene@60-250-129-58.HINET-IP.hinet.net) has joined #ceph
[9:07] <toluene> hi ! I'm a beginner in ceph, I wrote a test script to write millions of files with threads. Eventually, the ceph-module gone panic. Additionally, I noticed that the memory usage of my meta server was very high(more than 2G). Could someone give me some idea about this "disaster" ?
[9:10] * mib_5ip38z (3cfa813a@ircip1.mibbit.com) has joined #ceph
[9:26] * lidongyang (~lidongyan@222.126.194.154) has joined #ceph
[9:34] * lidongyang (~lidongyan@222.126.194.154) Quit (Read error: Connection reset by peer)
[9:37] * lidongyang (~lidongyan@222.126.194.154) has joined #ceph
[9:56] * Yoric (~David@213.144.210.93) has joined #ceph
[10:03] * lidongyang_ (~lidongyan@222.126.194.154) has joined #ceph
[10:06] * lidongyang (~lidongyan@222.126.194.154) Quit (Ping timeout: 480 seconds)
[10:06] * Jiaju (~jjzhang@222.126.194.154) Quit (Ping timeout: 480 seconds)
[10:07] * lidongyang_ (~lidongyan@222.126.194.154) Quit (Read error: Connection reset by peer)
[10:08] * lidongyang_ (~lidongyan@222.126.194.154) has joined #ceph
[10:09] * Jiaju (~jjzhang@222.126.194.154) has joined #ceph
[10:36] * Hugh (~hughmacdo@soho-94-143-249-50.sohonet.co.uk) has joined #ceph
[10:45] * lidongyang_ (~lidongyan@222.126.194.154) Quit (Read error: Operation timed out)
[10:46] * Jiaju (~jjzhang@222.126.194.154) Quit (Read error: Operation timed out)
[11:26] * Hugh (~hughmacdo@soho-94-143-249-50.sohonet.co.uk) Quit (Ping timeout: 480 seconds)
[11:33] * andret (~andre@pcandre.nine.ch) Quit (Remote host closed the connection)
[11:34] * andret (~andre@pcandre.nine.ch) has joined #ceph
[11:37] * Hugh (~hughmacdo@soho-94-143-249-50.sohonet.co.uk) has joined #ceph
[11:37] * lidongyang_ (~lidongyan@222.126.194.154) has joined #ceph
[11:38] * Jiaju (~jjzhang@222.126.194.154) has joined #ceph
[11:39] * Yuki (~Yuki@58.51.197.107) has joined #ceph
[11:44] * mib_5ip38z (3cfa813a@ircip1.mibbit.com) Quit (Quit: http://www.mibbit.com ajax IRC Client)
[11:49] * Hugh (~hughmacdo@soho-94-143-249-50.sohonet.co.uk) Quit (Ping timeout: 480 seconds)
[11:57] * Hugh (~hughmacdo@soho-94-143-249-50.sohonet.co.uk) has joined #ceph
[12:11] * Yuki (~Yuki@58.51.197.107) Quit (Quit: Leaving)
[13:18] * toluene (~toluene@60-250-129-58.HINET-IP.hinet.net) Quit (Quit: This computer has gone to sleep)
[13:18] * johnl_ (~johnl@johnl.ipq.co) Quit (Remote host closed the connection)
[13:23] * johnl (~johnl@109.107.34.14) has joined #ceph
[13:23] * Yoric (~David@213.144.210.93) Quit (Read error: Connection reset by peer)
[13:24] * Yoric (~David@213.144.210.93) has joined #ceph
[13:25] * samsung (~samsung@61.184.205.46) has joined #ceph
[14:06] * lightspeed (~lightspee@fw-carp-wan.ext.lspeed.org) Quit (Ping timeout: 480 seconds)
[14:13] * lightspeed (~lightspee@fw-carp-wan.ext.lspeed.org) has joined #ceph
[15:25] * neurodrone (~neurodron@cpe-76-180-162-12.buffalo.res.rr.com) has joined #ceph
[15:36] * ghaskins (~ghaskins@66-189-113-47.dhcp.oxfr.ma.charter.com) has joined #ceph
[16:36] * bchrisman (~Adium@c-98-207-207-62.hsd1.ca.comcast.net) Quit (Quit: Leaving.)
[16:38] * greglap (~Adium@cpe-76-170-84-245.socal.res.rr.com) Quit (Quit: Leaving.)
[16:50] * greglap (~Adium@166.205.139.252) has joined #ceph
[17:04] * Tv (~Tv|work@ip-66-33-206-8.dreamhost.com) has joined #ceph
[17:21] * cmccabe (~cmccabe@c-24-23-254-199.hsd1.ca.comcast.net) has joined #ceph
[17:26] * greglap1 (~Adium@166.205.137.196) has joined #ceph
[17:30] * greglap (~Adium@166.205.139.252) Quit (Ping timeout: 480 seconds)
[17:42] * greglap1 (~Adium@166.205.137.196) Quit (Quit: Leaving.)
[17:44] <sagewk> +1 on 6788c3c0e3b0f515fc9bcfdc85b53ea2b8f70d1e
[17:47] <cmccabe> it did seem easier to say
[17:49] <Tv> *cough* *cough*
[18:00] * bchrisman (~Adium@70-35-37-146.static.wiline.com) has joined #ceph
[18:09] * joshd (~joshd@ip-66-33-206-8.dreamhost.com) has joined #ceph
[18:09] * Yoric (~David@213.144.210.93) Quit (Quit: Yoric)
[18:10] <cmccabe> libradosgw.a(libradosgw_a-rgw_common.o): In function `calc_hmac_sha1(char const*, int, char const*, int, char*, int*)':
[18:10] <cmccabe> /home/cmccabe/src/ceph/src/rgw/rgw_common.cc:37: undefined reference to `CryptoPP::HMAC<CryptoPP::SHA1>::DIGESTSIZE'
[18:10] <cmccabe> collect2: ld returned 1 exit status
[18:11] <cmccabe> I forgot, are we still using cryptopp any more?
[18:11] <cmccabe> If not, I think we need to stop referencing it in RGW
[18:11] <Tv> depends on your ./configure invocaton
[18:14] <Tv> that sounds like libradosgw_a_LDFLAGS is missing CRYPTO_LDFLAGS, probably bad since f509c86333b2eb5af69ee3e2eb1b94287e77683a
[18:14] <Tv> hmm cae43fc7d0322499704ea965fd91efe26014a48c
[18:15] <cmccabe> strange
[18:15] <Tv> i saw that error too
[18:16] <Tv> # lib_LTLIBRARIES += libradosgw.a
[18:16] <Tv> wouldn't that be the reason automake doesn't know about it?
[18:16] <cmccabe> it looks like a 2-for-1 deal: the code directly references cryptopp and breaks when other crypto libraries are used, and LDFLAGS is screwed
[18:17] <Tv> from 6a78671c
[18:17] <Tv> cmccabe: you're mistaken about directly referencing, i believe
[18:17] <Tv> it just doesn't get linked against CryptoPP when that's needed
[18:18] <cmccabe> oh, I see we have two classes doing HMACSHA1
[18:18] <cmccabe> thought it was a library thing
[18:18] <Tv> hmm even before 6a78671c the lib_LTLIBRARIES += libradosgw.a was commented out
[18:19] <Tv> d0f58ad8b283cbbefcb41e89746bbc23bc281fb0 is the one commenting it out
[18:19] <Tv> with no reason stated
[18:19] <Tv> undoing those comment-outs sounds like worth a try
[18:20] <cmccabe> I'm not feeling overwhelmed by the quality of this code
[18:20] <cmccabe> we really need to stop putting so much in header files
[18:20] <cmccabe> also the phrase "contaminate with error checking... asserts MUST NOT be compiled out" really raises my hackles
[18:21] <Tv> cmccabe: NSS is a mess
[18:21] <cmccabe> stuff like this is why the designers of Go just decided not to implement assert()
[18:21] <Tv> what those really deserve is an equivalent of kernel BUG_ON, not assert
[18:22] <cmccabe> it starts out as a noble idea but once enough people take shortcuts, it's impossible to turn off asserts
[18:22] <Tv> alternative: redo just about *all* of ceph crypto, and complicate every code path
[18:22] <Tv> just in case somebody runs AES on a smart card
[18:22] <cmccabe> is that really the only case that can fail?
[18:22] <Tv> show me how e.g. SHA-1 can fail on some inputs...
[18:23] <cmccabe> failure to initialize the library properly?
[18:24] <Tv> the initialization happens elsewhere, and is error checked
[18:26] <cmccabe> a lot of this stuff seems like it's allocating memory too
[18:26] <cmccabe> I guess we're not checking that elsewhere though.
[18:26] <cmccabe> truthfully most daemons don't.
[18:27] <Tv> the api looks like it relies on caller-allocated memory for the transformations
[18:27] <Tv> apart from the importing key things etc
[18:27] <Tv> and to fix that is a rewrite of ceph crypto
[18:28] <cmccabe> I think a lot of this nastiness could be avoided if you put initialization into an init() function rather than having it in the constructor
[18:28] <cmccabe> then have the init function return an error code as usual
[18:28] <Tv> doesn't change a thing when the caller is not able to handle a failure anyway
[18:28] <Tv> because cryptopp has no failures in the equivalent api
[18:29] <cmccabe> it's not that hard to check an int, print a nice message if it's not 0, and call ceph_abort
[18:29] <Tv> which is different from the asserts here exactly how?
[18:29] <cmccabe> to me, code is "contaminated" when it doesn't support handling errors the way I want to handle them
[18:29] <cmccabe> when it's hard-wired to abort, exit, or assert rather than tell me what's wrong.
[18:29] <Tv> yes
[18:30] <Tv> and if you think that e.g. a sha1 update call is supposed to be able to fail, then ceph crypto is all wrong
[18:30] <Tv> personally, i don't think sha1 update has any reason to fail
[18:30] <Tv> and i'm not willing to rewrite all of ceph crypto right now merely for NSS
[18:31] <cmccabe> yeah, their choice of where to return errors is a little strange.
[19:07] <josef> sagewk: ok ceph 0.25.1 should show up in rawhide at some point
[19:08] <josef> tomorrow probably
[19:09] <sagewk> josef: yay thanks!
[19:09] <cmccabe> I just created a bucket named "10.10.10.10" on s3.amazonaws.com
[19:09] <cmccabe> so apparently the spec... isn't.
[19:10] <josef> sagewk: if you could setup an rss feed for your news stuff on ceph.newdream.net it would help me keep track of when you have new releases
[19:11] <gregaf> josef: separate from the blog rss feed?
[19:11] <cmccabe> now /usr/bin/s3 is refusing to allow me to delete bucket 10.10.10.10 because the name is scary :)
[19:12] <cmccabe> luckily I wrote my own rebellious client that can deal with these forbidden buckets
[19:12] <josef> gregaf: i couldnt find a rss feed for the block
[19:12] <josef> *blog
[19:12] <Tv> cmccabe: it's still better to follow the spec than the implementation, at least until that hits real-world problems.. because they may change the implementation at any time
[19:12] <josef> heh well apparently i was blind yesterday
[19:12] <gregaf> it's at the bottom of the front page :)
[19:13] <josef> yeah i got it this time, thanks :)
[19:13] <gregaf> although I think any modern browser will just give you the rss icon in the address bar :p
[19:13] <josef> chrome doesnt
[19:13] * Yoric (~David@dau94-10-88-189-211-192.fbx.proxad.net) has joined #ceph
[19:13] <gregaf> oh, I forgot that's a Google extension I installed for that
[19:14] <sagewk> cmccabe: that's /usr/bin/s3's problem. presumably it won't create that bucket either.
[19:14] <cmccabe> yes, it won't create that
[19:14] <gregaf> then why do we care about it?
[19:14] <cmccabe> but really it's amazon's problem because the spec forbids, but the impementation allows
[19:14] <sagewk> the linux nfs mantra gets it right i think: fix client bugs in client, server bugs on server.
[19:15] <cmccabe> gregaf: we care because we're trying to be s3-compatible, and the spec and implementation disagree about the meaning of that.
[19:15] <cmccabe> I'm going to just follow the spec for now. We can change our behavior later if customers care
[19:15] <sagewk> yeah that's the way to go i think
[19:22] * Yoric (~David@dau94-10-88-189-211-192.fbx.proxad.net) Quit (Quit: Yoric)
[19:29] <gregaf> bchrisman: around?
[19:30] <bchrisman> here
[19:30] <bchrisman> how goes?
[19:30] <Tv> sagewk: is the for-next ceph-client.git branch a good stable basepoint for development, or should i just use 2.6.38?
[19:30] <bchrisman> gregaf:
[19:30] <gregaf> I was wondering if you have any logs I can get at for that cfuse crash
[19:30] <sagewk> tv: use master
[19:30] <sagewk> the for-next branch is stale
[19:31] <gregaf> the assert on its own isn't very helpful except to say "AUGH BROKEN"
[19:31] <Tv> ok
[19:31] <bchrisman> yeah, that was just the log out of client.
[19:32] <gregaf> did you have any client logging enabled?
[19:32] <bchrisman> was a lot of spam because it takes a while to crash… but if there's non-client logs you need, I can modify debug logging.
[19:32] <bchrisman> hmm… thought I posted that.. lemme look at what I might've goofed up.
[19:32] <gregaf> probably just the client log will do it
[19:32] <gregaf> but all I'm seeing is the backtrace :)
[19:38] <bchrisman> hrm.. that was pulled from the logfile output I received from running cfuse with debug params: 'cfuse --log-file foo --debug-client 20 --debug-ms 1 --debug-objectcacher 20'
[19:38] <bchrisman> I can run again and get you more context...
[19:38] <bchrisman> but the logfile was large and dropped for further testing… so it'll be a little bit.
[19:38] <bchrisman> does logging provide stack trace when it dies?
[19:41] <gregaf> bchrisman: if you could add —debug_objecter 20 that might also be important (not sure yet)
[19:42] <gregaf> the log should include the stack trace when it dies, yes
[19:42] <bchrisman> gregaf: ok.. cool
[19:42] <bchrisman> I'll attach to the bug when it's done
[19:42] <gregaf> all right, thanks
[20:46] * Hugh (~hughmacdo@soho-94-143-249-50.sohonet.co.uk) Quit (Quit: Ex-Chat)
[21:25] <cmccabe> so I'm trying to get some work done here, but I'm getting blocked by this build issue
[21:25] <cmccabe> with crypto libraries
[21:25] <cmccabe> is anyone else seeing these build errors?
[21:25] <cmccabe> they're not showing up on gitbuilder for some reason
[21:25] <Tv> gitbuilder only does one variant - the cryptopp one
[21:32] <Tv> ..but the compile fail happens with cryptopp...?
[21:32] <cmccabe> it looks like it happens with either
[21:32] <cmccabe> and it looks like I'm going to have to fix this mess
[21:32] <cmccabe> or revert a bunch of recent commits, which I don't think anyone wants
[21:34] <Tv> i'm running a build to see what happens..
[21:34] <Tv> cmccabe: wait what
[21:34] <Tv> i just successfully with --with-nss --without-cryptopp
[21:35] <Tv> cmccabe: make really sure you get the same stuff with a clean build, ./autogen.sh and all
[21:35] <Tv> *successfully built
[21:35] <cmccabe> I just got this error, even with --with-cryptopp
[21:35] <cmccabe> libradosgw.a(libradosgw_a-rgw_common.o): In function `calc_hmac_sha1(char const*, int, char const*, int, char*, int*)':
[21:35] <cmccabe> /home/cmccabe/src/ceph2/src/rgw/rgw_common.cc:37: undefined reference to `CryptoPP::HMAC<CryptoPP::SHA1>::DIGESTSIZE'
[21:35] <cmccabe> collect2: ld returned 1 exit status
[21:35] <Tv> and a cryptopp build also worked
[21:36] <Tv> i'm saving work & doing a really clean build, just to make sure, but i don't see and gitbuilder doesn't see it -> local problem just for you?
[21:36] <cmccabe> yes, I am doing make distclean
[21:38] <Tv> duhh i'm missing --with-radosgw, rerunning
[21:38] <cmccabe> is gitbuilder also missing --with-radosgw?
[21:38] <Tv> nope
[21:39] <cmccabe> remind me again if cryptopp and crypto++ are the same library
[21:39] <cmccabe> they are ,right?
[21:39] <Tv> yeah
[21:39] <Tv> + is too magic to put in many places
[21:39] <Tv> like, identifiers ;)
[21:39] <cmccabe> boneheaded name in my opinion
[21:40] <Tv> beats NSS
[21:41] <Tv> 12d3038d81a593949b8b21505dea23c1df38e1c3 clean tree (git clean -fdx = really clean), ./autogen.sh && ./configure --with-radosgw --with-cryptopp --without-nss --with-debug && make-fast && make-fast check
[21:41] <Tv> worked perfectly
[21:41] <Tv> and i even cleared ccache before it
[21:43] <cmccabe> it looks like LDFLAGS is still commented out in master
[21:44] <Tv> yes but that doesn't cause a build failure
[21:44] <cmccabe> .... for you
[21:44] <Tv> for anyone but you ;)
[21:44] <Tv> now what's the difference?
[21:44] <cmccabe> sorry if I'm a little bit snippy, it's just that this is frustrating
[21:44] <Tv> do you have local changes?
[21:44] <cmccabe> no
[21:44] <Tv> did you really clean everything? did you autogen?
[21:44] <cmccabe> yes
[21:45] <Tv> git rev-parse HEAD
[21:45] <cmccabe> I'm not an idiot. I know how to do make distclean and I do it a lot
[21:45] <cmccabe> in these situations
[21:45] <gregaf> do you have different packages than we do?
[21:45] <cmccabe> I'm going to just hope that it's ldflags. We'll know in a minute or two.
[21:45] <Tv> cmccabe: but putting those back makes it give warnings for everyone else
[21:45] <Tv> no rash commits please
[21:46] <cmccabe> frankly I don't understand how it's working for anyone
[21:46] <gregaf> what happened with the ldflags?
[21:46] <cmccabe> the ldflags needs to include the libraries that the library is using right?
[21:46] <Tv> Tv: hmm even before 6a78671c the lib_LTLIBRARIES += libradosgw.a was commented out
[21:46] <Tv> Tv: d0f58ad8b283cbbefcb41e89746bbc23bc281fb0 is the one commenting it out
[21:46] <Tv> Tv: with no reason stated
[21:46] <Tv> Tv: undoing those comment-outs sounds like worth a try
[21:46] <cmccabe> AM_LDFLAGS doesn't have anything crypto-related in it
[21:46] <cmccabe> I have no idea how the build is working for you
[21:47] <cmccabe> building radosgw, which uses crypto, with those ldflags.
[21:47] <Tv> err i think i mispasted the commits
[21:47] <cmccabe> maybe it got dragged in by libcommon
[21:47] <Tv> there's one from sage that commits them out and quotes the automake warning that is thus avoded
[21:48] <cmccabe> looks like libcommon_a_CFLAGS has CRYPTO_CFLAGS in it. And libcommon now has crypto stuff...
[21:48] <Tv> cae43fc7
[21:48] <Tv> src/Makefile.am:299: variable `libradosgw_a_LDFLAGS' is defined but no program or
[21:48] <Tv> src/Makefile.am:299: library has `libradosgw_a' as canonic name (possible typo)
[21:48] <cmccabe> how is THAT working, without crypto in the libcommon LDFLAGS
[21:49] <gregaf> Tv: so that's just an issue with the libradosgw flags
[21:49] <gregaf> won't impact anything else
[21:49] <cmccabe> I still can't build, even after putting back in the radosgw LDFLAGS
[21:50] <gregaf> probably they should be defined based on whether we're building libradosgw (didn't know we even had a library for that...)
[21:50] <Tv> gregaf: according to automake, we don't have libradoswg.a
[21:50] <Tv> that's why it was commented out
[21:50] <gregaf> well that would explain why we shouldn't be defining bits for it, then
[21:50] <cmccabe> ok... think. Must not get enraged by automake waving this red flag in front of me.
[21:50] <gregaf> heh
[21:50] <cmccabe> I guess using ldd on things is a start
[21:51] <Tv> cmccabe: are you building on flab?
[21:51] <cmccabe> metropolis
[21:51] <Tv> cmccabe: what's different about that box vs what everyone else has
[21:51] <gregaf> wait, so Colin's build failure is for a libradosgw that according to the makefile shouldn't exist?
[21:51] <Tv> gregaf: no
[21:52] <cmccabe> gregaf: uh, do a grep, and you'll find that it does exist
[21:52] <Tv> gregaf: the reason that LDFLAGS line is commented out is to shut up automake; and it's not gonna help because it's apparently the target is not used by automake
[21:52] <cmccabe> what is with lib_LTLIBRARIES
[21:53] <Tv> # lib_LTLIBRARIES += libradosgw.a
[21:53] <Tv> that'd probably be why
[21:53] <Tv> from 6a78671c
[21:53] <gregaf> okay, libradosgw only exists because we have both a radosgw and a radosgw_admin binary
[21:53] <gregaf> but it shouldn't be used for anything else
[21:54] <Tv> which didn't actually introduce the commented-out line, just edited it
[21:54] <Tv> d0f58ad8b2 is what commented it out
[21:54] <Tv> with no real explanation
[21:54] <cmccabe> it looks like lib_LTLIBRARIES is a list of libraries that gets installed by make install?
[21:55] <Tv> but yes, libradosgw is not a library that we'd provide for 3rd parties to use
[21:55] <Tv> it's only internal for the benefit of those two binaries
[21:55] <cmccabe> "Automake uses libtool to build libraries declared with the LTLIBRARIES primary."
[21:55] <Tv> hence, the LDFLAGS belong to those binaries
[21:56] <Tv> /bin/bash ../libtool --tag=CXX --mode=link ccache distcc g++-4.4 -Wall -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_THREAD_SAFE -rdynamic -Wnon-virtual-dtor -g -O2 -Wl,--as-needed -latomic_ops -o radosgw_admin radosgw_admin-rgw_admin.o libradosgw.a librados.a libcrush.a -lfcgi -lexpat -lpthread -lm -lcrypto++
[21:56] <Tv> definitely getting crypto++ linked in
[21:57] <cmccabe> tv: do you have a line like this one?
[21:57] <cmccabe> libtool: link: g++ -Wall -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_THREAD_SAFE -rdynamic -Wnon-virtual-dtor - g -Wall -Wvolatile-register-var -Wno-unused-parameter -Wl,--as-needed -o radosgw radosgw-rgw_main.o -latomic_ops libradosgw.a librados.a libcrush.a /usr/lib/libfcgi.so /usr/lib/libexpat.so -lpthread -lm /usr/lib/libcurl.so - lcrypto++
[21:58] <Tv> radosgw_admin_LDADD = libradosgw.a librados.a libcrush.a -lfcgi -lexpat -lpthread -lm $(CRYPTO_LIBS) $(EXTRALIBS)
[21:58] <Tv> but no LDFLAGS
[21:59] <cmccabe> ok, I have a failing command
[21:59] <cmccabe> cmccabe@metropolis:~/src/ceph2/src$ g++ -Wall -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_THREAD_SAFE -rdynamic -Wnon-virtual-dtor -g -Wall -Wvolatile-register-var -Wno-unused-parameter -Wl,--as-needed -o radosgw radosgw-rgw_main.o -latomic_ops libradosgw.a librados.a libcrush.a /usr/lib/libfcgi.so /usr/lib/libexpat.so -lpthread -lm /usr/lib/libcurl.so -lcrypto++
[21:59] <cmccabe> libradosgw.a(libradosgw_a-rgw_common.o): In function `calc_hmac_sha1(char const*, int, char const*, int, char*, int*)':
[21:59] <cmccabe> /home/cmccabe/src/ceph2/src/rgw/rgw_common.cc:37: undefined reference to `CryptoPP::HMAC<CryptoPP::SHA1>::DIGESTSIZE'
[21:59] <cmccabe> collect2: ld returned 1 exit status
[21:59] <Tv> if i rm src/radosgw and make, i get the line i pasted above
[22:00] <Tv> well, then libtool outputs what you're pasting
[22:00] <Tv> libtool: link: ccache distcc g++-4.4 -Wall -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_THREAD_SAFE -rdynamic -Wnon-virtual-dtor -g -O2 -Wl,--as-needed -o radosgw radosgw-rgw_main.o -latomic_ops libradosgw.a librados.a libcrush.a /usr/lib/libfcgi.so /usr/lib/libexpat.so -lpthread -lm /usr/lib/libcurl.so -lcrypto++
[22:00] <Tv> works perfectly
[22:00] <Tv> what version of cryptopp do you have, etc?
[22:00] <Tv> you don't have -O2
[22:00] <cmccabe> /usr/lib/libcrypto++.so.8.0.0
[22:01] <cmccabe> you?
[22:01] <Tv> same soname
[22:01] <Tv> try with -O2
[22:01] <cmccabe> I wouldn't expect any differences; we're using the same distro
[22:01] <cmccabe> -O2 doesn't change the result
[22:01] <cmccabe> as expected
[22:01] <Tv> and your line works for me
[22:02] <Tv> here's a question
[22:02] <gregaf> are you using ccache?
[22:02] <gregaf> maybe it got confused
[22:02] <Tv> why do your command line args look different?
[22:02] <gregaf> he turned on the debugging extras presumably
[22:02] <Tv> you have -Wall -Wvolatile-register-var -Wno-unused-parameter where i have -O2
[22:03] <cmccabe> I used do_autogen,sh -d 2
[22:03] <cmccabe> to get some extra warnings
[22:03] <gregaf> cmccabe: are you using ccache, and did you clear its caches?
[22:03] <cmccabe> I did an nm on libradosgw_a-rgw_common.o, and got
[22:03] <cmccabe> U CryptoPP::HMAC<CryptoPP::SHA1>::DIGESTSIZE
[22:03] <cmccabe> I'm not using ccache
[22:03] <Tv> uhh my autogen.sh doesn't seem to use any arguments
[22:04] <cmccabe> tv: talking about do_autogen.sh, not autogen.sh
[22:04] <Tv> oh right duh
[22:04] <Tv> cmccabe: try doing that, then
[22:04] <gregaf> cmccabe: so you're not using makefast or whatever Tv's script is?
[22:04] <Tv> err
[22:04] <Tv> cmccabe: try *not* doing that, then
[22:04] <cmccabe> I didn't realize tv had a script
[22:05] <gregaf> okay, I just thought I was the only one not using it anymore
[22:05] <cmccabe> I was hoping to encourage people to use do_autogen so we'd all see the same compiler warnings
[22:06] <Tv> cmccabe: yes but for the sake of identifying the problem, eliminate differences
[22:06] <cmccabe> tv: what are your configure settings
[22:06] <Tv> i pasted them a while ago
[22:07] <cmccabe> what kind of target is make-fast?
[22:07] <Tv> read "Subject: Ceph internal tools repo; distcc to be SSH only"
[22:08] <Tv> but that shouldn't affect this issue
[22:08] <Tv> gitbuilder doesn't use make-fast
[22:08] <cmccabe> so it looks like it's just a distcc wrapper
[22:08] <gregaf> and ccache, which is the only reason I thought it might be relevant
[22:09] <Tv> well colin might still have ccache setup
[22:09] <cmccabe> gregaf: it might be, but gitbuilder isn't seeing the issue and it doesn't use ccache.
[22:09] <cmccabe> I do not, and never have, set up ccache. I just use a really high value for -j
[22:09] * Yoric (~David@dau94-10-88-189-211-192.fbx.proxad.net) has joined #ceph
[22:09] <gregaf> cmccabe: my expectation was that it would have been a confused or corrupted ccache, not a real problem ;)
[22:09] <gregaf> which would explain why you're seeing it and nobody else is
[22:10] <Tv> cmccabe: do a build with more plain configure flags
[22:10] <cmccabe> I am building it now with your configure flags.
[22:10] <Tv> the joy of c++
[22:10] <Tv> swordfight anyone?
[22:10] <cmccabe> I really doubt optimization flags will affect this, but I'm willing to try
[22:11] <gregaf> Tv: I'll need a rolly chair first
[22:11] <gregaf> mine has too big a back
[22:12] <cmccabe> the compile time isn't usually such a big deal because I usually have something else to think about
[22:12] <cmccabe> but in this case, I really have no idea what is going on here
[22:12] <cmccabe> we're clearly passing the -lcrypto++ on the command line.
[22:13] <cmccabe> ok, that did work.
[22:13] <Tv> *sigh*
[22:13] <cmccabe> one key difference I see is that you used --without-nss
[22:13] <Tv> habit from going in between those two a lot
[22:13] <Tv> grep USE_ src/acconfig.h
[22:14] <Tv> that's what matters
[22:14] <Tv> the logic prefers cryptopp over nss anyway
[22:15] <cmccabe> can we please standardize on one script to run autogen and configure?
[22:15] <cmccabe> I don't care whose it is, I just want to be able to reproduce the build that gitbuilder is doing with a single command
[22:15] <Tv> our users won't
[22:17] <cmccabe> I just feel frustrated that it isn't possible for me to reproduce the gitbuilder build without asking for the secret command line
[22:17] <cmccabe> it has nothing to do with users per se, although being able to tell them "try running script foo" would probably be an improvement
[22:17] <Tv> echo --START-IGNORE-WARNINGS
[22:17] <Tv> [ ! -x autogen.sh ] || ./autogen.sh || exit 1
[22:17] <Tv> autoconf || true
[22:17] <Tv> echo --STOP-IGNORE-WARNINGS
[22:17] <Tv> [ ! -x configure ] || ./configure --with-debug --with-radosgw --with-fuse --with-tcmalloc --with-libatomic-ops --with-gtk2 || exit 2
[22:17] <Tv> etc
[22:18] <cmccabe> is there a reason we can't just replace the call to autoconf and configure with a script?
[22:18] <cmccabe> specifically, do you have an argument for why not?
[22:18] <Tv> Tv: echo --START-IGNORE-WARNINGS ?
[22:19] <cmccabe> what about
[22:19] <Tv> that's gitbuilder internals
[22:19] <cmccabe> surely gitbuilder isn't hardwired to run autogen and configure
[22:20] <Tv> there's a gitbuilder-specific item between the autoconf and configure lines
[22:20] <Tv> so to have it be like that, we can't wrap all that in a single shell script nicely
[22:21] <cmccabe> so we just echo that silly phrase in do_autogen.sh
[22:39] * allsystemsarego (~allsystem@188.25.132.91) Quit (Quit: Leaving)
[22:58] <cmccabe> I can't understand this at all.
[22:58] <cmccabe> I have no problem running this:
[22:58] <cmccabe> make distclean && CFLAGS="-g -Wall -Wvolatile-register-var -Wno-unused-parameter" CXXFLAGS=$CFLAGS ./autogen.sh ; ./configure --prefix=/usr --sbindir=/sbin --localstatedir=/var --sysconfdir=/etc --with-gtk2=yes --with-debug --with-cryptopp ; make -j 8
[22:58] <cmccabe> but running do_autogen, which seems to do exactly the same thing, leads to that libtool error later
[23:05] <cmccabe> it seems impossible to get a repeatable build. I almost feel like giving up.
[23:19] * MK_FG (~MK_FG@188.226.51.71) Quit (Ping timeout: 480 seconds)
[23:22] <bchrisman> ahh the glories of mds in userspace… we had a locking problem.. turned on full mds debug… and after a few minutes of looking at log file "wait! What's the pid doing jumping in to lock that file!" problem solved… :)
[23:24] * Yoric (~David@dau94-10-88-189-211-192.fbx.proxad.net) Quit (Quit: Yoric)
[23:33] <cmccabe> finally fixed the build problem.
[23:41] <cmccabe> It turns out that static constants are not quite the same thing as preprocessor defines
[23:42] <cmccabe> there were some language extensions to C++ that let you sometimes use them interchangeably, but in general, you need a macro to declare things that must be known at build time
[23:43] <cmccabe> for some reason, in my build, it decided not to inline DIGESTSIZE from the library, and that caused problems.

These logs were automatically created by CephLogBot on irc.oftc.net using the Java IRC LogBot.