[00:00] ah so its just a coverup for a bet [00:00] made while drunk ;P === mnepton is now known as mneptok === slank is now known as slank_away [00:33] 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:33] Launchpad bug 1056743 in unity-lens-applications (Ubuntu Precise) "Searches fail across changes in case" [Undecided,In progress] https://launchpad.net/bugs/1056743 [00:46] Packages to change from priority required to important [00:46] ------------------------------------------------------ [00:46] libexpat1 [00:46] libpython3.3-minimal [00:46] python3-minimal [00:46] python3.3-minimal [00:46] I win. [01:19] 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:19] Launchpad bug 1070481 in xorg-server (Ubuntu Raring) "memory corruption in xorg-server when closing acpid" [Undecided,Fix released] https://launchpad.net/bugs/1070481 [01:19] Launchpad bug 1010794 in xserver-xorg-video-nouveau (Ubuntu Quantal) "Graphics/text corruptions in some applications with nouveau drivers" [High,Triaged] https://launchpad.net/bugs/1010794 [01:28] slangasek, done. [01:28] bryce: ta [01:29] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell [03:06] 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] no, maybe ubuntu-devel if it's related to Ubuntu Development [03:10] Here's the wiki page: https://wiki.ubuntu.com/ContributorConsole [03:12] 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] depends what you're asking for help wiht [03:14] *with [03:16] * micahg isn't sure....maybe someone else can answer this [03:20] 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] Good morning [04:35] hello pitti [04:43] 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] but for lenses, there are usually only single commits so distro patching would make sense as well [04:44] but thanks for approving it already === Ursinha is now known as Ursinha-afk === chiluk_away is now known as chiluk === cpg is now known as cpg|away [05:54] Mirv: you're welcome :) === doko_ is now known as doko [06:08] what's the state of the -compat package? [06:08] infinity, ^^^ [06:28] 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] abogdan: I think you want #ubuntu-app-devel. === cpg|away is now known as cpg === soren_ is now known as soren === chiluk is now known as chiluk_away [07:32] good morning === smb` is now known as smb === Ivanka_ is now known as Ivanka === Tonio_aw is now known as Tonio__ [09:13] ev: WDYT about http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/509 ? [09:15] pitti: looking [09:15] ev: with this, make check succeeds for me [09:30] pitti: yeah, that looks entirely reasonable [09:30] thanks for that! [09:30] feel free to merge [09:30] ev: pushed [09:30] thanks [09:31] 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] ah, right [09:31] 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] ev: such as [09:31] $ CRASH_DB_URL=http://localhost:8080 CRASH_DB_IDENTIFIER=TESTSUITE APPORT_REPORT_DIR=/tmp/x src/whoopsie -f [09:31] which I have working already, just cleaning up a bit [09:32] ev: does that sound ok to you? [09:32] yes, as it also means we could someday use that to generate a known identifier that we could filter out server-side [09:32] ev: it would also allow us to drop the "sudo stop whoopsie" bits from run-from-juju [09:33] woo [09:33] I was initially startled by that second password prompt :) [09:38] ev: hm, do you know that locking is broken without -f? [09:39] I did not know that, no [09:39] ev: the foreground process closes the lock fd as soon as it terminates [09:39] eep [09:39] no biggie, it just caught my eye; works fine with -f === henrix_ is now known as henrix [09:49] ah, very good; all working now === Pricey_ is now known as Pricey [09:55] awesome [09:57] ev: I tested this now with both the default "run as root" case, as well as running as user: http://paste.ubuntu.com/1425021/ === Sweetsha1k is now known as Sweetshark [10:10] ev: some cleanups and commit msg: http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/510 [10:11] ev: oh, this includes the packaging, sorry; I'll re-do the commit to update debian/changelog [10:11] thanks [10:11] ah excellent on opportunistically fixing the APPORT_REPORT_DIR bug [10:13] ev: changelog pushed for previous commit [10:14] yay [10:14] ev: http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/511 [10:33] ev: while I was at it, I also fixed all compiler warnings in http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/512 [10:33] ev: I'll push that once 511 gets reviewed and can land [10:33] wow, you're on a roll! [10:34] 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] 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] oh, I'll also chase up that ticket for getting openstack credentials [10:34] so we can get tarmac in place [10:34] :D [10:35] turtles all the way down [10:36] ev: do you want to give this some deeper eyeballing, want an MP, etc? [10:36] I'm looking over it now - no need for an MP === mcclurmc_away is now known as mcclurmc [10:37] looks excellent [10:37] this reminds me that I want to get the gcov stuff in the Makefile working again [10:38] feel free to merge [10:39] ev: pushed (for cleaner history); mind if I send this raring-wards? or do you want to do further changes? [10:39] https://bugs.launchpad.net/whoopsie/+bug/1088847 [10:39] Ubuntu bug 1088847 in Whoopsie "We should generate a gcov report with each commit" [Undecided,New] [10:39] please do [10:39] yeah, that sounds useful indeed [10:39] with pygobject I was really surprised how easy that was to set up, and how useful it its [10:39] s/its/is/ [10:40] 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] ev: the standard way known to me is to overwrite functions with an LD_PRELOAD library [10:41] 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] makes sense [10:42] right [10:42] not very elegant for sure, but unless you design the code in the way you mentioned I don't know another way [10:43] And indirecting everything through function pointer arguments is pretty un-C-like; I suspect it also has performance penalties [10:44] or you use GObject more, and thus get the function pointes that way (through the vtable) [10:44] cjwatson: yeah, that was very much a strawman [10:44] ev: what do you want to mock in whoopsie? [10:44] I don't like having to bust out cdecl to understand a function prototype [10:44] ev: (I guess you are talking about whoopsie, as all the other bits are py) [10:45] typedefs help a lot, but yes ... [10:45] pitti: for example, if we wanted to test handle_response [10:45] pitti: when we start getting a number of different potential responses from the server [10:46] it either needs to take a function argument to delegate to, or we need to mock out upload_core and friends [10:46] ev: wouldn't it be better to whip up a mock server in python and have whoopsie talk against that? [10:47] 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] but I guess the later is going to give far more interesting results [10:47] ev: I'm actually a mix of both [10:48] if you want to test for responding to server answers, this is already an integration test [10:48] for my current thinking, see the ServiceRequirements stuff on dev.launchpad.net [10:48] where I suggest having a python mock server that supports error injection, starts up in a jiffy etc. [10:48] 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] 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] understood, to both of your points [10:53] 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] 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] pitti: I believe so. We can always stick it in a PPA for other releases if it becomes necessary. [10:54] pitti: indeed we do want to run it for nagios [11:03] 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] cheers [11:07] win 18 [11:07] oops [11:07] Sorry people === _salem is now known as salem_ === Quintasan_ is now known as Quintasan === fisted_ is now known as fisted [11:25] kirkland: do you still maintain manpages.ubuntu.com? [11:34] Laney: are you also longing for recent releases? [11:35] Laney: I think we just should fork the config: add/remove releases and file RT to get it redeployed. [11:35] https://code.launchpad.net/ubuntu-manpage-repository [11:37] sure, that was the secret intent behind the ping [11:39] RAOF: do you have a second to discuss bug #985202 with me? [11:39] Launchpad bug 985202 in libxfixes (Ubuntu) "libx11 causes kwin to crash on login (over NX protocol)" [Undecided,Confirmed] https://launchpad.net/bugs/985202 [11:39] xnox: making it dynamic would be even better ;-) [11:40] 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] well, using distro-info [11:41] Laney: is that installed? [11:41] * xnox goes to talk to webops/is. [11:42] i'm sure it could be [11:47] Laney: why is distro-info --supported listing raring as supported release? [11:47] Laney: should I filter out --devel from --supported, or do we want manpages early? [11:48] does it always take the latest as the default? [11:48] and I dunno, sounds like a bug [11:48] bdrung: is that a bug? [11:50] debian-distro-info --supported looks similarly fishy [11:53] xnox: note there is python-distro-info for the python part [11:53] Laney: sure, but manpages.ubuntu.com is a pile of shell & perl scripts with config file sourced as shell. [11:53] Laney: so... DISTROS=`distro-info --supported` works just fine =) [11:54] there's at least search.py with a list of versions [11:54] dict [11:54] Laney: and some javascript as well =( [11:54] unlucky [11:55] Laney: do we SRU distro-info or does it fetch data over the interwebz? [11:55] the former [11:55] distro-info-data [11:58] (so IS has to take that SRU for the site to know about new releases, which is still easier than a full deployment) === Tonio_ is now known as Tonio_aw [12:02] Laney: that depends how you define supported. [12:02] --supported [12:02] list of all supported stable versions === Tonio_aw is now known as Tonio_ [12:03] "stable" is the issue here. [12:04] maybe it should be able to retrieve all supported stable version and all supported (not released) versions [12:05] bdrung: well --devel says raring, maybe it should somehow exclude devel from --supported. [12:30] Laney: filed RT, just a static update. [12:30] alright [12:30] ty [12:30] Laney: we have ~ a year to port this webapp to distro-info-data. === tkamppeter_ is now known as tkamppeter [13:06] 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] anyone know much about using imagemagick in the debian/rules file to draw the icon? is it possible? [13:25] israeldahl: what do you want to achieve ? [13:26] israeldahl: create an icon from an upstream image ? [13:27] OdyX: the icon looks awful when it gets installed and I want it to look correct. this is for lmms [13:29] doko: ping! [13:31] I have had to resort to linking to a different file in the lmms.desktop, but I want to fix it the right way === chiluk_away is now known as chiluk === cpg is now known as cpg|away === ogasawara_ is now known as ogasawara [14:03] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell, Laney === Laney is now known as robert_ancell [14:04] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney === robert_ancell is now known as Laney [14:04] :-) [14:04] Laney: how did you cross that continent so fast :) [14:05] Laney: cheat. [14:05] collapsars === tgall_foo is now known as tgall === Zdra is now known as xclaesse [14:44] barry: hey, around? [14:47] didrocks: hi! [14:47] 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] barry: hi! [14:48] sil2100: hi :) [14:49] 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] But since the latest version (uploaded yesterday?) the file is missing from all the python packages [14:49] I traced down the problem, and found which revision of the packaging branch removed it [14:49] Maybe by accident? SInce I'm not sure if it's intended [14:49] http://bazaar.launchpad.net/~doko/python/pkg2.7-debian/revision/93 [14:50] Here in the diff of debian/rules, around line 732 in that file [14:51] I saw some debian/rules cleanup there, so I though that maybe this one line got removed by accident [14:51] barry: do you know anything about this ;) ? [14:52] cyphermox: I think the indicator issue you got yesterday is maybe linked to that as well ^ [14:52] sil2100: yes. [14:53] 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] sil2100: it's the same change as with python3.3 - there are now two include locations. [14:53] barry: but hm, then which package installs pyconfig.h then? [14:53] Since it's not in python2.7-minimal anymore, neither is it in -dev and libpython2.7-dev [14:54] sil2100: one of dependencies of python-dev === slank_away is now known as slank [14:56] sil2100, dpkg -S pyconfig.h [14:56] sil2100: i still should be libpython2.7-dev [14:56] sil2100, it's installed, just in /usr/include//... [14:56] sil2100: the point is that python multi-arch now uses 2 include locations /usr/include/python2.7 and /usr/include//python2.7 and you need both includes. [14:57] xnox: ah, indeed, it's in libpython2.7-dev [14:57] libpython2.7-dev [14:57] xnox: thanks! See it now [14:57] oops, yeah [14:57] :) [14:57] We'll update the dependencies then! [14:57] I couldn't find it due to multiarch ;) [14:57] it's a brave new world [14:57] seb128: thanks as well! [14:57] 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] didrocks: I'll make a merge request for that [14:58] xnox: https://launchpadlibrarian.net/125437610/buildlog_ubuntu-raring-i386.compiz_1%3A0.9.9~daily12.12.05bzr3522pkg0raring0_FAILEDTOBUILD.txt.gz [14:58] sil2100: excellent! Thanks a lot for digging in :) [14:59] sil2100: thanks. well the build-record, such that I can grab source? e.g. which ppa is this for? =) [14:59] xnox, get compiz from raring I guess it will have the same issue [14:59] nevermind see it: unity-team/staging [14:59] xnox: https://launchpad.net/~unity-team/+archive/staging/+build/4055447 [14:59] sil2100: thanks. [14:59] xnox: just pull lp:compiz and you're done ;) [15:00] But I'm preparing a merge request for the change right now anyway, so we'll have it fixed soon [15:00] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [15:00] sil2100: ok, can you pastebin a patch such that I can review it? [15:00] sil2100: or point to merge proposal? [15:01] xnox: we do merge proposal for everything in our world :) [15:01] (with peer reviews) [15:01] ok =) [15:01] didrocks: bzr diff | pastbin & comments on irc is also "peer review" =))))) [15:01] xnox: I'll post the link to the merge proposal here ;) [15:02] xnox: right, but the merger won't care about your comment on IRC :) [15:02] 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] xnox, shouldn't cmake by fixed in that case? [15:05] didrocks, xnox: I'll just test-build it quickly [15:05] sil2100: "quickly"? aren't you talking about building compiz? :p [15:05] ...;p [15:06] 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] 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] 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] 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] e.g. I don't understand why so many packages use "custom" python detectors instead of using pkg-config. [15:11] 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] 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] =`((((( [15:12] clearly everyone should switch to waf build system. [15:12] * xnox hides =) [15:12] lol [15:15] barry, xnox: maybe I'll just include a fake header for all know multiarch tuples [15:16] doko: not sure what that means [15:16] 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] 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] 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] 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) === jcastro__ is now known as jcastro_ [15:43] xnox, barry: something like http://paste.ubuntu.com/1425505/ === henrix_ is now known as henrix [15:43] doko: oh wow, yeah. maybe put that in a new python2.7-your-build-is-broken binary package? :) [15:44] 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] doko: is that going into "multiarch-support" package? :P [15:45] didrocks: some changes will be needed for d/control d/rules [15:51] didrocks: shall we bump the version to 0.3? :) [15:52] barry: I'm fine with that :) [15:52] didrocks: cool :) i'll push an mp after some local testing [15:52] barry: sounds perfect! :) [16:06] seb128, what was the source package for the python autoconf test. there was one, but I can't remember which one ... [16:07] mhall119: FYI, singlet has some warnings about deprecated methods when run in raring [16:07] mhall119: I think the fix is safe in Q as well: PyGIDeprecationWarning: MainLoop is deprecated; use GLib.MainLoop instead [16:07] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney [16:09] doko: autoconf archive? [16:09] no, autoconf doesn't have such kind of macro themself [16:10] * dholbach hugs Laney [16:11] 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 === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ [16:18] ogra_: around? I'm having trouble reproducing bug 1079185 for SRU verification. [16:18] Launchpad bug 1079185 in flash-kernel (Ubuntu Quantal) "Wrong bootarg for disk with label" [High,Fix committed] https://launchpad.net/bugs/1079185 [16:18] ogra_: it's holding up landing the fix for bug 1084106 [16:18] Launchpad bug 1084106 in The Eilt project "highbank installer broken" [Undecided,Triaged] https://launchpad.net/bugs/1084106 [16:20] 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] 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] 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 === dholbach_ is now known as dholbach [16:23] mvo: see the discussion we had here 1h30 ago ^ [16:23] mvo: new python changed and is multiarch, sil2100 works on a fix [16:24] didrocks: aha, nice. then I will not duplicate this effort [16:24] no need! :) [16:25] 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] yes. [16:28] 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] arges: if you create sbuild with mk-sbuild, you auto-get ddebs. [16:30] doko, dunno for python autoconf test... [16:30] xnox, in precise? or does it need to be a newer sbuild host? [16:30] 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] sil2100: filed bug 1088988 [16:31] Launchpad bug 1088988 in python2.7 (Ubuntu) "inconsistent python2.7 include multiarch paths" [High,Confirmed] https://launchpad.net/bugs/1088988 [16:32] 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] xnox, with mk-sbuild... [16:32] xnox, mk-sbuild --arch=amd64 --distro=ubuntu lucid [16:32] xnox, not sure if there si something special I need to add to .mk-sbuild.rc [16:33] 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] xnox, ok and those ddebs will get placed in the same location as the .debs then after a build? [16:33] arges: which you can reconfirm by reading the buildlog - it will announce redirecting dh_strip / generation of ddebs. [16:34] arges: yes. [16:34] xnox, ok i'll investigate, I looked at the buildlogs and I saw it was installing pkg-create-dbgsym [16:34] didrocks, mvo, xnox: after this would get fixed, I think this merge request could be considered? [16:34] https://code.launchpad.net/~sil2100/compiz/fix_python_find_package/+merge/139256 === Ursinha-afk is now known as Ursinha [16:38] hmm, strangely, I can't link a branch to a bug [16:39] https://bugs.launchpad.net/compiz/+bug/1088996 [16:39] Ubuntu bug 1088996 in Compiz "FTBFS after python2.7 upgrade - missing pyconfig.h" [High,In progress] [16:39] Here's the FTBFS bug, but I'm unable to link my branch to it ;p [16:40] Ok, finally I was able === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ === deryck is now known as deryck[lunch] === henrix is now known as henrix_ [17:56] 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 === attente is now known as attente_zzz === shadeslayer is now known as buildslayer [17:57] 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) === henrix_ is now known as henrix [18:00] arges: well, it works for me on quantal/raring. i'll try against on precise and will let you know. [18:00] xnox, ok, I'll try on raring here as well... trying to target precise [18:00] arges: have you tried installing pkg-create-dbgsym in the golden/source image as I suggested earlier? [18:01] xnox, so I see it pulled in the buildlog [18:01] arges: 1 second - what does your machine run & what do you build for? [18:01] arges: can you pastebin the buildlog? [18:01] xnox, running precise amd64, schroot is lucid amd64 [18:02] xnox, sure one second [18:02] xnox, pastebin.ubuntu.com/1425766 [18:03] arges: i don't think ddebs existed in lucid. [18:03] arges: but I might be wrong. [18:03] xnox, there is a release directory in ddebs.ubuntu.com [18:04] xnox, for lucid [18:04] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [18:04] xnox, you are wrong ;-) [18:06] 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] arges: apart from that it is working "correctly" [18:07] xnox, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-November/000355.html [18:08] xnox, it was well before lucid ;-) [18:08] xnox, ok so I need to pick another package that has ddebs... [18:08] seb128: ok =0))) [18:09] xnox, i picked that one because it was small and I did find the -dbgsym in the ddebs archive [18:09] for lucid though [18:09] xnox, also pkg-create-dbgsym is in the golden master image [18:10] it was already created by default [18:10] s/created/installed [18:11] arges: pitti is probably the best person to ask about dbgsym. but he might be offline already. [18:12] it recent releases "it just works" & i never did dbgsym packages for lucid. [18:12] xnox, ok i'll hack on it [18:12] xnox, i'll try a precise schroot next . thanks a ton for your help! [18:12] arges: no worries, but it's not like i solve the problem for you =/ [18:14] * arges lunches [18:32] mfisch: did you file a bug and submit a patch? === slank is now known as slank_away === mcclurmc is now known as mcclurmc_away [18:40] barry: is there a mailman command to get a list of the lists I'm subscribed to? === Tonio_ is now known as Tonio_aw [18:58] mdeslaur_: from the command line, or email command (or via web)? === deryck[lunch] is now known as deryck [19:14] barry: from the web [19:15] barry: or email [19:15] barry: ie: I don,t have access to the command line === carif_ is now known as carif [19:26] mhall119: will do so [19:30] 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] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry [19:32] xnox, ok precise schroot on precise behaves as expected building the .ddebs properly , but lucid schroot on precise doesnt' build ddebs. [19:32] barry: ah, cool...thanks! [19:33] np! === henrix is now known as henrix_ [19:34] arges: are you doing xz debs? [19:35] 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] arges: ok, sorry, was missing some context, I know xnox was trying to get xz ddebs... [19:36] 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] let me see if I have an ddebs from lucid builds locally [19:39] arges: which package are you trying? [19:39] 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] micahg, i'd like to build a kernel with ddebs in a schroot, but rebuild/test cycle is pretty lengthy [19:40] TBH, idr if I get them or not [19:40] just kicked off a build to see if I do [19:42] micahg, ok . did you add any DEB_BUILD_OPTIONS or add anything when you called mk-sbuild? === attente_zzz is now known as attente [19:44] mhall119: here you go: https://code.launchpad.net/~mfisch/singlet/fix_deprecation_warning/+merge/139301 [19:45] thanks mfisch [19:45] arges: nope, and I don't get them on lucid, even with pkgbinarymangler installed [19:46] micahg, hmm ok. is this a bug I should file? or am I missing something [19:46] micahg: pkg-create-dbgsym, you mean. [19:47] micahg: pkgbinarymangler doesn't make ddebs. [19:47] infinity: right.. [19:47] infinity yea and I confirmed pkg-create-dbgsym is in the golden master lucid schroot by default [19:47] This reminds me that I need to recreate all my schroots after my great hard drive crash. What a pain. [19:48] actually, with pkg-create-dbgsym I do get the ddeb :) [19:48] 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] arges: want a build log? [19:49] barry: I thought someone merged it this morning, let me look [19:49] micahg, did you add it somehow? I entered the chroot and it said pkg-create-dbgsym was installed [19:49] arges: it wasn't in my chroot for some reason, I added it with --add-depends [19:51] barry: looks like someone merged it to me: https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/cracklib2/raring [19:51] micahg, ok --add-depends , you are adding that to sbuild or mk-sbuild? [19:51] arges: pkg-create-dbgsym is pretty vocal about disabling itself. Do you have a build log? [19:51] arges: sbuild [19:52] micahg, ok i'll try that [19:52] infinity, yea, I have a pastebin somewhere === slank_away is now known as slank [19:52] "somewhere". :P [19:53] infinity, pastebin.ubuntu.com/1425766 [19:54] arges: Right, so it's clearly installed and being triggered. [19:55] mfisch: ah, bzr bd info is out of date [19:55] 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] arges: The binaries in all those packages are already stripped, there's nothing pkg-create-dbgsym can do there. [19:57] infinity, ok so i need to choose another package then [19:57] jml: would you ever consider making undistract-me Expat licensed rather than PD? [19:58] jml: I'm packaging it for Debian and PD is.. less than desirable since it is a non-license. [19:58] 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] arges: DEB_BUILD_OPTIONS=parallel=4 debug nostrip noopt [19:58] barry: oh, sorry I forgot the LP in the changelog [19:58] micahg, yea that's what I added [19:58] nostrip would likely do it. [19:59] mfisch: no worries, i closed the bug [19:59] thanks [20:17] micahg, infinity : ok i figured it out... needed to use a package that actually build debug symbols properly. thanks for the help [20:31] doko: have you forwarded the scipy m-a patches? [20:32]