=== beuno_ is now known as beuno [01:39] So, I just found another interesting resolvconf failure. Inside an ubuntu-core image, run "apt-get update && apt-get install ubuntu-minimal". It will fail on resolvconf. [01:40] start: Unknown job: resolvconf [01:40] invoke-rc.d: initscript resolvconf, action "start" failed. [01:40] dpkg: error processing resolvconf (--configure): [01:41] GrueMaster: Is that running on top of overlayfs? [01:41] No, just chroot. [01:43] GrueMaster: Oh, uh. It's because you don't have upstart running in the chroot. Which is somewhat expected. Sorry, already turned my brain off for the day. :P [01:43] (assume sudo su): tar -C Core -zxvf precise-core-armhf.tar.gz && cp /etc/resolv.conf Core/etc && chroot Core. [01:44] GrueMaster: A policy-rc.d that prevents you from starting things would help. [01:44] Ah. Well, this is a problem. [01:44] GrueMaster: Installing any upstart service in a chroot would have the same result. [01:46] So, why do none of the other packages in ubuntu-minimal have this issue? [01:47] I assume there are other apps that use init. [01:47] Because none of them install upstart services and try to run them? [01:48] Basically, the only two ways upstart can know about a new service is either (A) running some cryptic command that I've now forgotten (but I think we should probably add it as a dpkg trigger), or (B) if upstart is running, it has an inotify hook on /etc/init. [01:52] FYI, upstart works fine in chroots [01:52] initctl reload-configuration [01:52] yeah that works [01:52] but you need, uh, natty's upstart or newer outside the chroot [01:52] yeah [01:53] Ah, well that would be problematic then. [01:53] and you don't need initctl reload-configuration for the initial start/stop .. but you do need it after that if you are chrooted on top of overlayfs, because overlayfs is broken [01:53] (some inotify bug) [01:53] I wonder how our buildds did it on the babbages? [01:53] a dpkg trigger wouldn't be an unreasonable way to work around overlayfs+inotify sucking [01:54] GrueMaster: no build will work if it depends on an upstart job AFAICT [01:54] broder: well in mk-sbuild chroots, policy.d denies starting jobs anyway [01:54] SpamapS: right, but there's a livecd issue [01:54] policy-rc.d rather.. or whatever its called [01:55] broder: I think we should actually be able to fix overlayfs.. very troubling to me that its broken. [01:55] * SpamapS wanders off to eat dinner. [01:56] good plan :) [02:09] SpamapS: Fixing inotify in overlayfs is a much tougher problem than it looks like at first blush. apw and I have talked circles around it a few times. [02:11] GrueMaster: buildds have no issues with it because we use a null policy-rc.d during livefs builds. [02:11] ah [02:42] any ubuntu folks going to https://events.linuxfoundation.org/events/collaboration-summit/request-an-invitation ? [03:00] @pilot out === udevbot changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect. Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [03:55] I have a question regarding Ubuntu install image ISO creation, but no one seems to ever be in the #ubuntu-iso channel. Does anyone have contact info for someone who might be able to answer my question? [03:56] sephthir: just asking in here has a decent chance of finding an answer [03:57] Alright, I wasn't entirely sure if this was a decent place to ask. What I really need is the method by which the Ubuntu alternate install discs are created, but I can't seem to find any documentation on it. Does anyone know where I might be able to find info on how they're created? === pp7 is now known as malkauns [04:41] Good morning === vindolin_ is now known as vindolin === bladernr_ is now known as bladernr_afk === dendro-afk is now known as dendrobates [05:14] theres no ubotu on #ubuntu-x, how to get it back? [05:16] tjaalton: ask in #ubuntu-irc I think [05:16] micahg: ok, thanks [06:51] pitti: for gmime2.4, if dh-cli is useful, why not duplicate it in the arch dependent build deps? [06:51] micahg: becuase it pulls in a gazillion build depends [06:52] and I think meebey's main point of having it in B-D-I was to allow much quicker -B builds [06:52] ah, ok [06:52] it's how the previous debian/rules worked [06:52] I just inadvertently broke it when moving from "-include cli.mk" to "dh --with cli" [06:52] (the "-" was the trick) [07:01] \o/ powerpc backlog clear [07:21] micahg: wait until Laney starts the ghc transition :) [07:21] or ":(" rather [07:21] I have two packages in ubuntu that have updates that I would like to get in for precise [07:22] i submitted update requests last week (Bug 933299 and 933303) with a link to the packages in my PPA, but it was suggested that I wait for them to get into debian first and then get a Feature Freeze exception [07:22] Launchpad bug 933303 in aweather (Ubuntu) "Please upgrade aweather to version 0.7" [Undecided,New] https://launchpad.net/bugs/933303 [07:22] Launchpad bug 933299 in libgrits (Ubuntu) "Please upgrade libgrits to version 0.7" [Undecided,New] https://launchpad.net/bugs/933299 [07:23] pitti: most of ghc won't go very far on powerpc due to ghc-ghci being dropped (unless it was added back) [07:23] meh, is it just me, or does pretty much every UDD branch fall over due to pre-applied quilt stuff? [07:24] however, they still haven't made it into Debian. should i keep waiting or should I ask someone to upload the packages from the PPA? [07:25] andy7534211: if you're the Debian maintainer, see if one of the Ubuntu DDs would be willing to sponsor it for you [07:26] andy7534211: since they're team maintained, have you asked in #debian-science? [07:29] i emailed the debian-science list yesterday after i was unable to contact the sponsor for the packages, but i guess he saw that email because he uploaded one of the packages (it's in the Debian New queue now) [07:29] but the second packages (aweather) depends on the first, so that's not in the queue yet [07:29] ah, ok, so we should just wait then [07:30] ok, i was wondering because the beta freeze is coming up and i wasn't sure if it would be possible to get a freeze exception for that [07:31] as tumbleweed mentioned they're leaf apps (well, co-dependent leaf apps), so an FFe shouldn't be that hard [07:31] ok, so that's still true during the beta freeze as well? [07:32] oh, i guess there's a `feature freeze' period between the two beta releases.. [07:34] final freeze for universe if a few days before release, that's the only period it would be almost impossible to get an exception, I don't suggest waiting an inordinately long time, but just past beta 1 (about a week from now) shouldn't be much of a problem [07:34] s/if/is/ [07:35] great, thanks for clarifying that for me [07:39] does anyone know where I might find more information about how the ubuntu install isos are built? [07:41] pitti: have you seen http://blog.bazaar.canonical.com/?p=405 [07:41] micahg: yes, I did; but that doesn't seem to be in precise yet [07:41] bzr: ERROR: unknown command "quilt-commit-policy" [07:42] mm i think this needs to be in ~/.bazaar/builddeb.conf or something [07:42] yes [07:42] it's not a command [07:42] oh [07:42] hth, let me know [08:10] good morning [08:26] to refresh my memory, we can only not explicitly depend on stuff that's Priority: required and Essential:yes, right? [09:58] hey, any idea if debian/ubuntu allows init scripts to take arguments? [09:58] (arguments additional to status/start/stop etc.) [09:59] so you can call them like "/etc/init.d/service status X") [10:08] kklimonda: http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit the single action argument is a "should" not a "must", so it's not entirely illegal. [10:14] tumbleweed: hmm, not entirely illegal makes it sound like not entirely good idea :) [10:14] kklimonda: as long as it's an extra feature and "status" still works as expected, I don't see any problem [10:15] pitti: actually I think infinity will be pulling the trigger this time ;) [10:15] plausible deniability [10:16] *chuckle* [10:16] tumbleweed: hmm, makes sense - thanks [10:16] Laney: I'm fairly sure the powerpc buildds won't care much :) [10:16] heh [10:16] whoah, no ppc build queue, I'm impressed [10:16] Laney: fix that [10:17] any one of you can start it; it's an easy merge :P [10:17] * Laney is doing some rebuilds in Debian instead, for now [10:19] actually two easy merges (ghc and haskell-devscripts) [10:22] diwic, seb128: I like the new audio settings capplet; it makes more sense than the old one [10:23] pitti, yeah, kudos to ronoc on #ubuntu-desktop as well who did most of the ui work [10:23] pitti, thanks :-) [10:23] (and is still doing) [10:24] ...and christian, and Allan Day from gnome design, and... [10:25] diwic, is that work going upstream? [10:25] because right now we have a forked codebase :-( [10:26] seb128, I intend to try once PulseAudio 2.0 is released [10:26] diwic, great [10:27] seb128, we're having some distro patches to PulseAudio 1.1 for this functionality to work, and they will (most likely) go in PulseAudio 2.0 [10:27] ok [10:28] so I doubt upstream Gnome would take it before they have a stable PA release to test it agains. [10:28] s/agains/against [10:32] * diwic notices that today's updates brings in version "1.0.0-1pitti1" of remmina, and recognised the name in the version more than the application itself [10:35] I was following this guide http://mhall119.com/2012/02/contributing-to-unity-for-non-developers-quicklists/ . "bzr branch ubuntu:totem" fails with "OUT-OF-DATE" error. Any idea? [11:02] About GoogleSoC2012 [11:03] improving speed of code generate by gcc [11:03] sets [11:03] ? === _salem is now known as salem_ === chrisccoulson_ is now known as chrisccoulson [11:38] JokerInDisguise, that's not an error. at least i see the same thing and the branch is succesful [11:40] brendand: not successful for me. http://paste.ubuntu.com/852530/ [11:40] JokerInDisguise, this is the error: bzr: ERROR: Target directory "" already exists. [11:41] JokerInDisguise, what command did you run exactly? [11:41] bzr branch ubuntu:totem [11:41] JokerInDisguise, does the directory 'totem' already exist? [11:41] bradm: No, its empty folder. [11:42] chrisccoulson, what was the reason for dropping libxul.pc? apparently the headers are still there [11:42] brendand: wrong mention, sorry.. [11:43] doko, nobody should be using libxul.pc. it only existed for embedders and extensions that needed to link against libxul [11:43] Laney, seb128: did any of you have a bit of time to review goocanvasmm-2.0 or libgdamm5.0 in my PPA? :) [11:43] the only thing that was using it was mozvoikko, but that is now pure-JS, so there should be nothing at all in the archive using it [11:43] the headers might go at some point too ;) [11:43] no sorry, just go ahead; there's nothing that can't be fixed later i'm sure [11:43] chrisccoulson, I hope not before the lts. and what should be used instead? [11:44] doko - the only headers that should be used are the npapi headers (which i wouldn't get rid of) [11:44] thanks Laney, seb128 [11:45] dholbach, thanks for working on that [11:45] thanks murrayc and the openismus folks :) [11:45] chrisccoulson, ok, thanks [11:47] chrisccoulson, #include [11:47] #include [11:47] are these kept as well>? [11:47] doko, yeah, those are fine [11:49] seb128, Laney: uploaded [11:49] dholbach, danke [11:49] dholbach: sorry for not doing it [11:49] i want to help it get into debian, but not enough fingers for all of the pies [11:50] I'm sure that if we stay on top of things and get glom in, we can help Murray and the Openismus maintain it afterwards - they defacto maintain it in their PPA anyway already [11:50] seb128, g_thread_init was deprecated, wasn't it? and what was the replacement? [11:51] doko, yes it is [11:51] doko, nothing, glib init it for you [11:51] doko, just drop the call [11:52] seb128, and for which glib/gtk versions do I need to keep it? [11:54] doko, it's deprecated since 2.31 [11:54] i.e this cycle [11:54] well things should just build fine with it if you don't use G_DISABLE_DEPRECATED [11:56] hmm, glib_init isn't called in the library [12:00] JokerInDisguise, i can't directly see what the problem is without being able to poke around. Are you using Precise? [12:01] brendand: yeah, I'm on Precise, fully updated. === MacSlow is now known as MacSlow|lunch [12:14] geser, could it be that the results of the application of nataliabidart was not announced yet? or did I miss a memo? [12:20] dholbach: could be, the DMB lacks sometimes to reply with the result to an application on devel-permissions [12:21] ok [12:21] checking right now it it was acted on at least [12:26] dholbach: it was acted on, nessita has upload right for the ubuntuone packageset, so only the announcement is missing [12:26] excellent [12:26] thanks a bunch geser [12:27] * nessita feels the ping [12:27] hello everyone! [12:27] hey nessita :) [12:27] * dholbach hugs nessita [12:27] hola dholbach! /me hugs back :-) [12:31] doko: yodl MIR ping, bug #920436 [12:31] Launchpad bug 920436 in yodl (Ubuntu) "[MIR] yodl" [Undecided,New] https://launchpad.net/bugs/920436 [12:31] I really want to update zsh this cycle [12:33] doko, I'm not sure if barry noticed, but sphinx FTBFS because python-whoosh is in universe (it's just needed for a fraction of the test suite and builds easily without it) - what do you think we should do about it? [12:35] dholbach: I thought he uploaded a fix [12:35] oh yeah? [12:36] yip, it's in NEW [12:36] oops, yeah, you're right [12:37] nevermind then :) [12:51] doko, are you able to apply https://bitbucket.org/tarek/distribute/changeset/191f38f47256 as it's a fix to a bug introduced in distribute (0.6.16-1) update [12:52] this is for Oneiric [13:22] Cas-, can you file an issue and prepare a SRU? === MacSlow|lunch is now known as MacSlow === jincreator1 is now known as jincreator === yofel_ is now known as yofel [13:48] ev: btw, how is apport/whoopsie supposed to work after release? [13:49] ev: usually we disable it completely in /etc/default/apport [13:49] ev: but I suppose that would also stop whoopsie-daisy? [13:49] ev, pitti: how is that apport,whoopsie thing supposed to work? do we still get bugs in launchpad the same way as before? [13:49] pitti: funny you should mention that. I was discussing it this morning with apw this morning [13:50] seb128: yes, we want to, at least until the crash db can create bug reports by itself [13:50] seb128: for now we need to upload them twice [13:50] good [13:50] pitti: I'll have to craft a branch to move the check of /etc/default/apport to when it wants to open the browser and file in launchpad [13:50] I was wondering if the work I put on improving GNOME hooks was going to be wasted [13:50] ev: I noticed a couple of other regressions, e. g. it lost the ability to display an existing bug if it has a DuplicateOf field; I guess I'll file bugs for that and the issues identified in the MP [13:51] pitti: please do === bladernr_afk is now known as bladernr_ [13:51] ev: we should be aware that leaving /e/d/apport enabled (i. e. the core dump and zipping) is a rather large overhead for stable releases [13:51] as it consumes quite a bit of CPU and IO, and leaves the crashing program in limbo during that [13:52] ev, pitti: yeah, please don't do that [13:52] it leads to user having things "freezing" for a minute rather than going down and respawning [13:52] hey, but its fun on arm :P [13:52] hmm [13:53] I'm struggling to think of a way in which we do that only if the crash signature has been seen before [13:54] as the database/launchpad/whatever might not be contactable at this time [13:54] we need the core dump to determine the crash signatuer [13:54] ah and then there's that :) [13:55] could we at least factor out the zipping? [13:55] yes, that should work [13:55] although that might not actually help [13:55] I was tempted to look into Snappy anyway, as it might be a bit better than gzip for sending this out [13:55] as core dumps compress well [13:55] so instead of writing 0.5 MB compressed you'd then write 50 MB [13:56] so trading CPU against much larger IO [13:56] of course we could stick to gzip; what I just said is not really relevant to the discussion [13:56] right [13:56] hm [13:56] what could help is to write data/apport in C or Vala, or find a quicker way to do the gzipping [13:56] ev, pitti: if you let in on one stable you want at least display a dialog when the collecting start explaining which cpu usage raise and stuff hang [13:56] oh god please not vala :) [13:57] ev, pitti: we already get quite some users in unstable series confused by that nowadays [13:57] like their bug description is "was doing nothing and then nautilus froze for 5 minutes and closed" [13:57] the froze for 5 minutes is apport [13:58] ev: or we find a clever way of piping it through /bin/gzip instead of using python's gzip module [13:58] I haven't checked whether that helps significantly [13:58] ev: actually, writing it into a tmpfs uncompressed ought to work [13:58] /var/run/ [13:59] then the process can die quickly at least [13:59] yeah [14:01] as for compression, I believe there are several algorithms that are less resource intensive than gzip, snappy included [14:01] whether that bit is something we can fit into 12.04, *shrugs* [14:02] ev: I was thinking, apport could feed it without compression to /var/run/ [14:02] ev: then close stdin, so that the process can die [14:02] and then do whatever it wants with the tmpfile [14:02] right, and I guess it doesn't matter what it does after that as the process is gone [14:02] instead of piping it thorugh the gzip module [14:02] indeed [14:02] well, it still uses CPU/IO, but at least it doesn't hang the process [14:03] right [14:03] and if we only want a crash signature, we don't even need to compress it, etc. [14:03] that would be much better indeed [14:03] we can just run gdb right away [14:03] it's quite a different way of doing things than we do right now, though [14:03] and in development/Launchpad bug filing mode it's not really optimal [14:03] as you'd do the gdb call all the time, even if you don't want to file a bug [14:04] * pitti is just brainstorming here [14:04] sure, though we should optimize for the common case, which would be the release being out the door and people using this thing for years :) [14:05] I'm still unsure those people want to be bothered at all about software issues [14:06] ev: bug 938700 FYI [14:06] Launchpad bug 938700 in apport (Ubuntu Precise) "1.92 regression: Does not open already existing bugs any more" [High,Triaged] https://launchpad.net/bugs/938700 [14:07] seb128: oh, AFAIUI the apport UI shouldn't pop up any more [14:07] I mean, not the full one, anyway [14:07] pitti, well still having any ui popping is annoying [14:07] I understand it'd only send the sig to whoopsie-daisy [14:07] it's still bothering, of course [14:07] (and I can't say I'm a fan of that) [14:07] seb128: the only way we're ever going to get a real picture of the most pressing issues is if we ask everyone [14:08] I still think we should disable it after 6 months or so after it's out [14:08] hey, I'd love it to all happen in the background [14:08] ev, well, users are not beta testers ;-) [14:08] especially seeing how few issues we fix on stable compared to the number of report [14:09] we keep getting annoyed user asking why we bother them and make them send feedback if we don't fix bugs in stable anyway [14:09] seb128: I'm not pretending users are beta testers. But if we don't find out what's going wrong on people's machines post-release, regardless of whether they're a developer, technical user, or anyone else, then we'll only have a very narrow and potentially inaccurate picture of the quality of the software we ship [14:10] which is a somewhat misleading view, we fix bugs, but yeah we know about issues before shipping stable [14:10] ev, we know our software is buggy and we know before shipping it [14:10] we're not filing bugs with this, and that's part of the point. The interface isn't creating an expectation that something's going to be fixed and there's something you can follow along with [14:10] seb128: :D [14:10] it's definitely a fire and forget thing here [14:10] ev, well I still think it annoys users for no good reason [14:11] we already know about the major issues and we already don't work on those because we don't have the manpower, priorities, etc [14:11] we don't know about the major issues [14:11] we do [14:11] what if there's a problem in a piece of software that's more commonly used by the vast majority of our users than by developers and beta testers? [14:11] or said differently, your system applied to an unstable cycle gives enough metric to know [14:12] ah [14:12] that still falls under my previous point [14:12] but otherwise what pitti said [14:12] we should probably disable it after 3 months of a stable cycle then [14:12] it will skew the results to the behavior of early adopters [14:12] by then we get enough datas [14:12] no point to annoy user for 5 years when we don't fix most bugs on stable anyway [14:13] it could be different if we were actively maintaining stable versions [14:14] seb128: and if something completely falls apart four years in and affects 80% of our users on a stable release? Shouldn't we at least have the data so we can make an informed decision on whether we should be investing the resources in fixing it? [14:14] every other serious operating system out there does this [14:15] on OSX and Windows, crash reporting is a continuous thing, throughout the entire lifecycle of the product [14:17] ev, yeah, sorry for sidetracking the discussion on that [14:18] ev, it's something I always hated in microsoft oses and liked in Ubuntu, no annoying dialog about issues in stable versions [14:18] I think it's an assumption that you learn enough about the crashes pre-release to consider what needs post-release changes. [14:18] ev, I got people who stop what they are doing and call for help when they get one of those under windows [14:19] seb128: you can turn it off very easily via the control center [14:20] ev, the people who stop what they were doing and come to call for help when they get one of those dialogs don't go to system settings though [14:20] ev, but yeah, it's a tradeoff, I'm not convinced the change is a win [14:21] but that's not a situation where there is a clear win [14:21] there are side cost either way [14:23] seb128: we'll surely see whether we know more or not once the release is out the door and this project has had a bit of time to mature [14:23] right [14:24] ev, it's just that I've the feeling that we know about hundred of importants bugs but don't have any resources to work on them anyway [14:24] so adding to that list is not going to help a lot [14:24] but let's see maybe it shows a different picture and will be useful ;-) [14:24] indeed, just think of it as a better bug heat algorithm, if that helps :) [14:25] I will be interested to compare what comes out of it and how that matches or not our current picture [14:25] ev, if the pictures are similar though I might try pushing to have it turned off in stable versions for the benefit of users :p [14:25] seb128: you're welcome to make any argument you want. I'll be sure to have plenty of counter arguments ready :-P [14:25] ev, ;-) [14:26] and failing that, pistols at dawn! [14:26] ev: my current collection: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=whoopsie-merge [14:26] ev, anyway I didn't mean that discussion to be negative, I'm really looking forward have a db and all your work landing [14:26] ev: I subscribed mpt to the two design-ish ones, as you said in teh MP [14:26] ev, I'm mostly discussing details ;-) [14:27] seb128: absolutely, and I appreciate that [14:27] pitti: cheers! [14:27] pitti: I'll add to that tag as I see bugs, and fix them as quickly as I can [14:28] seb128, re bug 933710, gnome upstream has commented on the upstream bug report that the workaround I supplied makes sense, as the required support isn't likely to be added to X in the short term. Can we go ahead and get the workaround (or something similar) applied? [14:28] Launchpad bug 933710 in xserver-xorg-video-intel (Ubuntu Precise) "Laptops with eDP panels do not suspend when lid closed" [Critical,Confirmed] https://launchpad.net/bugs/933710 [14:31] ev: I guess we'll leave the two design ones for mpt to return? [14:31] ev: (I don't think either is particularly importnat) [14:32] ev: the "known bug" one is fairly important, though; do you want to look into this, or want me to? [14:32] ev: nice gtk test suite, btw! [14:34] pitti: I don't mind, I can look at it now if you're busy [14:35] pitti: cheers on the test suite. If you're unfamiliar with Mock and need help understanding it, do let me know [14:35] ev: I'm chasing apport bugs, but different ones [14:35] it's a wonderful tool in small doses [14:35] okay, I'll have a look [14:36] ev: I have recently used a different mocking library (in aptdaemon), but not this one [14:36] ev: so @patch.object(GTKUserInterface, 'can_examine_locally') [14:36] ev: that means, you can pre-set a return value, and it records if it was called, and delivers that? [14:37] ev: I do that in the main test suite, but with something like myobject.mymethod = lambda self, args: return 'foo' [14:37] pitti: it means, turn the member can_examine_locally into a Mock object. At the end of this method, return the member to its original value [14:37] the [14:37] any call to the mock object will succeed, and any member or method on that mock object will magically exist [14:38] return_value sets what actually gets returned on method calls [14:38] and yes, it also tracks calls [14:39] so you can assert that a function was called with particular arguments [14:39] For what it's worth, Michael Foord, who works for Canonical, is the upstream author [14:39] ev: I guess we'll leave the two design ones for mpt to return? self.app.get_desktop_entry.return_value.getIcon.return_value = 'nonexistent' [14:39] eek, how did that happen [14:39] :D [14:40] ev: so for that call, it would mean that get_desktop_entry() would return an object with a getIcon() method which returns 'nonexistant'? [14:40] and yeah, he'll be back on the 27th [14:40] correct [14:40] I just pressed middle mouse, and weechat decided to also reply one of my earlier IRC messages, d'oh [14:42] :) [14:56] mdke: ping: https://launchpadlibrarian.net/92012331/buildlog_ubuntu-precise-i386.ubuntu-docs_12.04.2_FAILEDTOBUILD.txt.gz === Quintasan_ is now known as Quintasan [15:41] i'm having trouble tracing a ppa's build failure down; it's about the openscad - 2011.12-2precise2 build on the https://launchpad.net/~chrysn/+archive/openscad/+packages archive [15:42] i reproduced the build setup by installing an lxc virtual machine, made sure the dependencies are met with exactly the versions the build server used, and removed abundant packages (a -dev recommended another -dev) until the diff between my and the server's build log was reduced to build directory path differences [15:44] nevertheless, i get an undefined reference error where i know from the line number that the file used on the ubuntu build server contains the #include line, and i've looked at the package the build server downloaded to satisfy the respective dependency, and it has a GL/glu.h which does define what the error is about [15:45] any ideas what i could have been missing? [15:45] ev: hang on, that dupe problem is not your fault; unless you started on it already, I'll take it [15:45] pitti: I haven't gotten to it yet, so by all means :) [15:46] chrysn: It should fail the same locally too, that's not a PPA issue. [15:46] seems it's due to some recent Launchpad change [15:46] ahh [15:46] chrysn: And it's probably due to the order of arguments on your linking line. [15:47] is there a way to fetch the intermediate files from the build server to look for differences there? [15:47] chrysn: Nope, it's all thrown away after the build and the VM reset. [15:48] but that would show up anyway in the build log, wouldn't it? and that is the g++ line that fails is the same both on my system and the build server [16:13] doko, i'm just filling out an issue what should I put for SRU? [16:15] Cas-, a branch, or a debdiff [16:16] its in distribute release [16:16] this seems like a lot of hoops for such a simple fix [16:19] doko, https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/938786 [16:19] Launchpad bug 938786 in distribute (Ubuntu) "Import issue with namespace packages in pkg_resources" [High,New] [16:21] Cas-, and subscribe ubuntu-sru [16:25] k [16:27] ev: https://launchpadlibrarian.net/93753132/Traceback.txt (from bug 938625) looks very weird -- could this be a threading issue? [16:27] Launchpad bug 938625 in apport (Ubuntu) "apport-kde crashed with AttributeError in addbutton(): 'NoneType' object has no attribute 'addButton'" [Undecided,New] https://launchpad.net/bugs/938625 [16:38] Cas-, I can't see a branch or a debdiff in the report [16:44] pitti: my initial suspicion is that something is calling addbutton for the bug report dialog, which doesn't have a button box anymore. Digging. [16:51] pitti: presumably something like this would work: http://paste.ubuntu.com/852898/ but I'm still trying to see what is calling addbutton for that dialog === Guest51693 is now known as Zic [17:17] psusi: is zeroing the superblock the right way to get your array going again in bug 925280? [17:17] Launchpad bug 925280 in mdadm (Ubuntu) "Software RAID fails to rebuild after testing degraded cold boot" [Medium,Confirmed] https://launchpad.net/bugs/925280 [18:11] bdmurray: no, you don't want to zero the superblock, doing that and then adding the drive is like adding a completely new drive [18:12] psusi: then what would be the right thing? [18:12] bdmurray: you either need to enable the write-intent bitmap when you set up the array, and then you can --re-add the removed drive, or you need to --add --run ( both switches together ) to add the drive back, or zero the superblock, then -add it === nessita is now known as nessita-away [18:14] best is to just enable the write-intent bitmap, then you can --re-add the drive and it will sync back up fast [18:15] is there a way to enable that for an existing array? [18:17] sure, just pass the -b internal switch same as when you create the array === JanC_ is now known as JanC [18:40] infinity: any idea about bug 938867? [18:40] Launchpad bug 938867 in live-build (Ubuntu) "live-build fails to build on precise" [Undecided,New] https://launchpad.net/bugs/938867 [18:41] stgraber: Oh, ugh. The tidying in hacks doesn't run late enough. [18:41] stgraber: (Which now makes me wonder why any of said tidying is in that block of code...) [18:42] stgraber: I'll just revert that for now, and then look for a better way to do it a bit later. === Ursinha is now known as Ursinha-lunch [18:47] stgraber: Uploaded a revert. I'll try to sort out a better place to do cleaning a bit later (and probably move all the other cleaning from _hacks at the same time) === charles_ is now known as charles [18:55] doko, why can't the upstream versin of distribute be used? === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === nessita-away is now known as nessita [19:49] mdke: ping [19:49] barry: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back) [19:49] mdke: https://launchpadlibrarian.net/92012331/buildlog_ubuntu-precise-i386.ubuntu-docs_12.04.2_FAILEDTOBUILD.txt.gz === salem_ is now known as _salem [20:07] Cas-, we only fixing issues in stable releases, not updating to new upstream versions [20:09] i understand that but surely for such a crucial part of python the bugs should not be just left and fixed ad-hoc [20:09] http://pypi.python.org/pypi/distribute#changes === dendrobates is now known as dendro-afk === Ursinha-lunch is now known as Ursinha [21:11] infinity: please refresh my memory, if it's not essential:yes + priority: required, it needs to be depended on in some form? === dendro-afk is now known as dendrobates [21:38] jdstrand, hey [21:40] jdstrand, evince has some apparmor related bug and I would like your input, that's the best way? subscribe you or ubuntu-security? irc pings? [21:41] micahg: i thought you had to explicitly depend on anything that wasn't essential:yes [21:42] micahg: http://www.debian.org/doc/debian-policy/ch-binary.html#s-dependencies is the relevant policy snippet [21:47] fun, AFAICT, there's not an awk providing binary that's essential :) [21:49] wait, was the conclusion from yesterday that you get to keep the pieces of a system without ubuntu-minimal breaks? [21:50] because if so, it's purely an exercise in pedantry [21:51] I seem to have missed that discussion [21:51] but I do have a bug report :) [21:51] micahg: http://irclogs.ubuntu.com/2012/02/21/%23ubuntu-devel.html#t22:53 [21:55] umm, well, this one's a little different, a system can in theory live just fine without awk [21:55] right. the relevant portion of the discussion was whether or not you're allowed to run ubuntu without ubuntu-minimal installed [21:55]