[03:35] <pitti> Good morning
[03:41] <Unit193> pitti: Howdy.
[03:41] <pitti> hey Unit193, how are you?
[03:42] <Unit193> Stiiiilll alive.
[03:42] <Unit193> You?
[03:42] <pitti> infinity: how much can I rely on C.UTF-8 being present these days? I'd like to move autopkgtest's default C locale to that, as it's much more realistic
[03:42] <pitti> Unit193: very much alive, although still a bit tired (it's early)
[03:43] <infinity> pitti: It's shipped with libc-bin, it better always be there. :P
[03:43] <Unit193> Heh, yeah.  You normally come on 1-2am my time.
[03:43] <pitti> infinity: I don't see it yet in lucid/squeeze, but everywhere from precise/wheezy on; from these, will it always be there, or can the admin disable it?
[03:43] <pitti> infinity: ah, good :)
[03:44] <infinity> pitti: And yeah, wheezy/precise and onward.
[04:58] <slangasek> infinity: so when does C.UTF-8 become the default in the installer+
[04:58] <slangasek> ?
[05:00] <infinity> slangasek: You mean the default if nothing else is selected?  I want to do that this cycle.
[05:00] <infinity> TheMuso: Were you planning on dropping alsa-driver in favour of alsa-base at some point?
[05:01] <infinity> TheMuso: (This came up with a kmod merge that has a versioned Breaks on alsa-base and expects the jessie/sid versions)
[05:05] <infinity> TheMuso: Hrm, maybe I can just ignore it for now, since we don't install Debian's aliases files in kmod anyway.  But we should revisit this.
[05:06] <TheMuso> infinity: Yeah, I was planning on doing that swap at some point, seems like a rather delicate dance given the inter-dependencies.
[05:10] <infinity> TheMuso: Right, looks like alsa-base in Debian has gone completely empty, so we need to sort out what needs moving where and make it work for us.
[05:11] <infinity> TheMuso: But for now, I'm just dropping the Breaks from kmod, since we don't ship the conflicting aliases either. :P
[05:13] <TheMuso> Ok.
[05:14] <TheMuso> infinity: alsa-base in debian is just a transitional dummy package to remove old conf files, everything module alias wise for alsa is now in kmod.
[05:15] <TheMuso> I think we just need to remove alsa-driver from the archive, and sync alsa-base, given that alsa-driver and alsa-base source packages both share the same binary package namespace.
[05:16] <infinity> TheMuso: Right.  Our alsa-base has some other junk in it, though, so I guess we sort out where that goes, or if we care anymore.
[05:16] <infinity> TheMuso: I'll leave it to you to investigate which bits we care about and why, and we can move things around and follow Debian's lead.
[05:17] <infinity> TheMuso: Please poke me before you abuse kmod, though. ;)
[05:17] <TheMuso> Yeah, I don't *think* we care about that any more, given all that stuff is kernel anyway, but I'd ahve to check.
[05:17] <TheMuso> infinity: I have no intension of doing so. I'd rather work this through with an archive admin and a kmod maintainer to make sure things don't break.
[05:18] <infinity> TheMuso: I happen to be both of those things. :)
[05:18] <TheMuso> i.e I don't plan to do a thing until action is planned, and acted upon.
[05:18] <infinity> TheMuso: So, sometime that's not 11pm for me, let's play.
[05:18] <TheMuso> infinity: Sounds good, maybe if I poke you first thing in my AM. That would be about 4 PM for you or there abouts...
[05:19] <infinity> TheMuso: *nod*
[05:19] <TheMuso> Not necessarily tomorrow AM, but as the first task for a morning for me.
[05:19] <infinity> TheMuso: Yeah, no massive rush, just so long as we don't forget about it for 3 cycles.
[05:20] <TheMuso> infinity: Sure, i'm just helping updating alsa in debian svn, and looking to get testing packages ready for Ubuntu, so its in my sights currently. Will skim alsa-driver and get back to you soonish as to taking action on the core bits.
[06:25] <mvo> hallyn: sure, I sponsor netcf now
[06:42] <dholbach> good morning
[08:53] <popey> cjwatson: are you the only person about with live-build super cow powers? I am having an odd issue on trusty where sudo lb build doesn't bind-mount /dev so fails early on.. http://paste.ubuntu.com/7694146/ any ideas or someone else I can poke?
[08:59] <cjwatson> popey: Don't know, not run into that; you're not running under confinement or lxc or something maybe?
[09:07] <popey> cjwatson: no, just a bog standard trusty laptop (with luks). I bind mounted /dev in the chroot manually while it was in flight and its continuing now.
[09:08] <popey> cjwatson: looking for a pre-chroot hook now to manually fudge that during the build of the choot.
[09:20] <popey> cjwatson: is the config used by live-build to build an ubuntu iso publicly available - i presume it's modified from the skeleton you get from "lb config"?
[09:21] <cjwatson> popey: it's in livecd-rootfs
[09:21] <cjwatson> popey: https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html
[09:22] <popey> thanks cjwatson
[09:23] <cjwatson> Theoretically you can even set up a local Launchpad instance now to drive it, though that's probably a bit much for casual use :)
[09:24] <ogra_> cjwatson, is the new build infra more strict ? it feels like we get a lot more build failures with it
[09:25] <popey> hah
[09:26] <popey> yeah, i just want to run live-build locally to create an ubuntu iso, to prove it works, then futz around with it adding/removing packages
[09:26] <cjwatson> ogra_: No, there's just a couple of bugs I'm working through
[09:27] <ogra_> ah, k
[09:27] <cjwatson> ogra_: Most of the failures are from trusty images, which weren't building before so you don't have a good basis for comparison there :)
[09:27] <cjwatson> That's bug 1325281
[09:27] <ogra_> ah, yeah, i saw the uploads
[09:28] <ogra_> (or upload and seed change rather :) )
[09:31] <cjwatson> But at least now I have a way to test livecd-rootfs on our infrastructure without having to upload it to Ubuntu first \o/
[09:31] <cjwatson> (Though for the time being it requires a devirtualised PPA)
[09:32] <ogra_> cool !
[09:32] <cjwatson> And I can cancel livefs builds ... I like my new toys
[09:33] <xnox> winter's coming soon =)
[09:35] <popey> cjwatson: hm, using livecd-rootfs it also craps out because dev isn't mounted ⍨
[09:35] <cjwatson> ogra_: Ah, I see you updated touch-image-monitor, thanks
[09:35] <ogra_> yeah, missed to set the stamp
[09:36] <cjwatson> popey: try 'sudo lb clean' and then start afresh
[09:36] <cjwatson> just in case there's something left over from before
[09:37] <cjwatson> maybe also 'sudo lb clean --cache'
[09:37] <cjwatson> But I'm guessing, as I say this has worked for me not that long ago and we use it on our infrastructure
[09:38] <cjwatson> You can see the exact things we run in lp:launchpad-buildd
[09:38] <popey> k
[09:38] <cjwatson> (buildlivefs)
[09:48] <sil2100> doko: morning!
[09:49] <sil2100> doko: did you have a moment to quickly browse through the debdiff of the opal package? I would like to upload it if possible
[09:51] <sil2100> cjwatson: I guess the opal merge is so straightforward that maybe I could simply upload it?
[09:51] <cjwatson> no idea whether it's straightforward or not :)
[09:52] <cjwatson> I normally do prefer to wait for the touched-it-last person if at all possible
[09:52] <sil2100> cjwatson: ok ;)
[09:52]  * sil2100 waits a bit for mister doko still
[09:52] <cjwatson> (for my own uploads too, not just when sponsoring)
[09:56] <doko> sil2100, my upload was a no-change rebuild, so please go ahead
[09:57] <sil2100> doko: thanks o/
[09:58] <popey> cjwatson: that seems to have helped, thanks.
[09:58] <cjwatson> sil2100: just general advice on merges, I usually find it helpful to debdiff against both the last version in Ubuntu and the being-merged version from Debian
[09:58] <cjwatson> have caught a number of my own mistakes that way
[09:58] <infinity> sil2100: doko's comment implies that you're probably asking the wrong person. ;)
[09:59] <infinity> sil2100: The last uploader who did real changes was crimsun.
[09:59] <mlankhorst> any idea how this can happen btw? https://bugs.launchpad.net/ubuntu/+source/xorg-lts-transitional/+bug/1310093
[09:59] <cjwatson> infinity: I usually ask the actual last uploader simply because that matches merge-o-matic assignments and thus likely pending work
[10:00] <cjwatson> I think that's sufficient for the locking protocol, such as it is
[10:00] <infinity> cjwatson: Fair enough.  I tend to ask the last person who actually abused the package, not because I care deeply about locking, but because they have context on what they mangled and why.
[10:00] <infinity> I guess we all have our own method and madness. ;)
[10:01] <cjwatson> Depends on the changes; as sil2100 says, these ones aren't overly complex
[10:01] <infinity> Though, crimsun seems to have been mysteriously inactive since April 07... :/
[10:01] <sil2100> In this case the merged changes is only the addition of one patch that actually fixes a FTBFS with libav10
[10:02] <infinity> sil2100: Fair enough, yeah.
[10:02] <sil2100> infinity, cjwatson: thanks guys :)
[10:13] <mlankhorst> can someone sponsor https://mblankhorst.nl/etc/xorg-lts-transitional_6.tar.gz ? there's a debdiff too but it doesn't handle the symlinks for trusty postinst very well. :-)
[10:29] <popey> cjwatson: am I right in assuming utopic is built on trusty? (seems syslinux has been updated in utopic and the chain.c32 files have become more numerous and moved)
[10:29] <rbasak> doko: any chance of a pycurl merge please? We want one to sync python-tornado, which ScottK points out we can probably do with the latest pycurl.
[10:29] <rbasak> doko: or I can take a look, but the floating point SSE Ubuntu delta that we carry scares me a little.
[10:30] <rbasak> (and I'll need a sponsor)
[10:30]  * popey stabs lzcat also
[10:33] <popey> or indeed, to our builders run precise?
[10:34] <rbasak> popey: I have no idea about images, but our builders run a chroot that is periodically updated against the release itself. So utopic builds on utopic. Otherwise build-deps wouldn't work.
[10:36] <popey> rbasak: I'm talking about the host that live-build runs on, I expect the chroots to be $TARGET_RELEASE.. is that different?
[10:36] <rbasak> That I don't know, sorry.
[10:36] <popey> np, thanks
[10:37] <doko> rbasak, won't do it today, just keep the existing patch
[10:37] <rbasak> doko: OK, I'll take a look and stick it in the sponsorship queue and keep the existing patch - thanks
[11:23] <sil2100> Hey, did anyone try upgrading from trusty to utopic today?
[11:24] <infinity> popey: utopic builds on utopic, but if you're building ISOs with live-build, we don't do that.  We only use it to build the livefs (ie: the squashfs bit).
[11:26] <seb128> sil2100, you and have an experience to share?
[11:26] <popey> infinity: oh. i didn't realise that. what builds the isos?
[11:27] <infinity> popey: debian-cd, shoestring, and bubblegum.
[11:27] <sil2100> seb128: not sure what exactly happened yet, but apt-get dist-upgrade failed and I get tons of insserv warnings and errors during package configuration stage
[11:28] <seb128> sil2100, can you pastebin those?
[11:28] <popey> infinity: ☻ is this documented anywhere (hopeful I know)
[11:28] <sil2100> seb128: sure, let me pastebin some of the outputs, one moment
[11:28] <darkxst> popey, a terribly complex set of scripts, if you are wanting to just build stock trusty images it should be fine
[11:28] <darkxst> but if you want custom images, maybe easier to just use genisoimage
[11:28] <infinity> popey: The code is public, the documentation is lacking.
[11:28] <popey> I am trying to build a stock utopic image, from which to then start fettling the packages to make a simple derivative
[11:29] <darkxst> popey, livefs uses seeds which you can't alter for custom stuff
[11:29] <popey> but I can make my own seeds right?
[11:29] <popey> and point live cd at those seeds
[11:29] <popey> i mean, point live-build at those seeds
[11:30] <darkxst> popey, the actually it uses tasks generated from the seeds
[11:30] <darkxst> and you can't make them
[11:30] <popey> why?
[11:30] <sil2100> seb128: http://paste.ubuntu.com/7694686/ <- this is the output of my second dist-upgrade after the failure
[11:30] <darkxst> popey they are encoded into the archive Packages.gz file,
[11:31] <sil2100> seb128: here's what happens when I try apt-get -f install: http://paste.ubuntu.com/7694687/
[11:31] <popey> oof
[11:31] <seb128> sil2100, urg
[11:31] <darkxst> popey, you could make a seed, generate a meta package and then copy those package sets into live-build I guess
[11:31] <Laney> you can make livecd-rootfs install the metapackage instead of using the task
[11:32] <sil2100> I wonder if just my system was screwed or it's an overall problem
[11:32] <seb128> xnox, pitti: do you have any idea about sil2100's log? seems init system related
[11:32] <popey> so I probably don't want the ubuntu-desktop (for example) task, but a different set of packages entirely.
[11:32] <popey> build from ubuntu-minimal up, and perhaps make my own task.
[11:33] <darkxst> popey, you can't make a task
[11:33] <popey> ok, meta-package?
[11:33] <popey> apologies for my newbieness ☻
[11:33] <popey> but having trouble just proving that I can build a simple bog standard live cd first, to ensure the tools work
[11:34] <seb128> sil2100, lot of that log is vmware, I wonder if it installs file that confuse things
[11:34] <seb128> "insserv: Service mountkernfs has to be enabled to start service udev"
[11:34] <darkxst> popey, have a look in config/package-lists, the offical build use apt-cache to generate the package list based on task
[11:35] <darkxst> you should replace the ubuntu-desktop line, with you full list of packages
[11:35] <popey> e.g. the live-build process builds an iso, but that wont boot because it can't find /casper/vmlinuz, which may or may not be related to a missing variable somewhere, as all the filenames it generated have .. in the middle, indicating a missing something
[11:35] <popey> e.g. -rw-r--r--  2 root root 838M Jun 24 12:20 livecd..squashfs
[11:35] <darkxst> popey, that is not an iso
[11:35] <popey> no, it isn't an isi
[11:35] <popey> *iso
[11:36] <popey> it's just one of the files, all of which are missing something
[11:36] <sil2100> I wonder, it's been such a long time ago since I actually used vmware, I even forgot I had it
[11:36] <popey> http://paste.ubuntu.com/7694721/
[11:36] <popey> see ^^
[11:36] <popey> seems to be missing something, but I don't know what.
[11:36] <darkxst> you can't boot a squashfs!
[11:36] <popey> I didnt say I could
[11:37] <popey> it also built a livecd..iso and binary.iso
[11:37] <seb128> sil2100, that seems like a bug we should look at in any case, but not sure what to blame, I would like to heard back from some init system people on that one
[11:37] <popey> the binary.iso boots in qemu but fails to find casper/vmlinuz
[11:37] <popey> http://paste.ubuntu.com/7694727/ is the contents of the casper folder on the ISO...
[11:38] <darkxst> popey, live-build isos don't work on Ubuntu
[11:38] <popey> which seems to be missing the initrd/vmlinuz symlinks
[11:38] <popey> ☹
[11:38] <darkxst> you can make a working iso from the sqaushfs using genisoimage
[11:39] <seb128> popey, you can try using http://people.canonical.com/~laney/random-scripts/build-ubuntu-iso which is what Laney did for the unity8 iso before we had it integrated
[11:39] <sil2100> seb128: ok, I'll keep poking them as well, for now I'll try looking into it myself as well
[11:39] <popey> thanks seb128
[11:39] <seb128> popey, you need changes to livecd-rootfs to add you flavor if you do that
[11:39] <popey> that looks very helpful.
[11:39] <popey> thank you.
[11:40] <sil2100> pitti, xnox: once you're around I would appreciate some expertise help
[11:41] <darkxst> seb128, that only works for official flavours
[11:41] <pitti> sil2100: hey
[11:42] <darkxst> (well atleast the task based stuff that livecd uses)
[11:42] <pitti> sil2100: which package ships /etc/init.d/vmware-USBArbitrator ?
[11:42] <seb128> darkxst, the script is able to use a ppa, we built iso for unity8 with that before being "official"
[11:42] <pitti> sil2100: looks like this has a broken or absent LSB header, but the log is a bit self-contradictory
[11:42] <sil2100> Let me check
[11:43] <darkxst> seb128, you can add a ppa via EXTRA_PPAS
[11:43] <seb128> pitti, the second log he shared has ""insserv: Service mountkernfs has to be enabled to start service udev""
[11:43] <Laney> that's newer than this work, but indeed you can
[11:43] <sil2100> pitti: huh, seems to be some leftover
[11:43] <darkxst> but the tasks come from apt-cache, so if there are package changes that needs to be manually generated
[11:43] <sil2100> Not shipped by anything
[11:43] <seb128> sil2100, don't delete it, move it away, in case it's useful for debugging
[11:43] <sil2100> seb128: let me try that
[11:44] <Laney> you just can't use tasks, but if you generate a meta package then you can install that instead
[11:44] <pitti> sil2100: right, putting it into some pastebin would be useful for reproducing
[11:45] <pitti> sil2100: supposedly some VMware third-party package installed it dynamically?
[11:45] <sil2100> pitti: might be, but I wouldn't remember as it's been such a long time when I installed this actually...
[11:46] <sil2100> It seems to have helped, let me pastebin the script anyway
[11:47] <pitti> sil2100: ok, glad to hear it's at least unbroken again :)
[11:47]  * pitti toddles off for some lunch then, bbl
[11:47] <sil2100> pitti: thanks! :)
[11:50] <popey> Laney: gotcha
[11:51] <siretart> cjwatson: I guess that libavfilter-dev should in addition also depend on libswscale-dev, I'll add both libavresample-dev and libswscale-dev to libavfilter-dev's dependencies for the next upload
[11:51] <siretart> thanks!
[11:52] <seb128> sil2100, was that enough to restore sanity?
[11:52] <popey> Laney: did you run that script on trusty or utopic?
[11:52] <Laney> I was building U on U
[11:52] <popey> ok
[11:53] <sil2100> seb128: yes! Well, I'll give you guys an update once it finishes the upgrade, but it seems to have helped for now - and the file didn't seem to have been used at all since some time anyway
[11:58] <seb128> sil2100, right, it means the system is not robust to "buggy" scripts though
[13:14] <jamespage> infinity, do backports build with backports enabled yet?  just thinking about how we might get docker 1.0 back to trusty
[13:15] <cjwatson> jamespage: yes
[13:15] <cjwatson> https://bugs.launchpad.net/launchpad/+bug/888665
[13:15] <jamespage> cjwatson, ah - great - thanks!
[13:16] <cjwatson> We do fix buildd bugs sometimes :-)
[13:17] <infinity> jamespage: Why would docker need to build with backports?
[13:17] <jamespage> infinity, cause it needs a few extra new go dependencies - and they are all packaged as per policy in Debian
[13:17] <infinity> jamespage: Also, I think we're pretty intent on SRUing it, not putting it in backports (which is why I already SRUed docker/wmdocker).
[13:18] <jamespage> infinity, oh - ok
[13:18] <jamespage> I did not know that
[13:18] <jamespage> I saw it was SRU'ed
[13:19] <jamespage> infinity, docker 1.0 needs two extra dependencies and bumps on another four afaict
[13:19] <infinity> jamespage: We'll discuss how to sort that out, this is an ongoing thing.
[13:20] <jamespage> infinity, is there a bug or anything yet?
[13:21] <infinity> jamespage: Unsure.  Might ask kirkland.  I was working with paultag to make sure it was all sane in Debian (which it should be now) and starting things going in Ubuntu.
[13:22] <cjwatson> Riddell: Want me to sort out the opencv/arm64 thing?
[13:22] <Riddell> cjwatson: I have it compiling on my pandaboard here
[13:23] <Riddell> although still at 3%, I wonder if I should just upload
[13:24] <cjwatson> Presumably the rules diff is obviously confined to arm64 and so compiling on a pandaboard won't reveal anything interesting
[13:24] <cjwatson> (Please don't disable precompiled headers across the board, it's only needed temporarily on arm64)
[13:25] <hallyn> mvo: thanks!
[13:26] <Riddell> cjwatson: good point, I'll upload
[13:26] <infinity> cjwatson: "temporarily"... We seem to be spreading that temporary hack far and wide. :/
[13:26] <cjwatson> Yeah, I know :-/
[13:27] <cjwatson> Hopefully we can grep -changes for it to undo
[13:27] <cjwatson> I think it's still only on the order of 10 or 20 packages though
[13:35] <popey> Laney: your funky iso maker script is great. Did you experience an issue where it barfed looking for isolinux.bin or various .c32 files? We had to do some funky symlinking as syslinux 6 has moved those files.
[13:36] <Laney> nope, never saw that
[13:36] <popey> wonder if you ran it before syslinux 6 hit utopic?
[13:38] <cjwatson> most things that care about syslinux file locations need to be adjusted, indeed.
[13:39] <seb128> Laney, popey: hey, that was before syslinux 6
[13:45] <popey> yeah, it'll break when you run it again with syslinux6 in our experience
[13:48] <psusi> infinity: that util-linux get delayed in the upload queue? ;)
[13:51] <psusi> so if I understand udev correctly, ATTRS{} will search for a file with that name up the sysfs directory tree recursively... but what if you need to branch back down another path?  i.e. from the disk block device yuo go up several levels to ata1, then have to go back down into ata_port/ata1 to get to the port_no attribute, so how can you get a udev rule to match on that?
[14:01] <cjwatson> doko: Do you still have any interest in the fdupes output in livefs build logs?  You added it back in gutsy, but since then limits on image sizes have increased, and I'm not sure anyone's looked at that output for a while; if anyone still cares perhaps it could be run separately from the main build.  It adds quite a lot to the size of the build logs ...
[14:01] <cjwatson> So was wondering if I could get rid of it
[14:02] <doko> cjwatson, no, don't care for it anymore
[14:03] <cjwatson> doko: OK, thanks, will kill it off next time I'm uploading livecd-rootfs
[14:03] <psusi> cjwatson: does anyone else work on debian-installer that could apply those patches so we can unblock the parted 3 transition?  I hate to keep pestering you about it when I know you are so busy... as soon as I get an authorization issue sorted with the gnu ftp servers I'm going to release parted 3.2
[14:03] <cjwatson> I think they're all leaving it to me :)
[14:03] <psusi> I got that feeling ;)
[14:05] <cjwatson> I'm just finishing the livefs-in-LP project now, so we'll see
[14:05] <cjwatson> (Tidying up a few loose ends)
[14:07]  * psusi checks how long until utopic freeze
[14:33] <kirkland> jamespage: infinity: hey guys, yeah, docker was what I was pinging you about late yesterday
[14:33] <cjwatson> Riddell: That evidently didn't work - want me to have a play on arm64 hw?
[14:33] <kirkland> jamespage: the goal, is as infinity says, to have docker 1.0 SRU'd
[14:34] <jamespage> kirkland, OK
[14:34] <jamespage> kirkland, as you appear to have it in hand let me know if you need me todo anything
[14:35] <kirkland> jamespage: excellent, thanks, will do
[14:35] <kirkland> jamespage: glad to see you interested and on board
[14:35] <jamespage> kirkland, I started thinking about it this morning - but I see folks are ahead of me!
[14:35] <kirkland> infinity: I see docker 1.0 landed in Utopic two weeks ago
[14:35] <kirkland> jamespage: :-)
[14:43] <andrewrk> psusi, august 7. I've been keeping an eye on that too :)
[15:12] <bdmurray> Laney: can you have a look at bug 1333627?
[15:13] <Laney> bdmurray: Doesn't sound like it's strictly a problem caused by the update?
[15:18] <Laney> bdmurray: Looks like dpkg puts the symlinks back
[15:18] <Laney> Feels like any fix ought to be there?
[15:24] <Riddell> cjwatson: yeah please
[15:25] <bdmurray> Laney: ah, yeah it doesn't seem to be related to that specific update at all
[15:26] <Laney> bdmurray: if you remove one and then reinstall the deb it gets put back
[15:27] <bdmurray> Laney: right, so not a regression
[15:28] <Laney> no, but still a problem it seems
[15:40] <pitti> kees, slangasek, stgraber: reminder, TB meeting in 20 mins in #u-m-2
[17:21] <popey> cjwatson: do you need me to file a bug in live-build (it symlinks to files like *.c32 that have moved in syslinux 6.x)
[17:23] <cjwatson> popey: Sure, otherwise it's unlikely I'd fix it since we don't use that code :)
[17:23] <popey> heh
[18:13] <ScottK> seb128: You're elfutils arm64 FTBFS seems to be blocking some other stuff.
[18:17] <LocutusOfBorg1> sil2100, you there?
[18:17] <LocutusOfBorg1> still waiting for lucene++ :(
[18:18] <LocutusOfBorg1> I uploaded poedit (old version) in mentors
[18:18] <LocutusOfBorg1> I hope to update it soon with lucene :)
[18:39] <sil2100> LocutusOfBorg1: hey! I'll look for a sponsor soon :)
[18:41] <LocutusOfBorg1> wonderful, let me know if you need a sponsor
[20:01] <seb128> ScottK, sorry about that, I'm unsure how to debug/fix the issue though, I just merged on Debian and it built locally/on the debian archs
[20:15] <brendand> lifeless, ping
[20:33] <lifeless> brendand: hi
[20:33] <brendand> lifeless, did you happen to see my pings yesterday?
[20:34] <brendand> lifeless, or do i need to repeat?
[20:34] <lifeless> brendand: pings?
[20:34] <brendand> lifeless, i have a patch for the skip issue
[20:35] <brendand> lifeless, but i'm not that confident it's right - unit tests do pass though
[20:35] <lifeless> brendand: get it up in a PR on github then :)
[20:35] <lifeless> we'll review it
[20:37] <popey> Could someone please sync latest mate-session-manager from debian? Or tell me what buttons to press to request such a sync?
[20:49] <ScottK> seb128: I don't know either else I'd have just fixed it.  Can you hunt someone down to look at it?
[20:50] <ScottK> popey: We have the same one Debian does.
[20:51] <ScottK> If one was just uploaded the tools don't know about, it'll happen automatically.
[20:53] <seb128> infinity, slangasek: could anyone help to debug elfutils ftbsing on arm64? https://launchpadlibrarian.net/178211279/buildlog_ubuntu-utopic-arm64.elfutils_0.159-2ubuntu1_FAILEDTOBUILD.txt.gz
[20:53] <seb128> "/build/buildd/elfutils-0.159/tests/funcretval: dwfl_module_return_value_location: cannot handle DWARF type description"
[20:53] <seb128> not sure what to do about it (I merged the current Debian version, so the upload has my name on it)
[20:55] <popey> ScottK: sorry. my mistake
[20:55] <ScottK> No problem.
[21:05] <slangasek> seb128: make the Debian maintainer fix it? ;)
[21:05] <slangasek> seb128: arm64 is still in bootstrapping there... #debian-arm could probably help
[21:07] <seb128> slangasek, can we open bugs on the bts about the arm64? not sure how likely that is going to lead to a resolution
[21:07] <seb128> ScottK mentioned it's blocking things from migrating in utopic
[21:08] <slangasek> you certainly can open bugs in the BTS, but the only people realistically who'll work on it are the ARM porters, and for that - #debian-arm
[21:08] <slangasek> or highlighting wookey, maybe
[21:09] <seb128> k
[21:09] <seb128> I'm calling it a day now but can do that tomorrow
[21:09] <seb128> slangasek, thanks
[21:12] <wookey> highlighting meworks
[21:12] <wookey> I noticed elfutils was broke today
[21:12] <wookey> not looked into it yet
[21:13] <wookey> been having an NMU-fest for boring fixes
[21:16] <seb128> wookey, hey, ok, it would be nice if you could have a look to it when you get some free slots ;-)
[21:36] <nectarys> hi, how to make conky effects only appears on desktop. When I have set it to start on the startup of the PC via "conky" command. it's been displayed on the front of all of the windows. How to deal with this, please ?
[22:00] <sarnold> nectarys: does conky come with a manpage that describes options?
[23:43] <rick111> where are the glew files in ubuntu?\
[23:43] <rick111> cant find the opengl libraries anywhere after i installed them via sudo apt-get
[23:44] <sarnold> rick111: apt-file reports some glew-utils or libglew-dev packages
[23:44] <jtaylor> dpkg -S libglew should list their locations
[23:44] <jtaylor> oh its libGLEW
[23:46] <rick111> i found them...
[23:46] <rick111> im coming fromw windows and trying to get opengl up and running on linux
[23:47] <jtaylor> you normally do not need to know the location of system libraries
[23:47] <jtaylor> when linking use -lGLEW and the linker will find them when they are installed
[23:48] <rick111> so i can just compile the programs with gcc -lGLEW filenmae.c
[23:48] <jtaylor> gcc filenmae.c -lGLEW
[23:48] <rick111> but what if im compiling them through an IDE? dont i have to place the file paths somewhere in there?
[23:48] <jtaylor> libraries should always be after objects needing their symbols
[23:49] <jtaylor> depends on how your ide handles it
[23:49] <rick111> inside the code?
[23:49] <jtaylor> on the command line
[23:50] <rick111>  i know. but what about in an IDE? dont i have to know the file path to freeglut and glew libraries to place inside the IDE?
[23:50] <rick111> im using codeblocks
[23:50] <rick111> for the first time
[23:50] <jtaylor> it should be in their documentation
[23:51] <jtaylor> but also ides should not need to know the paths
[23:51] <jtaylor> just the name of the library without extension and lib prefix