[00:00] <mlankhorst> ah so its just a coverup for a bet
[00:00] <mlankhorst> made while drunk ;P
[00:33] <slangasek> Mirv: I'm confused by the SRU for bug #1056743.  Why is this done as a new upstream version instead of just a distro patch... and why did the version number jump from 5.12.0 to 5.18.0?
[00:46] <infinity> Packages to change from priority required to important
[00:46] <infinity> ------------------------------------------------------
[00:46] <infinity> libexpat1
[00:46] <infinity> libpython3.3-minimal
[00:46] <infinity> python3-minimal
[00:46] <infinity> python3.3-minimal
[00:46] <infinity> I win.
[01:19] <slangasek> bryce: the xorg-server in the precise-proposed queue was uploaded with the wrong -v option, so is missing refs to bugs #1070481 and #1010794.  Could I trouble you to reupload with the -v option?
[01:28] <bryce> slangasek, done.
[01:28] <slangasek> bryce: ta
[01:29] <robert_ancell> @pilot in
[03:06] <mspencer> I've recently started working on a launchpad project called Ubuntu Contributor Console, based off a spec on wiki.ubuntu.com. Is the ubuntu-devel-announce mailing list a good place to announce it and to get people interested in contributing to it?
[03:09] <micahg> no, maybe ubuntu-devel if it's related to Ubuntu Development
[03:10] <mspencer> Here's the wiki page: https://wiki.ubuntu.com/ContributorConsole
[03:12] <mspencer> micahg: So is it okay to announce it on that mailing list and list some things I don't know how to do and would like others to help on?
[03:14] <micahg> depends what you're asking for help wiht
[03:14] <micahg> *with
[03:16]  * micahg isn't sure....maybe someone else can answer this
[03:20] <mspencer> I don't really mean asking for help, I mean more like listing things that people could contribute if they are interested. Some things that I'm not good at/don't know how to do are designing an icon, coding the Updates panel (the ability to install and test SRUs).
[04:35] <pitti> Good morning
[04:35] <highvoltage> hello pitti
[04:43] <Mirv> slangasek: it's just a habit of that multi-personality of acting as a normal upstream project, making a new release when there are worthy commit(s). version bump because the idea of releasing eg. all "SRU-3" stack components at the same time with the same version number
[04:44] <Mirv> but for lenses, there are usually only single commits so distro patching would make sense as well
[04:44] <Mirv> but thanks for approving it already
[05:54] <slangasek> Mirv: you're welcome :)
[06:08] <doko> what's the state of the -compat package?
[06:08] <doko> infinity, ^^^
[06:28] <abogdan> I'm developing my first ubuntu app usig Quickly (python + gtk). I want to use some files and folders in my app. Do you know how to pack them together?
[06:31] <ScottK> abogdan: I think you want #ubuntu-app-devel.
[07:32] <dholbach> good morning
[09:13] <pitti> ev: WDYT about http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/509 ?
[09:15] <ev> pitti: looking
[09:15] <pitti> ev: with this, make check succeeds for me
[09:30] <ev> pitti: yeah, that looks entirely reasonable
[09:30] <ev> thanks for that!
[09:30] <ev> feel free to merge
[09:30] <pitti> ev: pushed
[09:30] <ev> thanks
[09:31] <pitti> ev: I didn't get much further with the test suite as I don't want to require root for it; but I need to figure out the system identifier
[09:31] <ev> ah, right
[09:31] <pitti> ev: so my idea was to finish the whoopsie branch to be able to start as normal user if you set a custom report dir and id
[09:31] <pitti> ev: such as
[09:31] <pitti> $ CRASH_DB_URL=http://localhost:8080 CRASH_DB_IDENTIFIER=TESTSUITE APPORT_REPORT_DIR=/tmp/x src/whoopsie -f
[09:31] <pitti> which I have working already, just cleaning up a bit
[09:32] <pitti> ev: does that sound ok to you?
[09:32] <ev> yes, as it also means we could someday use that to generate a known identifier that we could filter out server-side
[09:32] <pitti> ev: it would also allow us to drop the "sudo stop whoopsie" bits from run-from-juju
[09:33] <ev> woo
[09:33] <ev> I was initially startled by that second password prompt :)
[09:38] <pitti> ev: hm, do you know that locking is broken without -f?
[09:39] <ev> I did not know that, no
[09:39] <pitti> ev: the foreground process closes the lock fd as soon as it terminates
[09:39] <ev> eep
[09:39] <pitti> no biggie, it just caught my eye; works fine with -f
[09:49] <pitti> ah, very good; all working now
[09:55] <ev> awesome
[09:57] <pitti> ev: I tested this now with both the default "run as root" case, as well as running as user: http://paste.ubuntu.com/1425021/
[10:10] <pitti> ev: some cleanups and commit msg: http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/510
[10:11] <pitti> ev: oh, this includes the packaging, sorry; I'll re-do the commit to update debian/changelog
[10:11] <ev> thanks
[10:11] <ev> ah excellent on opportunistically fixing the APPORT_REPORT_DIR bug
[10:13] <pitti> ev: changelog pushed for previous commit
[10:14] <ev> yay
[10:14] <pitti> ev: http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/511
[10:33] <pitti> ev: while I was at it, I also fixed all compiler warnings in http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/512
[10:33] <pitti> ev: I'll push that once 511 gets reviewed and can land
[10:33] <ev> wow, you're on a roll!
[10:34] <ev> fwiw, I'm making it so that we can mock out the openid provider in lp:errors and adding decent error pages for authentication failures, so it doesn't just confusingly loop back to the openid login page
[10:34] <pitti> ev: my goal for the day is to get the ARM retracing running; prerequisite for this is a working test suite, which again depends on being able to get reports out of the API, which in turn depends on predictable system IDs, which depend on those whoopsie changes :)
[10:34] <ev> oh, I'll also chase up that ticket for getting openstack credentials
[10:34] <ev> so we can get tarmac in place
[10:34] <ev> :D
[10:35] <ev> turtles all the way down
[10:36] <pitti> ev: do you want to give this some deeper eyeballing, want an MP, etc?
[10:36] <ev> I'm looking over it now - no need for an MP
[10:37] <ev> looks excellent
[10:37] <ev> this reminds me that I want to get the gcov stuff in the Makefile working again
[10:38] <ev> feel free to merge
[10:39] <pitti> ev: pushed (for cleaner history); mind if I send this raring-wards? or do you want to do further changes?
[10:39] <ev> https://bugs.launchpad.net/whoopsie/+bug/1088847
[10:39] <ev> please do
[10:39] <pitti> yeah, that sounds useful indeed
[10:39] <pitti> with pygobject I was really surprised how easy that was to set up, and how useful it its
[10:39] <pitti> s/its/is/
[10:40] <ev> pitti: by the way, if you have good ideas on how to do mocking in C, I'm all ears. There's obviously a few options: function pointer arguments, splitting code more into libraries where you drop in a testing version, etc.
[10:41] <pitti> ev: the standard way known to me is to overwrite functions with an LD_PRELOAD library
[10:41] <ev> pitti: so define all the mock functions with the same function signatures as their non-mock counterparts in a library, then use LD_PRELOAD?
[10:41] <ev> makes sense
[10:42] <pitti> right
[10:42] <pitti> not very elegant for sure, but unless you design the code in the way you mentioned I don't know another way
[10:43] <cjwatson> And indirecting everything through function pointer arguments is pretty un-C-like; I suspect it also has performance penalties
[10:44] <pitti> or you use GObject more, and thus get the function pointes that way (through the vtable)
[10:44] <ev> cjwatson: yeah, that was very much a strawman
[10:44] <pitti> ev: what do you want to mock in whoopsie?
[10:44] <ev> I don't like having to bust out cdecl to understand a function prototype
[10:44] <pitti> ev: (I guess you are talking about whoopsie, as all the other bits are py)
[10:45] <cjwatson> typedefs help a lot, but yes ...
[10:45] <ev> pitti: for example, if we wanted to test handle_response
[10:45] <ev> pitti: when we start getting a number of different potential responses from the server
[10:46] <ev> it either needs to take a function argument to delegate to, or we need to mock out upload_core and friends
[10:46] <pitti> ev: wouldn't it be better to whip up a mock server in python and have whoopsie talk against that?
[10:47] <ev> hm, I suppose. I come from two conflicting schools of thought. The "test things in isolation" (previous python projects) and "test all the way down the stack" (lifeless' test harness for oops-repository, which requires a running cassandra)
[10:47] <ev> but I guess the later is going to give far more interesting results
[10:47] <lifeless> ev: I'm actually a mix of both
[10:48] <pitti> if you want to test for responding to server answers, this is already an integration test
[10:48] <lifeless> for my current thinking, see the ServiceRequirements stuff on dev.launchpad.net
[10:48] <lifeless> where I suggest having a python mock server that supports error injection, starts up in a jiffy etc.
[10:48] <pitti> so I think a mock server and running the actual whoopsie thing is better, as it avoids mocking over test code that you actually want to test
[10:49] <lifeless> the reason oops-repository runs all of cassandra is simple; the low level api wasn't stable when I did it, and mocking unstable APIs is a terrible idea.
[10:50] <ev> understood, to both of your points
[10:53] <pitti> ev: hm, if I make use of this feature in integration-test and run-juju-daisy, we depend on a raring-only version of whoopsie; would that be ok?
[10:54] <pitti> ev: not much trouble for a developer, but I guess we might want to run this for nagios at some point? we could run whoopsie out of bzr for that, of course
[10:54] <ev> pitti: I believe so. We can always stick it in a PPA for other releases if it becomes necessary.
[10:54] <ev> pitti: indeed we do want to run it for nagios
[11:03] <pitti> ev: oops, the kill command in run-juju-daisy doesn't kill the test whoopsie daemon (so it doesn't restore to sending to errors.u.c); fixing that along
[11:03] <ev> cheers
[11:07] <vibhav> win 18
[11:07] <vibhav> oops
[11:07] <vibhav> Sorry people
[11:25] <Laney> kirkland: do you still maintain manpages.ubuntu.com?
[11:34] <xnox> Laney: are you also longing for recent releases?
[11:35] <xnox> Laney: I think we just should fork the config: add/remove releases and file RT to get it redeployed.
[11:35] <xnox> https://code.launchpad.net/ubuntu-manpage-repository
[11:37] <Laney> sure, that was the secret intent behind the ping
[11:39] <siretart> RAOF: do you have a second to discuss bug #985202 with me?
[11:39] <Laney> xnox: making it dynamic would be even better ;-)
[11:40] <xnox> Laney: true.... not sure if IS will like dynamism =) anyway, not sure if it will let me push back due to acient bzr repo format.
[11:40] <Laney> well, using distro-info
[11:41] <xnox> Laney: is that installed?
[11:41]  * xnox goes to talk to webops/is.
[11:42] <Laney> i'm sure it could be
[11:47] <xnox> Laney: why is distro-info --supported listing raring as supported release?
[11:47] <xnox> Laney: should I filter out --devel from --supported, or do we want manpages early?
[11:48] <Laney> does it always take the latest as the default?
[11:48] <Laney> and I dunno, sounds like a bug
[11:48] <Laney> bdrung: is that a bug?
[11:50] <Laney> debian-distro-info --supported looks similarly fishy
[11:53] <Laney> xnox: note there is python-distro-info for the python part
[11:53] <xnox> Laney: sure, but manpages.ubuntu.com is a pile of shell & perl scripts with config file sourced as shell.
[11:53] <xnox> Laney: so... DISTROS=`distro-info --supported` works just fine =)
[11:54] <Laney> there's at least search.py with a list of versions
[11:54] <Laney> dict
[11:54] <xnox> Laney: and some javascript as well =(
[11:54] <Laney> unlucky
[11:55] <xnox> Laney: do we SRU distro-info or does it fetch data over the interwebz?
[11:55] <Laney> the former
[11:55] <Laney> distro-info-data
[11:58] <Laney> (so IS has to take that SRU for the site to know about new releases, which is still easier than a full deployment)
[12:02] <bdrung> Laney: that depends how you define supported.
[12:02] <Laney>        --supported
[12:02] <Laney>               list of all supported stable versions
[12:03] <bdrung> "stable" is the issue here.
[12:04] <bdrung> maybe it should be able to retrieve all supported stable version and all supported (not released) versions
[12:05] <xnox> bdrung: well --devel says raring, maybe it should somehow exclude devel from --supported.
[12:30] <xnox> Laney: filed RT, just a static update.
[12:30] <Laney> alright
[12:30] <Laney> ty
[12:30] <xnox> Laney: we have ~ a year to port this webapp to distro-info-data.
[13:06] <hrw> how to debug system where dbus is running but all dbus related tools say that it is not? where networkmanager is running (as a process) but there is no dbus so all tools say that NM is not running...
[13:19] <israeldahl> anyone know much about using imagemagick in the debian/rules file to draw the icon?  is it possible?
[13:25] <OdyX> israeldahl: what do you want to achieve ?
[13:26] <OdyX> israeldahl: create an icon from an upstream image ?
[13:27] <israeldahl> OdyX: the icon looks awful when it gets installed and I want it to look correct. this is for lmms
[13:29] <sil2100> doko: ping!
[13:31] <israeldahl> I have had to resort to linking to a different file in the lmms.desktop, but I want to fix it the right way
[14:03] <Laney> @pilot in
[14:04] <robert_ancell> @pilot out
[14:04] <Laney> :-)
[14:04] <micahg> Laney: how did you cross that continent so fast :)
[14:05] <xnox> Laney: cheat.
[14:05] <Laney> collapsars
[14:44] <didrocks> barry: hey, around?
[14:47] <barry> didrocks: hi!
[14:47] <didrocks> sil2100: maybe sum up what the issue you discovered to barry (which is making compiz and a lot of other build-deps failing) ^
[14:48] <sil2100> barry: hi!
[14:48] <barry> sil2100: hi :)
[14:49] <sil2100> barry: ok, so, compiz builds are failing on raring due to missing pyconfig.h in the python2.7 packages - in the past it was installed by python2.7-minimal
[14:49] <sil2100> But since the latest version (uploaded yesterday?) the file is missing from all the python packages
[14:49] <sil2100> I traced down the problem, and found which revision of the packaging branch removed it
[14:49] <sil2100> Maybe by accident? SInce I'm not sure if it's intended
[14:49] <sil2100> http://bazaar.launchpad.net/~doko/python/pkg2.7-debian/revision/93
[14:50] <sil2100> Here in the diff of debian/rules, around line 732 in that file
[14:51] <sil2100> I saw some debian/rules cleanup there, so I though that maybe this one line got removed by accident
[14:51] <sil2100> barry: do you know anything about this ;) ?
[14:52] <didrocks> cyphermox: I think the indicator issue you got yesterday is maybe linked to that as well ^
[14:52] <barry> sil2100: yes.
[14:53] <barry> sil2100: this change is for multiarch, and it's really a bug in your builds :)  you should be using `python-config --includes` to find the include paths to things (and --libs, etc.)
[14:53] <xnox> sil2100: it's the same change as with python3.3 - there are now two include locations.
[14:53] <sil2100> barry: but hm, then which package installs pyconfig.h then?
[14:53] <sil2100> Since it's not in python2.7-minimal anymore, neither is it in -dev and libpython2.7-dev
[14:54] <xnox> sil2100: one of dependencies of python-dev
[14:56] <seb128> sil2100, dpkg -S pyconfig.h
[14:56] <xnox> sil2100: i still should be libpython2.7-dev
[14:56] <seb128> sil2100, it's installed, just in /usr/include/<arch>/...
[14:56] <xnox> sil2100: the point is that python multi-arch now uses 2 include locations /usr/include/python2.7 and /usr/include/<arch>/python2.7 and you need both includes.
[14:57] <sil2100> xnox: ah, indeed, it's in libpython2.7-dev
[14:57] <barry> libpython2.7-dev
[14:57] <sil2100> xnox: thanks! See it now
[14:57] <barry> oops, yeah
[14:57] <barry> :)
[14:57] <sil2100> We'll update the dependencies then!
[14:57] <sil2100> I couldn't find it due to multiarch ;)
[14:57] <barry> it's a brave new world
[14:57] <sil2100> seb128: thanks as well!
[14:57] <xnox> sil2100: can I see your build-log? as I did patch ~20 packages to find both include locations, when I was transitioning packages to python3.3 (which also uses multiarch locations)
[14:57] <sil2100> didrocks: I'll make a merge request for that
[14:58] <sil2100> xnox: https://launchpadlibrarian.net/125437610/buildlog_ubuntu-raring-i386.compiz_1%3A0.9.9~daily12.12.05bzr3522pkg0raring0_FAILEDTOBUILD.txt.gz
[14:58] <didrocks> sil2100: excellent! Thanks a lot for digging in :)
[14:59] <xnox> sil2100: thanks. well the build-record, such that I can grab source? e.g. which ppa is this for? =)
[14:59] <seb128> xnox, get compiz from raring I guess it will have the same issue
[14:59] <xnox> nevermind see it: unity-team/staging
[14:59] <sil2100> xnox: https://launchpad.net/~unity-team/+archive/staging/+build/4055447
[14:59] <xnox> sil2100: thanks.
[14:59] <sil2100> xnox: just pull lp:compiz and you're done ;)
[15:00] <sil2100> But I'm preparing a merge request for the change right now anyway, so we'll have it fixed soon
[15:00] <Laney> @pilot out
[15:00] <xnox> sil2100: ok, can you pastebin a patch such that I can review it?
[15:00] <xnox> sil2100: or point to merge proposal?
[15:01] <didrocks> xnox: we do merge proposal for everything in our world :)
[15:01] <didrocks> (with peer reviews)
[15:01] <xnox> ok =)
[15:01] <xnox> didrocks: bzr diff | pastbin & comments on irc is also "peer review" =)))))
[15:01] <sil2100> xnox: I'll post the link to the merge proposal here ;)
[15:02] <didrocks> xnox: right, but the merger won't care about your comment on IRC :)
[15:02] <xnox> sil2100: it's just CMake's FindPython is broken, and instead I was using PkgConfig which will find python2.7 libs & includes correctly.
[15:05] <seb128> xnox, shouldn't cmake by fixed in that case?
[15:05] <sil2100> didrocks, xnox: I'll just test-build it quickly
[15:05] <didrocks> sil2100: "quickly"? aren't you talking about building compiz? :p
[15:05] <sil2100> ...;p
[15:06] <xnox> seb128: that would be lovely, but FindPython cmake module is a bit over-engineered and I didn't manage to find an easy way to hook a second include directory check in it.
[15:06] <seb128> xnox, compiz uses cmake so it's likely going to be the same cmake bug? we will need to fix cmake anyway rather than workaround in each component...
[15:09] <xnox> seb128: yes, and now. FindPython returns a single include path, this change requires that it now returns a list & uses an include list, so unsuspecting CMakeLists will still be broken =/ for python3.3 i fixed something like 3 packages which used CMake python detection incorrectly. Only one of them used CMake's module, the others had "embedded copies with changes".
[15:10] <xnox> seb128: e.g. even compiz kind of overrides and does stuff to the cmake's findpython module. so although fixing cmake would help, but is not guaranteed to fix all cmake packages....
[15:11] <xnox> e.g. I don't understand why so many packages use "custom" python detectors instead of using pkg-config.
[15:11] <xnox> same story applies to all the autoconf stuff which also missdetects python in different ways.
[15:11]  * xnox finished ranting about build systems.
[15:12] <seb128> xnox, yeah, I don't know, people tend to just copy build tools snippet around so errors and weird stuff got copied as well
[15:12] <xnox> =`(((((
[15:12] <xnox> clearly everyone should switch to waf build system.
[15:12]  * xnox hides =)
[15:12] <seb128> lol
[15:15] <doko> barry, xnox: maybe I'll just include a fake header for all know multiarch tuples
[15:16] <barry> doko: not sure what that means
[15:16] <xnox> doko: please don't. we should just fix stuff. When are we having a rebuilt to spot all of these? Or shall we upload into py2.7 ppa.
[15:16] <xnox> doko: also I think I finally did figure out & CMake has knoweledge of debian's multiarch triplets. I just need to find time to dig into cmake again.
[15:17] <xnox> doko: plus it's probably my fault, in some packages e.g. boost/blender I only applied python haz multiarch locations for py3 builds only. I didn't know we will have py2.7 multiarch in raring as well later on.
[15:35] <barry> didrocks: how do you maintain the packaging branch for oneconf?  i think i can do a quick update of debian/ if the latest trunk is merged in (but i don't want to break things)
[15:43] <doko> xnox, barry: something like http://paste.ubuntu.com/1425505/
[15:43] <barry> doko: oh wow, yeah.  maybe put that in a new python2.7-your-build-is-broken binary package? :)
[15:44] <didrocks> barry: it's a native package, just a quick update of debian/changelog, I'll push to trunk for you and please upload :)
[15:45] <xnox> doko: is that going into "multiarch-support" package? :P
[15:45] <barry> didrocks: some changes will be needed for d/control d/rules
[15:51] <barry> didrocks: shall we bump the version to 0.3? :)
[15:52] <didrocks> barry: I'm fine with that :)
[15:52] <barry> didrocks: cool :)  i'll push an mp after some local testing
[15:52] <didrocks> barry: sounds perfect! :)
[16:06] <doko> seb128, what was the source package for the python autoconf test. there was one, but I can't remember which one ...
[16:07] <mfisch> mhall119: FYI, singlet has some warnings about deprecated methods when run in raring
[16:07] <mfisch> mhall119: I think the fix is safe in Q as well: PyGIDeprecationWarning: MainLoop is deprecated; use GLib.MainLoop instead
[16:07] <Laney> @pilot in
[16:09] <xnox> doko: autoconf archive?
[16:09] <doko> no, autoconf doesn't have such kind of macro themself
[16:10]  * dholbach hugs Laney
[16:11] <xnox> doko: I meant autoconf-archive package, a package of extra autoconf macros, e.g. it has a broken /usr/share/aclocal/ax_python_devel.m4
[16:18] <rbasak> ogra_: around? I'm having trouble reproducing bug 1079185 for SRU verification.
[16:18] <rbasak> ogra_: it's holding up landing the fix for bug 1084106
[16:20] <xnox> doko: python-2.7.pc file has "-I${includedir}/x86_64-linux-gnu/python2.7m" while the include dir shipped is just -I${includedir}/x86_64-linux-gnu/python2.7 (no abiflag m)
[16:21] <xnox> doko: it's inconsistent, and which way should it be? shipping 2.7m includedir as well or declare 2.7 includedir as "/before/"?
[16:23] <mvo> didrocks: I get a error when trying to build compiz (trunk) on raring, it python3.3m/Python.h complains that pyconfig.h is not found - is that a known issue? it looks like fallout from the include moving from /usr/include/python3.3m to /usr/include/x86_64-linux-gnu/python3.3m
[16:23] <didrocks> mvo: see the discussion we had here 1h30 ago ^
[16:23] <didrocks> mvo: new python changed and is multiarch, sil2100 works on a fix
[16:24] <mvo> didrocks: aha, nice. then I will not duplicate this effort
[16:24] <didrocks> no need! :)
[16:25] <sil2100> mvo, didrocks: we're working on it, but the fix hm, doesn't work, since (if I understand xnox's analysis correct) there might be a bug in the new python packaging
[16:26] <xnox> yes.
[16:28] <arges> is there a wiki on how to setup sbuild to build ddebs? I've looked through this: https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment but am not sure if I need to add certain DEB_BUILD_OPTIONS to get it working.
[16:29] <xnox> arges: if you create sbuild with mk-sbuild, you auto-get ddebs.
[16:30] <seb128> doko, dunno for python autoconf test...
[16:30] <arges> xnox, in precise? or does it need to be a newer sbuild host?
[16:30] <xnox> arges: alternatively you need to install pkg-create-dbgsym inside the sbuild. Note a package can override & skip building ddebs (e.g. e2fsprogs)
[16:31] <xnox> sil2100: filed bug 1088988
[16:32] <xnox> arges: I don't run precise, but I thought that feature was around forever. Did you create chroots with mk-sbuild or manually / some other way?
[16:32] <arges> xnox, with mk-sbuild...
[16:32] <arges> xnox, mk-sbuild --arch=amd64 --distro=ubuntu lucid
[16:32] <arges> xnox, not sure if there si something special I need to add to .mk-sbuild.rc
[16:33] <xnox> arges: schroot into it and check if pkg-create-dbgsym package is installed, if not install it in the golden / source image and you should start generating ddebs.
[16:33] <arges> xnox, ok and those ddebs will get placed in the same location as the .debs  then after a build?
[16:33] <xnox> arges: which you can reconfirm by reading the buildlog - it will announce redirecting dh_strip / generation of ddebs.
[16:34] <xnox> arges: yes.
[16:34] <arges> xnox, ok i'll investigate, I looked at the buildlogs and I saw it was installing pkg-create-dbgsym
[16:34] <sil2100> didrocks, mvo, xnox: after this would get fixed, I think this merge request could be considered?
[16:34] <sil2100> https://code.launchpad.net/~sil2100/compiz/fix_python_find_package/+merge/139256
[16:38] <sil2100> hmm, strangely, I can't link a branch to a bug
[16:39] <sil2100> https://bugs.launchpad.net/compiz/+bug/1088996
[16:39] <sil2100> Here's the FTBFS bug, but I'm unable to link my branch to it ;p
[16:40] <sil2100> Ok, finally I was able
[17:56] <arges> xnox, so I rebuild the schroot with no special .mk-sbuild.rc . I tried to sbuild with no options (no ddebs andI see dh_strip), I tried DEB_BUILD_OPTIONS=debug,nostrip,noopt and still doesn't build the ddeb
[17:57] <arges> and I also still see the dh_strip ... so not sure if its particular to the package... I tried using 'hello' then 'ispell' (just to see if it works)
[18:00] <xnox> arges: well, it works for me on quantal/raring. i'll try against on precise and will let you know.
[18:00] <arges> xnox, ok, I'll try on raring here as well... trying to target precise
[18:00] <xnox> arges: have you tried installing pkg-create-dbgsym in the golden/source image as I suggested earlier?
[18:01] <arges> xnox, so I see it pulled in the buildlog
[18:01] <xnox> arges: 1 second - what does your machine run & what do you build for?
[18:01] <xnox> arges: can you pastebin the buildlog?
[18:01] <arges> xnox, running precise amd64, schroot is lucid amd64
[18:02] <arges> xnox, sure one second
[18:02] <arges> xnox, pastebin.ubuntu.com/1425766
[18:03] <xnox> arges: i don't think ddebs existed in lucid.
[18:03] <xnox> arges: but I might be wrong.
[18:03] <arges> xnox, there is a release directory in ddebs.ubuntu.com
[18:04] <arges> xnox, for lucid
[18:04] <Laney> @pilot out
[18:04] <seb128> xnox, you are wrong ;-)
[18:06] <xnox> arges: in that particular case pastbined 2322-2328 it says that it didn't create ddeb, because all binaries were already stripped: no debug symbols - no ddeb for you.
[18:07] <xnox> arges: apart from that it is working "correctly"
[18:07] <seb128> xnox, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-November/000355.html
[18:08] <seb128> xnox, it was well before lucid ;-)
[18:08] <arges> xnox, ok so I need to pick another package that has ddebs...
[18:08] <xnox> seb128: ok =0)))
[18:09] <arges> xnox, i picked that one because it was small and I did find the -dbgsym in the ddebs archive
[18:09] <arges> for lucid though
[18:09] <arges> xnox, also pkg-create-dbgsym is in the golden master image
[18:10] <arges> it was already created by default
[18:10] <arges> s/created/installed
[18:11] <xnox> arges: pitti is probably the best person to ask about dbgsym. but he might be offline already.
[18:12] <xnox> it recent releases "it just works" & i never did dbgsym packages for lucid.
[18:12] <arges> xnox, ok i'll hack on it
[18:12] <arges> xnox, i'll try a precise schroot next . thanks a ton for your help!
[18:12] <xnox> arges: no worries, but it's not like i solve the problem for you =/
[18:14]  * arges lunches
[18:32] <mhall119> mfisch: did you file a bug and submit a patch?
[18:40] <mdeslaur_> barry: is there a mailman command to get a list of the lists I'm subscribed to?
[18:58] <barry> mdeslaur_: from the command line, or email command (or via web)?
[19:14] <mdeslaur_> barry: from the web
[19:15] <mdeslaur_> barry: or email
[19:15] <mdeslaur_> barry: ie: I don,t have access to the command line
[19:26] <mfisch> mhall119: will do so
[19:30] <barry> mdeslaur_: the way to do it from the web is to log in to any list you know you're a member of, then on the options page look for "List my other subscriptions"
[19:30] <barry> @pilot in
[19:32] <arges> xnox, ok precise schroot on precise behaves as expected building the .ddebs properly , but lucid schroot on precise doesnt' build ddebs.
[19:32] <mdeslaur_> barry: ah, cool...thanks!
[19:33] <barry> np!
[19:34] <micahg> arges: are you doing xz debs?
[19:35] <arges> micahg, hi. there isn't xz compression in the debian/rules file for the package I am building. essentially I want to be able to get ddebs from a package in general when building in a lucid schroot
[19:36] <micahg> arges: ok, sorry, was missing some context, I know xnox was trying to get xz ddebs...
[19:36] <arges> micahg, I was following the security build environment wiki on setting this up actually.  But out of the box, precise schroot builds the ddebs, while lucid schroots do not
[19:36] <micahg> let me see if I have an ddebs from lucid builds locally
[19:39] <micahg> arges: which package are you trying?
[19:39] <arges> micahg, at this point I'm trying any package... I tried 'hello' then I tried 'ispell' since I saw that it had dbgsyms generated in ddebs.ubuntu.com for lucid
[19:40] <arges> micahg, i'd like to build a kernel with ddebs in a schroot, but rebuild/test cycle is pretty lengthy
[19:40] <micahg> TBH, idr if I get them or not
[19:40] <micahg> just kicked off a build to see if I do
[19:42] <arges> micahg, ok . did you add any DEB_BUILD_OPTIONS or add anything when you called mk-sbuild?
[19:44] <mfisch> mhall119: here you go: https://code.launchpad.net/~mfisch/singlet/fix_deprecation_warning/+merge/139301
[19:45] <mhall119> thanks mfisch
[19:45] <micahg> arges: nope, and I don't get them on lucid, even with pkgbinarymangler installed
[19:46] <arges> micahg, hmm ok.  is this a bug I should file? or am I missing something
[19:46] <infinity> micahg: pkg-create-dbgsym, you mean.
[19:47] <infinity> micahg: pkgbinarymangler doesn't make ddebs.
[19:47] <micahg> infinity: right..
[19:47] <arges>  infinity yea and I confirmed pkg-create-dbgsym is in the golden master lucid schroot by default
[19:47] <infinity> This reminds me that I need to recreate all my schroots after my great hard drive crash.  What a pain.
[19:48] <micahg> actually, with pkg-create-dbgsym I do get the ddeb :)
[19:48] <barry> mfisch: what's the deal w/cracklib2 2.8.20?  your branch is status merged into lp:ubuntu/cracklib2 but the source branch doesn't reflect that.
[19:49] <micahg> arges: want a build log?
[19:49] <mfisch> barry: I thought someone merged it this morning, let me look
[19:49] <arges> micahg, did you add it somehow? I entered the chroot and it said pkg-create-dbgsym was installed
[19:49] <micahg> arges: it wasn't in my chroot for some reason, I added it with --add-depends
[19:51] <mfisch> barry: looks like someone merged it to me: https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/cracklib2/raring
[19:51] <arges> micahg, ok --add-depends , you are adding that to sbuild or mk-sbuild?
[19:51] <infinity> arges: pkg-create-dbgsym is pretty vocal about disabling itself.  Do you have a build log?
[19:51] <micahg> arges: sbuild
[19:52] <arges> micahg, ok i'll try that
[19:52] <arges> infinity, yea, I have a pastebin somewhere
[19:52] <infinity> "somewhere". :P
[19:53] <arges> infinity,  pastebin.ubuntu.com/1425766
[19:54] <infinity> arges: Right, so it's clearly installed and being triggered.
[19:55] <barry> mfisch: ah, bzr bd info is out of date
[19:55] <mfisch> barry: so In the bug I also added a debdiff and the bug still shows in the sponsor queue, whats the right change there?
[19:57] <infinity> arges: The binaries in all those packages are already stripped, there's nothing pkg-create-dbgsym can do there.
[19:57] <arges> infinity, ok so i need to choose another package then
[19:57] <SpamapS> jml: would you ever consider making undistract-me Expat licensed rather than PD?
[19:58] <SpamapS> jml: I'm packaging it for Debian and PD is.. less than desirable since it is a non-license.
[19:58] <barry> mfisch: looks like the bug was not closed by the changelog entry.  that's why adding (LP: # 1088110) is useful.  at this point, i think just manually closing the bug as fixed released is the way to go
[19:58] <micahg> arges: DEB_BUILD_OPTIONS=parallel=4 debug nostrip noopt
[19:58] <mfisch> barry: oh, sorry I forgot the LP in the changelog
[19:58] <arges> micahg, yea that's what I added
[19:58] <infinity> nostrip would likely do it.
[19:59] <barry> mfisch: no worries, i closed the bug
[19:59] <mfisch> thanks
[20:17] <arges> micahg, infinity : ok i figured it out... needed to use a package that actually build debug symbols properly. thanks for the help
[20:31] <jtaylor> doko: have you forwarded the scipy m-a patches?
[20:32] <jtaylor> doesn't look like it ..
[20:40] <jtaylor> doko: I hope you don't mind, I made a pull request to scipys git
[21:55] <doko> jtaylor, thanks!
[22:02] <GunnarHj> Riddell: ping
[22:03] <Riddell> hi GunnarHj
[22:03] <GunnarHj> Riddell: Hello!
[22:04] <GunnarHj> Riddell: Saw your comment on bug 1041126. Does it mean that you prefer that we keep language-selector-kde for the time being?
[22:04] <Riddell> GunnarHj: isn't ubuntu desktop dropping language selector as well?
[22:05] <slangasek> why would it?
[22:05] <GunnarHj> Riddell: Yes, but it will probably be postponed yet another dev. cycler
[22:05] <Riddell> it's been on the wish list to replace it with the gnome module for cycles
[22:05] <slangasek> ah
[22:06] <GunnarHj> Riddell: And other derivatives, Xubuntu and Lubuntu, want to keep using it.
[22:06] <Riddell> GunnarHj: mm well we've no plans to pick it back up again currently so you can quietly let it bit rot if needed
[22:06] <Riddell> s/derivatives/flavours/
[22:07] <GunnarHj> Riddell: Ok, that may be a better word. :)
[22:07] <GunnarHj> Riddell: Thanks for giving me free hands as regards l-s.
[22:11] <jml> SpamapS: the license is whatever the hell makes it easy to distribute as open source
[22:11] <jml> SpamapS: expat is fine
[22:14] <ricotz> cjwatson, hi :), is it possible to get something like this into raring? http://paste.debian.net/plain/215675
[22:16] <GunnarHj> slangasek: Hi Steve, will you have time soon to take a look at https://code.launchpad.net/~gunnarhj/ubuntu/raring/pam/encrypted-home/+merge/135021 ?
[22:16] <slangasek> GunnarHj: I'm expecting to get to it next week
[22:16] <GunnarHj> slangasek: Great, thanks for letting me know.
[22:19] <ricotz> cjohnston, sorry for the typos :\ http://paste.debian.net/plain/215676
[22:19] <ricotz> cjwatson, ^
[22:21] <Laney> the most incorrectly tab completed nickname in the universe
[22:23] <slangasek> LanaTurner: yeah, sucks to be them
[22:23] <infinity> slank: :P
[22:23] <ricotz> Laney, oh, if you insist you can take a look too ;P
[22:25] <Laney> you probably want sla<tab> to look at that :-)
[22:26] <infinity> ricotz: I assume this magical new libpango doesn't exist yet?
[22:26] <ricotz> Laney, ok ;)
[22:26] <infinity> (I still have 1.6.0 here...)
[22:27] <ricotz> infinity, it is a new upstream release which is available for quite some time, but probably won't find its way into raring
[22:27] <ricotz> https://launchpad.net/~ricotz/+archive/staging/+sourcepub/2835187/+listing-archive-extra
[22:27] <infinity> ricotz: Kay, so just prepping plymouth for the future?
[22:28] <ricotz> exactly, and for ppa users of course ;)
[22:28] <ricotz> this newer pango is a hard-dep for the current gtk+3.0 dev releases
[22:29] <infinity> I assume it's still libpango1.0-0?
[22:29] <infinity> ie: not coinstallable with the previous version?
[22:29] <ricotz> yes it is
[22:29] <infinity> Kay, maybe this can autodetect a bit more sanely, then.
[22:31] <ricotz> probably, either way i would be happy to get it supported
[22:33] <infinity> for i in $(find /usr/lib/x86_64-linux-gnu/pango/ /usr/lib/pango/ -name libpango1.0-0.modules 2>/dev/null); do if [ -e $i ]; then echo ${i%%/module-files.d*}; fi; done
[22:33] <infinity> Gives me /usr/lib/x86_64-linux-gnu/pango/1.6.0 here.
[22:33] <infinity> Does it give you what you'd expect there?
[22:34] <ricotz> /usr/lib/x86_64-linux-gnu/pango/1.8.0
[22:34] <ricotz> here ;)
[22:34] <infinity> Right, I'll clean that up and use something like that, then.  Hardcoding the versioned path seems suboptimal.
[22:34] <ricotz> that is fine, thanks!
[22:35] <infinity> We can probably ditch the pre-MA path too, depending on when that was introduced.  Let me check.
[22:35] <ricotz> it is in precise for sure, so i guess it can be dropped
[22:36] <infinity> Oh, is this code also in Debian's plymouth?  Might be better to change it there.
[22:36] <infinity> slangasek: *pokity*
[22:36] <slangasek> mm?
[22:37] <slangasek> infinity: oh, is this why there's a bug report about text not rendering in the initramfs in raring? :P
[22:37] <infinity> No, this should be fine in raring.
[22:37] <slangasek> oh
[22:37] <infinity> Unless someone's using ricotz's PPA.
[22:37] <infinity> Then, not so much.
[22:37] <slangasek> probably not, since it's an ISO tester
[22:37] <slangasek> infinity: please file a bug report then
[22:38] <infinity> slangasek: Sure.  I was going to JFDI in Ubuntu, but if this exists in Debian too, may as well tidy it up a bit.
[22:38] <slangasek> infinity: er, then please file a bug report against the Debian package too? :)
[22:38] <infinity> A nick hilight wasn't enough? :P
[22:38] <slangasek> rumors to the contrary notwithstanding, I am not Daniel Baumann
[22:39] <infinity> I could have sworn I'd seen your name in the Debian plymouth changelog before.
[22:40] <infinity> Could be that it's Crack Tuesday.
[22:40] <slangasek> you could well have!  My name is in lots of changelogs
[22:40] <slangasek> I like to change things
[22:40] <slangasek> but I don't maintain plymouth in Debian ;)
[22:42] <hallyn> is there a debhelper way to add a /etc/sysctl.d/ file from a package?
[22:43] <infinity> hallyn: echo foo /etc/sysctl.d > debian/package.install
[22:43] <infinity> hallyn: HTH.
[22:43] <ricotz> infinity, oh, btw did you get my pm?
[22:43] <hallyn> infinity: ok, thanks :)
[22:43] <infinity> hallyn: (In other words, no, I don't think there's a helper for it)
[22:43] <slangasek> hallyn: you might want >> though :)
[22:43] <infinity> slangasek: Nah, the rest of the package's files were crap anyway.
[22:43] <slangasek> but yes, there's no specific helper for sysctl
[22:44] <infinity> ricotz: Maybe.
[22:44] <hallyn> screw the rest of the pkg.  sysctl will do it all
[22:44] <infinity> ricotz: Was is ASCII porn?
[22:44] <infinity> s/is/it/
[22:44] <ricotz> infinity, heh, let me try again
[22:44] <infinity> ricotz: If it was glibc-related, I haven't forgotten you.
[22:49] <ricotz> infinity, yeah, that too, if you have a ppa to check feel free to share ;)
[22:49] <infinity> ricotz: No, I have a hard drive to recover, and an experimental upload to prepare after that.
[22:50] <ricotz> alright
[22:52] <infinity> slangasek: Of course, it could be that this initramfs hook is Ubuntu-specific anyway (it is), so nevermind.  I'll just fix it here and carry on
[23:23] <xnox> micahg: we have xz ddebs  for raring, not anything earlier.
[23:23] <xnox> arges: ping pitti about ddebs on lucid-sbuild with precise host.
[23:25] <arges> xnox, so I figured out how to get ddebs for some packages
[23:26] <arges> xnox, trying to figure out how to get ddebs for linux kernel now
[23:27] <infinity> arges: The kernel build is "special".
[23:27] <infinity> arges: And has nothing to do with pkg-create-dbgsym (at all).
[23:27] <infinity> arges: It does it all by hand in rules.
[23:28] <arges> infinity, is there a wiki that explains how to do this via dpkg-buildpackage and sbuild?
[23:28] <infinity> The kernel team doesn't use sbuild for kernel testbuilds, so unlikely.
[23:29] <arges> infinity, so how to PPAs accomplish building the ddebs?
[23:29] <arges> i thought they used buildd which used sbuild?
[23:29] <infinity> Different sbuild.
[23:29] <infinity> But also, not the same thing at all, since you want your ddebs to end up in .changes, which they don't on the buildds.
[23:30] <arges> infinity, ok
[23:32] <infinity> arges: See debian/rules.d/2-binary-arch.mk
[23:32] <infinity> arges: Basically, it checks a magic buildd-only file, and does magic things based on it.  Which won't work for you. :P
[23:32] <arges> infinity, yea i see hmm
[23:33] <infinity> arges: So, either fix the source to unconditionally do what it normally does in that Build-Debug-Symbols case, or don't auto-clean your sbuild chroots, so you can fish the ddebs out of chroot/build/
[23:33] <infinity> (And by "fix", I mean "fix locally", cause it's doing the right thing in the archive right now)
[23:34] <arges> infinity, ahh I think there was a hook to do that somewhere
[23:35] <infinity> arges: You mean an sbuild hook to set up CurrentlyBuilding to look kinda like a buildd?
[23:35] <infinity> arges: That would work too.
[23:35] <arges> infinity, https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Setting_up_and_using_Sbuild_with_ddebs
[23:36] <arges> infinity, which had the  /etc/schroot/script-get-ddebs script. I'll give that a shot and see if it works
[23:37] <infinity> That would do the trick.
[23:37] <arges> infinity, cool... i'll give that a shot.
[23:37]  * arges heads out
[23:48] <barry> @pilot out