[00:00] <teward> sarnold, for the most part, "upstream" for the nginx package in relation to Ubuntu is Debian
[00:00] <teward> in relation to Debian, "upstream" is nginx.org
[00:00] <teward> and nginx.org *has* their own packages
[00:00] <teward> they're  not as admin-friendly though
[00:01] <teward> sarnold, i don't *mind* an Ubuntu delta for this addition of an extra binary that builds nginx.org-upstream-only modules.
[00:01] <teward> it's not *that* bad of a delta for me to keep working
[00:01] <sarnold> I expect the nginx.org packages are designed to work identically regardless if you're on debian, ubuntu, gentoo, arch, or centos, right? :) hehe
[00:01] <teward> since that's just adding a control entry and an extra ruleset for the modules
[00:01] <teward> "identically"?
[00:01] <teward> probably
[00:02] <teward> but "identically" is an obscure statement if you are including centos in that list
[00:02] <teward> since selinux can be evil there with ngixn
[00:02] <teward> nginx*
[00:02]  * teward kicks his keyboard from here to /dev/null and back
[00:02] <sarnold> oh sure, but that's not nginx's job to sort out :) hehe
[00:02] <teward> :P
[00:02] <teward> no, that's the centos people's job
[00:02] <sarnold> bingo
[00:02] <teward> it's also not "nginx"'s job to maintain the debian package
[00:02] <teward> that's mostly maintained by non-nginx-upstream people afaict
[00:04] <teward> sarnold, do we have anywhere on the wiki where we can document these things about certain packages?
[00:05] <sarnold> teward: not that I know of
[00:05] <teward> if all else fails I'll make an "NginxInMain" page in my own namespace regarding this, but...
[00:05] <teward> i want *somewhere* publicly listed the reasoning for this
[00:05] <sarnold> teward: very good idea.
[00:05] <teward> even if I have to create a page for it in wiki.u.c
[00:06] <teward> actually, how does one subscribe to notices for wiki edits in a given page/section of the wiki? (if you know)
[00:08] <sarnold> hrm, the 'new starter' page just says "subscribe to these regexs", doesn't mention how to do it..
[00:08] <sarnold> .. and clicking 'subscribe' on the front page of wiki.ubuntu.com just hangs
[00:09] <teward> so does logging in right now
[00:09] <teward> maybe someone should poke sysadmin about that?
[00:09] <teward> (laggggggggggg)
[00:20] <sarnold> teward: hey, the wiki is responsive again
[00:21] <sarnold> teward: once you're logged in you can click on your username, then notification, and add regexs as you need; or, you can subscribe to an individual page with the 'subscribe' link
[00:54] <infinity> teward: As I asked before, why do we need yet another ngingx binary, why not just drop the offending module(s) from -light and call it done?
[00:55] <infinity> Then if we just reverse the full|light depends for the 'nginx' metapackage, we can toss that in main too.
[00:55] <infinity> sarnold: ^
[00:56] <infinity> Looks like light only ships one third-party module, so that would seem the easiest course of action.
[00:57] <sarnold> infinity: I had considered suggesting that first, but -light is lacking UWSGI, spdy, and webdav; I figured the first two are mighty important, and the last one is perhaps convenient for someone..
[00:58] <infinity> sarnold: Oh.  So you want, basically, -full or -extras, minus third-party?
[00:59] <infinity> (Can modules not be distributed as DSOs, do they really need to be built in?  That would make this so much easier to deal with)
[00:59] <sarnold> infinity: sure, I didn't notice much difference among all the standard modules, but things felt -different- in the third-party modules.
[00:59] <infinity> Then you'd just have nginx-core and modules-extra modules-full modules-third-party...
[01:00] <sarnold> infinity: no idea there, but that would feel so much intuitive to me :)
[01:01] <infinity> Man, these really are all statically linked.
[01:01] <infinity> Ick.
[01:01] <infinity> So much ick.
[01:02] <infinity> "Nginx modules must be selected during compile, run-time selection of modules is not currently supported."
[01:02] <infinity> \o/
[01:02] <infinity> I guess we're stuck with the current state of affairs, then.
[01:04] <infinity> At least the rules looks like it would take 30 seconds to hack to support more flavours.
[01:55] <teward> infinity, if you mean like apache does
[01:55] <teward> that's planned
[01:55] <teward> but not implemented
[01:55] <teward> (yet)
[01:56] <teward> while on the topic of apache, it increases disk i/o crazily, which is why people kinda like nginx :p
[01:56] <teward> and other servers (still)
[01:56] <teward> but meh
[01:56]  * teward was busy and didn't see your messages until now
[01:56] <teward> infinity, it does take about 30 seconds to hack, but to match waht sarnold wants... i have to go poke the upstream package and get a list of what they compile in
[01:57] <teward> (nginx *has* an upstream package, but it's not as administrator friendly)
[01:57] <teward> i'm also stuck on windows until tomorrow
[01:57] <teward> so i can't do squat until then
[01:58] <sarnold> teward: no no, don't bother with checking the nginx.org packages, that's too much work :)
[01:58] <teward> :P
[01:58] <sarnold> teward: just disable the modules listed in the debian/control file as "third party modules" in a new binary package
[01:58] <teward> sarnold, ... right...
[01:58] <teward> sarnold, i still have to poke around to see if certain things're enabled or not :p
[01:58]  * teward yawns
[01:59] <teward> sarnold, what about the metapackage
[01:59] <teward> do we leave that in universe, or do we put nginx-core or w/e i name the new binary as the dependency on that
[01:59] <teward> since i know enoug hpeople use just `apt-get install nginx` and expect it to work
[02:02] <sarnold> teward: very good question. If I interpret infinity's suggestion loosely, we'd put nginx-main (or whatever) first in the list, then put the nginx metapackage in main also. but I really don't want to break existing users who might have installed 'nginx' but rely upon features from nginx-full
[02:02] <teward> sarnold, i was considering naming it nginx-core, because it's just the core packages.
[02:02] <teward> sarnold, in theory, could we do nginx-core|nginx-full|nginx-light?
[02:03] <sarnold> teward: ah, that's a good name.
[02:03] <sarnold> teward: yeah
[02:03] <teward> that way it doesn't break already-installed nginx-full/nginx-light + nginx metapackage installs
[02:03] <teward> but on new ones forces the use of -core
[02:03] <sarnold> I don't know what will happen on dist-upgrade.
[02:03] <teward> well, this is why sbuild exists
[02:03] <teward> and my staging ppa
[02:03] <sarnold> :)
[02:04] <teward> and the five other testing PPAs I have
[02:04] <teward> oh that reminds me, note to self, update my trusty VM
[02:04] <teward> since that's WAY behind and needs poked upwards before i can test
[02:05] <teward> sarnold, i'm probably gonna do two forms of testing...
[02:05] <teward> the first making sure that i put the rules in in such a way that i can get the -core one to build
[02:06] <teward> before I even get to testing the metapackage
[02:06] <sarnold> tell me about it, my testing trusty vm just downloaded 600 packages. sigh. :)
[02:06] <teward> (the packaging isn't exactly "neat" or "easy" here)
[02:06] <teward> sarnold, eww.
[02:06] <teward> sarnold, i might just nuke the VM I have now and install with the latest beta image or smth o.o
[02:07] <teward> sarnold, what's the timeline for the MIR changes, though, in terms of freezes I need to be aware of?
[02:07] <teward> I know feature freeze already happened, but...
[02:08] <sarnold> teward: we'll need to ask for a feature freeze exception; the fact that i didn't finish the MIR review ought to help encourage the release team to grant an ffe -- afterall, everyone -wants- nginx in, and this isn't exactly adding new features, just a few build-rules fiddling.
[02:08] <teward> sarnold, right...
[02:08] <teward> sarnold, you're gonna have to support the debdiff then when we ask for an FFe for this MIR...
[02:09] <teward> and note we got in 1.4.5 to trusty while you were reviewing 1.4.4
[02:09] <sarnold> teward: yeah, it seemed easier to continue where I was :)
[02:09] <teward> so any debdiffs're gonna be based off of 1.4.5
[02:09] <sarnold> though they had fixed the only bug I found. haha.
[02:09] <teward> heh
[02:14] <teward> sarnold, ooo i forgot about the rest of the packaging
[02:15] <teward> sarnold, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/nginx/trusty/files/head:/debian/
[02:15] <teward> sarnold, this is far more than just 30 seconds of work
[02:15]  * teward points at the other files
[02:15] <teward> such as install, preinst, postinst, etc.
[02:15]  * teward has a headache already >.<
[02:16] <sarnold> teward: definitely, it'd take me most of an afternoon before I think I'd have built packages to test. and I'm ususally too optimistic.
[02:16] <teward> sarnold, you were expecting about a ~50 lines debdiff?  probably safer to say closer to ~500 lines
[02:16] <teward> that much harder to get an FFe, maybe?
[02:16] <sarnold> teward: well, 75 lines. but I hope it's not too bad..
[02:16] <teward> i'm exaggerating, with 500
[02:16] <teward> but still
[02:16] <teward> it's not gonna be "small" like some security debdiffs or segfault debdiffs
[02:17] <sarnold> *nod*
[02:17] <teward> it's substantially larger :/
[02:17] <sarnold> I just finished doing some 'new library' debdiffs for apparmor; despite how much time it took, the changes were actually surprisingly small..
[02:19] <teward> i'm probably gonna end up cloning the nginx-full stuff and just tweaking it.
[02:19] <teward> rename things to nginx-core and such
[02:19] <teward> trim out stuff that doesn't apply, and what not
[02:20] <infinity> sarnold: dist-upgrade will be fine, it's an OR dep.
[02:20] <infinity> sarnold: Sort of the whole point of OR deps is to give the user choice.
[02:20] <sarnold> infinity: thanks
[02:20] <sarnold> infinity: well, okay, it feels a bit more obvious when you put it that way :)
[02:21] <infinity> teward: It should be tiny... Add a package to debian/control, a new configure stanza in rules, and copy the .install files.
[02:21] <infinity> (Well, okay, not "tiny", but obvious and small from a reviewability perspective)
[02:22] <teward> infinity, true.  my only concern is if, like, something bad happens and it ends up turning into a hack job
[02:23] <teward> which it *shouldn't* if i base it off what already exists for -full
[02:23] <teward> infinity, the debdiff's gonna catch all the new .install, .pre* etc. files though
[02:23] <infinity> Yeah, that's fine.
[02:23] <teward> that's what i mean by being "more than would normally be expected"
[02:23] <teward> but this is a project for tomorrow, i'm still stuck on this [WORDS REMOVED] Windows system.
[02:24] <infinity> I could just whip it up now. :P
[02:25] <teward> infinity, i'd like to put my name on the debdiff though :p
[02:25] <teward> infinity, besides, i need something to do tomorrow
[02:25] <teward> rather than sit on my butt doing nothign
[02:27] <teward> oh good this ISO's done downloading (finally, after 4 hours)
[02:27]  * teward boots into Linux
[02:27] <infinity> teward: I'm kinda halfway done.  But you're welcome to have it when I am. :P
[02:39] <infinity> teward: http://paste.ubuntu.com/7013893/
[02:39] <infinity> teward: Merry Christmas, you get to write a changelog that doesn't suck. ;)
[02:39] <infinity> sarnold: ^-- That look like what you had in mind?
[02:39] <sarnold> "stuff and things" :) haha
[02:40] <sarnold> teward: hey you were closer, 297 line debdiff
[02:42] <sarnold> infinity: ACK. looks great. :)
[02:47] <infinity> sarnold: Builds fine, debdiffs of the binaries look sane.
[02:57] <teward> sarnold: infinity: yeah, that's about what I get, i'm test-building in sbuild before i make the debdiff uploaded with my name on it instead
=== _salem is now known as salem_
[02:57] <teward> because I'm crazy paranoid
[02:57] <teward> and i want to make sure it actually builds here too
[02:57] <teward> since i have two custom builds that'd be based off of this in a private apt repository on my network
[02:57] <teward> (so I need to know it builds :P)
=== salem_ is now known as _salem
[02:58] <infinity> teward: Did diff I gave you builds and produces sane binaries, already tested.  But do test again.
[02:58] <infinity> teward: And if your diff is significantly different from mine, I'd be curious why.
[02:59] <infinity> (Note, if you were tempted to reproduce the Breaks/Replaces bits, those are unnecessary, since that old version of -core never existed)
[03:00] <teward> infinity: yeah i did add that, but i can remove that from the debdiff before i submit it
[03:00] <teward> (it may be unnecessary, but i added it in because consistency)
[03:01] <teward> they look basically identical, save for the debian/changelog entry
[03:01] <teward> ... note to self, don't let sbuild chroots go for weeks without updating >.>
[03:07] <teward> infinity: there will be minor differences, like, in the rules, I put the core build-dir after the existing config rules and builddir rules, and put it at the end of flavours.  i could easily switch them around to match your changes
[03:08] <pranith__> can someone point me how to create a package from source? I am trying to package gnu global which is here: https://code.launchpad.net/~bobby-prani/gnuglobal/global-6.2
[03:09] <pranith__> I am following instructions here but getting errors: http://packaging.ubuntu.com/html/packaging-new-software.html
[03:11] <teward> sarnold: infinity: Am I being too verbose in my changelog entry here?  http://paste.ubuntu.com/7013991/
[03:11] <teward> (opinions and suggestions welcome)
[03:14] <darkxst> pranith__, we are not mind readers, post logs of the failure ;)
[03:14] <sarnold> teward: perhaps modify the nginx-core.* line to say which ones you copied from -- but looks good to me, thanks
[03:14] <teward> sarnold: that one's easy :p
[03:17] <pranith__> darkxst, I created a branch of upstream source on launchpad and I am not seeing the source files in it...
[03:17] <pranith__> so when I try to compile it.. it is erroring out when applying the patches
[03:18] <teward> sarnold: infinity: this look about right to ya?  http://paste.ubuntu.com/7014014/
[03:18] <teward> (that's the entire debdiff I have)
[03:20] <Noskcaj> pranith__, Please link us a build log
[03:23] <sarnold> teward: line 85 looks off, nginx-core-dbg Depends: on nginx-full, not nginx-core
[03:26] <sarnold> teward: line 269 looks off, it does a cd $(BUILDDIR_full) instead of $(BUILDDIR_core)
[03:30] <teward> sarnold: oops
[03:31] <teward> sarnold: that it?
[03:31] <sarnold> teward: it's all I spotted :)
[03:32] <teward> sarnold: http://paste.ubuntu.com/7014046/ is the version that includes those fixes, if you'd like to go over it or have others go over it before i upload the .debdiff and attach to the MIR, feel free to.  :)
[03:40] <sarnold> teward: both nginx-full and nginx-core have a Description that includes "(standard version)" -- it might be worth changing the nginx-core and nginx-core-dbg Descriptions to say "(core version)" so that apt-cache search nginx | grep ^nginx  will show a difference between the packages
[03:41] <infinity> teward: ubuntu2, not ubuntu1.1 ... And all the diffs between mine and yours look to be mistakes.
[03:41]  * teward grumbles
[03:41] <infinity> http://paste.ubuntu.com/7014075/
[03:42] <infinity> So, description issues, line-wrap issues, and whitespace issues.
[03:42] <teward> yeah...
[03:42] <teward> that's probably a side effect of me being tired >.>
[03:45] <infinity> Small mistakes, mind you, but I'm anal. :P
[03:45] <teward> infinity: the whitespace issue on the rules file i don't see
[03:45] <teward> i think i actually *fixed* that...
[03:46] <infinity> teward: The diff you pasted has an extra tab there that doesn't need to be.
[03:46] <infinity> Which doesn't break GNU make anyway, but meh.
[03:46] <teward> ahhh
[03:50] <teward> infinity: okay, see, if there is an extra tab in there, gedit can't find it.  http://paste.ubuntu.com/7014088/ doesn't seem to have that extra tab where your diff of the diffs says it should be
[03:50]  * teward yawns
[03:50] <teward> i should seriously probably go to bed >.>
[03:50] <teward> (and thanks for checking these things though)
[03:55] <Noskcaj> Could someone please sponsor a few packages? The queue is now on 50 different things
[03:55] <teward> infinity: i do kinda want to get this uploaded, though, so hopefully there's nothing wrong with this debdiff (i've remade it enough xD)
[03:55] <teward> s/uploaded/debdiff uploaded to the Launchpad bug/
[03:58] <infinity> teward: That's missing the extra tab, but has an s/core/full/ bug.
[03:58] <teward> grrrr
[03:58] <infinity> teward: Do you need a sponsor for this?
[03:58] <infinity> http://paste.ubuntu.com/7014124/
[03:58] <infinity> If so, I'll just fix the three issues there and upload.
[03:58] <teward> infinity: the procedure is upload to the Launchpad bug, get FFe (if nobody yells at the debdiff), then upload
[03:59] <teward> unless you can also approve an FFe
[03:59] <teward> s/upload/find a sponsor to upload to trusty/
[03:59] <infinity> I can.
[03:59] <infinity> My sponsoring would be tacitly approving the FFe at the same time. :P
[04:01]  * Noskcaj directs infinity to bug 1282937
[04:01] <ubottu> bug 1282937 in xfburn (Ubuntu) "FFe: Please package xfburn 0.5.0" [Undecided,New] https://launchpad.net/bugs/1282937
[04:01] <teward> infinity: http://paste.ubuntu.com/7014141/ is the latest iteration, please check
[04:01] <teward> infinity: and i will need a sponsor, I have yet to finish a PPU application and file it
[04:02] <teward> because (1) lazy, (2) work, (3) [secret reasons]
[04:03] <teward> infinity: at least, i think that last iteration is right
[04:03] <teward> it may not have copied right :/
[04:03]  * teward yanws
[04:03] <teward> bleh, i can't even type "yawns" right >.>
[04:04] <infinity> teward: That iteration's better, except for the space in control that's driving me nuts that I'll strip before I upload. :)
[04:05] <teward> infinity: heheh, the extra space in the control file is really irking you isn't it xD
[04:05] <infinity> You have no idea.
[04:05] <infinity> Anyhow, if you're happy with this, I'll upload it.
[04:06] <YokoZar> infinity: Were you the one I was supposed to poke ~ wine1.6 being stuck in proposed
[04:06] <YokoZar> due to britney not liking the cross-arch wine1.6 dependency
[04:06] <teward> infinity: lemme upload it to the launchpad bug
[04:07] <teward> because i'm in on a temporary folder that'll get nuked after a while
[04:07] <teward> so i want this debdiff to be visible there :P
[04:07] <infinity> YokoZar: Maybe.
[04:07] <infinity> teward: Oh, the MIR also mentions that this needs to be bumped to the lua version in main while we're at it.
[04:08]  * infinity test builds with s/5.1/5.2/
[04:09] <teward> infinity: say what now?
[04:09] <teward> infinity: did I miss that?
[04:09] <infinity> teward: Yes.
[04:10]  * infinity test builds with lua5.2.
[04:11] <pranith__> Noskcaj, I created a local branch from lp:global and added the necessary debian files
[04:12] <pranith__> when I try to give the command bzr builddeb ... it errors out saying not able to get orig-source
[04:12] <teward> infinity: if that works i'll bump the build-deps, but the lua dep is for the universe package :/
[04:15] <teward> infinity: and do let me know if it works, as i can add the change to the changelog and the debdiff
[04:15] <infinity> Nope, it's going to need a patch, probably.
[04:16] <pranith__> where do I added the upstream source info so that bzr get-source-package does not fail?
[04:16] <teward> infinity: if and only if the Lua module, which is third party, works with 5.2
[04:16] <pranith__> add*
[04:16] <infinity> teward: That sentence didn't make a whole lot of sense. :P
[04:17] <pranith__> or create a source tar ball from my current tree while packaging?
[04:17] <teward> infinity: you're right, i'm tired, it happens
[04:18] <teward> infinity: your "it's going to need a patch, probably" statement is throwing me off, which needs the patch, the nginx lua module? or something else?
[04:20] <pranith__> darkxst,
[04:20] <pranith__> ?
[04:21] <teward> infinity: actually, I checked the upstream source for that module - https://github.com/chaoslawful/lua-nginx-module
[04:21] <teward> infinity: it doesn't support 5.2 yet.
[04:23] <infinity> Where there's a will, there's a way.
[04:23] <teward> infinity: the only option to address that would be to disable the module, which means I think we can then drop the Lua build-dep
[04:23] <infinity> That's hardly the only option. :)
[04:23] <sarnold> how bad is the breakage?
[04:25] <teward> infinity: if you've got a better option i'll take it :P
[04:25] <teward> infinity: i expect, though, that there'll be a FTBFS, and unless you can recode the module for 5.2, well...
[04:25] <teward> then there is no patch to fix it
[04:25] <teward> (yet)
[04:27] <teward> okay, i can't stay up any more without running the risk of passing out over my keyboard, if you find a fix let me know, infinity, but use a privmsg, because otherwise I might miss it
[04:28]  * teward is going to bed
[04:28] <sarnold> wow, looks like lua5.2 dropped a -lot- of stuff: http://www.lua.org/manual/5.2/manual.html#8
[04:28] <sarnold> g'night teward, have a good weekend
[04:28] <teward> is this channel logged on the irclogs?
[04:29] <teward> if it is then i'll go digging tomorrow for any highlights i got :/
[04:29] <teward> ... i answered my own question
[04:29] <teward> g'night.
[04:57] <Noskcaj> pranith__, Make the bzr branch with bzr branch lp:ubuntu/global
[04:58] <infinity> teward: Okay, I took a stab at porting it, but it's a more significant effort than I have time for tonight.
[04:58] <infinity> teward: Talk to me on Monday if you want some pointers, or nag upstream to fix it. :P
=== ev_ is now known as ev
[11:53] <toclax> Hi, I want contribute to ubuntu with code and repair packages but I don't know how start... someone could guide me?
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
=== freeflying is now known as freeflying_away
=== Lutin is now known as Guest30483
[17:21] <teward> infinity: upstream fixing it would be lovely, but I don't think they're even taking a stab at it yet based on their github
[18:30] <teward> infinity: i poked upstream for that lua module and they said they'd take a look at getting it ported to 5.2 today, or at least compatible.  I hope upstream knows what evil they're going to be facint
[19:16] <Laney> mlankhorst: Do you have some useful way to identify wine fixes? 1.6 broke an application for me vs. 1.4 which works again with 1.7.13 from the ppa
[19:40] <Noskcaj> Can someone please review https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfdesktop4/merge ? It fixes a bug with over 140 affected users
[19:45] <rbasak> infinity, sarnold, teward: just reading scrollback. I'm interested to hear opinions (from upstream, maybe) about how useful the pieces that we'll have in main will be to end users. Will they all end up having to the bits in universe instead, and in that case, how useful is the MIR? I don't mean to imply one answer or another; I'm just asking the question.
[20:14] <mlankhorst> Laney: no, in general wine has weird cycles :\
[20:15] <Laney> so it'd be good to get this fix, whatever it is, into 1.6 ...
[20:16] <mlankhorst> yeah but without a reverse regression test.. no idea
[20:16] <mlankhorst> maybe wine appdb has information
[20:17] <Laney> nein
[20:17] <mlankhorst> doesn't even say which wine version started working? in that case you're on your own :x
[20:18] <jtaylor> I also have a wine fix for 1.4 I'd like in but I'm very confused with the current status
[20:18] <jtaylor> do I stillm need to bother with 1.4?
[20:19] <Laney> trusty has 1.6 now
[20:19] <jtaylor> oh it migrated
[20:19] <jtaylor> nice
[20:20] <mlankhorst> Laney: what application?
[20:20] <jtaylor> but the 1.4 still is in the archive?
[20:22] <Laney> mlankhorst: http://appdb.winehq.org/objectManager.php?sClass=version&iId=26410
[20:23] <mlankhorst> so what broke?
[20:26] <Laney> It could launch the application but it'd just give me a dialog saying "YNAB has encountered a problem"
[20:27] <Laney> there was a 'more details' button but it had 'null' for the stack trace so that's not very useful
[20:30] <knocte> do the unity devs hang out here?
[20:30] <mlankhorst> yeah, installing wine1.6-dbg{,:i386} package might help
[20:31] <mlankhorst> but it seems like it's using its internal handler which makes things harder
[20:31] <mlankhorst> is there anything useful in the console when it crashes?
[20:31] <Laney> this dialog was internal to the application
[20:31] <Laney> it was handling the crash somehow
[20:31] <mlankhorst> yeah, anything in the console window at the time of crash?
[20:31] <Laney> nothing useful
[20:32] <Laney> can I downgrade back to 1.6?
[20:32] <Laney> it did some 'upgrading .wine' thing
[20:32] <mlankhorst> no idea then, I would try to install older wine1.7 packages, find the first workng one
[20:32] <mlankhorst> yeah usuall
[20:32] <mlankhorst> usually*
[20:32] <Laney> getting those is going to be a pain
[20:32] <Laney> oh actually they're here https://launchpad.net/~ubuntu-wine/+archive/ppa/+packages?field.name_filter=&field.status_filter=superseded&field.series_filter=trusty
[20:35] <mlankhorst> try the oldest one for saucy first
[20:35] <mlankhorst> then you know how much of a pain it will be :p
[20:42] <Laney> launchpadlib is a beautiful thing
[20:51] <Laney> mlankhorst: bad news, 1.7.8 is the oldest available and it works
[20:57] <mlankhorst> fun
[20:58] <Laney> can you give me 1.7.4 debs?
[20:58] <Laney> or older
[21:01] <alberts> Hi! Maybe someone here are able to help me regarding gtk? http://stackoverflow.com/questions/21969436/how-to-make-gtkplug-transparent-so-that-gtksocket-background-is-seen.
[21:06] <knocte> where's the source code of unity that checks the UBUNTU_MENUPROXY env var? https://launchpad.net/unity doesn't contain this check
[21:07] <knocte> alberts: I guess you would have better luck in irc.gnome.org/gtk+
[21:20] <Noskcaj> debfx, Is it worth packaging the latest steam bugfix release for trusty? Changes are at http://paste.ubuntu.com/7018443/
[21:44] <Noskcaj> bdrung, Could you package python-versiontools for debian? It's needed to fix the gevent-socketio ftbfs in ubuntu (and should be a build-depend of gevent-socketio in debian)
[21:48] <bdrung> Noskcaj: yeah, i could do that. can you send me a reminder to benjamin.drung@profitbricks.com?
[21:49] <knocte> where's the source code of unity that checks the UBUNTU_MENUPROXY env var? neither https://launchpad.net/unity nor https://code.launchpad.net/~ubuntu-branches/ubuntu/trusty/indicator-appmenu/trusty contain this check
[21:59] <mdeslaur> knocte: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/unity-gtk-module/trusty/view/head:/src/main.c#L826
[22:00] <knocte> mdeslaur: great! thanks
[22:00] <mdeslaur> yw
=== jackson is now known as Guest95629
=== jono is now known as Guest92194
=== Guest95629 is now known as Noskcaj
[23:26] <teward> rbasak, I think some people rely on the third-party stuff, but rely on nginx-extras for that.  Ultimately, you may be right, people're going to use the bits in Universe over the stuff in Main.  Either way, I'll keep on maintaining it, but I think jcastro is gonna look like an idiot for saying it is likely to get into Main in his blog post (which has now ended up pretty much everywhere)
[23:26] <teward> in the instance that we don't ahve something in main
[23:26] <teward> infinity, sarnold: ^
[23:30] <stgraber> well, people shouldn't blog about a package getting moved into main until the MIR has actually been approved ;)
[23:31] <teward> stgraber, tell that to jcastro
[23:31] <teward> i think there's a log about it in the community team channel, where I called him out on that