[00:40] <scientes> how can i install ubuntu side-by-side android on the nexus 7?
[00:40] <scientes> it seems like that would be nice
[00:43] <xnox> scientes: see upvoted answer on http://askubuntu.com/questions/210870/nexus-7-dual-boot-with-android
[00:44] <scientes> if i figured it out would my work be appreciated?
[00:44] <scientes> using something like clockworkmod
[02:10] <ScottK> Any suggestions what to do about http://paste.ubuntu.com/1378553/ ? It gets past this point on a buildd, it's just a local failure, but it's repeatable.
[02:11] <ScottK> Makes it tough to get to the actual build failure.
[02:11] <ScottK> It's armhf if it matters.
[05:03] <pitti> Good morning
[05:05] <pitti> doko, infinity: want me to upload the binutils autopkgtest (tested locally in a VM) in bug 1081500?
[05:08] <aaron> hey i have a question... how do you setup your email that i have from ubuntu.com?
[05:26] <infinity> pitti: That's doko's call, I have no firm opinion on the matter, but he may have a new binutils staged for other reasons.
[05:27] <pitti> infinity: ok, thanks; I'll ask him when he gets up
[05:31] <infinity> pitti: (As for the brown paper bag fix to the eglibc autopkgtest, I'll be rolling that into Debian experimental and then merging back soon)
[05:31] <pitti> thanks
[05:31] <infinity> ... just in time to start revving experimental to 2.17
[05:46] <pitti> infinity: so you and ScottK are the only Americans who are still on IRC these days/
[05:46] <pitti> ?
[05:47] <pitti> seems everyone else went off to indulging turkey
[05:47] <ScottK> infinity might object to the characterizaton.
[05:47] <pitti> I had no overnight backscroll pings at all, at first I thought my proxy was broken
[05:47] <ScottK> Heh.
[05:47] <pitti> I didn't say "USian" :)
[05:47] <pitti> Canada clearly is in America
[05:49] <Aaron> lol
[05:57] <infinity> pitti: Yeah, but Canadian Thanksgiving was last month, so no turkey for me.
[05:57] <pitti> ah, I see; it's earlier because of the (on average) colder climate in Canada?
[05:58] <infinity> pitti: Or because we just like to be different.  Who knows.
[05:58] <pitti> so the harvesting had to happen earlier?
[05:59] <pitti> infinity: well, at least this reasoning would be more convincing than the one about imperial units :)
[06:11] <ScottK> Maybe they lost a month in the Imperial to Metric conversion.
[06:54] <didrocks> @pilot in
[07:31] <darkxst> didrocks, can you take a look at this patch? https://bugs.launchpad.net/ubuntu/+source/gui-ufw/+bug/1071915
[07:32] <didrocks> darkxst: sure, will do :)
[07:32] <darkxst> didrocks, it probably should go into raring as well, but I dont think raring was actually open when I uploaded it
[07:33] <didrocks> darkxst: it needs to get to raring first
[07:33] <didrocks> darkxst: mind proposing a branch for it as well?
[07:33] <didrocks> darkxst: then, I'll do the review :)
[07:33] <darkxst> yeh I figured that
[07:34] <darkxst> ok one moment
[07:34] <didrocks> sure ;)
[08:00] <dholbach> good morning
[08:05] <pitti> ev: are you still waiting for apw's feedback on https://code.launchpad.net/~ev/apport/kernel-oops-crash-signature/+merge/129440 ?
[08:10] <darkxst> didrocks, https://code.launchpad.net/~darkxst/ubuntu/raring/gui-ufw/lp1071915/+merge/135834
[08:11] <didrocks> darkxst: excellent! I'll have a look this morning :) Thanks a lot!
[08:11] <darkxst> ok thanks
[08:35] <didrocks> darkxst: commented btw :)
[08:39] <rbasak> didrocks: may I poke you about sponsoring bug 1014732 please? It's been in the queue a while. The problem is that for as long as it isn't fixed, triaging other mysql bugs is harder because nobody has error logs
[08:39] <didrocks> rbasak: sure, looking :) (not sure having the competence on mysql though, so no promess)
[08:39] <rbasak> Thanks!
[08:40] <rbasak> didrocks: it's a trivial conffile change, cherry-picked from the development release (which was at the time quantal!). So just apport and conffile stuff
[08:41] <didrocks> rbasak: yeah, indeed, not really mysql-deeply-insane-code related :)
[08:41] <rbasak> :-)
[08:41]  * rbasak wonders if that is what was scaring off all the sponsors :)
[08:42] <didrocks> rbasak: it looks good to me, and no mysql in the SRU queue already, sponsoring :)
[08:42] <rbasak> \o/
[08:42] <rbasak> Thank you!
[08:42] <didrocks> rbasak: well, there are keywords that are a natural filters :)
[08:42] <didrocks> rbasak: like "potentially breaking all dbs on a LTS :p"
[08:43] <rbasak> I can see why that could be a problem!
[08:45] <didrocks> heh
[08:45] <didrocks> pitti: mind rejecting https://code.launchpad.net/~nabil-stendardo/ubuntu/quantal/compiz/fix-segfault-related-to-shaders-and-uniforms/+merge/130709 ?
[08:46] <pitti> didrocks: done
[08:46] <didrocks> thanks :)
[08:51] <didrocks> pitti: rejection needed on https://code.launchpad.net/~jlangvand/ubuntu/quantal/gnome-control-center/fix-for-993440/+merge/133570 :)
[08:52] <pitti> done
[08:52] <didrocks> thanks :)
[08:54] <didrocks> https://code.launchpad.net/~timo-jyrinki/ubuntu/quantal/gnome-settings-daemon/ubuntu.fix1058004/+merge/127430
[08:54] <didrocks> pitti: ^ de même, stp :)
[08:54] <pitti> didrocks: avec plaîsir, Monsieur! fini
[08:55] <didrocks> un grand merci :)
[08:55] <pitti> didrocks: oh, "plaisir"
[08:56] <pitti> dear French, please make up your mind about whether or not to put an accent into a particular word. Love, pitti
[08:58] <didrocks> we'll do it, just for you. I propose to put that as #1 world problem ;)
[09:08] <darkxst> didrocks, raring patch was done as distro patch (but i missed the actual patch) fixed now
[09:08] <didrocks> darkxst: same url?
[09:08] <darkxst> yes
[09:09] <didrocks> darkxst: and do you know why upstream set it as OnlyShowIn=Unity?
[09:09] <darkxst> didrocks, no idea, although one of the gufw devs did ok my patch in the bug report
[09:10] <didrocks> darkxst: I'm ok to sponsor it if you talk to them to get them upstream, can you do that?
[09:11] <darkxst> didrocks, ok will do
[09:11] <didrocks> darkxst: you forget to bzr add debian/patches/series though
[09:14] <darkxst> didrocks, oops, added that too
[09:14] <didrocks> pitti: and another one: https://code.launchpad.net/~bkerensa/ubuntu/raring/ubuntu-artwork/fix-for-depends/+merge/135534
[09:16] <pitti> *zap*
[09:16] <didrocks> darkxst: sponsored, thanks! :)
[09:17] <didrocks> merci pitti :)
[09:18] <didrocks> darkxst: do you want to put the quantal branch as a distro patch as well?
[09:21] <darkxst> didrocks, yeh
[09:28] <darkxst> didrocks, https://code.launchpad.net/~darkxst/ubuntu/quantal/gui-ufw/lp1071915B/+merge/135844
[09:28] <smb> pitti, Hi I wonder who nowadays would be the person to talk to about jockey (back in Precise) and apport (seems like Precise and Quantal)
[09:29] <pitti> smb: Apport is still me
[09:29] <pitti> smb: Jockey, I try to forget about it :-) , but I guess I can still answer questions
[09:30] <smb> pitti, So I am not completly sure about whether its pebcak but starting with jockey-text which since yesterday (with precise-proposed enabled) fails running, and apport asking me about submitting the report and then just ignoring my yes
[09:30] <pitti> smb: sounds liek a regression from https://launchpad.net/ubuntu/+source/jockey/0.9.7-0ubuntu7.6 then
[09:31] <pitti> smb: tseliot and bryce recently changed jockey to include the experimental nvidia drivers, that might have something to do with it
[09:31] <smb> pitti, If "from" means introduced by, yes seems like it
[09:31] <didrocks> darkxst: excellent!
[09:32] <smb> pitti, I am sure it did work the day before because the steam client I am playing around with always asked me about the newer fglrx
[09:32] <smb> (which failed to install then btu oddly succeeded today in text mode. gah!)
[09:33] <pitti> smb: if you can confirm it's a regression in -proposed (try downgrading and killing jockey-backend), can you please follow up in bug 1080588 ?
[09:33] <pitti> smb: apport didn't open a firefox tab? or it just crashed? do you have a /var/log/*apport*.crash?
[09:33] <smb> pitti, Should be able to try that, yep. :) Anyway apport seems to come up and it seems like the real upload part is not executed. And that seems to be the the same with another Precise box without proposed and Quantal
[09:34] <smb> pitti, It seems just to exit after saying upload
[09:34] <smb> pitti, no apport crash
[09:34] <pitti> oh, sure
[09:34] <pitti> smb: it's uploading to errors.ubuntu.com
[09:35] <pitti> not to LP, sorry
[09:35] <smb> pitti, At least in Precise there never is a *.uploaded (this seems to be there in Quantal)
[09:35] <smb> Though the experience is a bit weird then
[09:36] <pitti> smb: oh, but you have an .upload stamp?
[09:36] <smb> pitti, the upload stamp yes
[09:36] <smb> in all cases
[09:36] <pitti> smb: "pidof whoopsie"
[09:36] <smb> 2067
[09:37] <didrocks> pitti: https://code.launchpad.net/~darkxst/ubuntu/quantal/gui-ufw/lp1071915B/+merge/135844 can you mark it as merged? (was targeting quantal instead of quantal-proposed)
[09:37] <pitti> hm, I don't see a whoopsie log file
[09:37] <smb> pitti, Probably I am again just too "old school" and expect a lp bug to open which I can add info to
[09:37] <pitti> didrocks: done
[09:37] <didrocks> thanks :)
[09:37] <pitti> smb: yeah, we never did that in stable releases though (at least not for crashes)
[09:38] <pitti> smb: hm, I'm afraid I need to defer to ev about why whoopsie doesn't upload the report
[09:39] <smb> pitti, Ok, sure. Well maybe it *does*, I just have no clue how I would know
[09:40] <tseliot> smb: what happens exactly?
[09:40] <pitti> smb: firefox http://errors.ubuntu.com/user/`printf $(sudo cat /sys/class/dmi/id/product_uuid)|sha512sum`
[09:40] <pitti> smb: (how can that not be totally obvious :-P)
[09:41] <pitti> smb: displaying your sent errors is quite hard right now, that's known
[09:41] <smb> pitti, *grumble*
[09:42] <smb> tseliot, Basically everything looks "normal" and after clicking send report nothing happens. But as I learn this is normal and I probably did not try doing that for released releases for a while... :-P
[09:42] <pitti> didrocks: oh, our GPU freeze is the top crasher in 13.04 for today on errors.u.c.
[09:44] <didrocks> pitti: I have freeze, but not crasher now
[09:44] <didrocks> like some write on disk freeze the ui for 30s
[09:45] <didrocks> and then, back to life
[09:45] <tseliot> smb: if there really was a crash it should be in /var/log/jockey.log
[09:46] <smb> pitti, So I guess *if* I want to create a bug for a stable release now, I have to unpack the *.crash, create a bug with that title and run apport-collect for the rest after it is created?
[09:47] <pitti> smb: see privmsg
[09:49] <smb> pitti, yup thanks
[09:50] <smb> tseliot, There are things in there and it is some type problem in jockey-text -l, just ranting about my inability to know that I have sent info. ;)
[09:52] <tseliot> smb: heh, ok. If you pastebin the log I'llhave a look at the log
[09:52] <smb> tseliot, http://paste.ubuntu.com/1379087/
[09:56] <smb> tseliot, btw, downgrading jockey-common/-gtk to the precise-updates version makes it work for me again
[09:57] <didrocks> pitti: https://code.launchpad.net/~evfool/software-properties/lp1060543/+merge/135513 -> WIP please :)
[09:58] <didrocks> pitti: oh sorry, I can on that one
[09:58] <pitti> didrocks: eek, you can't even set WIP?
[09:59] <didrocks> pitti: on some, I can't
[09:59] <didrocks> and my reviews are set as "(community)"
[09:59] <Laney> usually SRUs
[09:59] <didrocks> (this one was a regular upstream branch, so not the case)
[10:00] <didrocks> (man, the sql testsuite is awfully long)
[10:02] <tseliot> smb: ok, I'll investigate the issue
[10:02] <smb> tseliot, Thanks, meanwhile I marked 1080588 as verification-failed
[10:03] <smb> tseliot, if you want me to attach my apport data, let me know
[10:05] <tseliot> smb: yes, it would be nice if you could attach your apport data
[10:09] <smb> tseliot, ok, its up there
[10:09] <tseliot> smb: thanks
[10:10] <brendand_> tseliot, hi
[10:10] <tseliot> hi brendand_
[10:28] <darkxst> didrocks, thanks!
[10:29] <didrocks> darkxst: yw :)
[10:29] <didrocks> thanks to you!
[10:30] <darkxst> np
[10:35] <pitti> did anyone use autopilot before? I have some trouble with running tests, it doesn't seem to find my tests
[10:39] <tkamppeter> Someone knows about the impact on battery life of avahi-daemon
[10:46] <tkamppeter> Someone knows about the impact on battery life of avahi-daemon?
[10:50] <sladen> tkamppeter: I don't, though perhaps the group in Montreal, with power-monitoring harnesses would be able to give you an exact figure
[10:57] <tseliot> smb: see my private message
[10:59] <didrocks> @pilot out
[11:12]  * dholbach hugs didrocks
[11:12]  * didrocks hugs dholbach back
[11:40] <jodh> cking: thanks! http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/revision/1390?start_revid=1390
[11:40] <cking> jodh, thanks for apply it and +1 to smatch
[11:41] <jodh> cking: yeah :)
[11:41] <cking> ..I wonder what to smatch next...
[11:52] <jodh> cking: what's already been covered? I vote for libc, libnih, udev and plymouth if they haven't been subjected yet :)
[11:53] <cking> jodh, libnih was clean when I tested it yesterday evening. how about doing udev and plymouth for starters?
[11:58] <jodh> cking: smatch barfs on udev.
[11:58] <cking> jodh, why am not surprised..
[11:59] <cking> smatch can produce some false positives that need looking at though
[12:00] <cjwatson> doko: Hmm, is g++-4.7-multilib busted perhaps?  Have a look at the tail end of the current gmp/amd64 build log
[12:13] <cjwatson> doko: bug 1082344
[12:42] <jamespage> are there any packages already in main that offer similar/same function as 'gdisk' (GPT format fdisk clone); I see some support in parted but can't see anything else...
[12:42] <jamespage> ?
[12:46] <cjwatson> jamespage: what are you trying to do?  the installer uses libparted everywhere
[12:47] <jamespage> cjwatson, I'm working on enabling the upstart integration for ceph; it used gdisk to prepare storage devices before bootstrapping them into a ceph cluster
[12:48] <cjwatson> should be straightforward to do that with parted
[12:54] <seb128> jamespage, hey, you are looking at samba in Ubuntu right? Do you plan to merge on Debian (I see we are 3 minor releases behind)
[12:58] <jamespage> seb128, I appear to be the samba merge monkey ATM - I'd not noticed the bump in experimental - I'll take a look
[12:58] <seb128> jamespage, thanks
[13:24] <mitya57> pitti: re https://bugzilla.gnome.org/show_bug.cgi?id=686006:
[13:24] <mitya57> git *does* support file permissions: http://paste.debian.net/211760/ :-)
[13:25] <pitti> well, they didn't work for me..
[13:27] <mitya57> cloning a branch also correctly restores all permissions
[13:30]  * mitya57 needs to stop reading his google+ and do some python-gdata upload
[13:40] <mitya57> hi dholbach
[13:40] <mitya57> can I remove emptry "_static" folder from lp:ubuntu-packaging-guide?
[13:40] <mitya57> I think we don't need it
[13:41] <mitya57> and I'll do a MP for ubuntu logo now
[14:01] <dholbach> mitya57, perfect
[14:02] <dholbach> mitya57, спасибо
[14:04] <mitya57> I think you should now bump the version to 0.3
[14:05] <mitya57> and thanks for dep-8 article update, I found it useful for myself :)
[14:05] <mitya57> I've already added 5 dep-8 tests since quantal release :)
[14:05] <dholbach> NICE
[14:05] <dholbach> pitti, ^ :)
[14:06] <mitya57> (warning: some are not released yet)
[14:06] <dholbach> mitya57, yes, I agree we should get another version out
[14:06] <dholbach> mitya57, it will be just a question if we can easily backport it to older releases - it might require a very recent sphinx, no?
[14:07] <mitya57> why?
[14:07] <dholbach> I thought we just got u-p-g to build because we got a sphinx fix into the archive?
[14:07] <dholbach> I might be mistaken
[14:08] <mitya57> If we don't build translations (do we?) we can get it to quantal & precise without any issues
[14:08] <dholbach> at least for precise it currently does not build
[14:08] <mitya57> let me look
[14:08] <dholbach> https://launchpad.net/~ubuntu-packaging-guide-team/+archive/ppa
[14:08] <dholbach> precise: https://launchpadlibrarian.net/123783723/buildlog.txt.gz
[14:09] <dholbach> and so far we got uploads into R, Q and P - the latter only through backports
[14:10] <mitya57> the only difference between precise package and precise package in our PPA is the fix-l10n-footnotes patch, right?
[14:11] <mitya57> (which (the patch) has been updated upstream recently — I will need to look at it)
[14:11] <dholbach> mitya57, ah, it's fixed and committed upstream now? that'd be fantastic
[14:12] <mitya57> not committed yet (but a pull request exists)
[14:12]  * Laney does a sad at 'only' :(
[14:13] <dholbach> Laney, hm?
[14:25] <dholbach> Laney, can you explain why you're sad? :)
[14:26] <Laney> dholbach: oh, because 'only' sounds like backports is somehow an inferior method of distribution
[14:26] <dholbach> no
[14:26] <dholbach> we're talking about something different
[14:27] <Laney> righto
[14:27] <dholbach> in the PPA we have a modified sphinx because i18n support in sphinx is still pretty fresh and we're trying to figure out issues together with upstream
[14:27] <dholbach> mitya57 has done the majority of the work
[14:27] <Laney> fair enough
[14:27] <dholbach> but we're not 100% there yet
[14:27] <dholbach> I'd love to have translations and up-to-date packaging guides in all pockets of Ubuntu
[14:27] <dholbach> it's in the cards, but will likely take a bit longer
[14:28] <dholbach> so no disrespect for backports here ;-)
[14:29] <mitya57> dholbach: forwarded the patch to debian (to debian bug 691719)
[14:29] <dholbach> mitya57, you're a hero
[14:29]  * dholbach hugs mitya57
[14:30]  * mitya57 hugs dholbach back and joins ~dholbach-huggers team on LP :-)
[14:30] <dholbach> haha :)
[15:00] <doko> cjwatson, still looking, it searches /usr/include/i386-linux-gnu/c++/4.7/32 instead of /usr/include/x86_64-linux-gnu/c++/4.7/32
[15:12] <doko> hmm, only wrong on amd64
[15:20] <doko> cjwatson, ahh, wrong MULTIARCH_DIRNAME for all 64bit archs with multilib builds
[15:30] <doko> hmm, no amd64 only
[15:43] <slangasek> cjohnston: hey, are you resetting the trend lines on status.ubuntu.com now that we've hit FDF?  I don't think I have access to do this
[15:44] <cjohnston> working with is right now on it slangasek
[15:53] <stgraber> wendar, highvoltage: FYI bug 1082426
[15:54] <highvoltage> stgraber: cool
[15:56] <stgraber> hallyn: ^
[16:02] <hallyn> stgraber: excellent, thx
[16:15] <stgraber> hallyn: oh, and bug 509647 and bug 1082431 too
[16:15] <stgraber> jdstrand: I guess you'll want to look at those two when you have a minute (as I'm guessing any other MIR team member will redirect those to you anyway :))
[16:46] <wendar> stgraber: awesome!
[16:51] <hallyn> stgraber: heh, "all are direct cherry-pics of staging" - or rather vice versa :)
[16:51] <hallyn> time to send that syslog-ns description to the kernel team methinks
[16:57] <stgraber> hallyn: hehe, yeah, I should maybe have mentioned that we are the author of 90% of those so technically the staging branch cherry-picks from Ubuntu :)
[17:06] <`|`roll> FELLERS, I discovered a bug in Unity that could lead a remote attack to compromised your system.
[17:08] <xnox> `|`roll: file a bug on launchpad, make sure you tick security such that it is private and the ubuntu security team will collaborate with you to handle it.
[17:08] <`|`roll> I have done that 2 weeks ago.
[17:08] <`|`roll> I havent had any response.
[17:08] <xnox> `|`roll: also see #ubuntu-security channel to enquire about the status
[17:09] <xnox> `|`roll: what's the bug number?
[17:09] <cjwatson> https://wiki.ubuntu.com/SecurityTeam/Contacts
[17:09] <`|`roll> It is somewhere on my email
[17:10] <cjwatson> `|`roll: https://bugs.launchpad.net/~/+reportedbugs should show it, if you're logged in
[17:11] <`|`roll> I just emailed them again.
[17:20] <`l`roll> Can I start developing for Ubuntu?
[17:28] <slangasek> cjohnston: cheers :)
[17:43] <`l`roll> niggers
[17:43] <`l`roll> niggers
[17:43] <`l`roll> niggers
[18:05] <hallyn> stgraber: are you an appropriate one to ping on bug 1075717 in mountall?
[18:07] <stgraber> hallyn: yeah, I'll take a look. How comes we didn't see this before?
[18:15] <hallyn> stgraber: because we didn't mount a separate /dev before
[18:15] <hallyn> stgraber: thanks
[20:19] <wbgs_gaming> hello guys will you be releasing a Openbox version of ubuntu casue thats really like the only version that works for me somthing like Openbox with either lxde,xfce or tint2 panel ?
[20:23] <sarnold> wbgs_gaming: you can always install and run whatever window manager you want, no need for a different version of ubuntu.
[20:24] <wbgs_gaming> sarnold I was thinking of making a my own distro but i need more help if I dont get linux running good then i might as well as throw my pc out lol
[20:25] <wbgs_gaming> could I use Ubuntu as base for open box style distro also might run low latency kernel
[20:25] <sarnold> wbgs_gaming: yeah, there's no need for that :) you just need to make sure you get your windowmanager of choice installed...
[20:25] <sarnold> wbgs_gaming: you sure could
[20:25] <wbgs_gaming> sarnold you a dev
[20:26] <sarnold> wbgs_gaming: but making a new distribution is a fair amount of work.
[20:26] <wbgs_gaming> I think ubuntu tweak can uninstall useless apps right
[20:27] <wbgs_gaming> i wanna strip ubuntu down to its core and just have a menu where you can choose to install games in teh repositroy and when steam release have that there along side POL
[20:28] <wbgs_gaming> the liter te kernel the better
[20:28] <wbgs_gaming> we re only focusing on browsing the net and gaming -_-
[20:29] <wbgs_gaming> the distro should be under 500mb
[20:30] <ogra-cb> use lubuntu then
[20:31] <sarnold> https://wiki.ubuntu.com/Core -- ~20 megabytes
[20:31] <ogra-cb> it has an openbox install that you can pick as your default desktop on the login manager
[20:31] <ogra-cb> and its under 500M
[20:31] <sarnold> you get to pick exactly what you want. :)
[20:31] <ogra-cb> no
[20:31] <ogra-cb> dont use ubuntu-core
[20:31] <wbgs_gaming> sarnold any how thanks alot for your help I think ill reinstall ubuntu and try my idea DE's lag my pc also Lubuntu has errors all the time in 12.10 and the graphics preformence is junk with AMD
[20:31] <ogra-cb> unless you know exactly what you are doing
[20:31] <sarnold> wow
[20:31] <wbgs_gaming> what you reconmend
[20:31] <sarnold> wbgs_gaming: try lubuntu first.
[20:32] <wbgs_gaming> sarnold already have
[20:32] <ogra-cb> well, you could do a cmonnadline install using the mini iso, then install openbox and xorg and be done
[20:32] <ogra-cb> *commandline
[20:32] <wbgs_gaming> sarnold Xubuntu is what i like but snap to screen is a pain alwasy enabling and teh AMD graphics dont preform up to par
[20:33] <sarnold> wbgs_gaming: indeed, amd has historically been a pretty poor partner
[20:33] <wbgs_gaming> well on all the ubuntu distros AMD has not preformed upto par
[20:33] <sarnold> wbgs_gaming: nvidia has done better, if you don't mind running proprietary drivers
[20:33] <sarnold> s/ubuntu/linux/
[20:34] <wbgs_gaming> well i am not gona switch to nvidia just to run Linux lmao
[20:34] <sarnold> intel's drivers on the other hand are open and good.
[20:34] <sarnold> their performance may not be nvidia, but I'd pick intel every time. they're a good partner. :D
[20:34] <wbgs_gaming> not as powerfull and again that requires me buying another pc
[20:35] <wbgs_gaming> the only soulution is openbox too bad there aint a flavour of that ubuntu has every thing but that
[20:36] <wbgs_gaming> any how i am gona reinstall my ubuntu i burned it too fast before i am gona try it agian see how it goes.
[20:38] <wbgs_gaming> sarnold thansk alot and ttyl
[20:39] <sarnold> have fun wbgs_gaming :)
[21:05] <Logan_> vila: Are you around?
[21:32] <achiang> does ubuntu ship valgrind suppression files anywhere?
[21:39] <jtaylor> achiang: pkg -L valgrind | grep supp
[21:39] <jtaylor> dpkg
[21:40] <achiang> jtaylor: hm, let me ask another way. i want to ship a suppression file for fontconfig. is there a standard way to do so?
[21:42] <jtaylor> achiang: python3 places a file in the valgrind folder
[21:42] <achiang> ah, ok
[21:42] <jtaylor> but I kind of doubt that is really how it should be done
[21:42] <jtaylor> a valgrind.supp.d folder would be nice
[21:43] <jtaylor> better ask the valgrind maintainers
[21:45] <infinity> Looks like they go in /usr/lib/valgrind/${package}.supp
[21:45] <infinity> Seems reasonable.
[21:45] <infinity> Don't know why you'd need another level of abstraction.
[21:45] <infinity> achiang: ^
[21:46] <jtaylor> infinity: we have .d folders for so much why not for this too?
[21:46] <infinity> Why would it need one?
[21:46] <achiang> infinity: yep, i'm playing with ${package}.supp now
[21:46] <jtaylor> consistency
[21:46] <jtaylor> if I wouldn't have found python3 in there I would never have guessed that that works
[21:47] <jtaylor> (if it even works, did not test it)
[21:48] <achiang> strange, i dropped fontconfig.supp into /usr/lib/valgrind and it doesn't seem to get autoloaded (or used or whatever)
[21:49] <jtaylor> I'll file a bug in valgrind, at least a clear strategy for package should be documented
[21:49] <infinity>        --suppressions=<filename> [default: $PREFIX/lib/valgrind/default.supp]
[21:49] <achiang> ok, /usr/bin/valgrind is a wrapper
[21:49] <infinity>            Specifies an extra file from which to read descriptions of errors to suppress. You may
[21:49] <infinity>            use up to 100 extra suppression files.
[21:49] <infinity> ^-- I see no mention that they'll be autoloaded (except for default)
[21:49] <achiang> that calls valgrind with a --suppressions arg
[21:50] <achiang> for the libc-dbg package
[21:50] <infinity> Right, but it's not going to autodetect all others.
[21:50] <achiang> nod
[21:50] <infinity> Maybe it could/should?  I dunno.
[21:50] <achiang> well... so here's the thing
[21:51] <achiang> we want to recommend to lots of people to start valgrinding packages everywhere for the nexus7
[21:51] <achiang> but i don't want to be flooded with false positives
[21:51] <infinity> Are suppression files sufficiently well namespaced that they can't clash/conflict?
[21:51] <jpds> jtaylor: Erm, .d is for a configuration file that can be split into other configuration files.
[21:51] <achiang> i can write suppression files, but it would be super nice if valgrind would automatically use them
[21:51] <infinity> If not, then autoloading /usr/lib/valgrind/*.supp would be a losing strategy.
[21:52] <jtaylor> jpds: kind of applies to suppression files
[21:52] <achiang> no clue really, which is why i'm asking here. :)
[21:52] <jtaylor> jpds: you can cat them together or just add multiple --suppression args
[21:52] <infinity> jpds: I could see an argument for moving suppressions to /usr/lib/valgrind/suppressions/, but that would not only require patching valgrind, but every package that already ships the other way.
[21:53] <infinity> Which doesn't seem like a win, just for aesthetics.
[21:53] <achiang> ignoring the aesthetics question for now, how about simple tractability? the namespace issue seems annoying (but not insurmountable)
[21:53] <jtaylor> btw someone should merge valgrind from unstable
[21:54]  * jtaylor hides
[21:54] <infinity> achiang: The file namespace is clear, it's $package.supp, and we can't have conflicting package names.
[21:54] <jtaylor> infinity: what is with user suppressions?
[21:55] <infinity> jtaylor: Those tend to be in your build directory.
[21:55] <achiang> infinity: nod. i'd agree with that
[21:55] <jtaylor> there are reasons to have those system wide
[21:55] <jtaylor> though probably rare
[21:55] <achiang> the next question is, how to make valgrind magically use them
[21:56] <achiang> i don't want a situation where well-intentioned (but not super technical) folks flood LP with bogus reports
[21:57] <jtaylor> achiang: if lib/valgrind/ does not work then file a bug
[21:57] <jtaylor> to me it looks like a useful feature
[21:57] <infinity> achiang: The wrapper could be changed to walk /usr/lib/valgrind/*.supp and use them all, I'm just unsure if that's a good idea.
[21:58] <infinity> I don't know enough about valgrind suppressions to say one way or the other if you actually always want them all loaded.
[21:58] <achiang> jtaylor: see above, i wrote a fontconfig.supp and put it into /usr/lib/valgrind, but it doesn't get autoloaded. and i think i agree somewhat w/infinity that it might not be a good idea
[21:59] <achiang> maybe a better way to do this would be to write a user-friendly valgrind wrapper that knows to load specific suppression files based on the app you're profiling. except that's signing up for a *lot* of manual maintenance
[21:59] <infinity> achiang: Actually, that wouldn't be wildly difficult.
[22:00] <achiang> sketch an outline for me?
[22:00] <achiang> see also discussion here - https://code.launchpad.net/~achiang/ubuntu-nexus7/valgrind-ubuntu-dbg-packages/+merge/134841
[22:00] <infinity> achiang: Well, for C, it's easy.  Parse ldd output, trace owners of libraries to map lib->package, add $package.supp to command line.
[22:01] <achiang> maybe some sort of apport wrapper thingy that not only installs the -dbg packages but also adds $package.supp to cmdline?
[22:01] <infinity> achiang: For interpreted languages, a bit stickier, you'd need to parse the dpkg depends for the package, since there's no simple way to know all the deps of a shell script, for instance.
[22:02] <infinity> apport-retrace does indeed have most of the magic already, perhaps it could be leveraged for valgrindiness too.
[22:02] <achiang> infinity: i don't mind doing a simple thing first and then iterating to something fancy later
[22:02] <infinity> Since it also handles debug symbols and the like.
[22:04] <infinity> pitti / ev / bdmurray: Opinions on the suitability of genericising apport-retrace to also do valgrind dep-tracking magic?
[22:04] <achiang> but we run apport-retrace on the server side, right? i'd want something that's dead simple for users to run... the end goal is: ./wrapper <app> => *useful* log to upload to LP
[22:04] <achiang> (without multiple rtts)
[22:05] <infinity> achiang: It can be run locally too.  Some people do.
[22:06] <infinity> achiang: But this is more about possibly refactoring its dependency tracing and ddeb-installing magic, so it could be used in a valgrind wrapper, not really about retracing.
[22:06] <infinity> But writing code twice seems silly.
[22:06] <achiang> libnih? ;)
[22:06] <infinity> Not my project. :P
[22:06] <achiang> but yeah, +1 to code reuse
[22:06] <infinity> I'm a glibc maintainer, I believe in improving on old codebases, obviously.
[22:07] <infinity> (We'll ignore the ancient history of libc4 and libc5...)
[22:10] <achiang> infinity: looks like pitti is suggesting exactly that -- apport-valgrind <package>
[22:10] <infinity> achiang: Great minds and/or fools.
[22:10] <achiang> https://code.launchpad.net/~achiang/ubuntu-nexus7/valgrind-ubuntu-dbg-packages/+merge/134841/comments/291330
[22:11] <achiang> guess i should go stare at apport code
[22:12] <achiang> oh, oops, it was actually this comment where he suggests it - https://code.launchpad.net/~achiang/ubuntu-nexus7/valgrind-ubuntu-dbg-packages/+merge/134841/comments/291343
[22:14] <infinity> achiang: Right, of course that should be "apport-valgrind <binary> -- -args" with apport figuring out the package itself, but otherwise I agree that seems a sane way to go.
[22:16] <achiang> infinity: so not being entirely familiar w/apport, would someone be able to have a long running process in the -S sandbox?
[22:20] <infinity> achiang: I'm not hugely familiar with it myself, but I don't see why it wouldn't be possible.
[22:20] <infinity> achiang: Though, sandboxing may be overkill.  apport can do sandbox-free as well, I believe?
[22:21] <infinity> achiang: Just means removing the ddebs/-dbgs you install, instead of blatting a sandbox chroot.
[22:21]  * slangasek looks around for the library that libnih is redundant with ;)
[22:22] <infinity> slangasek: Possibly glib?
[22:22] <slangasek> I think that might've been the joke, but I know I'd much rather use libnih than glib
[22:22] <infinity> slangasek: Wasn't the intent to write a slimmer and more targetted glib, to avoid having glib as a low-level system dep, and then glib ended up a low-level dep of everything else anyway?
[22:22] <slangasek> it didn't
[22:22] <slangasek> not at that level
[22:23] <infinity> Pretty close.  It's required on Debian/Ubuntu.
[22:24] <slangasek> hmm, that appears to be a bug?
[22:24] <slangasek> I don't see any Prio: required revdeps in Ubuntu
[22:24] <infinity> udev?
[22:24] <slangasek> nope
[22:24] <infinity> Yep...
[22:24] <slangasek> though that reminds me, I should probably see about getting libjson moved to /lib before I reboot again
[22:24] <slangasek> libjsonc
[22:25] <slangasek> ah, udev does depend on it, weird that grep-available doesn't know this
[22:26] <slangasek> ok, so *why* does udev depend on glib? :)
[22:27] <infinity> Looks like a ton of the utils in /lib/udev link it.
[22:28] <slangasek> only /lib/udev/udev-acl
[22:29] <infinity> slangasek: You and I have divergent definitions of "only".
[22:29] <infinity> slangasek: http://paste.ubuntu.com/1380670/
[22:30] <slangasek> infinity: only one of those is from the udev package
[22:30] <infinity> Ahh.
[22:30] <infinity> Fair enough.
[22:30] <slangasek> the rest are hooks to the crazy train
[22:33] <infinity> Seems like mostly a non-issue since any sufficiently interesting system will have glib installed anyway.
[22:33] <infinity> Though, if that's the only thing dragging it into initrds as well, that's a bit irksome.
[23:18] <mspencer> Is this a good channel to ask questions about quickly?
[23:19] <bkerensa> mspencer: #quickly might be more adequate
[23:19] <mspencer> bkerensa: Thanks, I didn't know there was a specific channel.