[00:00] curently i am using vgaswitcheroo to shutdown my ati hd5470 card to use the intel hd3000 but for a unknown reason, when i setup the stuff in rc.local file, it disables my sound card. it simply doesn't detect it. I think its because of the "sleep 6" comand that i had there. [00:00] if i remove it, it detects my sound card after reboot. [00:00] anny ideas about to fix this? [00:13] barry: there is no broken more than shibroken =)))) Have you had a chance to look at the proposed patches to fix it? or should I do a shout-out to digia to review / merge the one that is on Qt side? === wedgwood is now known as wedgwood_away [00:30] xnox: i haven't had time to look at it. if you can line up a reviewer, that would be great [02:10] oh dear... the more I read about udisks2, the worse it sounds [02:44] sarnold: its sort of weird when someone reports a bug, assigns it to themselves, and mark it as "in progress" that you'd go in and mark it as "incomplete"… (re LP #1145560) [02:45] Launchpad bug 1145560 in openafs (Ubuntu) "OpenAFS Security Advisories 2013-001 and 2013-002" [High,In progress] https://launchpad.net/bugs/1145560 [02:45] lfaraone: my apologies :) [02:47] lfaraone: I'll be more careful in the future to look for people assigning themselves the bugs. (you're the first :) [02:47] sarnold: no worries :) in this case, I was told "here's a security fix. file a bug and post a debdiff", and had done ½ of that :P [02:48] haha [02:48] And then I had class :P [02:48] you left out the *smack* in the middle while I muddle up your bug.. [03:34] hi, looking for some advice on how to get started in ubuntu dev [03:36] looking to find places to contribute, but not sure where to start [04:21] hello. I need to speak with an ubuntu devoloper if possible [04:24] i guess i will come back tomorrow [04:26] !ask | dbrown [04:26] dbrown: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience [04:27] is ubuntu moving toqt and away from compiz? [04:28] excuse me is ubuntu moving to qt? and away from compiz? [04:32] dbrown: Yes. [04:32] I don't know about away from compiz but I believe according to the announcements Unity is moving to Qt. [04:33] okay then my problem is that I am visually impared user who uses the enhanced zoom desktop feature of compiz [04:34] dbrown: No promises with regards to magnification and unity in Qt, but there are those of us who are aware of that being a requirement for some users, and will try to get this addressed in some way. [04:34] I myself am vision impared, and use a screen reader, and occasionally use magnification, so I will find it useful too. [04:34] So I will be following up about magnification to see what could be done. [04:35] ttyl got to go [04:48] Are any of the archive builders broken? [04:48] https://launchpad.net/ubuntu/+source/openafs/1.6.2-1+ubuntu1/+build/4345033/+files/buildlog_ubuntu-raring-i386.openafs_1.6.2-1%2Bubuntu1_FAILEDTOBUILD.txt.gz died strangely [04:48] lfaraone: No. [04:48] "/lib/i386-linux-gnu/libpthread.so.0: could not read symbols: Invalid operation" [04:49] lfaraone: Read up. [04:49] lfaraone: You're missing a link to -lpthread. [04:49] /usr/bin/ld.bfd.real: note: 'pthread_create@@GLIBC_2.1' is defined in DSO /lib/i386-linux-gnu/libpthread.so.0 so try adding it to the linker command line [04:51] I'll admit that "could not read symbols: Invalid operation" is about as intuitive as operating a television with a fish. [04:51] But the previous two lines are pretty clear. [04:53] hmm. this wasn't a problem in 1.6.2~pre3. [04:53] Apologies. === BruceMa is now known as BruceMa_afk [05:13] ScottK: did we tighten up the linker in raring? (the package builds in quantal) [05:18] cjohnston, mhall119: I need to add another 'required' participant to http://summit.ubuntu.com/uds-1303/meeting/21598/foundations-1303-hwe-stack/, but he's not showing up in the 'review attendees' list despite having been added to the blueprint over an hour ago [05:43] lfaraone: It could be that one of the other libraries it links to used to link pthread and no longer does. [05:43] lfaraone: Correctly or incorrectly. [06:39] Good morning [06:40] https://launchpad.net/ubuntu/+source/openafs/1.6.2-1+ubuntu2/+build/4345141 seems to be building… again? [06:40] "currently building", yet "Started 2 minutes ago\n Finished 2 minutes ago (took 31 minutes, 3.5 seconds)" [06:41] lfaraone: It's a display bug that happens when a build gets thrown back in the queue... [06:41] infinity: I see. Why might that have happened? [06:42] Oh, it was given back? [06:42] Dunno, don't have the old log. [06:42] infinity: would you mind removing the pygobject propagation block? autopkgtests look good [06:43] StevenK: Looks like a give-back or previous abort or something. Hard to say the cause from my vantage point. You have access to buildd-manager logs, which might be more enlightening. [06:43] well, at least not worse than they already looked before [06:43] StevenK: But that display bug has always annoyed me (cf: not resetting the build record properly) [06:43] Ugh. The last build took 30 mintues, so *sadness* [06:44] pitti: Done. [06:44] infinity: danke [06:44] lfaraone: What's the bug hurry? It'll take longer on ARM anyway. [06:45] lfaraone: And PPC, where you're stuck behind some security builds... [06:46] infinity: this is a security build. [06:46] I'll score it up, then. [06:47] lfaraone: Err, why the weird version number, by the way? [06:47] 1.6.2-1+ubuntu2 <-- That should be 1.6.2-1ubuntu2 [06:47] infinity: no, it shouldn't, because openafs is horrible: https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/356861/comments/1 [06:47] Launchpad bug 356861 in openafs (Ubuntu Jaunty) "OpenAFS Security Advisories 2009-001 and 2009-002" [Undecided,Fix released] [06:48] infinity: It's not a display bug, it's an obscure buildd-manager corruption bug that's never been identified [06:48] Retries reset that properly [06:48] lfaraone: Oh, that's entertaining. [06:49] wgrant: I didn't mean the bug is in the display code, but that it's displaying the silliness of the data. [06:50] In this case it looks like batsu died [06:50] Or was killed [06:50] wgrant: It seems to occur in cases where buildd-manager takes it upon itself to pop a build back in the queue, and reasonably consistently, I'm surprised it's never been identified. Unfixed, sure, but not unidentified. [06:51] infinity: It appears reasonably consistent because you only notice it when it happens. [06:52] wgrant: Fair enough. :) === tvoss|eod is now known as tvoss === henrix_ is now known as henrix [09:11] xnox, cjwatson: online? [09:30] doko: only slightly; starting properly in a couple of hours [09:31] cjwatson, I was pointed to #1083498. would it be ok to get this into precise and quantal? [09:32] same for 1018522 === smb` is now known as smb [09:39] doko: 1018522 should certainly be done in raring (first). as for precise/quantal, I think it's probably doable in principle under the banner of improved hw enablement or something, but you'd need to think very hard about the regression test plan === ckpringle_ is now known as ckpringle [09:52] I read about https://wiki.ubuntu.com/MirSpec today. [09:53] and this might interest anyone working with Mir: https://devtalk.nvidia.com/default/topic/529486/general-graphics-programming/direct-rendering-access-on-linux/ [09:53] Cheery, hey, you can find them on #ubuntu-mir [09:53] all right [10:22] lfaraone: Yes. [10:23] It's more likely you've no longer saved by indirect linking in some other library, but there are some changes too. [10:27] doko: cjwatson: anything that improves performance and saves power are good candidates for SRU, imho. As both hyperscale and client factors like that a lot =) === MacSlow is now known as MacSlow|lunch === ckpringle_ is now known as ckpringle === _salem is now known as salem_ [12:52] slangasek: ping === MacSlow|lunch is now known as MacSlow === dayangkun_ is now known as dayangkun [13:23] cjwatson: how much do we care about cross buildable packages for packages not essential to arch bootstrap? [13:25] rbasak: Varies. https://wiki.ubuntu.com/CrossBuilding has some arguments [13:25] I wasn't aware of that page - thanks! [13:25] rbasak: More relevant for things you might want to build for mobile devices [13:25] Ah - of course [13:36] seb128: ping [13:36] cjohnston, hey [13:37] seb128: short answer: blame jasoncwarner_ [13:37] re: last night [13:37] oh, what did he do? [13:37] he marked them approved in LP, which means LP will not give Summit the info [13:38] oh, ok [13:38] seb128: for the meetings at the 1500 slot today in client, there are no people required, so it will be an empty hangout [13:38] fwiw === jono is now known as Guest21624 [13:38] hum [13:39] cjohnston, isn't the lead inviting people? [13:39] that didn't get very well communicated [13:39] you mark them required and then Summit gives them a link [13:39] is there some automation? [13:39] oh [13:39] I though the link was going to be public [13:39] lool, ^ you were right [13:40] I hope we don't run into issues with non-canonical.com Google accounts trying to join canonical.com hangouts [13:41] I had trouble with my @gmail being the default logged in account with google trying to join canonical.com hangouts some weeks ago [13:41] same here [13:41] something was turned on that was enforcing that, that's been shut off [13:41] I don't remember the details but they flipped it back [13:41] I've been using my non canonical one for team meetins since then and it's been fine [13:41] jcastro: ok, let's see how it goes then :) [13:42] I didn't say that that would mean that it would all work this morning. For the record, heh. [13:42] jcastro: no no no, you *did* personnaly certified it, I have prooves :) [13:45] jcastro: Ok; thanks for confirming this [13:45] I had guessed they had flipped a domain-wide bit at some point, but it's great to hear they flipped it back off [13:45] didrocks: time to put your swimming-suit on [13:46] lool: the coffee machine is already on :) === rickspencer3_ is now known as rickspencer3 [13:48] * rickspencer3 slurps coffee [13:49] didrocks, lool, jcastro you guys ready? [13:50] rickspencer3: more than ever! :-) [13:50] * didrocks hopes that his internet connexion will follow though [13:51] rickspencer3: assuming Didier brings in the coffee in the rooms [13:51] Why are you guys on about coffee? You've been up for hours. :p [13:51] cjohnston: pong [13:51] lool: now that we have daily release, you think I'm just slackering, isn't it? :p [13:52] we'll be doing an intro starting in 9 minutes [13:52] slangasek: you were having an issue last night. is that resolved? [13:52] rickspencer3: is that with us? [13:52] rickspencer3: I am ready to rock! [13:52] lool, jono, me, and track leads [13:52] ok [13:52] an intro with Q+A if there is time [13:52] cjohnston: no, I still can't add people as required who need to be there, but I have a theory now that I'm following up quickly [13:53] it feels weird getting ready for something this important, but being in my normal office [13:53] ok [13:53] * tvoss is ready for UDS :) [13:53] rickspencer3: I guess track leads will present each track; let me know if there's some specific topic you want me to cover [13:54] lool: you may soon start to be the coffee man :p [13:54] (I am happy to present track contents too except for cloud and community and I'd likely not be able to present an exhaustive picture) [13:58] where's the continental breakfast? [13:59] on your continent [13:59] barry: it's the first day, you're supposed to still be able to wake up on time [13:59] barry: In 6 hours. My body is still sleeping at this time. :p [13:59] tumbleweed: i was told there'd be gluten free muffins [14:00] i ate them all ! [14:00] ooooggraaaaaa! [14:00] :) [14:00] lol [14:00] will jono tell us to eat our veggies? [14:01] jono_: yes [14:01] pgraner, rickspencer3: would moving community-1303-rolling-release before the plenaries be possible? (conversation moved from #ubuntu-motu) [14:03] tumbleweed, I'll check after the kickoff [14:12] tumbleweed, moved to 16:00 in community 1 [14:12] seb128: ta [14:12] cjohnston: right, my problem is required people not being registered for UDS [14:12] cjohnston: so, prodding them to fix on their end [14:13] slangasek, glad you were able to figure it out! :-) let me know if you need help === tkamppeter_ is now known as tkamppeter [14:21] heh, psusi found a fanboy on the devkit-devel list :P [14:22] ogra_: I can't tell what the hell he was saying... was it sarcasm because he thought I was a "hater"? [14:22] psusi, see "2 users simultaneous access to udisks2 mounted drive" ... he started that on feb 12th [14:23] i think he is actually fanboying in a weird style [14:23] he was talked down with his (rather hackish) proposal [14:23] so he likes my idea and was simultaniously venting frustration? boy... that does *not* translate well into written language [14:24] hahaha, yeah [14:24] i just got it because i read the former thread [14:24] what do you think of the idea? [14:24] ++ [14:24] but upstream will not like it i fear [14:24] its their way or none [14:28] I'm still trying to figure out why in raring I now have two different udisks installed and running, and neither of them seem to be able to read my SMART status === ckpringle_ is now known as ckpringle [14:28] smartctl works just fine still of course [14:29] you should only have udisks2 [14:29] I seem to have both [14:29] i think pitti tried to get rid of the older one [14:29] but probably there are still universe packages unported [14:29] usb-creator still pulls in udisks1 [14:29] ah [14:29] xnox is porting it to udisks2 [14:29] pitti: I did, and it segfaults =) i need to fix it up. [14:30] psusi: something has activated udisks1, since by default udisks1 is not running it's only started when usb-creator is launched. [14:31] why the big API breakage? [14:36] * xnox is clearly sees network manager dropping wifi connection periodically. === wedgwood_away is now known as wedgwood [14:54] arges, pgraner, Ursinha: hangout open for http://summit.ubuntu.com/uds-1303/meeting/21603/community-1303-plusone-maintenance/ === mhall119 is now known as mhall119|afk [14:54] seb128, did you open the hangout yet? [14:55] how should we receive the link for required attendees? Seems the hangout is opened but no link on the page [14:55] slangasek: thanks, do you need me on the hangout. I think i'm probably more of an observer. : ) [14:55] arges: don't need you, but you're welcome [14:56] slangasek: awesome thanks [14:56] arges: and we can always rotate you in later if you decide to [14:56] cjwatson: do you want to be in the +1 maintenance hangout this morning? [14:57] jasoncwarner_, do you run the refactor and cleanup session? [14:58] slangasek: Yes please [14:58] tvoss: ? [14:58] oh tvoss no, seb [14:59] seb128, ping [14:59] seb128, got a hangout invite for me? [14:59] tvoss, you should have it in the summit details [14:59] tvoss, http://summit.ubuntu.com/uds-1303/meeting/21608/client-1303-refactor-platform-api/ [14:59] no? [14:59] seb128: people say they aren't getting invited...I'm pasting URL directly [15:00] jasoncwarner_, ok [15:01] didrocks: can you take notes for this? [15:01] jasoncwarner_: already started :) [15:33] mpt: how about adding a topic to community-1303-rolling-release about whether this should be done for raring? [15:34] Riddell, ScottK suggested that, I just haven't gotten down that far in the thread yet :-) [15:37] (ah, just got to Stefano saying the same thing) === fire is now known as nerd [15:42] mhall119|afk: so, what's the expectation with the recordings - I guess I need to do something in youtube to get them published? [15:43] dholbach: can we register a GSoC discussion in the Community track? (preferably scheduled after 6PM EST / before 10AM EST) [15:45] Hi. [15:46] I coudn't find the exact command line (genisoimage-call) which was used to create the ISO image for Ubuntu 12.10 or 12.04.2. Maybe someone know where it's documented and give me a pointer? [15:47] something keeps changing the level of my input source, does anyone know if that google hangout itself? [15:48] seb128: yeah, it's a hangout feature [15:48] seb128: you can disable it though [15:48] didrocks, where? [15:48] seb128: http://blog.didrocks.fr/post/Getting-sound-working-during-a-hangout-in-raring [15:48] ~/.config/google-googletalkplugin/options [15:48] swith audio-flags to 1 [15:48] kill the plugin [15:48] didrocks, ah, file, I was looking for it in the ui :p [15:48] restart it [15:49] this will remove audio level autoadjustement [15:50] didrocks, thanks [15:50] yw seb128 :) [15:54] yeah I applied that just before this UDS in the hope that it will stop me randomly muting [15:56] lfaraone, can you file a blueprint for it? community-1303-summer-of-code or some such - propose it for 'ubuntu' on https://blueprints.launchpad.net/sprints/uds-1303 [15:56] lfaraone, then I can accept it and see if there's still a slot where we can put it [16:10] dholbach: https://blueprints.launchpad.net/ubuntu/+spec/community-1303-summer-of-code [16:10] thanks lfaraone [16:16] lfaraone, accepted the blueprint, will take a while to show up in summit - then I'll check where we have an open slot [16:16] dholbach: stellar. [16:17] dholbach: this year's GSoC deadline is Mar 29, it'd be nice to meet it :) [16:17] lfaraone, totally - did you guys get my email? [16:18] dholbach: I believe so [16:18] ok cool [16:18] dholbach: also, uh, I'm still waiting on reimbursements for UDS-P and I never received a response… who should I contact? [16:19] dholbach: actually I think the last mail I have from you about GSoC was from december. [16:19] let'S move to query [16:27] Good evening all [16:28] I'm new on development and I want to upgrade a .deb file from source.. Teamspeak .deb on repository is outdated and i want to update it but I don't know how to do.. Someone can help me please? [16:32] lfaraone, today 18:15 [16:33] dholbach: oof, is there space tomorrow at the same time? [16:34] lfaraone, that was the only free slot in the community track [16:34] lfaraone, you might have to ping some other track leads to see if they still have an empty slot [16:34] http://summit.ubuntu.com/uds-1303/2013-03-05/ and http://summit.ubuntu.com/uds-1303/2013-03-06/ [16:35] dholbach: thursday isn't scheduled yet it looks like? [16:35] there's no thursday [16:35] well there is [16:35] but not part of UDS [16:37] lfaraone, ^ also I subscribed all you guys to the blueprint [16:37] dholbach: could we swap with something at 14:00 UTC tomorrow? [16:39] lfaraone, can you join #ubuntu-community-team? [16:56] cjwatson: I know you are rather firmly against syncing from testing, but WDYT about some middle ground like syncing from unstable after they spent $urgency days in unstable, and not autosync if there are new RC bugs? [16:56] cjwatson: (I haven't thought about this very deeply, it just came to my mind) === wedgwood is now known as wedgwood_away === wedgwood_away is now known as wedgwood [17:00] pitti: the big problem, I think, is the very large corner case of transitions [17:00] slangasek: but those are already caught by britney [17:00] pitti: if the maintainer has uploaded 10 packages for a transition, and the package at the base of that transition has an RC bug, what happens in raring-proposed? [17:00] slangasek: I was thinking about catching the worst functional bugs [17:00] in practice what I think would happen is that we would make -proposed a tangled mess [17:00] slangasek: wouldn't it be better to hold that off then? I'd say it would [17:00] slangasek, what will happen in this case if we sync from unstable anyway? [17:01] we will get the RC and the not finished transition [17:02] pitti: It's technically possible, but TBH I think adding an artificial delay just means we get to wait longer for regressions to be fixed; I'm not sure I see it protecting us against must [17:02] pitti: I do think we should do something with RC bugs, though I [17:02] 'm not sure exactly what [17:02] (I posted something to ubuntu-devel about that recently) [17:02] pitti: the problem is that the RC bug list only gives you information about holding off *one* of the packages, and it's possibly the worst one to hold off [17:02] cjwatson: hence waiting for some days, so that people have some time to actually file them [17:03] I think the delay is the most harmful part [17:03] because then you've imported the other 9 packages which now misbuild or ftbfs and you have to clean up 10 packages by hand [17:03] slangasek: yeah, it's obviously not ideal [17:03] So I really want to avoid it [17:03] I wouldn't like to wait the potentially infinite delay that testing migration would have [17:03] I appreciate that a delay guards against some functional bugs, but I think the flip side is worse [17:03] ok; seems this was already discussed then [17:04] We should definitely do something about *Ubuntu* RC bugs, if nothing else so that there's a better workflow than "bug release team member to install a block" [17:05] cjwatson: but people wouldn't even see the new version until it's already in the RR, i. e. too late: [17:06] You yourself have a couple of times asked for a block immediately after upload [17:06] That's time enough [17:06] And there's the brown-paper-bag case [17:07] Also I'd like to have some downward pressure on Critical priority bugs; we don't have much such pressure at the moment and the effect is that you really can't use the Critical list as a guideline of anything much [17:07] Which seems rather a shame [17:11] cjwatson: I usually ask before a new pygobject upload, until we have britney autopkgtest integration [17:12] cjwatson: but for autosyncs we don't have that "oh sh*t" window after dput [17:12] There's a window before it builds and publishes [17:12] Sure, not a very long one, but it's sometimes enough to notice a problem [17:13] And certainly for "oh damn I'm not sure I meant to upload that", it's enough [17:13] cjwatson: I think we are talking about two different things here [17:13] cjwatson: I'd like to put some additional delay/checks for autosyncs, not for ubuntu uploads [17:14] as otherwise we'd routinely import new unstable uploads which other people already identified as having an RC regression [17:14] One possibility would perhaps be to get confirmation from +1 maint (somehow) before autosyncing packages with RC bugs [17:15] I really really really don't like the idea of an automatic delay, but if some human is actually on the hook to be responsive, it might be OK to reduce the level of automation? [17:15] we could try that at least [17:16] auto-sync is already not your grandfather's auto-sync [17:16] Though most of the newer intelligence is related to syncing entirely new packages [17:17] I definitely think there's room to make it smarter, and I think it can be better than a simple delay [17:18] my main aim is at new Debian RC bugs; but if we want to use them, then we need some delay so that people can actually file them [17:18] Well [17:18] if we don't want to take RC bugs into account, we won't need that of cours [17:18] e [17:18] Depends. We could do a better job of tracking new Debian RC bugs for things we've already imported [17:18] Very very few of them will be kitten-killing regressions [17:19] I mean, right now we basically don't track new Debian RC bugs at all === wedgwood is now known as wedgwood_away [17:22] slangasek makes a good point about this idea exacerbating import ordering problems though. We already have this problem with merges, but at least merges by definition have a human who at least peripherally cares associated with them [17:22] Extending the problem to the entirely automated case is ... troublesome [17:23] it would certainly lead to a lot more things being held back in -proposed [17:23] I think this is a situation where I would rather do after-the-fact cleanup, on the basis that any negative consequences of that are likely to be on the whole less severe [17:23] But that does mean we have to actually track it rather than hope :-) [17:23] ok; it may make sense to actually do this, and do some post-mortems on concrete cases where this actually bit us [17:24] Yeah [17:24] right, either way it'd be more human effort (watching RC bugs pre- or post-import) === wedgwood_away is now known as wedgwood [17:40] * Laney idly wonders if it would be worth not autosyncing things which start transitions [17:42] Laney, +1 [17:43] Laney: ITYM things which are /involved/ in transitions... otherwise you get the problem again that you've synced the leaf packages that were uploaded for the transition, but not the base of it [17:43] otherwise you get a set of packages stuck in proposed until the transition is complete, which might take weeks and block important packages [17:43] mmm, that's harder to determine though [17:43] I don't see why we should particularly worry about transitions, given that they're exactly what we already have the best handling of [17:43] Seems like solving the wrong problem [17:43] Dunno === deryck is now known as deryck[lunch] [17:44] (And if we have -proposed backing up and it's a problem, poke +1 maint, this is in their remit to deal with) [17:46] Seems to be better when someone has skin in the game to push them through. Granted though that +1 can look after them, not that they wouldn't have stuff to do otherwise. [17:46] cjwatson, well, let's say that there is a libpng transition that start (or something not trivial) which will includes hundred of packages and block e.g unity from landing ... it means we might hold off any unity work for weeks the time we go through the transition [17:47] seb128: that's quite different than what I was talking about, though; the new libpng is very likely not having any functional regressions, i. e. RC bugs attached to it [17:48] seb128: (it still is a problem, of course, just a different one) [17:48] Functionality bugs is the area where we have worst coverage indeed [17:48] pitti, sorry i didn't read the full backlog or implied it was what you were talking about [17:48] pitti, but it's another issue syncing from unstable [17:49] you might catch the start of a transition that will takes weeks to go through [17:49] and that will lock proposed meanwhile [17:49] right [17:49] seb128: I understand the concern - what I'm saying is that if *any* transition takes weeks then that is a problem in itself, regardless of what it blocks [17:50] if we would do any large transition on the Ubuntu side, we'd probably stage it in a PPA or equivalent, not in -proposed [17:50] cjwatson, well, if you sync from testing the transition is already done and it doesn't take weeks [17:50] and my proposal hoping to avoid things taking weeks, because developers get to choose when they happen [17:50] And that I'd rather fix that by making the transitions happen, not by deferring the transition [17:50] seb128: And there are *soooo* many other problems [17:50] It's not worth it [17:50] Also, you actively create problems that way by inverting the build order vs. Debian [17:50] In many cases [17:51] Because of binNMU you'd mostly end up syncing things which had to be uploaded for API changes which are exactly the packages you don't want [17:51] hmm [17:52] And syncing from Debian testing doesn't magically make transitions happen for us - we still have to rebuild things that were binNMUed in Debian, and we'll still run into cases where something fails to build in Ubuntu but not in Debian [17:52] So it doesn't solve the problem anyway [17:52] that's something we have to deal with for a rolling release anyway [17:53] you can't have "crack of the day" for all packages and robust quality at the same time [17:53] I guess I mostly think that if we're doing a rolling release we can't simultaneously be scared of change [17:53] well, dealing with a few build failures is easier than to carry through a big transition that only started in Debian [17:54] pitti, do you know of an uptodate and comprehensive document that describes Ubuntu plumbing components, to be used as a starting point for introducing someone to the big picture? [17:56] am I off base in expecting to be able to chroot into another system fs and run an apt-get dist-upgrade? isn't that why we use invoke-rc.d? so you can do this and NOT have rogue daemons spawned from the foreign system? [17:56] janimo: I don't think we have one in one big document [17:57] psusi: you have policy-rc.d in place? [17:58] psusi: being in a chroot doesn't by itself determine any policy for whether services should start; you have to declare this with policy-rc.d, which some of the chroot-creating tools do for you [18:00] slangasek: it seems like it should since invoke-rc.d won't run things that arne't supposed to be run in this runlevel, and there *is* no runlevel in the chroot [18:01] and it seems to mostly work, but it looks like some jobs that have been ported to upstart *are* being started, and much to my surprise, initctl still works in the chroot === kentb is now known as kentb-afk [18:02] and more annoyingly, initctl outside the chroot shows no evidence that upstart is managing any of the jobs in the chroot, yet *something* keeps restarting them when I kill them [18:02] psusi: upstart has chroot support; packages with upstart jobs are not exempt from using the invoke-rc.d abstraction. Do you have a specific example? [18:02] right, upstart has notions of chroot "sessions" which are managed in a separate namespace [18:03] jodh: ^^ is there a way to use initctl outside the chroot to list jobs associated with a chroot? [18:03] oh that's bizarre, why does my raring chroot not have /sbin on the path? [18:03] ohh, so upstart *is* managing the jobs of the chroot session, and I'm just not using the right fu to see it? whew... that actually makes sense... was losing my mind there [18:03] psusi: right - and upstart jobs are, of course, much harder to kill than things started by init scripts without process supervision :-) [18:04] now... why is upstart reachable from within the chroot? isn't that a bad thing? unless you explicitly link the socket into the chroot? [18:04] no, it's by desin [18:04] "link the socket" - upstart uses magic namespace sockets that Just Work [18:05] if you want them to not work, you use a container rather than a chroot [18:05] I noticed... and very much don't like that ;) [18:06] hrm... I dont recall seeing anything that indicated the magic namespace wouldn't be shared in a container [18:06] well [18:06] I can assure you that this is the case, otherwise people wouldn't be able to run upstart in a container and they are able to :) [18:07] psusi: anyway, to the earlier question... were you seeing this problem with particular upstart jobs? I want to make sure nothing's bypassing invoke-rc.d inappropriately [18:07] but my recollection is that invoke-rc.d doesn't care about unknown runlevels in any case, so that's probably a bug on invoke-rc.d to request a behavior change [18:08] slangasek: nmbd, rsyslogd, crond, atd, acpid, whoopsie [18:09] psusi: I know for sure that nmbd doesn't have broken invoke-rc.d handling for its upstart job, so sounds like you're just getting bitten by invoke-rc.d default behavior and not having policy-rc.d [18:09] from what I can see, if `runlevel` fails ( which it does, since there is no utmp in the chroot ), then invoke-rc.d doesn't run anything [18:10] since it can't verify that it should run it in this runlevel [18:15] psusi: in practice, that doesn't seem to be what happens [18:24] so... why does upstart want to manage jobs in a chroot? ( and not seem to have a way to admin them outside the chroot )? === henrix is now known as henrix_ === henrix_ is now known as henrix [18:46] Anyone (possibly network-manager or libnl3 maintainer/developers) know how to debug netlink message sources from the kernel? [18:46] cyphermox: ^^ :) [18:47] I'm debugging a cpu hogging bug in network-manager and I've traced it to the network interfaces being up causing an endless supply of netlink events coming from the kernel, but I can't figure out how to find out where those messages are coming from because of the abstraction in the kernel [18:47] BenC: ahah, yes, I know how to do it, to some degree :) [18:47] BenC: what release though, is that in raring? [18:47] raring [18:48] 3.8 kernel [18:48] * cjwatson gets lost in gdb [18:48] BenC: you know you can run NM in NLDBG=3 NLCB=debug ? [18:49] Actually, hmm, I guess if I'm looking for a sample implementation of the target side of the gdb remote protocol, gdb itself is the wrong place to look (it has examples, but not for amd64) [18:49] you can see all the netlink messages that way, but it's a huge amount of info [18:49] cyphermox: Right, I've done that [18:49] ok [18:50] But it just shows this loop of nondescript messages, which appear to be triggering the link up/down callback [18:50] constantly in up state [18:50] Hm, maybe gdbserver [18:50] BenC: can you share the messages you're wondering about, just so we're both on the same page? [18:50] cyphermox: Give me a sec [18:51] cyphermox: https://bugs.launchpad.net/network-manager/+bug/1111926 [18:51] Launchpad bug 1111926 in NetworkManager "NetworkManager increases CPU utilization" [Critical,Confirmed] [18:51] last comments [18:52] aye [18:52] so yeah, seems like either the kernel is doing something funny, or we're trapping a netlink message in NM that we perhaps shouldn't be [18:53]