[03:25] <foxx> if anyone has a moment, i would appreciate a code review of my first debian package.. criticisms are most welcome.. i'll be doing a blog article about my experiences with debian packaging shortly after, so want to make sure this package ive done is correct! https://github.com/foxx/atlassian-bamboo-debian/
[04:50] <foxx> one improvement i was thinking of making was make the package Makefile install to temporary directory, and then use postinst to move the tmp dir into the right place.. this means you can have non impacting upgrades (i.e. say an upgrade fails, it just deletes the tmp dir without leaving any files overwritten.. it also means you can ensure that an 'abort' works cleanly/sanely) - does that
[04:50] <foxx> sound right?
[11:45] <ESphynx> xnox: ping ;)
[11:45] <xnox> ESphynx: hola =) UDS is here =)
[11:45] <ESphynx> xnox: UDS? trying to wrap up this 0.44.04 so it can make it into Raring here...
[11:45] <ESphynx> xnox: adding you in the credits... do you prefer xnox or your full name? :P
[11:46] <ESphynx> xnox: i'm hoping you'll help me sponsor this update in a heart beat when it's ready :P This adds 64 bit support
[11:55] <xnox> ESphynx: no need to credit me at all. i did nothing, and one can check see that I sponsored the uploads.
[11:55] <xnox> and that is enough.
[11:55] <ESphynx> xnox: just a special thanks :P
[11:55] <xnox> ESphynx: yes, UDS. https://uds.ubuntu.com/
[11:55] <xnox> Ubuntu Developer Summit
[11:56] <ESphynx> nice :)
[11:56] <ESphynx> special thanks -- if you don't mind :) is your name OK?
[12:38] <quickQuest> Hi, i am using Ubuntu precise 12.04 LTS, and the latest package for mysql is version: 5.5.29, i noticed a memory leak and i was told that it's fixed in 5.5.30
[12:38] <quickQuest> is there anywhere, where i can request this 'package upgrade' ?
[12:40] <sladen> quickQuest: Launchpad -> file bug
[12:42] <quickQuest> sladen: thanks, so for any package with is by default 'provided with ubuntu' i can still file a bug to ubuntu so they update the package
[12:45] <sladen> quickQuest: I'm unclear; where did the package come from?  From the Ubuntu archives, or from a separate PPA?
[12:46] <sladen> quickQuest: generally something is updated in the development version of Ubuntu, and then backported to previous releases if there is enough of a case to be made for doing so (as there is a risk at the same time)
[12:47] <quickQuest> sladen: yeah the risk was something which i had in mind and i wasn't sure if they do it automatically or somebody has to request it basically
[12:49] <quickQuest> sladen: it is a package from ubuntu archives, so that's why i was asking where can i tell ubuntu about it
[12:49] <sladen> quickQuest: for security updates, the benefits outweigh the risks and so the security team normally do this as quickly as it is safe to do so
[12:49] <sladen> quickQuest: for other updates, there is a conflict between the stability and predictability of an LTS (hence the reason you deployed it), and updating software to the latest
[12:50] <sladen> quickQuest: to make a case for a Stable Release Update (SRU) you'll need to show that the proposed update from the development release has been carefully tested by multiple people
[12:52] <quickQuest> sladen: thanks for your information, it's a bit more clear now :)
[12:53] <ockham> hi, i've got a question about SRUing. in precise, the photoprint package is completely broken, see bugs #1136290 and #260849. the latter has a comment (#38) that suggests that version 5.2.9 (which is both in quantal and raring) fixes this, and that upstream highly recommends updgrading.
[12:53] <ockham> now here's my question: could some MOTU do just that? ;-)
[12:54] <ockham> v5.2.9 of gutenprint, that is
[13:08] <tumbleweed> ockham: always try to find a minimal patch for SRUing
[14:11] <menesis> hello, I need sponsors for three new packages
[14:12] <menesis> two are new plugins, and one contains documentation
[14:12] <tumbleweed> the usual question: why aren't they in Debian?
[14:13] <menesis> for schooltool, a school information server that I maintain in Ubuntu
[14:13] <tumbleweed> ah yes, that's Ubuntu only
[14:13] <menesis> http://pad.lv/385036 http://pad.lv/1147311 http://pad.lv/1147352
[14:14] <menesis> I will ask for them to be added to schooltool packageset that I have the rights for, but I don't have motu rights
[14:15] <tumbleweed> yeah, looking at them
[14:15] <menesis> thank you tumbleweed
[14:16] <foxx> @all in ref to https://github.com/foxx/atlassian-bamboo-debian/ - one improvement i was thinking of making was make the package Makefile install to temporary directory, and then use postinst to move the tmp dir into the right place.. this means you can have non impacting upgrades (i.e. say an upgrade fails, it just deletes the tmp dir without leaving any files overwritten.. it also means
[14:16] <foxx> you can ensure that an 'abort' works cleanly/sanely) - does that sound sane?
[14:18] <tumbleweed> foxx: no
[14:18] <tumbleweed> postinst should be as simple as possible
[14:18] <tumbleweed> and it's really helpful to everyone if dpkg's package manifest matches reality
[14:20] <foxx> hmm, so lets say the install or upgrade is aborted... any files copied in by the packages makefile will automatically be reverted out right?
[14:21] <foxx> in which case, the only thing i need to handle is reverting any customizations ive done in my postinst during abort if needed
[14:21] <tumbleweed> foxx: either dpkg refuses to install, because dependencies aren't met
[14:21] <tumbleweed> foxx: or it installs
[14:21] <tumbleweed> what kind of aborting are you thinking about?
[14:22] <tumbleweed> and the makefile isn't involed in installation
[14:24] <tumbleweed> menesis: you don't like dh_sphinxdoc ?
[14:24] <foxx> hrm, i might be getting confused here.. at one point during dpkg, i hit ctrl + c to interrupt the install. after that, i was unable to purge or force install because of half left over changes from the previous aborted install
[14:24] <foxx> is that something that just cant be avoided?
[14:25] <tumbleweed> the sysadmin has to resolve that, dpkg won't let you do anything else until you do
[14:25] <tumbleweed> packages don't try and work around anything like that
[14:25]  * jtaylor didn't even know you could abort it
[14:25] <jtaylor> I though it ignores ^C
[14:25] <tumbleweed> same
[14:26] <jtaylor> or is that just apt?
[14:26] <foxx> ahh
[14:26] <foxx> okay that makes more sense, and makes life a lot easier lol
[14:26] <foxx> also, i really appreciate the help tumbleweed and everyone else has given, i probably wouldnt have got this far without it.. so ive included a small acknowledgement at the bottom of the README to show my appreciation
[14:27] <tumbleweed> np :)
[14:28] <jtaylor> is there another session on whats done with raring? the one yesterday had no conclusion
[14:28] <jtaylor> or I missed it :/
[14:28] <tumbleweed> sadly, not to my knowledge
[14:28] <menesis> tumbleweed: dh_sphinxdoc you say... didn't know about it. yeah it should do what's needed.
[14:29] <tumbleweed> menesis: it looks like you are using bits of it...
[14:29] <tumbleweed> just not actually using dh_sphinxdoc :)
[14:29] <menesis> I adapted packaging from ubuntu-packaging-guide
[14:29] <tumbleweed> also, always set -e before executing multiple shell things on one line in make (unless you know you don't need to)
[14:30] <menesis> in regular makefiles, not only debian/rules?
[14:30] <menesis> yes I forgot that
[14:31] <tumbleweed> I meant debian/rules
[14:31] <tumbleweed> but yeah, everywhere in make :)
[14:31] <menesis> thanks for advice
[14:46] <foxx> @all got a design question.. I'm attempting to use Debian packages to push webapp releases into our production servers (there's an automated build server that creates the packages etc).. In this example, it's a django helloworld project. I can't decide whether the build scripts should be kept in their own seperate repo, or kept inside the repo where the helloworld application is..
[14:46] <foxx> having it inside its own repo ensures the release process can never be accidently broken by developers.. but increases complexity slightly and adds another repo into the mix
[14:48] <Zhenech> are you using jenkins?
[14:48] <foxx> no, bamboo
[14:51] <foxx> personally, im thinking that keeping it seperate would be good. you could even go as far as storing application settings in there (such as database config, server paths etc)
[14:55] <Zhenech> if you would use jenkins I would suggest jenkins-debian-glue :)
[14:57] <foxx> *googles*
[14:57] <foxx> also - i just hit this bug lol
[14:57] <foxx> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590052
[14:57] <foxx> dev1 hmee # pwd
[14:57] <foxx> dev1 hmee # pwd
[14:57] <foxx> /hmee instead of /home lol
[14:58] <foxx> jenkins-debian-glue looks nice
[16:19] <foxx> @all ahh okay putting app config into the build repo = bad idea.. cos say a package gets built, one goes to a server in UK, the other goes to a server in the US.. both point to a replicated db, but the IP space is different on either side
[17:06] <micahg> cjwatson: would you mind if I merged blender before feature freeze?
[17:08] <cjwatson> micahg: Not at all, go ahead
[17:08] <micahg> thanks
[17:29] <micahg> jbicha: I see you were a bit quicker than me with blender
[17:35] <menesis> tumbleweed: I have changed schooltool-book to use dh_sphinxdoc
[17:37] <jbicha> micahg: I'm afraid https://buildd.debian.org/status/logs.php?pkg=blender&arch=powerpc doesn't look good though
[17:38] <micahg> hrm, looks like a missing include somewhere
[17:39] <micahg> that or a bug in the code
[17:39] <micahg> more likely the later given that it wants a "huh"
[17:40] <jbicha> nice
[17:41] <micahg> being that I don't have hardware or a porter box, I'm reluctant to dig into it
[17:43] <jbicha> same here, except it's rare that I'm able to figure out how to fix build problems on other archs
[18:04] <tumbleweed> menesis: looking again
[18:27] <tumbleweed> ok I lied, but actually looking now :P
[18:48]  * tumbleweed grumbles at native packages
[18:55] <jtaylor> so feature freeze tomorrow or not?
[18:55] <tumbleweed> atm, yes
[18:55] <jtaylor> k then I should probably upload shiboken
[19:08] <jtaylor> k opening a dialog a couple dozen times did not increase memory usage, good enough for me :)
[19:12] <ockham> tumbleweed: not sure if you've been following #debian-python, but would you mind taking a look at https://github.com/thinkle/gourmet/tree/debian (and, erm, eventually upload it to raring?)
[19:13] <tumbleweed> I saw it, and grumbled at your "I don't want to do this in Debian"
[19:14] <TheLordOfTime> anyone know where I can find the results of a UDS discussion regarding nginx and whether it should be moved to main or not?
[19:14] <TheLordOfTime> due to the snow storm knocking out my power, i missed the session.
[19:15] <TheLordOfTime> (I thought I'd ask here because MOTUs would probably know whether there was anything that came from it)
[19:15] <tumbleweed> TheLordOfTime: you can still watch it / read the etherpad
[19:15] <ockham> tumbleweed: i'd normally LOVE to do this in Debian, but it seems to involve a lot of cherry-picking for some minimal NMU, which means i have to wait for another upload for the rest of the debian/ changes.
[19:15] <TheLordOfTime> tumbleweed, i'm getting timeouts to the UDS site, so... i can't right now, i'll have to take a look later, once i figure out what's up
[19:16] <TheLordOfTime> i betcha network routing with the ISP is regionally broken
[19:16] <tumbleweed> I keep having live streams drop out :/
[19:18] <tumbleweed> ockham: yeah, that was unresearched grumbling
[19:18] <ockham> tumbleweed: :-)
[19:19]  * tumbleweed is alternating between LTE and 3 ADSL accounts, moving around when one starts getting choppy (so far LTE wins)
[19:23] <jtaylor> hm: ImportError: libpyside.cpython-33m.so.1.1: cannot open shared object file: No such file or directory
[19:23] <jtaylor> the file exists
[19:23] <jtaylor> qtcore.so is linked against it
[19:23] <jtaylor> no undefined references
[19:23] <jtaylor> what else could be wrong?
[19:25] <Zhenech> some file that one is linked against is missing?
[19:26] <jtaylor> wait found missing file, yey restart a 2 hour build
[19:27] <tumbleweed> :)
[19:27] <jtaylor> I should probably reduce the timeout for the failing tests, its waiting 10 minutes on each
[19:27] <tumbleweed> if we are ignoring results...
[19:28] <jtaylor> your welcome to fix them
[19:28]  * tumbleweed has his hands full with pypy
[19:30] <jtaylor> thats probably more worthwile than pyside :)
[19:30] <jtaylor> with its woping 2 rdepends which are both pyqt4 | pyside
[19:31] <tumbleweed> well, it has no rdeps either at all :P
[19:31] <tumbleweed> but I really should be slipping a new release in before the freeze :/
[19:34] <cjohnston> jtaylor: let me know if I can assist you in any way
[19:34] <jtaylor> arg
[19:34] <ockham> tumbleweed: sooo... would you consider uploading gourmet?
[19:34] <jtaylor> my package was fine, I just forgot to install one
[19:35] <jtaylor> but why wasn't there a dependency
[19:35] <jtaylor> hm
[19:46] <tumbleweed> xnox: what was the practical result of https://launchpad.net/ubuntu/+source/urwid/1.0.1-2ubuntu1 ?
[19:47] <xnox> tumbleweed: ugly hacks and dirty tricks to make it not ftbfs with the dh_python3 as it was at that point in time. dh_python3 was throwing exceptions.
[19:47] <tumbleweed> xnox: ok, because it doesn't any more
[19:47] <xnox> tumbleweed: this may not be necessary any more.
[19:48] <xnox> tumbleweed: sync, or whatever =)
[19:48] <tumbleweed> that could have been due to changes in dh_python3
[19:48] <tumbleweed> cjohnston: ^
[19:48] <cjohnston> gotcha
[19:49] <cjohnston> so it should be able to by sync'ed then and drop the delta
[19:49] <tumbleweed> yeah, it looks like the new cdbs / dh_python3 does the right thing
[19:50] <jtaylor> cjohnston: uploaded "fixed" pyside and shiboken
[19:50] <cjohnston> jtaylor: that's awesome!
[19:50] <jtaylor> tried a few of the apps in the examples git
[19:50] <jtaylor> python2 seems to work ok
[19:51] <jtaylor> some python3 fail, but I think thats related to unicode things
[19:51] <cjohnston> :-/
[19:51] <jtaylor> unicode differences in py3
[19:51] <jtaylor> some embedded binary resources, I did not run 2to3 on it
[19:52] <tumbleweed> the fancy multi-size unicode strings thing?
[19:52] <jtaylor> the python file contains qt_resource_data="lots of binary\x00\x01"
[19:52] <jtaylor> I'm not surprised that does not work in python3 without change
[19:52] <tumbleweed> lol
[19:53] <jtaylor> simpler examples worked fine in py3
[19:58] <jtaylor> adding b to the string works
[19:58] <jtaylor> b""
[19:58] <jtaylor> so everything fine
[20:02] <jtaylor> now jsut don't dare failing on an arch I did not test!
[20:05] <tumbleweed> ockham: so, what am I looking at?
[20:06] <ockham> tumbleweed: well, i've taken debian's 0.15.9-1 gourmet packaging and updated it to 0.16.0-1, with a bit of cleanup
[20:06] <tumbleweed> where?
[20:06] <tumbleweed> 0.16.0-ubuntu1, if it's for ubuntu
[20:06] <tumbleweed> I'd also avoid the cleanup, unless it matters
[20:06] <tumbleweed> if it doesn't let that wait fro the debian maintainer
[20:07] <ockham> for now it's only in git: https://github.com/thinkle/gourmet/tree/debian
[20:07] <ockham> i know about the version, i'll change that of course
[20:08] <ockham> unfortunately the debian maintainer is unresponsive... (i wouldn't consider uploading directly to ubuntu otherwise...)
[20:09] <tumbleweed> ockham: yeah, we have the advantage of being able to do whatever we want to, whenever we need to, in Ubuntu
[20:09] <ockham> tumbleweed: i know, that's why i'm here :-P
[20:09] <tumbleweed> how big is this repo?
[20:09]  * tumbleweed is at 50MB
[20:10] <ockham> my working dir is at some 25MB currently
[20:11] <ockham> wait, hadn't deleted dist/ subdir. subtract 8MB
[20:11] <tumbleweed> 80%, 95MiB
[20:12] <ockham> oops, was on gh-pages branch. sry. master is at some 50MB, yup.
[20:12] <tumbleweed> well, the size of .git is what really matters
[20:12] <ockham> well, history reaches back quite a bit
[20:12] <tumbleweed> \o/, done
[20:12] <ockham> thx for checking this out
[20:13] <tumbleweed> ockham: so, I see you've done mountains of cleanup
[20:13] <ockham> tumbleweed: um, yeah. both upstream and debian-wise.
[20:13] <tumbleweed> what's the plan? are you going to continue merging this if the debian maintainer doesn't want it?
[20:14] <ockham> tumbleweed: hm. haven't considered the rejection option yet. *thinks*
[20:14] <tumbleweed> well, I see things like "Switch to tiny dh style"
[20:14] <tumbleweed> not everyone likes that, and I don't know christian's views...
[20:15] <ockham> i've actually asked him to change maintainership to PAPT, and set himself and me as Uploaders...
[20:15] <tumbleweed> ockham: oh, you should migrate to beautifulsoup4 at some point
[20:15] <tumbleweed> ockham: yeah I saw that
[20:15] <ockham> yeah, i've met some tiny dh style haters
[20:15] <ockham> tumbleweed: i know. still tons of modernization ahead, hence the github issue label
[20:16] <ockham> i hope to apply gourmet for gsoc to have some of it done
[20:17] <ockham> anyway, about future maintenance. yeah, i guess i'd continue merging to ubuntu in case he doesn't want some of this stuff.
[20:17] <tumbleweed> ok, then I'll review...
[20:17] <ockham> tumbleweed: great, thx!
[20:17] <tumbleweed> dpkg-source: info: local changes detected, the modified files are:
[20:17] <tumbleweed> etc.
[20:18]  * tumbleweed can't build a source package
[20:18] <ockham> yikes
[20:19] <ockham> maybe this tree is somewhat dirty as it's also used for upstream stuff, with master merged regularly into debian. hm. care to use uscan to download the release tarball?
[20:21] <tumbleweed> yeah, I did that
[20:23] <tumbleweed> ockham: and that's when it threw up at me
[20:23] <ockham> tumbleweed: oops. sry.
[20:24] <ockham> one sec
[20:30] <ockham> hm, downloaded tar.bz2 manually, copied debian dir to it, ran dpkg-buildpackage -S -sa -rfakeroot, then tried debuild -> seems to WFM. strange.
[20:30] <ockham> tumbleweed: ^
[20:30] <tumbleweed> ockham: I did debuild in a the git checkout
[20:32] <ockham> tumbleweed: would you mind trying the tarball plus the debian dir from git?
[20:32] <tumbleweed> sure
[20:32] <ockham> i guess there *are* some differences between git and the tarball (produced with python setup.py sdist)
[20:32] <ockham> i tried to make sure contents are identical with the git repo, but must've missed something
[20:33] <ockham> tumbleweed: thx
[20:46] <tumbleweed> ockham: http://paste.ubuntu.com/5591432/
[20:47] <ockham> tumbleweed: ooh crap.
[20:47] <ockham> and i just released that tarball.
[20:47] <tumbleweed> (that was from a chroot, thus the DISPLAY:...)
[20:47] <tumbleweed> but I assume it's an issue
[20:49] <ockham> tumbleweed: yeah, i think it's this one: . and i guess it occured because i didn't test other locales than de_AT. you're en_ZA, right?
[20:50] <ockham> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614367
[20:51] <tumbleweed> I am
[20:51] <tumbleweed> are you going to fix that?
[20:52] <ockham> yeah, investigating now
[20:53] <ockham> exactly when is the FF? tomorrow at 9pm UTC?
[20:53] <ockham> tomorrow being 7th
[20:55] <tumbleweed> Freezes normally happen at 2100 UTC, to permit overnight builds to include the last content. Please make sure all changes have been uploaded before then unless agreed to by the release team.
[21:03] <cjohnston> hrm... virtualbox on raring seems to be having issues with the newer kernels
[21:07] <TheLordOfTime> cjohnston, there's an open bug about kernel issues and VBox
[21:07] <TheLordOfTime> at least one, that is.
[21:07] <TheLordOfTime> cjohnston, what kernel does raring use again?
[21:07] <TheLordOfTime> (version number)
[21:08] <cjohnston> I see that
[21:09] <cjohnston> 3.8.0-11
[21:13] <cjohnston> I'm testing the upstream patch
[21:13] <TheLordOfTime> cjohnston, mind dropping a link to that patch?
[21:14] <cjohnston> https://www.virtualbox.org/changeset/44317/vbox
[21:15] <ogra_> https://plus.google.com/hangouts/_/914b5784e52c5967784eae44e4b138a346b1ff90?authuser=0 post UDS drinking hangout ....
[21:29] <debfx> cjohnston: I'm about to upload virtualbox 4.2.8 to Debian
[21:29] <cjohnston> debfx: ok
[21:30] <debfx> the only thing blocking it is the configure script that doesn't detect the multiarch python in raring
[21:35] <ajmitch> debfx: this'll work as a guest with the current kernel in sid?
[21:37] <jbicha> micahg: that new blender is segfaulting :(
[21:37] <debfx> ajmitch: afaik the current version also works fine with the Debian sid kernel
[21:38] <ockham> tumbleweed: your .bashrc (or whatever) isn't set to LC_ALL="C" by chance, is it?
[21:38] <tumbleweed> ockham: in this case, no locale environment variables at all
[21:39] <ajmitch> debfx: I barely had time to take a look at what was going wrong, but I had issues with the guest dkms modules
[21:39] <ajmitch> I'd file a bug now but I'm not at that machine :)
[21:39] <ockham> tumbleweed: chroot or some, right. so that's equivalent to LC_ALL="", right?
[21:42] <tumbleweed> ockham: installing a lang-pack and using a non-C locale works
[21:42] <tumbleweed> that sounds like something you should fix, though
[21:42] <ockham> tumbleweed: yup, i know. i think i've found, but could only reproduce it with LC_ALL="C". LC_ALL="en_ZA.UTF-8" WFM, though
[21:43] <tumbleweed> yup, en_ZA works for me
[21:44] <tumbleweed> so, you're saying this isn't a regression, and I should just upolad this as is
[21:44] <tumbleweed> ?
[21:46] <debfx> ajmitch: I'm not aware of any bugs. they may not work with kernel >= 3.5 but that shouldn't affect sid.
[21:46] <debfx> oh great, now gcc throws an internal compiler error at me
[21:47] <debfx> anyone interested in taking over virtualbox package maintenance? ;)
[21:47] <ajmitch> debfx: yeah, I'll take a look again when I get back to that machine & file a bug in debian if there's a problem
[21:47] <ajmitch> hah
[21:49] <cjohnston> debfx: just applying that patch there is a problem building
[21:52] <debfx> ajmitch: as long as the bug contains a patch ... :)
[21:52] <debfx> cjohnston: the python issue?
[21:52] <cjohnston> yup
[21:53] <cjohnston> debfx: is there a fix for that somewhere that you know of? trying to get it into a ppa if nothing else for someone
[21:53] <debfx> cjohnston: no, that's what I'm working on right now
[21:53] <cjohnston> ahh
[21:55] <ajmitch> debfx: sure :)
[21:56] <debfx> tumbleweed: have you deliberately not synced beets 1.0 to raring?
[21:57] <tumbleweed> debfx: no, I'll do it
[21:58] <debfx> thanks
[21:58]  * tumbleweed must have forgotten
[22:11] <micahg> jbicha: awesome :(
[22:14] <ockham> tumbleweed: well it's clearly a bug for LC_ALL="C", though not necessarily a regression. i think i've found a fix, but if it's really only going to affect LC_ALL="C", i think i'd rather not release a 0.16.1 tarball with only one line changed...
[22:14] <jtaylor> does shiboken have to be unnewed before ff?
[22:14] <tumbleweed> ockham: debian quilt patch?
[22:14] <ockham> tumbleweed: sounds good
[22:15] <ockham> tumbleweed: one moment
[22:15] <thjaeger> Hi.  Could someone please upload the new rc of easystroke that fixes this show-stopper bug: https://bugs.launchpad.net/ubuntu/+source/easystroke/+bug/1106922 ?
[22:16] <jtaylor> sure
[22:19] <jtaylor> thjaeger: any more info on the gtkmm issue?
[22:20] <jtaylor> I heard from some mint people that their gtk stuff is broken in raring too, maybe a larger issue
[22:20] <thjaeger> it's a custom cellrenderer, which really needs to be implemented as a GObject
[22:23] <thjaeger> I don't think it's possible to do this within gtkmm
[22:24] <thjaeger> there a couple mailing list postings on the subject but not really a resolution
[22:24] <thjaeger> gtk has always been spitting out warnings about this thing, but in this iteration it finally broke
[22:24] <jtaylor> if only my raring chroots would work ._.
[22:25] <thjaeger> the only way out I saw was to implement the cellrenderer in vala (because who can actually write gobject c code)?
[22:26] <thjaeger> the package I attached to the bug report is identical to the version in the ppa, so it should build, but I can provide a pbuilder log if that helps
[22:27] <jtaylor> thjaeger: is it possible to let easystroke disable itself when something goes into fullscreen?
[22:30] <jtaylor> thjaeger: the package does not build depend on vala
[22:30] <jtaylor> packages should regenerate the sources, using pregenerated sources is very bad style
[22:31] <thjaeger> jtaylor, that's an interesting idea, it wouldn't be hard to implement since I'm already keeping track of properties of application windows
[22:31] <thjaeger> (but no, it's not possible right now)
[22:31] <jtaylor> thjaeger: that would be a nice feature, I always forget to disable easystroke when I start a game :/
[22:32] <thjaeger> the thing is, I actually had to modify the gtk-3.0 vapi file to generate the C source
[22:32] <notgary> I'm attempting to install egg-list-box using jhbuild and am making it as far as the build phase before I get the error "/bin/bash: --pkg: command not found". The full output from that phase can be found at http://paste.ubuntu.com/5591640/. I can't find any package called 'pkg' (unless someone's misspelled dpkg). Can anyone help me out with this?
[22:33] <jtaylor> thjaeger: in what way did you have to modify it?
[22:33] <ockham> tumbleweed: pushed to git
[22:33] <thjaeger> jtaylor, so I would have to import the 8600-line vapi file into my source tree (which is actually encourage, apparently), at which point I might as well just keep the autogenerated code in the tree
[22:34] <thjaeger> makes it easier to compile, too
[22:35] <thjaeger> jtaylor, some arguments are not declared nullable in the vapi file that gtk actually passes null to under some circumstance
[22:35] <thjaeger> and vala generates code that bails out when null gets passed
[22:35] <jtaylor> thjaeger: did you file a bug?
[22:36] <thjaeger> not yet
[22:36] <jtaylor> looks to me like something better fixed in the vala package so its fixed for all users
[22:37] <thjaeger> jtaylor, i think what needs to happen is for someone to grep the C documentation for the word NULL and fix this for all function this applies to
[22:37] <thjaeger> I have a feeling this happens a lot in the less-used parts of gtk
[22:38] <thjaeger> (sorry about my spelling)
[22:40] <jtaylor> thjaeger: first step would be to file a bug and attach the fixes you have
[22:40] <jtaylor> for the package right now I'm unsure
[22:40] <jtaylor> we could add your patch to the package and patch it during build
[22:41] <jtaylor> because machine generated code does not count as source under dfsg rules, especially if you have to patch the toolchain to generate it
[22:43] <ockham> tumbleweed: *ping* (pushed quilt patch to git)
[22:43] <jtaylor> @other motus: given ff tomorrow can we make an exception for now? or file for ffe later?
[22:43] <Laney> either
[22:43] <thjaeger> jtaylor, not even when it is part of the upstream package?
[22:45] <jtaylor> thjaeger: but its not part of upstream package, you have to patch it
[22:46] <tumbleweed> ockham: seems happy
[22:46] <thjaeger> jtaylor, sorry I meant easystroke upstream, not vala upstream
[22:46] <ockham> tumbleweed: yay!
[22:47] <jtaylor> thjaeger: is the patch in the source somewhere?
[22:48] <thjaeger> the patch for gtk+-3.0.vapi? not right now, but I could add it if it helps things along
[22:49] <thjaeger> what if I modify the generated C code to get rid of the warnings have been annoying me?  Then it's not auto-generated code anymore, so dfgs guidelines should not apply...
[22:50] <cjohnston> debfx: you still around?
[22:51] <ockham> tumbleweed: so where do we go from here? you want me to fix the version number in debian/changelog to 0.16.0ubuntu1, and add that XSBC-Original-Maintainer stuff?
[22:51] <jtaylor> thjaeger: you can argue your way around this issue yes :)
[22:51] <tumbleweed> ockham: naah, I'll just do it
[22:52] <ockham> tumbleweed: cool, thx!
[22:52] <jtaylor> thjaeger: the spirit of it is that e.g. vala gets a security update, we just need to rebuild everything
[22:52] <jtaylor> thjaeger: if you do not generate during the build you have to track down all packages and update the files
[22:52] <jtaylor> fiddling out where the author maybe changed things
[22:53] <ScottK> thjaeger and jtaylor: DFSG requires distirbution in the preferred form of modification.  If you can no longer generate the code, then you aren't doing that.
[22:53] <jtaylor> but if the once generated source is upstreams preferred form of modification? :)
[22:54] <jtaylor> thjaeger: can you send me the patch? we can put it in the package and patch the vapi file during the build
[22:54] <ScottK> If that's really, actually true and they'll never regenerate it again, I suppose, but that doesn't sound like the case here.
[22:54] <jtaylor> that would be sufficient for now, we can fix vala itself later
[22:55] <jtaylor> or we copy the patched vapi file into debian/ or the orig tarball
[22:58] <thjaeger> jtaylor, I've attached the patch to the bug report
[23:01] <ockham> tumbleweed: so, um, is that all you need from me?
[23:02] <jtaylor> thjaeger: how do I use the patched file?
[23:02] <tumbleweed> ockham: https://launchpad.net/ubuntu/raring/+source/gourmet/0.16.0-0ubuntu1
[23:02] <ockham> tumbleweed: awesome, thx!
[23:02] <thjaeger> jtaylor, patch -p1 /usr/share/vala-0.18/vapi/gtk+-3.0.vapi < make-event-argument-nullable.patch
[23:03] <jtaylor> thjaeger: I mean with valac
[23:03] <jtaylor> I don't want to patch the system file
[23:03] <thjaeger> i don't know
[23:04] <thjaeger> let me try --vapidir
[23:05] <jtaylor> seems to work
[23:06] <thjaeger> jtaylor, got it: valac -c cellrenderertextish.vala --vapidir=dir,/usr/share/vala-0.18/vapi/ --pkg gtk+-3.0 -C -H cellrenderertextish.h
[23:07] <jdstrand> heading out. see you guys tomorrow :)
[23:10] <thjaeger> jtaylor, bug reported with vala upstream: https://bugzilla.gnome.org/show_bug.cgi?id=695329
[23:10] <jtaylor> thx
[23:27] <thjaeger> jtaylor, i gotta run, but thanks for looking into this issue.
[23:39] <ockham> okay, good night everybody!
[23:39] <ockham> tumbleweed: thx again!