[06:05] <lordievader> Good morning
[07:32] <punkgeek> is there anyway to solve this problem? https://paste.ubuntu.com/p/XKBpjmcHMS/
[07:40] <lordievader> You might want to check the mysql/mariadb error log to see what the actual error is.
[07:51] <punkgeek> now i have this error
[07:51] <punkgeek> https://paste.ubuntu.com/p/fmjmZkG2D5/
[11:50] <data_> Hi. I'm looking for a tool to get a server up and running repeatably. E.g. I have a clean LTS ubuntu server, which I want to hav A, B and C packages installed, X and Y users created, SSH keys installed, etc etc etc. Are tools like Ansible/Chef/Puppet what I'm looking for? They look very complicated - I'm looking for something very simple. Is my current approach of a bash script the best solution? Thanks for any help.
[11:52] <blackflow> data_: Start with Ansible. doesn't require any client/server setup, only ssh.
[11:53] <data_> Ansible seemed really complicated
[11:54] <blackflow> simpler than writing a bash script which woul dhave to do all the logistics of checking whether files exist, packages are installed etc...
[11:54] <lordievader> Other automation tool you can look at is Puppet.
[11:55] <blackflow> which is way more complicated.
[11:57] <data_> Any tool for editing ansible yml files you could recommend?
[11:57] <blackflow> any text editor
[11:58] <data_> I guess I'm looking for something with auto-complete, discoverable modules and all that
[11:59] <blackflow> like, how complex do you think your set up will grow that you need all that?
[12:01] <data_> well, not that complex, to be honest - and if this was just a local home server i wouldnt give it a second thought: php (composer), python (pip), postgres, apache, some users, some databases. basically ~20 lines of a bash script
[12:02] <data_> but it feels "dirty" to do it that way - "there must be a better way!"
[12:03] <data_> im thinking ansible would be more resistant to things going haywire in the middle of the script and doing lots of weird stuff
[12:03] <blackflow> well if it's just bootstrapping (imperative, no state), then I suppose a shell script is better.
[12:03] <blackflow> data_: and the key to that is writing idempotent rules
[12:03] <blackflow> and those require state checking so something like Ansible is really the best thing to do.
[12:04] <data_> right, because you tell ansible what you want the end result to be, not what to do (i.e. creating databases)
[12:06] <blackflow> more or less, yeah.
[12:06] <blackflow> primarily it is like that yes. you describe a state. but you also describe handlers that trigger when state changes and those are, for example, places where idempotency can break if you're not careful.
[12:09] <data_> blackflow: here's a an example script of what i'm talking about: https://gist.github.com/iivmok/2c6224fa33a4c4ac51207fa601017514
[12:14] <blackflow> data_: well if that works for you.... and I'm totally not gonna say anything about running that php -r thing and fetching files to exec, as root :)
[12:16] <data_> that's from composers installation guide, and it does check the hash of the downloaded script, so i think it should be safe from MITM
[12:22] <lordievader> The download of the script can't be MITM'ed?
[12:24] <blackflow> data_: you'll also need   set -e    in that script so it exits when a command fails. see, logistic requirements start to pile up if you want it done properly. just use Ansible ;)
[12:26] <data_> lordievader: if understand that line right, it removes the composer-install file if it fails a hash check
[12:27] <lordievader> data_: No, you are saying that because the script checks the hash of a downloaded file you should be fine against MITMs. But what if the script has been tempered with while you where downloading through a MITM attack? (I know very theoretical).
[12:28] <blackflow> btw why are you using php for things like unlink....
[12:28] <blackflow> this it TheDailyWTF material :)
[12:29] <data_> blackflow: as I said, that's from the composer installation docs - theres a link in the comment there
[12:29] <data_> here https://getcomposer.org/download/
[12:30] <blackflow> that's so much full of fail.....
[12:30] <data_> should've used the script from here: https://getcomposer.org/doc/faqs/how-to-install-composer-programmatically.md
[12:30] <data_> but that's beside the point
[12:31] <data_> blackflow: eh. your perl is my python is their php. i mean sure, rm would be more portable, but i don't remember a builtin md5 tool in *nix
[12:31] <blackflow> well, not blindly running stuff found online is one of the steps toward proper server maintenance :)   Have to be harh. Unfortunately we live in the age of IT pwnage, massive data breaches, infosec-pocalypse :)
[12:32] <blackflow> *harsh
[12:32] <blackflow> md5sum
[12:32] <blackflow> also sha384 sum, if you really want that one.
[12:33] <blackflow> but anyway... what I would do there, with Ansible, is prepare all such files in the config repo itself, not download ad-hoc on the machines.
[12:33] <data_> blackflow: why blindly? it does check for the hash, and i mean, it has to start somewhere. if its not in the distros ppa, its all as unsafe
[12:33] <blackflow> beside better security, you also make sure that all the machines are running exactly the same setup procedure.
[12:34] <data_> any npm/pypa/packagist package could be compromised
[12:35] <blackflow> technically so can distro repos
[12:35] <blackflow> but really, that's why you downlaod those files yourself, chekc them, test them, and upload to the server for use. with Ansible, that's very easy to do.
[12:54] <RoyK> blackflow: md5 has been cracked years ago
[12:55] <blackflow> RoyK: that's why we use sha, yes.
[12:55] <blackflow> (256 or better)
[12:56] <RoyK> sh512 is good - and faster than 256 on 64bit machines
[12:59] <blackflow> though I have yet to see a viable misuse of md5 for checksum validation. that's quite different from crypto where all the collisions make md5 very bad choice for, say, password hashing.
[15:35] <DirtyCajun> my nfsd is running 16 threads on a 16 thread system and i am sitting at a 18 load often. Should i increase the threads or decrease the threads to remedy?
[15:37] <compdoc> 18% cpu use, or aht?
[15:37] <compdoc> what
[15:38] <DirtyCajun> nono. 18 load on a 16 core server
[15:38] <DirtyCajun> so about 120% load
[15:38] <compdoc> whew
[15:38] <DirtyCajun> but low cpu/ram utilization. its all nfsd waiting to do stuff
[15:38] <DirtyCajun> pretty low iowait too
[15:39] <dlloyd> where is the time spent if iowait is low?
[15:40] <DirtyCajun> its all nfs threads waiting
[15:40] <DirtyCajun> ps -e v shows the stat for all the threads as D
[15:42] <DirtyCajun> and thats uninterruptable sleep. man page says (usually IO) but io_wait is low like i said before
[15:42] <dlloyd> then there doesn't seem to really be an issue? loadavg is a composite metric that doesn't necessarily correlate to an 'overloaded' system
[15:43] <DirtyCajun> you dont see an issue with a loadavg metric above the threadcount of your system?
[15:44] <DirtyCajun> ive never heard that opinion in my 20 years in the industry (not saying that agressively just saying)(
[15:47] <blackflow> DirtyCajun: btw is it 16 thread or 16 core system?
[15:47] <dlloyd> it entirely depends on the workload. unless there are metrics indicating either processing delays or latency in handling requests, i would say that its not actionable. without knowing more about the precise state of the threads, i would say if you want to reduce the load average, reduce the count of threads. no idea what impact that will have on the performance
[15:47] <DirtyCajun> 2 4core 8thread systems
[15:47] <DirtyCajun> s/systems/system
[15:48] <blackflow> 2 x 4 core HT cpus, right?
[15:48] <DirtyCajun> dlloyd, i would agree with you and that was my initial thought, but everything online seems to say to increase which is why i hopped on here in the first place haha
[15:48] <DirtyCajun> blackflow, yes
[15:48] <dlloyd> state D is counted against 'running' in load average calculation, but isn't necessarily consuming actual cpu time
[15:49] <dlloyd> right, i was saying if you want to game load average down vs handling more throughput/connections
[16:20] <RoyK> DirtyCajun: how much of the load is I/O wait?
[16:20] <RoyK> DirtyCajun: sar/systat or top or whatever will tell - I guess it's most of it
[16:54] <DirtyCajun> So after upping the threads to 64, it looks like the load has gone down to 10ish out of 16
[16:55] <DirtyCajun> i do see that context switches are really high (ctx_sw). LIke 100K of them
[18:13] <steve3245> Anyone running critical production web-facing servers....do you use ufw  or manually set rules with iptables directly?  other?
[18:13] <steve3245> **for establishing host firewall rules
[18:17] <_KaszpiR_> steve3245 firewalld
[18:17] <steve3245> _KaszpiR_, from fedora-land?
[18:17] <_KaszpiR_> or plain iptables or ferm
[18:18] <steve3245> _KaszpiR_, do you administer ubuntu and fedora-derived servers?
[18:18] <_KaszpiR_> both
[18:18] <_KaszpiR_> (well it's centos, not fedora but close)
[18:18] <steve3245> (a second question i'm looking into now is if i can develop a unified approach to firewalling centos/debian/ubuntu machines)
[18:18] <steve3245> right
[18:19] <steve3245> i like just using plain IPtables on centos
[18:19] <whislock> firewalld.
[18:19] <steve3245> but i didn't know if that is a kind of lame hack for ubuntu best practices
[18:19] <_KaszpiR_> at first I was not happy with firewalld till I just beat the shit out of it and started to like it
[18:19] <whislock> Honestly, unless you're extremely good at firewalls, you shouldn't be mucking with iptables directly.
[18:19] <_KaszpiR_> there are some pretty decent things in it
[18:19] <whislock> I know a lot of people will disagree with me, but I've seen a lot of large security holes left open or created because people wanted to directly manipulate iptables.
[18:20] <steve3245> I'm no expert but what i like about plain IPtables is i just basically set default DENY on incoming, and then add very restrictive incoming allow rules
[18:20] <_KaszpiR_> do you hhave WAF (web app firewall wich actually filters out and validates requests before they reach application)?
[18:21] <steve3245> not at this time
[18:21] <steve3245> possibly in the future but we are kind of a small shop
[18:21] <_KaszpiR_> then don't spend too much time on firewall
[18:21] <steve3245> most of this stuff is just LAMP type servers etc
[18:21] <_KaszpiR_> most attacks are just on app layer itself
[18:22] <_KaszpiR_> such as exploiting app vunerabilities
[18:22] <steve3245> i hear you - we got owned recently due to web devs not keeping drupal updated
[18:22] <steve3245> ~10 compromised sites
[18:22] <_KaszpiR_> where's your firewall now? :D
[18:23] <steve3245> haha
[18:23] <_KaszpiR_> ssure it's good practice to fliter unwanted stuff as close to the source as possible
[18:24] <steve3245> Yes I think they were all "drupalgeddon" attacks....it looks like all it took was someone stuffing some bogus strings into a URL and they had write permissions to the webroot dir  sigh
[18:24] <steve3245> I will look into that
[18:24] <steve3245> is that some kind of hardware appliance you run?
[18:24] <_KaszpiR_> I'd rather focus on processing logs and adding something like fail2ban on too many errors for given app
[18:25] <steve3245> yes i'm definitely hoping to get fail2ban going on these soon
[18:25] <steve3245> i inhereted a fair amount of kind of not so well kept servers
[18:25] <steve3245> and just trying to tidy them up a bit
[18:26] <steve3245> do you know if fail2ban directly depends on my using any particular firewall?
[18:26] <steve3245> (related to my earlier question about ufw/iptables/firewalld)
[18:26] <_KaszpiR_> otherwise just making very strict rules for web servers of what is acceptable by the app (this may be tricky but usually boils down to what kind of requests are allowed, what vars are allowed with what kind of type, for example page can be number only) - usually iuts just a lines and lines of regexp rules ;)
[18:27] <_KaszpiR_> fail2ban can run with different stuff, by default it talks with iptables by creating dedicated rules which it manages
[18:28] <whislock> Consider snort/suricata.
[18:28] <steve3245> yes i'm looking into running snort also to keep eyes on network stuff
[18:28] <steve3245> what is flying around the network
[18:28] <steve3245> do you need realy fast hardware to run that?
[18:28] <whislock> No.
[18:28] <_KaszpiR_> nope
[18:28] <steve3245> it sounded like it needed a dedicated bare metal fast CPU host
[18:28] <whislock> But it's not just network stuff. IDS can alert/IPS can mitigate some app exploits.
[18:28] <steve3245> oh awesome
[18:29] <whislock> Depends on the engine, the rules its fed, etc.
[18:29] <steve3245> yeah i'd love that....it sounded like it could inspect packets and notice "bad" signatures flying around and alert in real time?
[18:29] <steve3245> like "hey this tcp header looks like you might have some ransomware stuff in the network"?
[18:30] <whislock> It's more interested in the content than in TCP.
[18:30] <steve3245> great - are you using snort now in production
[18:31] <whislock> "This request coming into your web server looks like a SQL injection attack" kind of idea.
[18:31] <steve3245> oh awesome
[18:31] <steve3245> yes after this recent drupal incident i'm hoping to be a little more proactive in the future
[18:31] <steve3245> and not depending on the web devs to keep drupal updated
[18:31] <_KaszpiR_> 'nah that the devs that made a typo' ;D
[18:32] <steve3245> hey i'd rather have false alerts than not know :]
[18:32] <whislock> Snort is the most widely deployed IDS/IPS engine in the world.
[18:32] <whislock> It's maintained by Talos - Cisco's threat intelligence arm.
[18:33] <whislock> https://www.talosintelligence.com/snort
[18:33] <whislock> I was using it for my house, before my employer transitioned me to Palo Alto firewalls.
[18:35] <steve3245> thanks I will check it out
[18:35] <steve3245> appreciate the input whislock and _KaszpiR_
[18:36] <_KaszpiR_> there is one more thing you may consider
[18:36] <whislock> Zoom.
[18:36] <_KaszpiR_> https://en.wikipedia.org/wiki/Open_Source_Tripwire
[18:37] <_KaszpiR_> for validating files on host, so that you can detect if file signatures change
[18:37]  * trippeh_ trips
[18:37] <trippeh_> clear
[18:38] <trippeh_> nm, I'm not tripwire on this IRC network it turns out
[19:25] <oerheks> info suckless-tools


[07:39] <dholbach> good morning
[13:05] <dholbach> did anybody read the last comment on http://ubuntungo.wordpress.com/2009/11/11/milieudefensie-friends-of-the-earth-netherlands-%E2%80%93-ngo-interview/ ?
[13:05] <dholbach> might be interesting to get in touch with them
[13:14] <JanC> indeed
[13:15] <JanC> hm, "some of the people writing OpenERP are from Luxembourg,and actually speak Dutch in addition to French." --> actually, it's a Belgian company, not from Luxemburg, which makes the speaking dutch more plausible too  ☺


[00:00] <tsimonq2> that was me
[00:00] <tsimonq2> and me
[00:01] <tsimonq2> I'm halting the nightlies because Qt will land before I go to bed
[00:02] <tsimonq2> and that's a *fact*
[00:03] <tsimonq2> (at least for Yakkety it will)
[00:03] <tsimonq2> Xenial Qt 5.7 will land tomorrow
[02:24] <tsimonq2> Alright! Yakkety is copied to the PPA.
[02:24] <tsimonq2> After it's all done publishing I'll do a global rebuild of just Yakkety
[02:50] <tsimonq2> my goal is to get the first wave of core Qt packages and the non-core Qt packages done tonight
[02:50] <tsimonq2> then tomorrow morning I'll finish up the Xenial stuff
[02:50] <tsimonq2> but all of it should be BEFORE then next nightly
[02:51] <tsimonq2> so PLEASE, NOBODY TOUCH XENIAL BUILDS
[02:52] <tsimonq2> ooh ok, cool
[02:54] <tsimonq2> perfect! :P
[02:54] <tsimonq2> so now it's scary rnough that nobody will touch it :P
[02:54] <tsimonq2> *enough
[02:57] <tsimonq2> no no no, I have to spice it up a little bit :P
[02:58] <tsimonq2> gosh darnit, too long
[02:58] <tsimonq2> there, fine
[02:59] <tsimonq2> alright, Yakkety all published
[02:59] <tsimonq2> Here comes a global rebuild of Yakkety
[03:03] <tsimonq2> Now, anything with _FAILURE_ is my fault
[03:03] <tsimonq2> Whoops I mean _FAILURE_
[03:03] <tsimonq2> Whoops I mean _FAILURE_
[03:04] <tsimonq2> maybe?
[03:04] <tsimonq2> grrrr
[03:04] <tsimonq2> whatevrt
[03:04] <tsimonq2> you guys get the point
[03:05] <tsimonq2> that's caused by fuzz ^
[03:05]  * tsimonq2 rebuilds to be sure
[03:07] <tsimonq2> yeah fuzz
[03:11] <tsimonq2> so it's slim enough to fix
[03:11] <tsimonq2> *fit
[03:11] <tsimonq2> still scary
[03:11] <tsimonq2> t it's all good :)
[03:11] <tsimonq2> perfect <3
[03:11] <tsimonq2> I won't touch it anymore, I promise :P
[03:13] <tsimonq2> menawhile lemme fix yakkety_unstable_kscd
[03:13] <tsimonq2> *meanwhile
[03:28] <tsimonq2> ahhhhhhhhhhhh
[03:38] <tsimonq2> there I think I fixed it
[03:48] <tsimonq2> alright, the non-core Qt packages are building in ppa:kubuntu-ninjas/qt-5.7 now.
[03:48] <tsimonq2> idk if that will be done before I go to bed :/
[03:48] <tsimonq2> if it will, I'll start on wave two of the core Qt package tweaking
[03:48] <tsimonq2> (but I highly doubt I'll finish it all tonight)
[05:38] <tsimonq2> me ^
[06:31] <tsimonq2> !info libanalitza-dev
[06:32] <tsimonq2> ¯\_(ツ)_/¯
[06:32] <tsimonq2> not related to Qt
[06:32] <tsimonq2> so I'm updating symbols for khtml
[06:33] <tsimonq2> it happened right after a bump to the ECM and KF5 deps
[06:33] <tsimonq2> just DDGing "KJS kde" as that's where the symbols came from, I got this description: "KJS is KDE's ECMAScript-JavaScript engine that was originally developed for the KDE project's Konqueror web browser by Harri Porten in 2000."
[06:34] <tsimonq2> ECMA sounds like ECM so I think I'm fine
[06:34] <tsimonq2> :P
[06:34] <tsimonq2> in any case, I'm doing a local rebuild to confirm that removing these three symbols is correct
[06:34] <tsimonq2> then I'm going to bed
[06:37] <tsimonq2> ^ seems to not related to Qt, test failures :/
[06:47] <acheronuk> tsimonq2: those are the symbols that need to be marked GCC 6 optional, not removed AFAIK
[06:48] <tsimonq2> ok fixing
[06:48] <acheronuk> https://git.launchpad.net/~panfaust/kubuntu-packaging/+git/khtml/commit/?id=8466bebcd1a52bfc4c86e7635052710381fc8b74
[06:50] <acheronuk> tsimonq2: was just waiting for yofel to ok that merge ^^^ + 2 or 3 similar ones to YY archive branch, which would then automerge to KCI's unstable
[06:51] <tsimonq2> ok after this I'm going to STOP attempting to (and screwing up) updating symbols... :P
[06:51] <tsimonq2> reverted
[06:51] <tsimonq2> I'll let his commit be mergede
[06:51] <tsimonq2> *merged
[06:54] <tsimonq2> yofel: I *really* need to sit down with you in the future and talk through refreshing symbols, and what goes through your mind when doing this. Because I think this is the third time in a row I've tried to refresh symbols and I just failed...
[06:54]  * tsimonq2 is starting to get a little irked :/
[06:55] <acheronuk> tsimonq2: I still need to get some stuff on symbols completely straight in my head :P
[06:55] <tsimonq2> yofel: well then let's schedule a dojo with me you and acheronuk :) :P
[07:06] <acheronuk> it's a long long time since I've properly done any C++, and I've forgotten much of what I did know, which wasn't huge to start with
[07:09] <tsimonq2> well I'm learning more and more every day acheronuk :)
[07:10] <tsimonq2> yesterday I finally learned what :: means :P
[07:15] <acheronuk> maybe brushing up on C++ a bit is something to do while the rest are off drinking beer in Berlin
[07:59] <tsimonq2> yeah acheronuk :)
[07:59] <tsimonq2> well bed for me o/
[10:32] <acheronuk> yofel: mgmt_docker on linode appears to be failing
[11:59] <BluesKaj> Hiyas all
[15:27]  * acheronuk prods KCI
[15:28] <clivejo> whats it doing?
[15:29] <acheronuk> the mgmt_docker on linode was faling, and lindode was failing on all jobs sent to it
[15:29] <acheronuk> *failing
[15:57] <acheronuk> tsimonq2: linode (and KCI) cra**ed out shortly after you went this morning, so not much has been done against Qt 5.7
 He killed it
[16:01] <yofel> ?!?
[16:02] <acheronuk> it certainly wasn't happy for a while!
 /me wakes up and finishes things
[18:40] <tsimonq2> nobody fear
[18:40] <tsimonq2> I'm here
[18:40] <tsimonq2> :P
[18:55] <ahoneybun> Kubuntu Members: Remember to vote on the next KC members, if your a member you should have gotten an email to vote. Deadline is Sept 12th!
[18:58] <tsimonq2> acheronuk: *you're *member, *The deadline *12 September 2016
[18:58] <tsimonq2> whoops ahoneybun ^
[18:58]  * tsimonq2 runs
[18:58] <ahoneybun> tsimonq2: your already on my list
[19:00] <tsimonq2> *you're
[19:00] <tsimonq2> lol
[19:00] <tsimonq2> maybe you shiuld learn proper grammar first ;)
[19:00] <tsimonq2> *should
[19:03] <ahoneybun> maybe you should not be...
[19:04] <tsimonq2> hm?
[19:04] <ahoneybun> not going to finish that
[19:04]  * tsimonq2 throws ahoneybun into a river
[19:05]  * ahoneybun can swim
[21:04] <acheronuk> tsimonq2: may have to either rebuild qtwebengine and qtwebchannel 5.6 in KCI....
[21:05] <acheronuk> tsimonq2: or upload v 5.7. Neon have packaged that
[21:05] <tsimonq2> yeah
[21:07] <tsimonq2> acheronuk: could you do me a huge favor?
[21:07] <acheronuk> possibly
[21:07] <tsimonq2> WHY DO WE SHOP FOR CLOTHES THE DAY BEFORE SCHOOL STARTS :(
[21:08] <tsimonq2> could you continue the process?
[21:08] <tsimonq2> Xenial is on second wave core packages
[21:09] <ahoneybun> tsimonq2: the US is weird
[21:09] <acheronuk> tsimonq2: not today probably, but I'll look tomorrow
[21:10] <tsimonq2> dad decided to take us for ALL the before school errands today :(
[21:10] <tsimonq2> fine I'll do it later :/
[21:10]  * tsimonq2 isn't happy right now
[21:11]  * ahoneybun isn't in Berlin right now and is sad
[21:14] <acheronuk> tsimonq2: where did qtserialport 5.7 go? don't see that having been built for YY?
[21:15] <acheronuk> I think you may be missing some Qt
 Not uploaded to experimental yet
 If it's in neon or something I'll redo the process with just those packages
 But I checked all the packages you had against what's in experimental
[21:17] <acheronuk> well, something are going to need it.
 Ik ik ik
[21:19] <acheronuk> e.g. build depend on pyqt5 now errors with
[21:19] <acheronuk> he following packages have unmet dependencies:
[21:19] <acheronuk>  libqt5serialport5 : Depends: qtbase-abi-5-6-1
[21:20] <acheronuk> as old qtbase is gone
[21:21] <acheronuk> I think it's all the required parts of Qt 5.7 or none at all. A halfway house won't work
 I'll fix it when I get home I promise
[21:22] <acheronuk> I thought you had it all to build
[21:23] <acheronuk> It's ok. will sort it or revert it. one way or another
[21:24]  * clivejo cant fit his laptop in his bag
[21:28] <acheronuk> either clivejo has a huge widescreen laptop, or needs a bigger bag
[21:37] <acheronuk> 17" into 15" doesn't go!
[21:38] <clivejo> but why not!
[21:40] <acheronuk> I put mine in a freebie conference satchel I got years ago. Fit pretty well.
[23:56] <acheronuk> Nice test errors with Qt 5.7
[23:56] <acheronuk> libGL error: No matching fbConfigs or visuals found
[23:56] <acheronuk> libGL error: failed to load driver: swrast
 :/
 What's that mean?


[00:41] <ehoover> wgrant: is there a way to abort a recipe build?
[00:41] <ehoover> (we spotted a failure locally, so we would prefer to shut it down before waiting forever)
[00:51] <wgrant> ehoover: You should have a cancel link on the build page
[00:51] <wgrant> Otherwise I do.
[00:51] <ehoover> wgrant: nope: https://code.launchpad.net/~pipelight/+archive/stable/+recipebuild/648715
[00:51] <ehoover> (recipe part of build, not build part of build - if that helps)
[00:51] <wgrant> ehoover: Cancelled
[00:51] <ehoover> wgrant: thank you so much :)
[00:52] <wgrant> np
[01:11] <ehoover> wgrant: is there some reason merging a small repo onto a large repo in a recipe takes a really long time? (and is there a way to work around it?)
[01:19] <wgrant> ehoover: That's hard to make a general statement about. Have you tried running the recipe locally?
[01:19] <ehoover> wgrant: yeah, it takes forever locally too
[01:19] <wgrant> Is it network-bound, CPU-bound, RAM-bound?
[01:20] <ehoover> wgrant: good question, let me run it again
[01:22] <ehoover> (it'll take longer to get to the same point than the build farm since it needs to download everything, but i'll let you know as soon as it's there)
[01:31] <ehoover> wgrant: hmm, i actually got a connection timeout while it was still downloading :/
[01:31] <wgrant> :/
[01:32] <ehoover> wgrant: do you know if there's a quick and easy way to change the timeout?
[01:32] <wgrant> Assuming it's the 300 second timeout, there is no way to change it.
[01:32] <wgrant> That usually means the connection was idle for a long time
[01:33] <wgrant> Suggesting you might be CPU-limited locally, or something like that
[01:34] <ehoover> wgrant: well, it didn't seem to use hardly any of my resources - i have 4 cores with hyperthreading and 16GB of RAM on this box...
[01:34] <ehoover> (and yes, it was a 300 second timeout)
[01:39] <ehoover> wgrant: none of my cores went over about 10%, my RAM is almost completely free, and iotop reports very little activity
[01:39] <ehoover> during where it's working on the "build phase", not long after this message:
[01:39] <ehoover>  96288kB   500kB/s - Build phase:Adding file contents 5575/7072
[01:40] <ehoover> it wrote out:
[01:40] <ehoover> Connection Timeout: disconnecting client after 300.0 seconds072
[01:41] <ehoover> on the build farm it actually hangs after it says "Merging revision 'revno:55' of 'lp:wine-compholio' in to..." and again after "All changes applied successfully."
[01:41] <ehoover> but it eventually finishes, it just takes a really long time
[01:41] <wgrant> It might only work on the build farm because they use HTTP
[01:41] <wgrant> So there's no session to time out.
[01:42] <ehoover> wgrant: well, i could pre-download the repo and do it that way - if that will help
[01:46] <wgrant> ehoover: It's worth a try, I think
[01:58] <ehoover> wgrant: it looks like the connection is over SSH, so (if someone asks in the future) you can probably get it to not timeout by setting the SSH ClientAliveInterval
[01:58] <wgrant> ehoover: Nope, the timeout is at a higher level than that.
[01:58] <ehoover> hmm
[01:58] <wgrant> It's based on Bazaar smartserver commands, not just SSH activity.
[02:05] <ehoover> wgrant: ok, local build is in progress and it's only using one core and pegging - hard
[02:07] <ehoover> iotop shows nothing, iftop shows nothing
[02:09] <ehoover> still true after "All changes applied successfully.", one core is pegged
[02:19] <ehoover> wgrant: where it spends most of the time is between "All changes applied successfully." and "Committing to: ...".  if i spend some time investigating this is there any chance it can get fixed?
[02:27] <ehoover> anway, need to head home before the wife gets upset - ttyl
[12:28] <directhex> is there an easy way to retrieve the gpg pubkey of everyone with upload rights to main & universe?
[12:48] <jelmer> directhex: does the ubuntu keyring include them all?
[12:48] <directhex> jelmer, i don't know. does it?
[12:55] <czajkowski> could stab wgrant to find out
[12:55] <czajkowski> not like he actually sleeps ;)
[13:29] <cjwatson> no, the Ubuntu keyring doesn't, but it should be scriptable using the API.  let me see if I can demonstrate that ...
[13:35] <directhex> i'd definitely appreciate such a script, or its output, to<EMAIL_ADDRESS>[13:36] <cjwatson> ok, working on it
[13:38] <directhex> thanks
[13:41] <cjwatson> directhex: clarification before I get too far into this: do you mean strictly people who have general upload access to an entire component (core-devs, MOTUs), or also people who have any kind of individual-package or set-of-packages upload access (which I suppose is sort of analogous to DMs)?
[13:42] <directhex> cjwatson, i guess what i want is the ubuntu-flavoured equivalent to the DD and DM keyrings. so whether that means, say, members of core-dev and motu... i haven't kept up to date on how upload rights are delegated these days
[13:43] <cjwatson> I think that is probably equivalent to including per-package upload rights, since DM ~= you get to upload some small number of signed-off packages
[13:43] <cjwatson> but I can easily annotate them
[13:45] <directhex> i'll trust your judgement on this. i wouldn't bother with annotation, i'm just going to munge everything into one big local keyring, because reasons
[13:45] <cjwatson> k
[14:10] <ekristen> morning, I have a package that is failing to build, it depends on a specific version of another package in my PPA, however it continues to fail saying the libewf-dev depends on libewf2-dev, which isn’t true, in fact I cannot find a libewf-dev package out there that does depend on libewf2-dev so I don’t know where it is getting it from, can someone help please —
[14:10] <ekristen> https://launchpadlibrarian.net/165391068/buildlog_ubuntu-precise-i386.sleuthkit_4.1.3-1ubuntu4_FAILEDTOBUILD.txt.gz
[14:16] <cjwatson> ekristen: It's in https://launchpad.net/~pi-rho/+archive/security, which /~sift/+archive/dev is apparently configured to depend on
[14:16] <ekristen> ah
[14:16] <ekristen> I missed that
[14:17] <ekristen> cjwatson: thank you!
[14:17] <cjwatson> (see https://launchpad.net/~sift/+archive/dev/+edit-dependencies)
[14:17] <cjwatson> yw
[14:19] <cjwatson> directhex: ok, yhm
[14:20] <directhex> ta
[15:25] <ekristen> cjwatson: this this package unable to build because of the “cannot find -ltalloc” error? https://launchpadlibrarian.net/165394185/buildlog_ubuntu-precise-i386.pytsk_4.1.3-1ubuntu1_FAILEDTOBUILD.txt.gz
[15:38] <cjwatson> ekristen: no, "tsk3.c:79:29: error: 'TSK_IMG_TYPE_EXTERNAL' undeclared (first use in this function)" and "tsk3.c:141:29: error: 'TSK_IMG_TYPE_EXTERNAL' undeclared (first use in this function)"
[15:38] <cjwatson> though that first error might indeed indicate a missing build-dependency
[15:39] <cjwatson> (This is not Launchpad-specific; you ought to be able to reproduce the exact same failures in a local sbuild instance.)
[15:39] <ekristen> I’m realitively new to launchpad and all, I’ll have to checkout sbuild
[15:44] <ekristen> guess getting a local build of sbuild up is a little involved
[15:45] <cjwatson> https://wiki.ubuntu.com/SimpleSbuild
[15:49] <ekristen> thanks
[15:52] <ekristen> cjwatson: sg build asks for a password any idea what password it wants?
[15:53] <cjwatson> your own
[15:54] <ekristen> :/ it doesn’t work
[15:54] <cjwatson> "doesn't work" is not a useful report
[15:54] <ekristen> sorry always says “invalid password"
[15:54] <cjwatson> also it should be "sg sbuild" not "sg build" as you typoed above
[15:55] <ekristen> sorry, that was a typo
[15:55] <ekristen> on my part
[15:55] <cjwatson> but you can always just log out and back in to get the new group membership
[15:55] <ekristen> hrm that seems to have done the trick, thanks
[16:09] <psusi> bug #1164683 has a remote bug tracker for debian that is incorrectly showing up as the upstream project.  Under target -> distribution it does not give the option to select Debian.  What happened to that choice?
[22:18] <ekristen> cjwatson: I don’t think https://wiki.ubuntu.com/SimpleSbuild works on precise, at least I can’t get it to work
[23:50] <maxb> ekristen: That seems entirely likely, sbuild has improved a fair bit over the last few release cycles. Generally people doing package dev would be using at least the latest stable as a host OS, so instructions tend to target that