[02:16] <MACscr> whats the proper way to limit the number of kernels installed on my ubuntu servers? I only want to keep the newest one and whatever is installed
[02:19] <MACscr> bikeshed seems cool, but for a small server, it it installs way to many packages
[02:21] <pmatulis> MACscr: cron-triggered shell script?
[02:21] <sarnold> I thuoght apt had some clever setting about that
[02:21] <MACscr> i know yum does, but doesnt seem like apt does
[02:38] <pmatulis> MACscr: http://askubuntu.com/questions/563483/why-doesnt-apt-get-autoremove-remove-my-old-kernels perhaps?
[02:41] <MACscr> pmatulis: oh there are tons of ways to do it, but im quite surprised there isnt an official way that doesnt require scripting
[02:41] <sarnold> pmatulis: YES!
[02:41] <sarnold> pmatulis: now why isn't that in the first three pages of google results? heh
[02:50] <RoyK> MACscr: wht the newest kernel?
[02:53] <MACscr> RoyK: not sure. why does it matter?
[02:53] <RoyK> MACscr: the older ones work well too ;)
[02:54] <MACscr> and?
[02:54] <MACscr> i have limited space for the OS storage
[02:54] <MACscr> so want to keep things as minimal as possible
[02:55] <RoyK> a new kernel woon't help that
[02:56] <MACscr> still not sure what that has to do with my question
[04:31] <k2gremlin> Hello all, quick and easy question for you guys. I am trying to setup a br0 interface. I have installed bridge-utils and configured in my /etc/network/interface file. When I try to do ifup br0 it tells me cannot find device br0. Thoughts?
[04:43] <ianorlin> k2gremlin: did you reload the config file?
[04:58] <lordievader> MACscr: Apt should only keep the current and current -1 kernels when running apt-get autoremove.
[05:23] <qman__> MACscr, lordievader: it should, but often doesn't, I'm not sure exactly why. I solved the problem for me by writing a script which removes all but the currently running and most recent kernels, and put it in cron.weekly. https://deadface.org/index.php?p=kernelkeeper
[05:24] <qman__> it's also variant aware, so if you ahve more than one kernel variant (such as -generic and -rt) it manages both variants separately
[05:25] <MACscr> it does seem to work sometimes and other times it doesnt. its weird
[05:26] <lordievader> qman__: Nice ;)
[09:36] <adun153> Anybody here experienced with LVM in DRBD?
[09:45] <adun153> In DRBD, If I re-create an internal MD, will it delete the data?
[11:11] <atralheaven_> how can I create a user that can do nothing, and access to nothing, only for using ssh socks proxy?
[11:12] <atralheaven_> I mean ssh -D port user@ip
[12:43] <jonah> Hi I just wanted a bit of advice. Upto now I've always rented servers from a datacentre, but I now want to have a pysical office server. I've started building it and have ordered most of the parts BUT before I start installing ubuntu server I just wanted to check about the best options for disk/raid setups. I've read it is good to keep the OS on a seperate disk and then have a raid for the data?
[12:43] <jonah> But the server I'm building is mainly going to be for websites, cloud login storage and basically just a LAMP
[12:44] <jonah> so I ordered an SSD to put ubuntu on and then 4 x 5.25" drives for the raid
[12:44] <rbasak> Why do you want RAID?
[12:44] <jonah> will this work, or is it just as well to stick everything on one raid?
[12:44] <rbasak> For reliability or performance or something else?
[12:45] <jonah> rbasak: well I already have a big enough backup drive to backup the raid, so I just wanted the speed and the potential to hotswap and expand/repair if a drive goes down
[12:45] <rbasak> So all of the above :)
[12:46] <jonah> rbasak: haha yeah
[12:47] <jonah> rbasak: but before I put the disks in the server case, I'm wondering if I should just install ubuntu on the raid and then install lamp as normal and leave it that way. Is there an advantage of having the extra SSD drive there? I've read a lot of conflicting things and also don't know how I'd actually get it to work right and set it up
[12:47] <rbasak> My home server runs on two disks with RAID-1 and LVM on top of that.
[12:47] <rbasak> I have no need for an SSD on my server. Cache suffices for me.
[12:48] <rbasak> You could look into bcache but we don't have installer support for that yet. Depends on how much you're prepared to do manually, skill level, etc.
[12:49] <jonah> so do you think I'm best just leaving that SSD out of there or is there a way I can use it to improve performance. I suppose I thought the OS would be faster and the boot/reboot fast etc.
[12:49] <jonah> I don't have that much skills with linux, I use it as a desktop daily and also do a few ssh into data centre and copy the odd thing etc but not too sure about raids, fdisks, partitions, caches and the like
[12:50] <rbasak> If you have enough RAM then you won't get much of an OS speedup with an SSD, except when doing things that you haven't done in a while (presumably non-workload things).
[12:51] <rbasak> Boot will be faster but does that really matter on a server?
[12:51] <rbasak> I'd stick to what the installer lets you set up. Keep it simple. The closer your configuration is to others, the less likely you are to be on your own for any problems.
[12:52] <shauno> I think one thing to remember putting the OS on a separate disk, is that you've chosen raid for reliability, and then introduced another disk as a single-point-of-failure anyway.  murphy says the non-raid disk will be the one that goes.
[12:55] <jonah> ok great thanks, so i just put the normal drives in (leave out the ssd) and just use what ubuntu installer offers me and it will set up the software raid and install all the defaults?
[12:55] <jonah> then I just back up the whole raid to my backup drive?
[12:57] <rbasak> I'd say so, yes. Though I haven't used the installer in a while so I can't really help with that part.
[12:58] <rbasak> I would definitely have RAID-1 at a minimum for a server nowadays though. Disks are guaranteed to fail eventually and it's a very easy way to get continuity.
[13:00] <jonah> baffle: ok thanks I'll opt for just the raid in that case, I was going to use raid 5 as most lamp servers I think use that, will that be ok?
[13:01] <jonah> rbasak: sorry sent the last reply to baffle by mistake! oops
[13:01] <rbasak> RAID-5 does what it says on the tin. It's just a cost/risk thing.
[13:02] <rbasak> But understand that your disks will fail eventually. If they're both from the same batch and have had a similar workload (eg. by being part of a RAID) then they are likely to fail at around the same time.
[13:03] <rbasak> I've seen disks fail during RAID-1 and RAID-5 reconstruction.
[13:03] <rbasak> I do not put disks from the same batch into a RAID.
[13:03] <rbasak> (well 1 or 5)
[13:04] <rbasak> IMHO buying five of one SKU all at once and putting them into a RAID-5 is pointless. Might as well just have a RAID-0 for all the good it does.
[13:04] <Walex2> rbasak: that's a bit excessive...
[13:05] <rbasak> Walex2: which bit?
[13:05] <Walex2> rbasak: anyhow I have seen commercial storate systems with hundreds of identical drives with virtually consecutive serial numbers...
[13:06] <Walex2> rbasak: the "five of one SKU ... just have a  RAID-0 for all the good it does
[13:06] <rbasak> Maybe those storage systems are doing more to handle concurrent failures?
[13:07] <rbasak> In a previous job we won business due to concurrent RAID disk failures by previous suppliers not doing this.
[13:07] <rbasak> It was a reasonably regular thing, in that I've seen it multiple times.
[13:07] <rbasak> With both commodity SATA and expensive "server grade" SCSI drives.
[13:08] <rbasak> Or perhaps they didn't wait for drives to fail before replacing them? I don't know.
[13:20] <Walex2> rbasak: I agree that is a bad idea, but concurrent failures can wait years to happen even among hundreds of drives.
[13:20] <Walex2> rbasak: I agree that is a bad idea, but concurrent failures can wait years to happen even among hundreds of identical drives.
[13:22] <rbasak> Walex2: depends on how the drives are used, and whether they're from the same batch!
[13:23] <rbasak> Walex2: having the same usage pattern and the same environmental conditions from the same batch will make it more likely that they will fail close together in time, clearly.
[13:23] <rbasak> As I say, I have seen it happen multiple times.
[13:24] <rbasak> So for a small business buying one server, it makes sense to avoid that risk because there's virtually no cost to doing so.
[13:24] <rbasak> If OTOH you are backblaze or someone similar, then clearly you can't achieve that. But your usage patterns are probably different enough that the risk is lower anyway.
[13:25] <rbasak> And in any case, you probably aren't using a minimum level of redundancy like RAID-5 that is more at risk.
[13:32] <Walex2> rbasak: your level of optimism is astounding... :-)
[13:33] <Walex2> rbasak: imagine rows and rows of racks with identical drivess with nearly consecutive serial numbers arranged in 16-wide RAID5s "because it optimizes the space".
[13:34] <jpds> Walex2: Dude, build a Ceph cluster at that point
[13:36] <RoyK> Walex2: I remember an email on some zfs mailing list some 4-5 years back. someone had built a raidz1 (similar safety as with raid5) with 30 drives and some drives were failing...
[13:39] <Walex2> RoyK: I collect emails like that. The 32-wide RAID5 was particularly amusing, but a 30-wide RAIDZ1 is good too :-).
[13:40] <Walex2> http://www.sabi.co.uk/blog/14-two.html#141019 for the 32-wide RAID5
[13:50] <jonah> sorry to pipe back in but say I use the Raid 5 and have 4 hard drives. My system is running nice but then one fails, how do i hotswap in a new drive and rebuild the array? Won't ubuntu just see a new drive, not a replacement for the failed one if I just whip it out and stick a new one in?
[13:57] <RoyK> Walex2: this guy had even added three spares
[13:57] <Walex2> jonah: depends on what the RAID system is. Most require you to explicitly label a drive as a spare before it will be added into a RAID.
[13:58] <RoyK> jonah: mdadm --add /dev/md0 /dev/newdisk
[13:59] <jonah> Walex2: well i mean just a standard ubuntu server install running on software raid5
[13:59] <RoyK> jonah: that adds a disk to the raid and unless you grow it, that disk is flagged a spare and will work like one
[14:00] <jonah> RoyK: I see Roy, so you'd power off and take out the dead one, then power back up with the new one added in it's bay then run that command?
[14:00] <RoyK> jonah: then just mdadm --remove the failed drive, unplug it, install a new one and mdadm --add it
[14:00] <RoyK> jonah: if you don't have hotpluggable disks, yes, but both SATA and SAS should handle hotplug
[14:01] <RoyK> it's part of the specification
[14:01] <jonah> RoyK: ah so with mine being sata 3 i can just hotswap with it all still turned on
[14:02] <RoyK> should work
[14:02] <jonah> RoyK: so I'd just find the dead one, pull it out and put the new one in and run mdadm
[14:02] <RoyK> you should probably mdadm --remove the dead one first, then mdadm --add the new one
[14:02] <RoyK> jonah: are you using partitions? if so, you'll need to create those first, obviously
[14:03] <jonah> RoyK: haha I know it sounds silly but how do you know which is the dead one
[14:03] <RoyK> hehe
[14:03] <rbasak> /proc/mdstat will tell you what the system considers to be alive or dead
[14:03] <rbasak> (or hot spare)
[14:03] <RoyK> jonah: try smartctl -i /dev/nameofdisk
[14:03] <rbasak> etc
[14:04] <RoyK> jonah: that should give you the make and serial number
[14:04] <RoyK> jonah: otherwise, it should be in /dev/disk/by-id
[14:04] <rbasak> RoyK: assuming that the disk isn't timing out on commands :)
[14:04] <rbasak> (I agree, but you might want to know your mapping in advance if that might be a problem)
[14:04] <RoyK> rbasak: yeah, but the data in /dev/disk/by-uuid should stick
[14:05] <jonah> RoyK: well my plan was to just partition 4 drives all with 10% swap partition and the rest free. then set up the raid on the ubuntu server installer. So if I add a label name to them all when I partition them I'll know which has died if one fails?
[14:05] <RoyK> jonah: I'd recommend using a pair of smallish (2,5" perhaps) drives for the root and the rest for data with LVM on top
[14:05] <jonah> RoyK: ah I see so I just have the serials numbers of each drive on the front of them so I can see when I open the bays up to swap them out
[14:06] <RoyK> better poweroff first, so you don't unplug something in use
[14:08] <jonah> RoyK: well the plan is to just have a big lamp server and then run owncloud and some other cms stuff on there. Do I need the LVM and different drives/partitions or can I just have the bog standard raid5 and just install?
[14:08] <RoyK> jonah: I always use LVM - it doesn't hurt and it's more flexible
[14:09] <RoyK> jonah: but really - if you have a couple of old drives, use them as a mirror for the root, don't mix root and data
[14:10] <RoyK> jonah: some even use USB sticks for the root - it's not much in use anyway
[14:10] <jonah> RoyK: ah this is interesting as when I first came into this chat my initial question was whether I should have an SSD for the OS (or two I suppose if mirrored) and then a seperate raid array for the data.
[14:10] <lordievader> LVM ftw :D
[14:11] <jonah> RoyK: but I wasn't sure how complex or necessary this was to setup up. Especially if I'm backing everything up anyway
[14:11] <RoyK> jonah: I helped a friend of mine to setup her home server, and we chose a smallish ssd and an old laptop HDD for the root, the HDD set to write-mostly
[14:12] <RoyK> jonah: that gives you the read speed of an SSD and HDD write speed
[14:12] <RoyK> which is quite handy :)
[14:16] <jonah> RoyK: sounds good, but I'm thinking more of the overall lamp with webmim virtualmim and all the rest of it installed. There is a bit of a mixture of data and config/os - not sure how I could separate it or benefit. For example if the OS drive failed and I had to reinstall, would the data stuff work correctly with it still. Sounds like a minefield.
[14:16] <RoyK> don't use webmin
[14:16] <RoyK> !webmin
[14:17] <RoyK> jonah: with a mirror of an ssd and a hdd, you can handle a disk failure
[14:17] <RoyK> jonah: and no, it's not a minefield, mixing root and data is, though
[14:26] <jonah> RoyK: Blimey RoyK - I'm used to cpanel currently but thought webmin was the best open source had to offer if I don't want to pay?
[14:27] <RoyK> jonah: use the commandline :P
[14:27] <disposable> i'm trying to install 14.04 on hp microserver (n54l). i have a problem with the installer though. as soon as the purple ncurses based interface starts, my usb keyboard stops working. does anybody know a workaround? (it works fine with centos installer and omnios (solaris)) and yes, i have tried a different usb keyboard. same story. i'm installing from a usb2 drive onto a usb3(in usb2 port) drive,
[14:27] <disposable>  in case that matters. google shows many people with the problem but no solution.
[14:29] <RoyK> jonah: it's not that hard, and once you've learned it, you'll never look back
[14:32] <jonah> RoyK: yes fair enough. The thing that scares me I suppose is the security, I can probably follow some guides and get something working but if it's served to the outside world hackers could well have a field day. I've just had a cpanel hacked recently and that had all the modsecuirty addons and a firewall running and cloudflare etc - so doing it commandline is really honourable and I'd love that but the last thing I need is a hackfest!
[14:34] <RoyK> jonah: just choose good passwords, like http://xkcd.com/936/, setup ufw to block anything you don't want to be open (it's simple, really) and use SSL/TLS whenever possible
[14:34] <RoyK> don't allow ssh login with passwords, only keys, or at least only keys with root (which I think is default now)
[14:34] <rbasak> Also, install and use unattended-upgrades, and pay close attention to anything you don't install from the archive (or even from the archive and in universe).
[14:35] <rbasak> Which also means: be biased against any technology not in the archive. Ask why it isn't packaged as part of Ubuntu.
[14:35] <RoyK> jonah: it will *not* be any more secure if you trust som flashy GUI to do the job
[14:35] <RoyK> jonah: and at the end, you'll even end up with more linux knowledge, which won't hurt :)
[14:36] <jonah> RoyK: you've talked me into it!
[14:42] <RoyK> jonah: :)
[18:23] <fx159> hello, is there anything I can do to debug reboot problems? my server gets stuck after displaying "all processes ended after 2 seconds", I'm using 14.04.3
[18:24] <sarnold> fx159: try fiddling with shutdown -H, shutdown -P, shutdown -r, I've heard some systems handle some of those poorly
[18:25] <RoyK> fx159: how do you reboot the server? have you checked the logs?
[18:25] <fx159> RoyK: I enter reboot into the console
[18:26] <RoyK> fx159: should work
[18:26] <RoyK> fx159: if you have another linux machine around, try setting up rsyslog to log to that machine as well to see if you get anything useful out of the logs
[18:26] <fx159> RoyK: also nothing obvious in the syslog
[18:27] <fx159> RoyK: I have a serial console to the machine... it just sits there after "all processes ended after 2 seconds", no further output, also no errors before
[18:27] <RoyK> no idea, sorry
[18:28] <fx159> too bad, well I can live with it... machine is online 24/7 anyways
[18:28] <TJ-> fx159: it's usually a firmware ACPI bug; there are some workarounds, such as matching the expected OSI string with a kernel command-line entry of the form "acpi_osi=Windows XXXX" where XXXX is some Windows version string present in the ACPI DSDT (the most recent Windows version usually). "sudo strings /sys/firmware/acpi/tables/DSDT | grep -i windows" might help you find those strings
[18:29] <sarnold> TJ-: good idea
[18:30] <fx159> TJ-: I know it worked with earlier versions of 14.04, before rebooting it displayed a message saying something like "rebooting system now", that message no longer appears, still a firmware bug?
[18:30] <TJ-> fx159: maybe a regression in the kernel
[18:30] <sarnold> fx159: there's a 'fwts' package that's supposed to help test firmwares; I haven't used it myself so I can't really say if it is appropriate for end users or just hardware distributors, but it may useful too
[18:31] <sarnold> fx159: ooh, interesting. if you're up for testing the 14.04.2 and 14.04.1 kernels, that might be worthwhile. granted, it'd take some time, but it'd make a bug report more interesting :)
[18:32] <fx159> sarnold: oh well, already tested a lot of the 3.19 kernels for another bug report, not again hehe
[18:32] <sarnold> fx159: hehehe
[18:33] <sarnold> there are more fun ways to spend your time, that's for certain.
[18:33] <fx159> https://bugs.launchpad.net/bugs/1504909 any ideas regarding this bug? hehe
[18:35] <sarnold> fx159: argh. that looks -really- annoying
[18:36] <sarnold> fx159: does a scrub repair it?
[18:36] <fx159> sarnold: scrub fixes the errors, yes
[18:37] <fx159> sarnold: but I'd prefer spin down to work without data corruption ;)
[18:37] <sarnold> fx159: yes :)
[18:37] <sarnold> especially since scrubs aren't exactly fast
[18:39] <fx159> sarnold: 600M/s is kinda fast, but scanning the pool still takes about 3 hours :/
[18:40] <fx159> sarnold: I'm considering going back to the 14.04.2 kernel
[18:41] <sarnold> fx159: There's a few approaches that might be worthwhile, but none of them are fun. maybe try 14.04.1's kernel, see how well that works; try to reproduce on a single drive without zfs; try replacing the controller with something else (funny, I'd heard really good things about the m1015, but perhaps not many people spin them down..)
[18:41] <fx159> sarnold: spindown is something that also worked with earlier verions :(
[18:41] <sarnold> fx159: have you asked around #zfsonlinux or filed github issues there? those guys are helpful and might know something that I don't..
[18:42] <fx159> sarnold: yes I did, initally there was also a zfsonlinux bug... but that got fixed...
[18:42] <sarnold> fx159: heh
[18:42] <fx159> sarnold: https://github.com/zfsonlinux/zfs/issues/3785
[18:43] <sarnold> fx159: doing the full bisection is probably the best bet, though that might be dozens of compiles and reboots..
[18:44] <fx159> sarnold: too bad, I don't have that much spare at the moment...
[18:44] <fx159> *time
[18:53] <fx159> sarnold: I believe it has something to do with zfs... error occurs with 3.16 as well now, wtf?
[18:54] <fx159> sarnold: I'm 100% it never appeared with 3.16 before ._.
[18:54] <sarnold> fx159: interesting. did you upgrade pool or dataset features? if not you could try an older zfs...
[18:55] <sarnold> bisecting zfs/spl may be easier than the kernel :)
[18:55] <fx159> sarnold: upgraded the pool :-(
[18:56] <sarnold> :(
[18:57] <fx159> sarnold: I always wanted to try out FreeNAS... hm... whatever
[18:57] <fx159> sarnold: no more spin down or reboots for me, for now hehe
[18:57] <sarnold> fx159: did you notice any decent power savings or noise savings when spinning down the disks?
[18:59] <fx159> sarnold: noise is not a concern, power draw with spinning disks is about 90 - 100W, with spun down disks something like 45W, so yes, there is potential
[19:08] <sarnold> fx159: wow. thanks. I'm sooner or later going to be putting together my own smallish zfs system and was curious about power draw, heat, and noise from all those drives..
[19:10] <fx159> sarnold: I'm using a supermicro 4U server case, 8 bay hot swap in the front, heat is no problem, noise...well... there are system that are quieter, power draw is quite good as you see :)
[19:12] <sarnold> fx159: hehe, yeah, server gear is never going to be -quiet- but it still seems surprising to me that there's not much in the middle ground of ~dozen drives systems for home use. it's all "look! four drives in this nas!" or "this chassis holds 24 drives" :)
[19:28] <fx159> sarnold: Yea, four is just not enough, and 24 is overkill...
[19:40] <dasjoe> sarnold: is http://cdimage.ubuntu.com/releases/wily/release/ supposed to contain just powerpc and ppc64el images?
[19:40] <sarnold> dasjoe: hah, good question
[19:42] <dasjoe> sarnold: same for vivid. trusty has some weird images I don't recognize, too: "64-bit Mac (AMD64) desktop image"
[19:42] <OerHeks> dasjoe, use the server and install the desktop you want
[19:42] <sarnold> OerHeks: those -are- the server images, and it's only two oddball arches :)
[19:42] <sarnold> dasjoe: I've poked infinity in #ubuntu-devel, he seems most likely to know what's going on..
[19:43] <sarnold> off to lunch..
[19:44] <dasjoe> OerHeks: thanks, but that's not what I'm after :) I just noticed cdimages does not contain images for any arch I use
[19:45] <tarpman> dasjoe: are you looking for http://releases.ubuntu.com/wily/
[19:45] <OerHeks> images like logos / artwork ?
[19:46] <Obelus> Probably disc images...
[19:48] <shauno> dasjoe: it seems to be intentional.  the front page of http://releases.ubuntu.com has an explanation.  in all honestly, I'm surprised the root of cdimage. doesn't
[19:48] <dasjoe> shauno: thanks, just found that explanation, too
[19:50] <OerHeks> oh the regular versions http://releases.ubuntu.com/15.10/ , i was lost in powerpc
[20:00] <dasjoe> I finally found what I was looking for in the first place, the netboot minimal ISOs: http://cdimage.ubuntu.com/netboot/
[20:01] <Obelus> Ah netboot.
[20:30] <rattking> hello, does anyone know if the grub2 password behavior was suppose to change between precise and trusty? I just upgraded a test node to trusty and its asking for a PW to boot when it use to require a PW to edit or access  grub's cli
[20:38] <rattking> ohh yes there was a change in behavior there, and its documented :)
[21:00] <Wicaeed> how long does it take to sync a single image with uvt-simplestreams-libvirt? I'm running the command to sync a single image yet I'm not seeing any noticeable network activity
[21:01] <Wicaeed> I see it taking a boatload of CPU though
[21:06] <atralheaven_> Hello, what tool do you suggest for downloading torrents on vps?
[21:10] <bittin> rtorrent
[21:14] <keithzg> atralheaven_: Yeah, bittin's suggestion of rtorrent is probably the best one. Although, I remember some time ago having to go with ctorrent instead because of dependencies. That was a while ago and it was on an OpenBSD VPS, though.
[21:15] <atralheaven_> I think I've used it before...
[21:15] <atralheaven_> im installing it
[21:17] <atralheaven_> how can I add a user that can only use ssh socks proxy? nothing more, only ssh socks proxy, is it possible?
[21:18] <atralheaven_> the user shouldn't be able to run any command


[01:48] <micahg> fta: asac: anyone around?
[05:45] <micahg> asac: don't release Firefox 3.6 in the morning...I need to talk to you first
[06:05] <fta> micahg, hmm.. build/rules.mk?
[06:05] <micahg> fta: Do we have to edit that with a patch?
[06:06] <fta> if you need to fix it, yes
[06:06]  * fta out for work
[06:06] <micahg> My stuff builds, it just doesn't clean since I needed to add 2 dirs to the build system (only 2 files)
[06:06] <fta> you can do it in d/rules too then
[06:07] <micahg> fta: well, anyone building against the build-system will have the issue, so I figured I needed it to be global in scope
[06:08] <micahg> fta: when is distclean triggered?
[06:08] <fta> moz uses GARBAGE and GARBAGE_DIR for that (each makefile could set thos)
[06:08] <fta> e
[06:08] <fta> off for real now.
[06:08] <micahg> fta: ah, ok, you have that in your makefile
[06:08] <micahg> ok
[06:08] <micahg> fta: have a good day :)
[08:56] <BUGabundo_remote> morning
[08:59] <BUGabundo_remote> kenvandine: couch broken again? http://paste.ubuntu.com/390913/
[09:02] <asac> hmm ... wonder what was the prob with fffox36
[13:04] <sindhudweep> asac: you there?
[13:40] <micahg> asac: available?
[13:41] <asac> micahg: yes
[13:41] <asac> micahg: whats going on?
[13:41] <asac> i saw you writing about ffox not releasable
[13:41] <micahg> asac: k, first, the mozilla-kde patch won't build on hardy as it uses a newer GTK function
[13:42] <asac> sindhudweep: sigh
[13:42] <asac> sindhudweep: i will do that now. i think all is ready?
[13:42] <asac> micahg: sigh too ... push that back to devfx
[13:42] <micahg> asac: so, I didn't know if you wanted to drop it till they fix or release it and not use it on hardy
[13:42] <asac> micahg: for the hardy security update we dont want to use it
[13:42] <asac> we need to branch for that
[13:42] <asac> and remove it
[13:42] <asac> for all stable releases actually
[13:43] <micahg> asac: k, but for lucid, it's fine?
[13:43] <micahg> it breaks the daily build though
[13:43] <micahg> for hardy at least
[13:44] <asac> !info gnash
[13:45] <asac> sindhudweep: we merged ubuntu2 stuff to ubuntu.head at some point
[13:45] <asac> your new packaging asks for merge into ubuntu
[13:45] <asac> does it include all that was previously in .head?
[13:46] <asac> sindhudweep: you didnt include the files changed in changelog
[13:47] <asac> ok merged packaging
[13:49] <asac> sindhudweep: upstreampkg+bzrbd+py2.6 isnt a merge request?
[13:49] <asac> e.g. ok to release without that?
[13:54] <sindhudweep> asac: just one second.
[13:55] <asac> i am fine to trash the .head
[13:55] <asac> please check ;)
[13:55] <asac> i committed your parts there
[13:55] <asac> if you could add the changed filenames for each of the changes in changelog that would be better
[13:55] <asac> its always a mystery from outside to see that
[13:56] <sindhudweep> upstreampkg+bzrbd+py2.6 is rob savoye's packaging. It's based off of your packaging from gnash 0.8.2 and his changes since then. I've merely added a few fixes to get it to work with lucid.
[13:56] <sindhudweep> It's purely and experiment and wont have any of the history we have in bzr.
[13:57] <sindhudweep> please ignore ubuntu.head as that was a bad attempt at fixing the missing kde4-gnash packages.
[13:58] <sindhudweep> I would like you to review and merge  lp:~sindhudweep-sarkar/gnash/gnash0.8.7packaging  into  lp:~gnash/gnash/ubuntu if it's suitable. I think in the long term going with rsavoyes packaging would be better
[13:58] <sindhudweep> but i'm not sure if that's feasable this cycle.
[13:59] <sindhudweep> please let me know any changes you need to make lp:~sindhudweep-sarkar/gnash/gnash0.8.7packaging mergable or if you want to switch to the upstream packaging.
[14:01] <sindhudweep> thoughts?
[14:03] <asac> sindhudweep: i think its fine what you did
[14:03] <asac> i assume you tested stuff?
[14:03] <asac> sindhudweep: can you add the files changed for each changelog entry please? i already committed your merge, so  base that on ubuntu
[14:03] <asac> i think you can also commit
[14:03] <sindhudweep> Yes the gnashteam ppa has all revisions in the branch you merged except the last one which disabled explicitly enabling jemalloc as that is the default.
[14:04] <sindhudweep> I will fix the files changed in the changelog entry and push it to the ubuntu branch.
[14:04] <sindhudweep> I'll let you know when that's done
[14:04] <asac> ok thanks
[14:04] <sindhudweep> thanks!
[14:04] <asac> i will upload directly when thats done
[14:04] <asac> maybe do a final test round
[14:04] <sindhudweep> great!
[14:04] <asac> if you thin that would be helpful
[14:04] <sindhudweep> will do
[14:05] <micahg> asac: so, back to firefox, are we ok for lucid and do I need add something to that the dailies don't build with the firefox-kde patch on hardy?
[14:06] <asac> micahg: we are fine for now
[14:06] <asac> we can fix that later
[14:06] <micahg> asac: k, then ubuntu6 is tagged and ready for release :)
[14:06] <asac> cool
[14:06] <micahg> asac: what to do when I push to PPA (disable on hardy only)?
[14:07] <micahg> firefox-stable
[14:08] <asac> micahg: the tag doesnt include the kde patch
[14:08] <asac> ?
[14:08] <micahg> what?
[14:09] <micahg> it should
[14:09] <asac> oh right
[14:09] <asac> ok
[14:09] <asac> micahg: how were you able to bake a release on a normal revision?
[14:09] <asac> i thought the stuff was already ahead
[14:09] <micahg> asac: I did it before I fixed it for 3.6.2
[14:09] <asac> ah ok
[14:10] <micahg> next release will be trickier
[14:10] <asac> why?
[14:10] <micahg> but I think we might need to do one more before beta hard freeze
[14:10] <asac> ah
[14:10] <asac> in case we need another one
[14:10] <asac> right
[14:10] <asac> lets hope for .2/3
[14:10] <micahg> that's at the end of the month, may we can wait...the other fixes are minor IMHO
[14:11] <micahg> *maybe
[14:11] <asac> we shouldnt wait for fixes just because of this
[14:11] <asac> rather take the pain and branch old/merge after release ;)
[14:11] <asac> but lets see whats coming up
[14:11] <micahg> asac: k, then I'll prepare another release over teh weekend :)
[14:12] <micahg> asac: should I tag TB3, I prepared it but not tag?
[14:12] <asac> micahg: there are apport fixes not documented in changelog?
[14:13] <micahg> asac: which ones?  I thought all the apport fixes were in there
[14:13] <micahg>   [ Kees Cook<EMAIL_ADDRESS>]
[14:13] <micahg>   * fix LP: #531581 - cannot report bugs or crashes when profile names contains
[14:13] <micahg>     spaces; concatenate non alnum characters in profile name for apport use
[14:13] <micahg>     - update debian/apport/firefox.py
[14:13] <asac> right
[14:13] <asac> ok
[14:13] <micahg> is there another one?
[14:13] <asac> no didnt spot
[14:13] <asac> that
[14:13] <asac> because too long changelog entry ;)
[14:14] <micahg> :) he made the patch
[14:14] <micahg> asac: you told me not to worry about space in changelog
[14:15] <asac> yes, i usually start with "fix apport hook to do this, that etc."
[14:15] <asac> e.g. dont have the subject of the fix at the end ;)
[14:15] <asac> uploading
[14:15] <micahg> asac: k, should I tag TB3 for upload?
[14:15] <asac> micahg: yes
[14:15] <asac> unless you have fixes
[14:15] <asac> we should forward bugs
[14:16] <micahg> asac: yes, and there was one fix I already made
[14:16] <asac> ok
[14:16] <asac> in future just ping chrisccoulson to update tbird ... so you can focus on porting
[14:16] <asac> also for daily build failures he wants to help ;)
[14:16] <asac> :-P
[14:16] <chrisccoulson> hi :)
[14:16] <asac> hi!
[14:16] <micahg> asac: I had to make the at least one of th efixes as I knew the issue :)
[14:17] <asac> sure
[14:17] <micahg> asac: should chrisccoulson prepare the TB<IP_ADDRESS> release?
[14:17] <asac> just saying we should get him involved ;)
[14:17] <asac> yeah. that would be a good excersize
[14:17] <asac> to get started
[14:17] <kecsap> asac: hi! thanks for merging one of my branches at ubufox. I have submitted more branches with simple fixes for review. Now I have 4 branches waiting for review/merge and bugs 493805 and 123713 have patches to be reviewed and committed. When will you have time to check them? Anyway I will check more (harder) bugs to reproduce/fix this week.
[14:19] <chrisccoulson> micahg - did you say you couldn't recreate the openjdk build failure locally?
[14:19] <micahg> chrisccoulson: right, well, I'm still on karmic
[14:20] <micahg> but it built fine locally, but I didn't test in a clean environment either
[14:20] <chrisccoulson> micahg - ah, that's probably why. the version currently in the archive also fails against xulrunner 1.9.1
[14:20] <chrisccoulson> in a clean environment here
[14:20] <micahg> chrisccoulson: I tested locally against xul192 though
[14:20] <asac> i think it needs 1.9.2 now
[14:20] <micahg> and that's what the PPA should've used
[14:20] <asac> because they needed to fix it in order to work with 1.9.2 at all (thats what i got from random chatter)
[14:21] <chrisccoulson> micahg - it fails against xulrunner 1.9.2 locally here too
[14:21] <micahg> asac: yes, well it's hard coded to build the proper plugin against 192
[14:21] <micahg> chrisccoulson: same build failure or different?
[14:21] <chrisccoulson> i've got a shell open in the failed build environment later, so i will try and figure out why it failed
[14:21] <chrisccoulson> same failure...
[14:21] <micahg> chrisccoulson: k, that would be great
[14:21] <asac> pasting build failures is often helpful ;)
[14:22] <chrisccoulson> oh, i meant to say " i've got a shell open in the failed build environment right now"
[14:22] <asac> sometimes i just know whats going on from lookig at it ... sometimes not :)
[14:22] <micahg> asac: is this changelog fine or should the line start at the beginning: http://pastebin.com/xM04hb1b
[14:22] <asac> ah
[14:22] <chrisccoulson> asac - http://launchpadlibrarian.net/40287073/buildlog_ubuntu-lucid-amd64.openjdk-6_6b18~pre1-1ubuntu1.0ffox36.1_FAILEDTOBUILD.txt.gz
[14:23] <asac> micahg: if you dont have a USN/CVE below it, i think not having empty line is ok
[14:23] <micahg> asac: I was referring to the line with the bug fix
[14:23] <chrisccoulson> anyway, i'm disappearing for lunch for a bit, i've not eaten anything yet today
[14:23] <micahg> I wrapped the text under the rest of the title
[14:23] <asac> chrisccoulson: ok. thats feeling like a bug in the script ;)
[14:24] <asac> but would need to look
[14:24] <chrisccoulson> asac - yeah. i'm not sure what has changed though - i can recreate the same issue with the version already built in the archive against xulrunner 1.9.1
[14:25] <micahg> chrisccoulson: then how did doko get it to build 2 weeks ago?
[14:25] <chrisccoulson> i'm not too familiar with openjdk though, so i was going to ping doko about it, but he's not around
[14:25] <asac> that feels like a CFLAGS somehow ending up at  the command line ;)
[14:25] <chrisccoulson> micahg - not sure
[14:25] <micahg> I made no packaging changes
[14:25] <asac> unless that thing is supposed to build something of course
[14:25] <micahg> except for the maintainer
[14:26] <micahg> asac: so the fix LP: line in the changelog is ok with the wrapping underneath?
[14:27] <asac> micahg: i usually dont indent
[14:27] <asac> just same indent as prvious line
[14:27] <micahg> asac: that's what I wanted to check, I'll fix, tag, and push :)
[14:27] <asac> that looks a bit odd that way
[14:27] <asac> kk
[14:27] <asac> let me know
[14:29] <micahg> asac: done
[14:30] <micahg> asac: about xulrunner, the new build system rquires libnotify-dev, should that be a dep on xulrunner-1.9.2-dev or on the app itself?
[14:30] <chrisccoulson> asac - i can reproduce the error that triggers the openjdk build failure manually in the failed pbuilder environment i have
[14:30] <chrisccoulson> so i could probably look at that after lunch
[14:33] <asac> micahg: libnotify-dev?
[14:33] <asac> it fails without it?
[14:33] <micahg> asac: yes, that's one of the new requires
[14:34] <micahg> in configure
[14:37] <micahg> asac: BTW, I only had to add 2 files to the build system :)
[14:38] <asac> good
[14:38] <asac> well. for now ad libnotify-dev
[14:38] <micahg> asac: where?
[14:38] <asac> feels wrong, but ok
[14:38] <asac> to xulrunner-1.9.2-dev i guess
[14:38] <micahg> we added it to firefox 3.6 and xul192
[14:39] <micahg> k
[14:39] <micahg> asac: will shlibdeps add it to the package if it's required?
[14:39] <micahg> I mean prism
[14:40] <micahg> that was my main question as to where to add it
[14:41] <micahg> asac: it's required because libnotify was enabled in 192
[14:42] <asac> it will add it if its required
[14:42] <asac> imo it shoudnt e required to build
[14:42] <asac> its a biuld system bug to require it imo
[14:42] <asac> maybe worth upstream discussion
[14:43] <micahg> asac: k, I'll add to xul192dev and test, thanks
[14:52] <micahg> asac: the other think with xulrunner, is I wasn't able to clean out the 2 new directories I added on make clean
[14:52] <micahg> I added them to GARBAGE_DIRS, but that didn't seem to help
[14:53] <micahg> rather GARBAGE_DIRS in the build system
[14:56] <asac> micahg: what do you mean?
[14:56] <asac> in debian/rules?
[14:56] <asac> otherwise i would have thought that the build system doesnt get removed
[14:56] <micahg> asac: the build system has a makefile with GARBAGE_DIRS
[14:57] <asac> yeah
[14:57] <micahg> so I added there so I wouldn't have to add to every app
[14:57] <micahg> but it didn't work
[14:57] <asac> what are you trying to remove?
[14:57] <asac> build/ ?
[14:57] <micahg> tools and testingf
[14:57] <micahg> oops
[14:57] <micahg> testing
[14:57] <asac> why those?
[14:57] <micahg> I added 2 files under there
[14:58] <micahg> and make clean won't remove it
[14:58] <asac> the rest of the build system already gets removed?
[14:58] <micahg> but removes the rest
[14:58] <micahg> yes
[14:58] <micahg> I was wondering if you knew where it did that :)
[14:58] <asac> make clean removes the build system? how is it extracted?
[14:58] <asac> i mean ... how does it come back?
[14:58] <micahg> it's untarred again
[14:58] <asac> i would have thought that debian/rules clean removes it
[14:58] <asac> thats where it should get removed ... not in the Makefile
[14:59] <asac> unless i fail so see the point
[14:59] <micahg> asac: then it has to be added to every app that uses the build system
[14:59] <asac> right. but its the same for build/ etc.
[15:00] <micahg> no
[15:00] <micahg> somehow, that's taken care of with the build system
[15:00] <asac> hmm
[15:00] <asac> please post the top level Makefile.in
[15:00] <micahg> from teh buidl system?
[15:01] <asac> what else would be doing it ;)
[15:01] <micahg> http://pastebin.com/XDXzdpkj
[15:02] <micahg> I added them to line 62, but that didn't seem to work
[15:02] <asac> i dont see biuld/ config/ getting removed there
[15:02] <asac> so after make clean
[15:02] <asac> what is left?
[15:02] <micahg> this gets run at the end:
[15:03] <micahg> http://pastebin.com/JBpL1NSn
[15:03] <micahg> just tools and testing
[15:03] <asac> where is "Drop build-system" ?
[15:03] <asac> i dont see that anywhere in build system
[15:04] <micahg> asac: that's what I'm wondering
[15:04] <micahg> I'm guess in one of the .mk files...I'll grep for it
[15:04] <asac> i grepped for it
[15:04] <asac> nothing
[15:04] <micahg> hmm
[15:04] <asac> my guess is that its all in rules
[15:04] <micahg> weird
[15:04] <asac> or in prism/build.mk
[15:09] <micahg> it's not anywhere in the build directory that I can see
[15:10] <asac> when do you get it?
[15:11] <micahg> when fakeroot debian/rules clean is run, it's at the end
[15:11] <asac> yeah. that could be rules then
[15:11] <asac> you should see if it really happens on make clean
[15:11] <asac> or make distclean
[15:11] <asac> without rules
[15:11] <micahg> make clean
[15:11] <micahg> oops
[15:12] <micahg> nope, no clean target in the file
[15:12] <micahg> can I add a clean target to the Makefile then?
[15:12] <sindhudweep> asac: I've fixed the changelog and pushed it to https://code.launchpad.net/~gnash/gnash/ubuntu. I have built a package from that branch in one of my personal ppas and tested it out a bit. I think we're good here.
[15:12] <sindhudweep> Thanks again!
[15:13] <asac> let me lkook
[15:14] <asac> ok producing stuff
[15:49] <ccheney> asac: did you get my email from friday?
[15:58] <micahg> asac: I got it, it's in mozilla-devscripts...
[16:01] <micahg> asac: so, should I propose a change for mozilla-devscripts, or move that to xulrunner-1.9.2-dev?
[16:01] <micahg> xulapp.mk I mean
[16:03]  * micahg needs to get ready for $WORK...bbi 10 min
[16:18] <mahfouz> jdstrand, is apparmor at all active right now in fx 3.6?
[16:18] <micahg> asac: so what to do with xulapp.mk
[16:19] <mahfouz> I'm in lucid right now and have no apparmor problems atm
[16:23] <jdstrand> mahfouz: it is enabled in the default install, and working, yes
[16:23] <mahfouz> hmm, but my scid runs from fx
[16:23] <mahfouz> I filed that bug
[16:24] <mahfouz> /usr/games/scid
[16:29] <mahfouz> emacs also open files from fx
[16:29] <mahfouz> I have firefox daily build and running lucid
[16:30] <mahfouz> there seem to be no apparmor restrictions at all
[16:32] <jdstrand> mahfouz: you likely have to do:
[16:33] <micahg> asac: I goofed on the sparc fix...I'll fix it for ubuntu7 :(
[16:33] <mahfouz> don't get me wrong, I don't need apparmor restrictions :)
[16:33] <jdstrand> sudo aa-enforce /etc/apparmor.d/usr.bin.firefox
[16:33] <mahfouz> jdstrand, yes
[16:33] <mahfouz> jdstrand, I was just wondering if this is default or maybe a bug
[16:33] <jdstrand> mahfouz: it is probably not enabled due to the firefox-3.x -> firefox name transition and running the dailies
[16:34] <mahfouz> I'm actually happy without apparmor
[16:34] <micahg> jdstrand: didn't you make it so if it was disabled before it remains that way in teh dailies
[16:34]  * jdstrand nods
[16:34] <micahg> I just enabled mine locally so I can do more testing
[16:37] <asac> micahg: really? hmm. did the sparce fix break anything?
[16:37] <micahg> asac: no, the flag was just ignored
[16:37] <asac> k
[16:37] <micahg> asac: k, I just discovered another dependency
[16:37] <asac> thats fine. commit the correct fix
[16:37] <asac> done
[16:37] <micahg> libiw-dev
[16:38] <micahg> asac: well, if I commit it on top of what's there, won't that not get into the next 3.6.0 upload?
[16:38] <asac> you know the troubles with that ,)
[16:39] <asac> backbranch/merge etc.
[16:39] <micahg> right, so isn't it better to wait to commit it then until I'm ready to do all that?
[16:40] <micahg> asac: now xul build system wants libiw-dev as well
[16:40] <asac> micahg: you know the schedule for .1
[16:40] <asac> ?
[16:40] <micahg> asac: .2 actually
[16:40] <asac> yeah
[16:40] <asac> you said end of month?
[16:40] <micahg> asac: yes
[16:40] <micahg> but you said that we should get more fixes in Lucid before that I thought
[16:41] <asac> is there anything?
[16:42] <micahg> there are a few bugs...I can't really go into it now
[16:43] <micahg> asac: once they do the QA builds, can we throw that in Lucid, or we have to wait for release?
[16:44] <ejat> asac: im having problem with NM .. wireless keep reconnecting ..
[16:44] <ejat> and i need to manually request dhcp for any interface :(
[16:49] <ejat> !ping asac
[17:10] <mahfouz> ejat, that's a lucid bug
[17:10] <ejat> mahfouz: know the bug #
[17:10] <mahfouz> probly this one:
[17:11] <mahfouz> https://bugs.launchpad.net/ubuntu/lucid/+source/network-manager-applet/+bug/445487
[17:11] <mahfouz> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/496093
[17:12] <ejat> mahfouz: thanks
[19:30] <ccheney> asac: ping again :)
[19:37] <asac> ccheney: hi
[19:38] <asac> ccheney: have you bootstrapped the libs somewhere?
[19:38] <asac> in appa?
[19:38] <micahg> asac: so, what should I do about xulapp.mk in m-devscripts <--- that's where the clean rule is for the build system
[19:39] <asac> ah
[19:39] <asac> micahg: yeah. i think thats where it belongs for now
[19:39] <micahg> asac: so, should I propose a merge for m-devscripts?
[19:40] <micahg> so I can add tools and testing to that clean rule?
[19:43] <micahg> asac: I also added libiw-dev to xulrunner-1.9.2-dev...fennec and prism built after that and libnotify-dev were added
[19:43] <asac> micahg: yes
[19:43] <asac> yeah. we should come up with a patch for the build system imo
[19:44] <asac> that makes those go away again
[19:44] <asac> for now its ok
[19:44] <asac> just file a bug while doing that
[19:44] <asac> so we dont forget
[19:44] <micahg> asac: since xulrunner's already compiled against it, the apps woudl be able to use them anyways?
[19:45] <micahg> s/it/them/
[19:45] <asac> well. the iw and notify stuff is not needed
[19:45] <asac> because its hidden
[19:45] <asac> so that depends are useless
[19:45] <asac> and wrong
[19:45] <asac> so yeah. apps can use that ... through the xulrunner apis
[19:45] <micahg> asac: well, what if a xul app wants to use either is my question
[19:46] <asac> dont undersatnd that question
[19:46] <asac> toolkit has a API that allows notifications
[19:46] <asac> and also scanning for networks
[19:46] <asac> the app doesnt know what its using in the back
[19:46] <micahg> k, so once the toolkit is built against the libs, the program doesn't need to be?
[19:46] <asac> yes
[19:46] <micahg> k, same for notifications?
[19:46] <asac> because the program doesnt use the libnotify nor libiw apis directly
[19:46] <micahg> k
[19:46] <asac> just the toolkit api
[19:46] <micahg> fine, I'll file a bug then
[19:47] <micahg> in LP I'm asumming, then upstream when we have a patch?
[19:47] <asac> yeah
[19:47] <micahg> asac: what should I do with xulapp.mk though?
[19:47] <asac> we can also open upstream directly and explain whats the prob
[19:47] <asac> update it
[19:47] <asac> to remove the new files
[19:47] <micahg> k, I'll do that then
[19:47] <asac> actually maybe it should be shipped by xulrunner-dev
[19:48] <asac> but well. lets keep it the way it is by now
[19:48] <micahg> asac: xulrunner-dev pulls in the versioned -dev
[19:49] <micahg> asac: but what to do about the clean rule...
[19:56] <ccheney> asac: i can put the rest up, but epiphany-browser is at http://people.canonical.com/~ccheney/
[19:59]  * ccheney will upload up to date version for all of them
[20:04] <ccheney> will be at http://people.canonical.com/~ccheney/2010-03-08/ when it is done
[20:32] <asac> ccheney: cant you make proper packages out of them?
[20:32] <asac> so i can install everything instead of bootstrapping and stuff
[20:38] <ccheney> asac: ok will do
[20:38] <ccheney> i am on amd64, hopefully you too :)
[20:59] <fta> asac, i still have to push the chromium codecs to lucid, is it too late?
[22:13] <BUGabundo> o/
[22:22] <micahg> asac: BTW, thunderbird 3.0.3 is tagged
[22:22] <asac> ccheney: ppa? amd64 shouldnt mater there ;)
[22:29] <asac> fta: we need a FFe bug
[22:29] <asac> file one i can argue why we want that.
[22:30] <asac> is the licensing all properly documented? e.g. is it ready?
[22:53] <jdstrand> asac: is firefox-3.6.head where to commit to lucid, or does lucid have its own branch now?
[22:53] <asac> jdstrand: that commits to lucid
[22:53] <ccheney> asac: would take a while to get it actually build for ppa due to version changes, and needing to determine what to do with libsoup bootstraping itself, etc
[22:53] <asac> though if we need to releas another 3.6.0 we have to do some shuffeling
[22:53] <ccheney> asac: almost have all of it uploaded though as debs to p.c.c
[22:53] <asac> but we will ensure stuff that gets landed there gets released
[22:54] <asac> ccheney: we need to do that anyway
[22:54] <jdstrand> asac: thanks
[22:54] <asac> ccheney: debs are not that useful
[22:54] <ccheney> yea was hoping to have an answer for rickspencer3 for tomorrow about how to get it finished :)
[22:54] <asac> i need all the debs with sources so i can hack on it
[22:54] <ccheney> the sources are already up there
[22:54] <ccheney> you then asked for debs which i uploaded
[22:54] <asac> i asked for proper packages
[22:54] <ccheney> :)
[22:54] <asac> not just crazy debs where i cant see the diff etc.
[22:54] <asac> or source tarballs
[22:55] <ccheney> the diffs are already up there
[22:55] <asac> so you uploaded proper source packages?
[22:55] <asac> with minimal patches?
[22:55] <asac> ok
[22:55] <ccheney> yea its inside all the *-backport.tar.gz
[22:55] <ccheney> including the bzr dir everything
[22:55] <micahg> jdstrand: that first line in your changelog is missing an LP #
[22:55] <ccheney> its not completely minized yet, since some of them require re autoconfing to be able to build :-\
[22:56] <asac> ccheney: what does "including the bzr dir" mean?
[22:56] <asac> is that against upstream bzr?
[22:56] <ccheney> i'm not sure what to do about that as far as a final patch is concerned
[22:56] <asac> or against packaging bzr?
[22:56] <ccheney> foo/.bzr
[22:56] <asac> well i know that
[22:56] <asac> but what kind of tree?
[22:56] <ccheney> the original ubuntu package unpacked with bzr init run then checked in, so bzr diff shows everything that has been changed
[22:57] <ccheney> i'm not sure if there are really upstream bzr for the various packages
[22:57] <asac> hmm
[22:57] <ccheney> at least not in a manner i could easily use for this
[22:57] <asac> thats really an odd way to do things
[22:57] <asac> not really organized
[22:57] <asac> but ok
[22:57] <asac> i can see
[22:58] <ccheney> i guess for the final diff i should remove anything autoreconf did and then put the resulting patch into debian/patches and a patch adding the autoreconf cruft as a second patch?
[22:59] <asac> well. you should make proper patches out of it
[22:59] <asac> without the autoconf stuff of course
[22:59] <asac> its just painful to work on this
[22:59] <ccheney> then it won't build because many of them REQUIRE autoreconf to build at all
[22:59] <asac> but yes, in general what you outlined ;)
[22:59] <ccheney> unless you mean manually hack up the resulting automake output files?
[23:00] <ccheney> everything i had to add file wise had to be added to Makefile.am configure.in etc then rerun of the various autotools to use it, etc
[23:00] <asac> what i would have loved to see was a upstream bzr tree
[23:00] <asac> with stuff committed without autoconf
[23:00] <asac> then i could run autoreconf or something on my own etc.
[23:00] <asac> but well. thats too late now
[23:01] <ccheney> i'm a bit rusty on the tools since the only thing i normally use rcs for is debian dirs
[23:01] <asac> also i now how to go through the painful libsoup bootstrapping etc. would have been great t ohave this in a ppa properly where we could just work on
[23:01] <ccheney> OOo is a just set of tarballs that no one wants to use via a rcs :-\
[23:02] <asac> anyway
[23:02] <asac> i will pull that stuff now and see how far i get
[23:02] <ccheney> the libsoup debs are up there already
[23:02] <ccheney> along with the build log, diff etc
[23:03] <asac> ccheney: ok so you are working on ephy and gtk atm?
[23:03] <asac> e.g. the rest i can juzst install?
[23:03] <ccheney> yea trying to figure out what to do with ephy with respect to the entry stuff
[23:04] <ccheney> the rest should be installable as is
[23:04] <ccheney> i am uploading webkit atm and then have to determine why libproxy no longer patches properly so i can get it uploaded
[23:05]  * ccheney thinks he didn't even modify that package so wonders what is up
[23:07] <ccheney> hmm i think it just won't cleanly rebuild a second time
[23:07] <ccheney> reverted everything in the package and rebuilt fine
[23:10] <ccheney> ok proxy is uploaded there now, just waiting on webkit to finish
[23:13] <ccheney> done
[23:18] <asac> i dont have amd64
[23:20] <asac> so the glib thing doesnt have a bzr dir
[23:21] <ccheney> hmm, looking
[23:21] <ccheney> uh the one i uploaded did before it got to the server
[23:21]  * ccheney looks at the version on the server to see if its still there
[23:21] <asac> oh it had
[23:21] <asac> sry
[23:22] <ccheney> ok np
[23:22] <asac> is it usable with bzr from hardy?
[23:22] <asac> asac@tinya:~/ccheney/glib2.0-backport/glib2.0-2.16.6$ bzr info
[23:22] <asac> bzr: ERROR: Unknown working tree format: 'Bazaar Working Tree Format 6 (bzr 1.14)\n'
[23:22] <asac> asac@tinya:~/ccheney/glib2.0-backport/glib2.0-2.16.6$
[23:22] <ccheney> oh apparently not :-\
[23:23] <ccheney> i'm doing the work inside a chroot but did the bzr from outside apparently when i grabbed the packages
[23:24]  * asac mumbles about bzr
[23:24] <asac> so i need soup for glib?
[23:24] <asac> or for proxy?
[23:24] <ccheney> you need proxy for soup and proxy needs webkit
[23:24] <asac> where was the circle?
[23:24] <ccheney> and webkit needs soup
[23:25] <ccheney> so disable gnome support in soup then build webkit and proxy then rebuild soup with gnome enabled
[23:25] <asac> yeah. first need to build glib
[23:25] <asac> so guess i wont be of much help today
[23:25] <ccheney> ok
[23:29] <asac> ccheney: so where is ephy failing and how?
[23:31] <asac> if (priv->search_terms)
[23:31] <asac> there is a huge block of code rmeove there
[23:32] <asac> ephy-location-entry.c
[23:32] <asac> in editable_changed_cb
[23:32] <asac> just an experiment? or is that needed?
[23:33] <asac> ccheney: ?
[23:33] <asac> 1st. where is the current problem ;)
[23:39] <ccheney> oh sorry was on the phone
[23:39] <ccheney> just an experiment
[23:39] <ccheney> i was trying to forward port the old code to the new in that part and it wasn't working out
[23:40] <ccheney> backporting the entry code from gtk just into ephy doesn't look like it will work, or without a lot of effort since it changes already existing structs in hardy gtk
[23:41] <ccheney> so wasn't sure if trying to backport the entry code directly into gtk would work out, or if some other direction should be tried
[23:41] <asac> ccheney: what i mean is ... i take the current tarballs nad build them
[23:41] <asac> what happens?
[23:41] <asac> and what is in current tarballs? is there a port attempt?
[23:42] <asac> ccheney: i need to see where the new API is used in epiphany to check what to do
[23:42] <ccheney> it currently fails to build in ephy
[23:42] <asac> where and how?
[23:43] <asac> thats what i asked initially
[23:43] <ccheney> oh ok
[23:44] <ccheney> checking to see where it fails
[23:44] <ccheney> its failing in lib/widgets/ephy-location-entry.c
[23:44] <ccheney> due to the changes for the entry code
[23:45] <asac> error?
[23:45] <ccheney> if the various files related to that are reverted to original state they fail due to gtkentry not having new enough api in hardy
[23:45] <ccheney> as the code currently it fails due to: http://pastebin.ubuntu.com/391366/
[23:46] <asac> libxslt1-dev ... is that in universe?
[23:46] <asac> (in hardy)
[23:46] <asac> !info libxslt1-dev hardy
[23:46] <asac> hmm
[23:47] <asac> ok misinterpreted the apt error
[23:47] <asac> now its installing
[23:47] <ccheney> ok
[23:48] <asac> ok currently webkit is building
[23:48] <asac> then proxy
[23:48] <ccheney> ok
[23:48] <asac> then second soup run
[23:48] <asac> then i get to it i guess
[23:48] <asac> might need gtk too?
[23:49] <asac> thats a small patch adding two enums
[23:49] <ccheney> yea i think it needs those two enums at the moment anyway
[23:49] <asac> ccheney: so in the current epiphany its some incomplete state?
[23:49] <asac> or did you remove the experiemnts?
[23:50] <asac> ccheney: any other API parts you spotted that epiphany devs jumped on ?
[23:50] <asac> (of gtk)
[23:50] <asac> guess you didnt get that far
[23:52] <ccheney> yea its incomplete state
[23:52] <ccheney> not yet, i got part of it working then ran into entry bits that got me stuck
[23:53] <ccheney> the parts i backported that are still in the build are under lib/
[23:53] <ccheney> lib/gtk-* lib/gdk-* lib/glib-*
[23:55] <asac> ccheney: what api parts of gtkentry is ephy using that doesnt exist?
[23:56] <ccheney> https://wiki.ubuntu.com/epiphany-browser-backport-hardy
[23:56] <ccheney> lots of them
[23:57] <ccheney> it appears it was originally written in ephy then moved to gtk but changed a bit then ephy updated to use it and also a list of icons or something to that effect
[23:58] <asac> ok so for the entry stuff you cannot implement because you cant access the Private struct?
[23:58] <ccheney> from what i recall that the biggest part of the issue yes the private struct changes between hardy gtk and karmic gtk and the new entry stuff needs bits of the new private struct
[23:59] <ccheney> iirc they rewrote how the gtkentry code works as well when they added the new functions so i am not sure if the api is compatible


[03:10] <bilal> thumper: Hi
[03:10] <bilal> thumper: https://code.launchpad.net/~unity-team/unity/autohide-load-934514/+merge/117367 The answer is yes
[03:10] <bilal> should I re-propose for a ~unity-team review or will you take it up?
[03:22] <thumper> bilal: I've got it
[03:23] <bilal> thanks!
[03:23] <thumper> bilal: I think we need a manual test though
[03:23] <thumper> to make sure it doesn't regress
[03:23] <bilal> alright
[03:24] <bilal> I'll write one
[03:24] <thumper> thanks
[03:30] <bilal> thumper: test added, pushed, diff updated
[03:33] <marcavis> hey folks, we at #frogatto (also at www.frogatto.com, a 2d platformer game) are having an issue where, when we enter the game editor, the program tries to change its window size, which isn't working well on Unity; it keeps flickering between the former and the new size, for several seconds, sometimes crashing at the end. Have you heard of similar problems in other programs?
[03:34] <thumper> marcavis: no... please file a bug :)
[03:34] <thumper> marcavis: are the developers able to use your game editor to test?
[03:36] <marcavis> yes, the editor is built into the game, as well, accessible by pressing CTRL+E in the game
[03:36] <marcavis> (unneeded "as well" above)
[03:37] <thumper> marcavis: what toolkit does the editor use?
[03:37] <duflu> marcavis: I've seen the same bug happen with QEMU/KVM windows. It's probably compiz to blame.
[03:38] <marcavis> hmmm, makes sense... Frogatto just uses SDL/OpenGL, no specific GUI toolkits
[03:38] <duflu> marcavis: Yes, QEMU/KVM uses SDL too
[03:39] <duflu> marcavis: I can't remember if there ever was a bug for it. Please log one with "ubuntu-bug compiz"
[03:39] <marcavis> right... will do so in a bit
 marcavis: I can't remember if there ever was a bug for it. Please log one with "ubuntu-bug compiz"
[05:04] <marcavis> duflu, about that; doesn't gnome 3 use compiz as well?
[05:05] <duflu> marcavis: No, Gnome 3 has a different compositor.
[05:05] <duflu> marcavis: Unless you use "Gnome Classic" which is still compiz :)
[05:06] <marcavis> ahh, okay. though... yeah, I actually use the "Gnome Classic" session most of the time, and I don't get that bug
[05:07] <duflu> marcavis: "Gnome Classic" uses compiz. "Gnome Classic (no effects)" does not
[05:07] <duflu> marcavis: Which do you use?
[05:07] <marcavis> ahh, understood. Yep, it's the latter
[05:07] <duflu> marcavis: OK, please log then bug then
[05:07] <marcavis> In fact, I'll try the former just to be sure it's compiz...
[05:08] <marcavis> well, unless you are quite sure already
[05:13] <duflu> marcavis: Yes, I'm quite sure. But you don't have to have 100% certainty to log a bug. That comes later :)
[05:14] <marcavis> Right, I see.
[05:20] <Mirv> let's try the compiz again today..
[05:20] <marcavis> 'kay, reported
[08:15] <sil2100> Trevinho: hi!
[08:15] <sil2100> Trevinho: are you around?
[10:53] <sil2100> didrocks: hi
[10:53] <sil2100> didrocks: need some advice again
[10:53] <didrocks> hey sil2100
[10:54] <sil2100> didrocks: so, I would prefer to revert the gesture commits made to nux and unity, since they are causing a LOT of regressions
[10:55] <didrocks> sil2100: ensure you revert that in trunk first
[10:55] <sil2100> didrocks: the unity commit regarding gestures can be reverted easily
[10:55] <sil2100> didrocks: but now regarding nux - which is the preferable way? :
[10:55] <sil2100> didrocks: 1) reverting the commit in trunk
[10:56] <sil2100> didrocks: 2) modifying distro by adding --disable-gestures to autoconf?
[10:56] <sil2100> (since nux has the ability just to disable geis during compile)
[10:57] <didrocks> sil2100: no, if it's really buggy, always ask for trunk revert before reverting in the packaging branch
[10:57] <didrocks> sil2100: otherwise, we will have ids conflict next time you merge
[10:57] <didrocks> sil2100: and it means that this code is not mature enough
[10:57] <sil2100> didrocks: ACK, so trunk it is
[10:58] <sil2100> Thanks
[11:00] <didrocks> yw ;)
[11:06] <didrocks> plus que 3 sujets à développer dans le google doc \o/
[11:07] <didrocks> oupss, wrong window :)
[12:55] <ice_flame1> Hello
[12:56] <ice_flame1> Can I ask a question?
[13:01] <dandrader> mhr3, ping
[13:02] <sil2100> dandrader: hi! Since the gestures issue wasn't yet resolved, I'll be reverting the nux and unity changes - it seems there's a bug in geis somewhere
[13:02] <sil2100> dandrader: so not to delay the release any further, I'll just revert the revisions that were using the bug and thus causing severe regressions
[13:03] <dandrader> sil2100, ok. I cannot do much about it since I cannot reproduce the issue in any of my two computers
[13:04] <sil2100> dandrader: we'll help in finding the cause, I'm pretty sure Jay and the others have some leads already
[13:20] <mhr3> dandrader, pong
[13:20] <mhr3> dandrader, i think the geis dbus backend isn't playing nice, why did you move from xcb to dbus?
[13:22] <dandrader> mhr3, that dbus backend is not used anymore.
[13:22] <dandrader> mhr3, gesture recognition is done now all in-process
[13:22] <mhr3> dandrader, eh, my unity thinks differently
[13:23] <dandrader> mhr3,  now that's weird. is it with my "nux gestures" patch on?
[13:23] <mhr3> dandrader, yes
[13:23] <dandrader> that really should not be happening
[13:23] <mhr3> well, is that something special?
[13:24] <mhr3> or just trunk nux
[13:24] <dandrader> mhr3, xcb backend was used back when xserver was doing gesture recognition. this is now long dead
[13:24] <dandrader> mhr3, and the d-bus backend was used when there was a separate daemon doing the recognition. this is also no longer the case
[13:24] <mhr3> dandrader, so what's supposed to be used?
[13:25] <dandrader> mhr3, in geis, the *grail* backend is the one that *must* be used now
[13:25] <mhr3> dandrader, hmm, so why isn't it?
[13:25] <dandrader> meaning that there's a grail instance running locally, doing the gesture recognition locally
[13:27] <dandrader> mhr3, what makes you think geis in unity (behind nux) is using the d-bus backend?
[13:27] <mhr3> dandrader,     geis_warning("back end not specified, defaulting to DBus");
[13:27] <mhr3> that ^^
[13:27]  * dandrader checks code
[13:28] <mhr3> you're not passing any backend to geis_new afaict
[13:28] <dandrader> yep. and it should end up fetching the grail backend
[13:29] <Mirv> seb128: would you have time to upload the compiz SRU today?
[13:29] <seb128> Mirv, trying to
[13:30] <Mirv> ok, let's see :)
[13:30] <dandrader> mhr3, it should fail getting the d-bus one up and running and then fallback to grail
[13:30] <mhr3> dandrader, why should it fail?
[13:32] <mhr3> aaah, ok, yep, it does that
[13:32] <dandrader> mhr3, because there's no gestures daemon working
[13:32] <dandrader> mhr3, you can run compiz/unity with the env variable GEIS_DEBUG=6 to see what happens on the terminal
[13:32] <mhr3> i thought 3 was enough :)
[13:33] <dandrader> mhr3, might be. I always use 6 :)
[13:33] <dandrader> and for grail output you would add GRAIL_DEBUG=-1
[13:33] <dandrader> pretty standardized :P
[13:33] <mhr3> dandrader, any chance for quick patch so it uses grail right away?
[13:34] <mhr3> (maybe the dbus one doesn't get destroyed properly or something
[13:34] <mhr3> )
[13:34] <dandrader> mhr3, sure, let me prepare one for nux and pastebin it
[13:34] <sil2100> mhr3: is this regarding the recent regressions in unity/nux trunk?
[13:35] <mhr3> yes
[13:35] <sil2100> mhr3: is this something that will fix the regressions ;p ?
[13:35] <mhr3> we'll see soon
[13:36] <sil2100> And I spent so much time today, battling CMake and autotools to revert those changes...
[13:36] <sil2100> Will be funny if it ends up not being needed
[13:36] <mhr3> i wouldn't hold by breath :)
[13:37] <mhr3> s/by/my/
[13:37] <dandrader> mhr3, http://paste.ubuntu.com/1136123/
[13:39] <mhr3> thx
[13:39]  * mhr3 builds, tests
[13:40] <mhr3> dandrader, fixed :)
[13:40] <dandrader> mhr3, what!?
[13:41] <mhr3> sil2100, i was wrong, you could have hold your breath :)
[13:42] <sil2100> Oh noes
[13:42] <sil2100> mhr3: so what, no regressions? No launcher bollocks?
[13:42] <mhr3> dandrader, it's not nice that you ship deprecated modules that do weird things to dbus :P
[13:43] <mhr3> sil2100, no lockups of launcher, so i proclaim it works
[13:44] <mhr3> sil2100, so there's your patch ^^
[13:44] <sil2100> mhr3: \o/
[13:44]  * mhr3 goes back to his work
[13:45] <sil2100> mhr3: I'll test it, thanks! You're a life-saver
[13:45] <sil2100> dandrader: thanks to you too
[13:46] <dandrader> mhr3, oh my... you're my hero!
[13:47] <dandrader> cnd, please check the backlog ^^^^
[14:09] <sil2100> JohnLea: hi, are you around?
[14:09] <JohnLea> sil2100; hyia
[14:10] <sil2100> JohnLea: I have a question - since I'm browsing though some distro manual tests right now
[14:10] <JohnLea> sil2100; cool, fire away
[14:11] <sil2100> JohnLea: sent the test-case to priv
[14:19] <cnd> dandrader: great!
[14:19] <cnd> I wonder if the patch from bregma yesterday fixes the same issue
[14:22] <sil2100> https://code.launchpad.net/~sil2100/nux/geis_fix/+merge/118760 <- the patch as a merge request
[14:23] <sil2100> mhr3: tested it on my system, it works like a charm \o/
[14:30] <dandrader> jaytaoko, could you please review it ^
[14:30] <dandrader> or maybe cnd...
[14:30] <bregma> ftr, my patch yesterday would not fix the issue, it only affects the case of no geis daemon on the dbus _and_ no XI2.2 support for MT
[14:32] <bregma> not sure why the dbus query would make Unity go haywire, but the proposed patch will definitely avoid that case
[14:33] <jaytaoko> dandrader: reviewing...
[14:34] <cnd> dandrader: approved :)
[14:35] <sil2100> cnd: thanks for the review!
[14:35] <sil2100> jaytaoko: if it's ok with you, we can merge it in ;)
[14:35] <jaytaoko> dandrader: I am compiling to test it on my system
[14:36] <sil2100> jaytaoko: ACK :)
[14:36] <sil2100> jaytaoko: please approve the merge when you test it positively
[14:37] <jaytaoko> sil2100: dandrader: I can't reproduce the bug from yesterday. yeah!
[14:37] <dandrader> awesome
[14:37] <jaytaoko> sil2100: dandrader: anything you want me to test before I approve?
[14:38] <dandrader> no
[14:38] <sil2100> \o/
[14:38] <jaytaoko> sil2100: dandrader: ok, I am approving
[14:39] <jaytaoko> sil2100: I am merging it now. ok?
[14:40] <jaytaoko> sil2100: do we need the UNBLOCK?
[14:40] <sil2100> jaytaoko: approve it :) The UNBLOCK is needed, since we're in a freeze
[14:40] <sil2100> But I already added it
[14:40] <jaytaoko> sil2100: oh right!. Ok, I am merging it.
[14:41] <jaytaoko> sil2100: done!
[14:41] <sil2100> jaytaoko: thanks! :)
[15:00] <seb128> sil2100, jaytaoko: you will have "fun", the merger fails because nux fails to build with the quantal version of glew
[15:01] <seb128> sil2100, jaytaoko: somebody needs to fix nux to build with glew 1.8
[15:01] <sil2100> Aw come ooon ;p!
[15:01] <seb128> ;-)
[15:01]  * sil2100 chokes nux
[15:02] <sil2100> jaytaoko: ^
[15:02] <didrocks> sil2100: welcome welcome welcome :)
[15:02] <jaytaoko> seb128: hello!
[15:03] <sil2100> Maybe we can somehow stick with the old glew ? ;)
[15:03] <jaytaoko> seb128: sil2100: ok, i am on it
[15:03] <seb128> sil2100, no, we can't go back in versions in distro
[15:04] <jaytaoko> seb128: by the way, glew 1.9 has been released yesterday with support for opengl 4.3
[15:04] <seb128> sil2100, and there is no reason to downgrade system libs and break other stuff to avoid fixing nux
[15:04] <seb128> jaytaoko, yeah, I saw, I didn't want to jump directly on the just released version, Debian already had 1.8
[15:11] <jaytaoko> seb128: can I just install libglew1.8?
[15:12] <seb128> jaytaoko, yes, just apt-get install libglew-dev
[15:12] <seb128> the current version is 1.8 and will give you libglew1.8 with it
[15:14] <jaytaoko> seb128:ok
[16:03] <jaytaoko> seb128: sil2100: i am still on the glew problem...
[16:03] <seb128> jaytaoko, did you manage to reproduce?
[16:04] <jaytaoko> seb128: yes, I am reproducing the issue
[16:17] <jaytaoko> seb128: ping
[16:17] <seb128> jaytaoko, hey
[16:18] <jaytaoko> seb128: I may have found something: http://sourceforge.net/tracker/?func=detail&aid=3549981&group_id=67586&atid=523274
[16:19] <jaytaoko> seb128: it seems to describe the problem we are having
[16:21] <seb128> jaytaoko, so you think it's an issue in glew?
[16:22] <jaytaoko> seb128: I think so, I did a diff with the previous version of GLEW and I found that there is a bloc of function that is affected
[16:23] <seb128> jaytaoko, do you have a patch?
[16:23] <jaytaoko> seb128: these function are the one you see in the build errors
[16:23] <jaytaoko> seb128: no, I am first going to test that it works as per the recommended fix
[16:26] <jaytaoko> seb128: NuxGraphics has compiled
[16:27] <jaytaoko> seb128: so I don't know if this is "the fix" but I tried what was described in the link
[16:27] <jaytaoko> seb128: but that involves changing a file in /usr/include/GL/glxew.h
[16:31] <seb128> jaytaoko, let me finish what I'm doing and have a look
[16:31] <jaytaoko> seb128: ok, I am compiling unity as well to test
[16:41] <seb128> jaytaoko, does that fixes it: http://glew.git.sourceforge.net/git/gitweb.cgi?p=glew/glew;a=blobdiff;f=auto/src/glxew_mid.h;h=e9a3391acefafcc1b2979d2cfad1d43c602521c1;hp=cfcd20d472a790f461e01e6e20a570582452236c;hb=6d14805de58321e8a7b1881323e604bb0ba27217;hpb=38a3d857549e7ac31b7edb2a1cfa1ead52f72220 ?
[16:43] <jaytaoko> seb128: it should
[16:44] <seb128> jaytaoko, I'm backporting that and retrying nux, thanks
[16:45] <jaytaoko> seb128: ok unity has compiled and is running with my local fix.
[16:46] <seb128> jaytaoko, thanks for looking at it
[16:46] <jaytaoko> seb128: no problem...
[16:46] <jaytaoko> seb128: I am going to make the same fix as the link you posted just to be sure...
[16:46] <seb128> jaytaoko, I'm pushing to a ppa for testing
[16:47] <jaytaoko> seb128: ok
[16:48] <sil2100> jaytaoko: so, will you push the nux merge to Approved once this glew issue gets resolved :) ?
[16:49] <seb128> sil2100, I can retry the nux merge requests once that's in
[16:49] <sil2100> seb128: awesome, thanks!
[16:50] <seb128> sil2100, yw!
[16:50] <jaytaoko> sil2100: has soon as seb128 ppa is in, yes, we can try an merge again the geis fix
[16:51] <sil2100> \o/
[16:51] <sil2100> Excellent
[16:51] <sil2100> See you tomorrow everyone!
[16:54] <jaytaoko> seb128: I did the same fix as in your link and Nux compiled. it is looking good...
[16:58] <seb128> jaytaoko, I pushed it to quantal, it should be available in 30minutes
[16:59] <jaytaoko> seb128: cool! when can we approve the geis merge again?
[17:00] <seb128> jaytaoko, I will set it to approved when things are ok
[17:00] <jaytaoko> seb128: thanks!
[17:01] <seb128> jaytaoko, yw!
[17:33] <seb128> jaytaoko, https://launchpadlibrarian.net/112271202/buildlog_ubuntu-quantal-i386.nux_3.0.0-0ubuntu3~build1_FAILEDTOBUILD.txt.gz
[17:33] <seb128> jaytaoko, that patch is not good enough :-(
[18:07] <jaytaoko> seb128_:: I don't understand...
[18:08] <seb128_> jaytaoko, I will have a look, maybe that doesn't patch the right .h
[18:10] <jaytaoko> seb128_: ok
[18:11] <jaytaoko> seb128_: the file I patched locally is /usr/include/GL/glxew.h
[18:13] <seb128_> jaytaoko, yeah, that's not the one the git diff is patching
[23:01] <thumper> morning
[23:01] <thumper> where are we at now with the nux/unity release?
[23:02] <bschaefer> thumper, there was a regression in geis, but mhr3 found a fix but then there was a problem with something seb123 pushed causing Nux to not compile
[23:02] <thumper> bschaefer: and now?
[23:02] <bschaefer> thumper, I think, and jaytaoko was looking into getting Nux to compile to make unity merger happy to fix the regression the geis changes
[23:02] <thumper> bschaefer: I saw those results at 4am :)
[23:03] <thumper> really wondering what magic has happened in the intervening 7 hours :)
[23:03] <bschaefer> thumper, oo ok, yeah I think jaytaoko was looking into getting nux compiled (which I thought I saw he had a fix, but that branch isn't merged yet :( )
[23:04] <thumper> just saw the nux fix merge
[23:04]  * thumper goes to do an update
[23:04] <bschaefer> o nice!
[23:04] <bschaefer> so hopefully when that goes, then the geis fix merges then 6.2 is released! (im hoping at lease)