[08:07] <lifeless> persia: do we have a meeting tonight?
[08:29] <nigelb> lifeless: as per wiki, seems like you do
[09:28] <persia> lifeless, I believe so.
[10:08] <lifeless> hi
[10:08] <elky> hi
[10:09] <persia> Hi.  You live in a benighted realm that believes that sunrise should happen after sensible people are already awake.  Wait an hour.
[10:09] <persia> Or did something change that I missed?
[10:11] <lifeless> wiki page says 1000 utc
[10:11] <nigelb> @now
[10:11] <lifeless> is gnome lying to me about time in london ?
[10:11] <persia> Right, and it's 9:00 UTC
[10:12] <lifeless> blah
[10:12] <nigelb> heh
[10:12]  * lifeless stabs gnome
[10:12] <persia> Time in London doesn't matter.  time in Reykjavik is more interesting.
[10:12] <persia> London is part of one of the benighted realms above-mentioned.
[10:13] <nigelb> When does DST change, last sunday of this month?
[10:15] <lifeless> nigelb: I'm already on DST
[10:15] <lifeless> so, bleh, this meeting will be @ 11pm.
[10:15] <nigelb> heh
[10:16] <persia> nigelb, Randomly, in abitrary directions, depending on the whim of the governments for the area.  I think the worst was once when a government decided on a Friday that DST started that weekend.
[10:16] <persia> If you want gory and amusing details, read the tzdata changelog.
[10:17] <lifeless> you can blame NZ for this
[10:17] <nigelb> Eeek, no thanks
[10:18] <elky> I should probably find some food before this reprieve ends.
[10:18]  * persia remembers one morning having to reschedule a conference call because DST happened in different directions on the same day in the areas where all the participants sat.
[10:18] <persia> (and, annoyingly, ending up with a 5am call in Sydney as a result)
[10:19] <nigelb> I think this month is going to be generally confusing for meetings
[10:19] <nigelb> Someone should tack that on the /topic
[10:19] <nigelb> right, its already there :)
[10:23] <lifeless> mmm
[10:23] <lifeless> I may not make it
[10:45]  * elky munches and waits.
[10:53] <Mohan_chml> @now
[10:54] <persia> Mohan_chml, Soon.
[10:54] <Mohan_chml> persia: yeah :)
[11:00] <persia> Good evening Vantrax
[11:05] <persia> So, um, it's 10:05.  Who is present?  Do we have quorum?
[11:05] <lifeless> I'm here for a few minutes; really just a few.
[11:06] <persia> ogitux seems not here yet, so we may not have that much business before us.
[11:06] <Mohan_chml> yes. His wiki seems not updated with details
[11:06] <elky> shall we take the moments until he arrives to discuss board population?
[11:07] <persia> Sure.
[11:08] <Vantrax> yep
[11:08] <elky> #startmeeting
[11:08] <MootBot> Meeting started at 05:08. The chair is elky.
[11:08] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[11:08] <elky> Woo, I remembered!
[11:08] <elky> [TOPIC] Board members
[11:08] <MootBot> New Topic:  Board members
[11:08] <Vantrax> nice work:P
[11:09] <Vantrax> I have seen 4 apps total.
[11:09] <persia> And our target is still 9 total members, 3 east, 3 central, and 3 west, right?
[11:10] <Vantrax> do we hand that to CC or go back again and ask for more
[11:10] <Vantrax> I think its 8
[11:10] <Vantrax>
[11:10] <Vantrax> err we have 8
[11:10] <persia> Right.  We got one more last time we talked about this, but never the other one, and never moved to split meetings.
[11:11] <Vantrax> and 12 was the goal with 2 meetings and 4 for quorum still
[11:11] <elky> I'm rather eager to avoid holding this up unnecessarily.
[11:11] <Vantrax> we are still going to have a numbers issue atm
[11:11] <persia> 12!  That's larger than I think we need, especially with a quorum of 4.  I'm not precisely happy about assuming most folk won't show up.
[11:12] <Vantrax> we have 8 right now afaik
[11:12] <elky> Yeah, that worries me too.
[11:12] <Vantrax> we struggle to get 4
[11:12] <elky> We're still in the rut where it's always the same few who show up.
[11:12] <Vantrax> yep
[11:13] <persia> Vantrax, yes, but the question is: do we need the folk that don't show?
[11:13] <Vantrax> probably not
[11:13]  * persia would rather have a smaller board that was mostly present: people who only show once every few months are hard to trust
[11:13] <Vantrax>  we have the same four each time normally
[11:14] <persia> Right.
[11:14] <Vantrax> with amachu and takdir making it intermittantly
[11:14] <persia> So, let's look at distribution.
[11:14] <persia> lifeless is *way* east.  elky is east.  I'm central.  Vantrax: I forget if you're east or central?
[11:15] <Vantrax> I'm east, in brisbane
[11:15] <lifeless> I'm so far east, ATM, that I'm really west.
[11:15] <Vantrax> lol
[11:15] <lifeless> (UTC+13)
[11:16] <persia> lifeless, For our purposes, that's merely east, when far-west is still +5:30
[11:16] <persia> OK, so we need some central and west.
[11:16] <Vantrax> yep, we can safely assume people can make this time
[11:17] <persia> Right.  Let's take the position we don't need anyone else to the east.
[11:17] <elky> Central is historically where we've had retention issues.
[11:17] <persia> Let's ask the current members that don't show if they want to remain on the board.
[11:17] <elky> May I suggest that's the wrong question?
[11:18] <Vantrax> I'm happy with that asumption elky
[11:18] <persia> And let's send the list of new nominees and commonly-missing members to the CC as two separate groups, "central" and "west" and ask them to select two central and three west.
[11:18] <Vantrax> excellent idea
[11:18] <persia> elky, What's a better question, assuming that we're not guaranteeing them a continued spot regardless of their answer?
[11:18] <elky> persia, I'm more inclined to ask if they're able, rather than if they're willing.
[11:19] <Vantrax> I think we should ask what they want
[11:19] <persia> elky, That's a *much* better question.  Good call.
[11:19] <persia> Vantrax, As someone who is rarely able to do the set of things I want, I'll say that's dangerous.
[11:20] <lifeless> agreed
[11:20] <Vantrax> if they can't fulfil the obligation they resign
[11:20] <Vantrax> that is my opinion
[11:20] <elky> Vantrax, easily spoken in theory. Harder to actualy do.
[11:21] <elky> Noting that when asking if they're able that we'd be specifying *both* times.
[11:21] <Vantrax> yep, I'm pretending its a perfect world
[11:21] <persia> No, we're not asking that people can make both times.
[11:22] <persia> We're asking that central people can make both times and western people can make the later time.
[11:22] <elky> persia, we're asking them if they can make at least one of the times.
[11:22] <persia> OK.
[11:23] <persia> I just want to make sure we're not asking our sometimes-present western member to attend the earlier time at which lifeless hasn't already fallen asleep.
[11:23] <Vantrax> are we looking at three or two meetings?
[11:23] <persia> Two ought be enough.
[11:23] <Vantrax> I agree, was just checking
[11:23] <persia> If we were doing three meetings, we'd not have enough coherency, and I'd argue we ought to split into an "Asia" board and an "Oceania" board.
[11:24] <Vantrax> I think 2 should be good coverage
[11:24] <lifeless> speaking of which. ciao.
[11:24] <Vantrax> night champ
[11:24] <elky> lifeless, thanks for coming, ciao
[11:26] <Vantrax> so we have the same continuing problem
[11:26] <elky> We do. We've had it since the inception of the RMB.
[11:26] <elky> We get closer to solving it each time.
[11:26] <Mohan_chml> o/
[11:26] <persia> That's the point of going from the original 7 to 9 members and splitting the meeting.
[11:26] <Mohan_chml> can I have a minute?
[11:26] <persia> We're up to 8 and have 4 regulars, which beats the 3 regulars we had at one point.
[11:26] <Vantrax> hello mohi
[11:27] <elky> persia, yep. Improvements have been achieved.
[11:27] <Vantrax> true, we make quorum usually, even if I'm on my phone like today
[11:27] <persia> So, Everyone feel good about the plan I've outlined above?
[11:27] <Mohan_chml> what about starting an IRC channel for Asia/Ociania memebers and analysing their presence at the time of meeting before making them as an RMB?
[11:28] <Mohan_chml> Hola Vantrax =]
[11:28] <persia> Mohan_chml, Doesn't help.  I'm often around at this time, but my join/part messages wouldn't even begin to help anyone know that.
[11:28] <Vantrax> hrm, not a bad idea
[11:28] <elky> Mohan_chml, or they could just attend the meetings like now.
[11:28] <Mohan_chml> elky: that is also acceptable
[11:28] <Vantrax> I would think people wanting to join would turn up to meetings as elky said
[11:29] <elky> Mohan_chml, then consider it already in action ;)
[11:29] <Mohan_chml> (:
[11:30] <Mohan_chml> My suggestion is, Lets make a single meeting for next two times, see the presence of the applicants and their skill of Judging, then making the meeting as two
[11:30] <Vantrax> mohi, we don't have enough applicants
[11:31] <Mohan_chml> ah..!
[11:31] <nigelb> ah, a bit of arm twisting required to get more people to apply? :)
[11:31] <Vantrax> yep
[11:32] <persia> Vantrax, Are you up for taking an action to contact the often-missing members and get them to say whether they'd be able to make one of the new meeting times?
[11:32] <persia> (8:00 and 12:00, weren't they?)
[11:32] <Vantrax> yes, ill do that and report back
[11:33] <persia> Anyone *not* on the Asia/Oceania RMB who would like to be, or anyone who thinks someone else should be (and has confirmed that person *can*) should also contact the RMB.
[11:33] <Vantrax> I think it was 0900 and 1200 UTC
[11:33] <persia> If both those actions complete for next time, we'll be able to ask the CC to give us the new members, and we can meet at the new times.
[11:34] <Vantrax> yes, ill get something in the fridge
[11:34] <persia> 9:00 is still late in +14, but I don't think we have anyone further east than +13 in practice.
[11:34] <Vantrax> maybe we will have more luck
[11:35] <Vantrax> I rarely get home before 7pm aest
[11:35] <Vantrax> too much earlier and ill be doing all meetings on a phone:D
[11:36] <persia> Ah, so 9:00 is about as early as works.  OK.  9:00 then.
[11:36] <persia> nigelb, As someone in IST, do you think 12:00 is late enough for your compatriots?  Does it need to be a bit later?
[11:37] <Vantrax> earlier?
[11:37] <persia> Vantrax, Just to confirm, AE{SD}T varies between +10 and +11, right?
[11:37] <persia> Vantrax, I'm not expecting anyone "east" to attend the later meeting :)
[11:37] <Vantrax> not for me, but yes
[11:38] <nigelb> persia: hold on, let me calculate that.
[11:38] <Vantrax> the southern half use daylight savings
[11:38] <elky> How does the later time pan out for muslim prayer time, too. I know it's been an issue for some in SE Asia previously.
[11:39] <nigelb> 12:00 UTC is 17:30 local time, which is okay.
[11:39]  * persia looks up relevant prayer schedules
[11:39] <elky> nigelb, isn't that commute time?
[11:40] <nigelb> elky: varies, commute time is an hour more from then
[11:40] <Vantrax> good point elky
[11:40] <nigelb> 9:30 to 6:30 is normal office timings (at least in this city)
[11:40] <persia> elky, We can't win for that.  "Sunset" and "evening" are always likely to collide a bit, unless we make it very late indeed.
[11:41] <elky> persia, yeah I figured. Most of the muslim nations I think get a fair crack at EMEA anyway.
[11:41] <persia> Looks like sunset in our region can be as late as 13:42
[11:42] <persia> (for 2010: I didn't check past years)
[11:43] <elky> I don't recall any significant meteorological bodies throwing us too far out of traditional orbit, so close enough.
[11:44] <persia> Well, governments have odd ideas about time.  There are precious few places left where the sun is in at the midpoint of it's path at 12:00
[11:44] <Vantrax> yeah, I notice that too
[11:44] <Vantrax> its confusing sometimes
[11:45] <persia> Anyway, do we have any more topics?
[11:45] <elky> I don't believe so.
[11:46] <elky> [ACTION] Vantrax to email current board members for commitment info
[11:46] <MootBot> ACTION received:  Vantrax to email current board members for commitment info
[11:46] <Vantrax> persia/elky can you send an email with action items, I'm about to head home
[11:47] <elky> I guess we adjourn to list and next fortnight
[11:47] <Vantrax> logs are painful on a phone:p
[11:47] <persia> Sounds good to me.
[11:47] <elky> I think that's the only action item actually.
[11:47] <Vantrax> yay me
[11:47] <elky> [ENDMEETING]
[11:47] <Vantrax> ill get on to that soon
[11:47] <elky> #endmeeting
[11:47] <MootBot> Meeting finished at 05:47.
[11:47] <persia> I may have trouble making the next meeting, as I'll be in UTC-4, just as a warning.
[11:47] <elky> persia, next meeting is UDS week?
[11:48] <Vantrax> np persia, thanks for making the effort
[11:48] <persia> Two weeks from today, yes?
[11:48] <elky> Then I'll also be subject to being in the wrong timezone.
[11:48]  * Vantrax wishes he got to go to uds
[11:48] <Vantrax> maybe next time
[11:48] <nigelb> ugh, uds
[11:49] <Vantrax> can't even make linux.conf.au this year
[11:49] <elky> nigelb, next time you won't have to argue with 'murricans.
[11:49] <persia> elky, With two of us the peer-pressure might be enough to make a 6:00 meeting :)
[11:49] <nigelb> elky: I just hope so :/
[11:49] <elky> persia, lifeless not likely to be there?
[11:50] <persia> Dunno.  He often seems to make UDSs though, so maybe three.  He's an early person too.
[11:51] <elky> It's not like we're even from the same countries. We can't even just vote on moving .Au for example. So sad.
[11:52]  * persia fails to be convinced that a vote is sufficient to so accelerate continental drift
[11:54] <elky> persia, who cares about moving the actual landmass.
[11:55] <persia> Oh, just the routing assignments?  I tend to be conservative, and want alignment between routing assignments and geographic features.
[11:58] <elky> How quaint.
[12:52] <ogitux> hello all
[12:56] <persia> ogitux, Hey.  Meeting ended about an hour ago: it's at 10:00 UTC.  `date -u` run from a terminal will show you current UTC time.
[12:57] <ogitux> :(
[13:00] <ogitux> huft I was Late
[13:01] <persia> Next meeting on the 26th.
[13:02] <ogitux> ok thx persia
[13:02] <persia> I doubt enough members of the Board are awake at this hour, really.
[13:02] <ogitux> why doubt persia
[13:03] <persia> Because some of them are in UTC+13 and UTC+11, so it's really late.
[13:04] <ogitux> so I have not  been able to join in ubuntu member
[13:04] <ogitux> persia:
[13:05] <persia> Not this week, no.
[13:05] <ogitux> next week yah persia
[13:05] <persia> I don't happen to know offhand when the other boards meet, if you want to try one of them at an odd time, but if you want the evening meeting for Asia/Oceania, you will have to wait for the 26th.
[13:05] <persia> No, week after next.
[13:06] <ogitux> ok, what time persia
[13:06] <persia> 10:00 UTC
[13:06] <ogitux> thx
[13:12] <ogitux> persia: where are u?
[13:59] <NCommander> #startmeeting
[13:59] <MootBot> Meeting started at 07:59. The chair is NCommander.
[13:59] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[13:59] <NCommander> [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20101012
[13:59] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20101012
[14:00] <lag> A bit premature
[14:00] <lag> o/
[14:00] <davidm> G'day all
[14:00] <NCommander> better early than late
[14:00] <davidm> true
[14:00] <mpoirier> o/
[14:00]  * NCommander gives everyone a moment to appear before starting properly
[14:00] <lag> Tell that to my Mrs ;)
[14:00] <persia> Within a few seconds is better than most meetings time themselves.
[14:00] <GrueMaster> Actually, right on time.
[14:01] <davidm> Good work all, 10.10 went out well, congratulations.
[14:01] <lag> \o/
[14:01] <NCommander> and the world didn't explode
[14:01] <NCommander> I consider tha an important bonus!
[14:02] <dyfet> that's tomorrow's asteroid...
[14:02] <persia> Or if it did, enough was reconstructed so that the difference is inobvious from the PoV of the average developer.
[14:02] <NCommander> dyfet: maybe we'll get lucky and it will only squish Redmond or something :-P
[14:02] <NCommander> anyway
[14:02] <NCommander> [topic] Action Item Review
[14:02] <MootBot> New Topic:  Action Item Review
[14:03] <NCommander> [topic] persia to close and/or postpone his remaining action items for 10.10
[14:03] <MootBot> New Topic:  persia to close and/or postpone his remaining action items for 10.10
[14:03] <persia> Nothing shows up on the new WI tracker.
[14:03] <NCommander> [topic] ogra + davidm to determine armel+omap4 releasability and notify the release team with the result
[14:03] <MootBot> New Topic:  ogra + davidm to determine armel+omap4 releasability and notify the release team with the result
[14:04] <ogra> long done
[14:04] <ogra> since we released apparently
[14:04] <NCommander> NCommander to unassign himself from bugs
[14:05] <ogra> (a roll call at the begining of the meeting would have been nice btw)
[14:05]  * NCommander is assigned :-)
[14:05] <NCommander> *unassigned
[14:05] <ogra> yeah, you were a bit over-enthusiastic :)
[14:05] <ogra> i assigned the flash-kernel breakage back to you
[14:05] <NCommander> I reassigned that to myself :-/
[14:05] <ogra> it wasnt
[14:05] <ogra> at least last night
[14:05] <NCommander> argh
[14:06] <NCommander> d'oh
[14:06] <NCommander> whoops
[14:06] <ogra> well, it is now :)
[14:06] <NCommander> [topic] Standing Item Review
[14:06] <MootBot> New Topic:  Standing Item Review
[14:06] <NCommander> I don't tihnk there's much point to go over the work trackers
[14:06] <NCommander> [topic] Kernel Status (cooloney, mpoirier, lag)
[14:06] <davidm> True
[14:06] <MootBot> New Topic:  Kernel Status (cooloney, mpoirier, lag)
[14:07] <lag>  * Texas Instruments (ti-omap)
[14:07] <lag>    * REBASE   : ti-omap4 branch is now at Ubuntu-2.6.35-903.15
[14:07] <lag>    * ON GOING : B605716 Regression from Karmic - corrected in Maverick - unsure what to do as the reporter has moved to Maverick.
[14:07] <lag>    * ON GOING : B637947 Kernel/userspace issue - lag is hosting a meeting with the top ASoC people today to discuss
[14:07] <lag>    * ON GOING : B535315 For some reason the net dev watchdog is timing out - more investigation needed.
[14:07] <lag>    * ON GOING : B613214 Regression from Karmic - working with user to bisect.
[14:07] <lag>    * ON GOING : B390959 For some reason the HID is recognising this keyboard as a joystick - more investigation needed.
[14:07] <lag>    * ON GOING : B22070  Looks like a USB issue, rectified in Maverick - need to fix Lucid.
[14:07] <lag>    * ON GOING : B43092  pata_pcmcia driver is not receiving correct IRQs - polling works, but was declined upstream.
[14:07] <lag>    * FIXED    : B637947 Audio fixing was merged and released - still need some user space configuration to make audio fully work
[14:07] <lag>    * FIXED    : B655746 HDMI bug fixing patch was merged.
[14:07] <lag>    * FIXED    : B586386 ti-omap4 branch missed this fix which is required by the upstart userspace application.
[14:07] <lag>    * FIXED    : B653002 An MLO patch was submitted to decrease the amount of occurence.
[14:07] <lag>    * FIXED    : B592295 omapdss DISPC error: SYNC_LOST_DIGIT.
[14:07] <lag>    * FIXED    : B605832 LG monitor behaving incorrectly when used in conjunction with the Panda board and HDMI.
[14:07] <lag>    * FIXED    : B612895 Unable to handle kernel NULL pointer dereference at virtual address 00000000 - fix released.
[14:07] <lag>    * FIXED    : B471228 Acer 5720 laptop will not wake from suspend - this issue has been rectified in Maverick.
[14:07] <lag>    * INVALID  : B628029 Not a bug, suspend is just not available on this h/w yet.
[14:07] <lag>    * INVALID  : B645420 Not a bug, USB OTG functionality is just not provided yet.
[14:07] <lag>    * PATCH    : IGEPv2's 6 patches have been SRU'ed. (OMAP3)
[14:07] <lag>    * PATCH    : The new set of ftrace patches have been submitted to linaro. (OMAP3)
[14:07] <lag>    * PATCH    : Working with Vincent Rabin on the remaining "graph tracing" patches. (OM
[14:07] <lag> Open those clients :)
[14:07] <lag> s/open/widen
[14:07] <lag> ..
[14:08] <lag> Oh bottom!
[14:08]  * ogra has 1080p here
[14:08] <ogra> fits well
[14:08] <lag> I've just realised (a lot of them aren't arm)
[14:08] <persia> lag, Don't bother to fix it now.
[14:08] <ogra> well, for arm we mostly care about the audio stuff
[14:08] <lag> k
[14:08] <persia> ogra, it's not the resolution of the screen: it's also how one *uses* the client.
[14:08] <lag> Yep
[14:08] <ogra> for which we have a meeting today
[14:08] <lag> 2nd one down
[14:08]  * persia abhors fullscreen harder
[14:10] <NCommander> I think I cna mov eon
[14:10] <NCommander> [topic] QA Status (GrueMaster)
[14:10] <MootBot> New Topic:  QA Status (GrueMaster)
[14:11] <GrueMaster> Images were tested with only a couple (kubuntu-mobile) seeing issues.
[14:11] <GrueMaster> Work started on blueprints for UDS-N related to QA on armel.
[14:11] <persia> Most kubuntu-mobile ARM folk are tweaking the image for use on N900s anyway, so that's only of moderate concern.
[14:12] <ogra> what do they do with the kernel and initrd then ?
[14:12] <ogra> ours wont boot
[14:12] <Riddell> GrueMaster: what was the issue with kubuntu-mobile?
[14:12] <ogra> and without initrd oem-config wont run
[14:13] <ogra> (and they will run out of space very fast due to no resize happening)
[14:13] <GrueMaster> Met with TI validation team.  Some overlap, but not much.  Their focus is on testing hardware & drivers to the maximum capabilities in a series of long test runs (over a week on dozens of systems).  Our testing is more distro completeness centric.
[14:13] <persia> ogra, Dunno: ask rbelem or ian_brasil: I think there's a script that does it, and some documentation.
[14:14] <ogra> persia, well, if they dont generate a new initrd and boot with it their image will be horribly broken
[14:14] <GrueMaster> The kubuntu-mobile images are incomplete in that they look like a single partition, not a complete drive with partitions.
[14:14] <ogra> i dont really care about running our image on n900
[14:14] <persia> ogra, I have no detailed idea.
[14:14] <persia> I know you don't care.  they do.
[14:14] <ogra> right
[14:14] <ogra> so they should ask for the right way ;)
[14:15] <persia> Point being that it's not that important that GrueMaster discovered issues.
[14:15] <ogra> i'm happy to give info ... but to lazy to hunt someone down
[14:15] <GrueMaster> The images worked on RC.  Not sure what changed.
[14:15] <persia> Won't help: N900 isn't a fully open platform.
[14:15] <ogra> the kernel surely did
[14:15] <persia> Anyway, enough of that.  Just a note to say that it's not a showstopper for anyone that the images weren't perfect.
[14:15] <ogra> persia, they worked on beagle
[14:16] <GrueMaster> No they did not.
[14:16] <ogra> they stopped working on beagle with final
[14:16]  * persia ran into OOM issues on beagle
[14:16] <ogra> erm, where did they work then ?
[14:16] <GrueMaster> kubuntu-mobile final images never worked.
[14:16] <ogra> (if i say beagle blantly assume i say XM :) )
[14:16] <GrueMaster> RC did.
[14:16] <ogra> GrueMaster, but thats what i said
[14:16] <ogra> :)
[14:17] <GrueMaster> And the kubuntu omap3 testing I did complete was on beagleXM.
[14:17] <ogra> indeed
[14:17] <ogra> no point in testing on C4
[14:17] <persia> Oh, XM worked fine.
[14:17] <persia> omap4 and C4 didn't work, which doesn't matter, because the objectives are met.
[14:17] <ogra> omap4 still doesnt work ?
[14:18]  * ogra thought it did
[14:18] <GrueMaster> C4 and XM are the same image.  And Neither image (omap3 and omap4) worked for release.  Both worked for RC.
[14:18] <ogra> k
[14:18] <GrueMaster> As I am the QA guy, I know what I tested.
[14:18] <ogra> geez, you keep notes ?!?
[14:18] <NCommander> one would hope
[14:19] <NCommander> [topic] ARM Porting/FTBFS status (NCommander, dyfet)
[14:19] <MootBot> New Topic:  ARM Porting/FTBFS status (NCommander, dyfet)
[14:19]  * ogra is overwhelmed
[14:19] <dyfet> Most of the ones I did last week were also security vulnerabilities
[14:19] <ogra> :)
[14:19] <persia> GrueMaster, XM didn't work for release?  Ah, yeah, that's probably annoying.
[14:20] <GrueMaster> persia: image was incomplete.
[14:20] <GrueMaster> Compare it with a different image.  Run "file <image>" and you will see immediately what I am talking about.
[14:20] <GrueMaster> No need to test it on a platform.
[14:20] <persia> Ah, right.  Somehow I thought that was only the omap4 image.  Oh well.
[14:21] <GrueMaster> See bug 657281
[14:21] <GrueMaster> I added a note on the bottom detailing the issue.
[14:21]  * ogra doesnt get the reboot part
[14:22] <ogra> After the installation, the installer reboots the board and users are presented with the expected login prompt
[14:22] <persia> Right.  I just misread your comment.
[14:22] <ogra> i dont get what was tested there
[14:22] <ogra> none of omap3 or 4 images reboot after the installer was run
[14:22] <persia> ogra, The description is kinda painful, mostly because it's second-hand.
[14:22] <ogra> ah
[14:23] <persia> Basically, jasper works, boot works, oem-config works, reboot doesn't work.
[14:23] <ogra> well, i dont get why mpoirier couldnt file it himself either
[14:23] <GrueMaster> mpoirier ran the test and reported to marjo (instead of filing the bug himself).
[14:23] <persia> For that matter, even trying to log in post oem-config doesn't work on a C4 (but that's for OOM reasons)
[14:23] <ogra> right
[14:23] <ogra> right, screw C4
[14:23] <mpoirier> I didn't file 'cause I thought someone would look at it right away...
[14:23]  * ogra wants an official note that we dont support it in natty
[14:23] <mpoirier> ask questions if you need more info.
[14:24] <GrueMaster> File bugs so we can.
[14:24] <ogra> right
[14:24] <ogra> that bug wasnt triaged at all
[14:24] <ogra> i only heard about it when the final images were done already
[14:24] <persia> Indeed.
[14:24] <ogra> in fact it still isnt
[14:24] <persia> mpoirier, Please always file bugs.  Nobody will look at anything that isn't findable.
[14:24] <ogra> and triage them properly
[14:25] <mpoirier> it was friday before the release and the QA team was on.
[14:25] <ogra> (subscribe ubuntu-armel and add an armel tag if we should look at it)
[14:25] <mpoirier> the kubuntu was supposed to be waiting.
[14:25] <persia> mpoirier, Doesn't matter.  We're all responsible for everything, as much as we specialise.  We can't expect anyone else to know what we mean, so we need to work with LP ourselves.
[14:26] <ogra> mpoirier, well, we would probably still have had time to fix it
[14:26] <ogra> we all returned saturday there was time for a respin
[14:26] <ogra> anyway
[14:26]  * persia only heard about it *late* saturday night.
[14:27]  * ogra heard about it late saturday night
[14:27] <ogra> too
[14:27]  * NCommander didn't see see any chatter in u-release until it was too late about it unfortunately :-/
[14:27] <ogra> sat. morning would have given us the time needed
[14:28] <persia> Anyway: problem was one person submitting information to another person.
[14:28] <ogra> anyway, move
[14:28] <ogra> NCommander,
[14:28] <persia> We need to put stuff in LP, and notify teams and channels
[14:28] <ogra> ^^
[14:28] <persia> (yes, move)
[14:28] <NCommander> [topic] ARM Porting/FTBFS status (NCommander, dyfet)
[14:28] <MootBot> New Topic:  ARM Porting/FTBFS status (NCommander, dyfet)
[14:28] <ogra> well, its over ;)
[14:29] <dyfet> I feel dajavu
[14:29] <NCommander> maverick shipped with 81 FTBFS total
[14:29] <ogra> unless you have SRUs
[14:29] <ogra> cool
[14:29] <ogra> 81 isnt as bad as former releases
[14:29] <persia> In fact, it's the best ever.
[14:29] <dyfet> the ones i focused on last week were also security related...
[14:29] <NCommander> maybe we can get it to 0 for natty ;_)
[14:30] <ogra> NCommander, if we get doko proper hardware i'm sure of that
[14:30] <ogra> davidm, doko urgently needs a panda
[14:30] <persia> http://skitterman.wordpress.com/2010/10/09/ftbfs-final-score/ was a bit of a nice thing to see
[14:30] <MootBot> LINK received:  http://skitterman.wordpress.com/2010/10/09/ftbfs-final-score/ was a bit of a nice thing to see
[14:30] <ogra> doko did the heaviest lifting on ftbfs within teh last weeks i have seen yet
[14:31] <davidm> ogra, as they become available we can get him one
[14:31] <ogra> davidm, he should get the first one we recieve ;)
[14:31] <davidm> nothing we can do until they go into GA
[14:31] <ogra> from the new chunk
[14:31] <ogra> understood
[14:32] <NCommander> yay
[14:32] <NCommander> [topic] ARM Image Status (ogra, NCommander)
[14:32] <MootBot> New Topic:  ARM Image Status (ogra, NCommander)
[14:32] <ogra> virtually they would be fine if they would exist :)
[14:32] <ogra> no natty images yet
[14:32] <ogra> we're all slackers !
[14:33]  * GrueMaster blames the beer.
[14:33] <ogra> maverick images were fine apart from the sound issues
[14:33]  * NCommander smacks ogra
[14:33] <persia> And the Kubuntu-mobile issues Gruemaster discovered.
[14:33] <ogra> indeed
[14:34] <ogra> so for kubuntu, i want a clear definition for natty what will be supported and what we will build
[14:34] <ogra> and a want a *gaurantee* that there are *community* testers
[14:34] <NCommander> [action] ogra to follow up with kubuntu-dev with the images to build for natty
[14:34] <MootBot> ACTION received:  ogra to follow up with kubuntu-dev with the images to build for natty
[14:34] <ogra> at UDS
[14:34] <NCommander> :-)
[14:34]  * ogra wants to have a BOF for that
[14:34] <ogra> no need for an action
[14:34] <ogra> rather a spec :)
[14:35] <NCommander> [topic] ogra to draft kubuntu image spec
[14:35] <MootBot> New Topic:  ogra to draft kubuntu image spec
[14:35] <ogra> i dont want to be hammered with kubuntu testing requests from QA the last minute before release becuase the community has no HW
[14:35] <NCommander> [topic] Any Other Business
[14:35] <MootBot> New Topic:  Any Other Business
[14:35] <ogra> specs ?
[14:36] <dyfet> posting status?
[14:36] <persia> ogra, http://projects.powerdeveloper.org/project/imx515/801 should help in the HW department for Kubutnu
[14:36] <ogra> persia, with what ?
[14:36] <ogra> we dont support imx5*
[14:36] <ogra> i only care about image testing for the official images here
[14:37] <persia> What you support and what are images are only tangentially related.  I don't suggest you should support that, but it ought mean less demand for Kubutnu images for arbitrary pre-availability development boards, which ought make less demand on you.
[14:37] <ogra> and for these i expect a minimum of HW to be available by the community that asks me to build their images, else i wont build them
[14:38] <ogra> and i want a guarantee in advance at UDS that this testing can happen
[14:38] <persia> I'm in favour of a spec: just noting that you may find less hard requirements on yourself.
[14:38] <ogra> well, if we build images i want them tested
[14:39] <persia> And so you should.
[14:39] <ogra> if they cant be tested i wont build them
[14:39] <persia> Right.  Let's have a spec about this.
[14:39] <ogra> yeah
[14:39] <NCommander> Minimal requirements for us to spin images?
[14:39] <davidm> need blueprints this week
[14:39] <persia> I know that lots of the -testing crowd was unhappy with image validation because of lack of hardware.
[14:39] <ogra> and invire QA, TI and the KDE community
[14:39] <persia> NCommander, No.  Verification that we actually have testers with hardware for each image built.
[14:39] <ogra> NCommander, no, specific for kubuntu
[14:39] <persia> ogra, Please no.  Other flavours might want it, etc.
[14:40] <ogra> persia, well, we dont build for other flavours atm
[14:40] <persia> Let's just set up a chart, and make sure we have volunteers for everywhere.
[14:40] <NCommander> ogra: what if xubuntu/mythbuntu/* want images on arm?
[14:40] <davidm> I think the hardware issues will get sorted this cycle, the community should have their own hardware this cycle.
[14:40] <ogra> they are free to show up in the sessio and raise their hands
[14:40] <persia> ogra, Right.  "atm" is the reason for my objection :)
[14:41] <ogra> davidm, i want a written down list of stuff that can be testedd and the safety that our team doesnt have to do it in the end
[14:41] <ogra> sure the HW situation will be better, but people still have to buy it or find a sponsor
[14:41] <GrueMaster> ogra: Add to that a guarantee from our hw suppliers that we won't need to show up at the last minute for new hw.
[14:41] <persia> ogra, You probably also want some agreement from the cdimage team that they won't enable arbitrary other images on platforms with limited HW availability without confirming testers.
[14:42] <NCommander> [topic] ogra + persia to take this converation (on community ARM hardware) offline, and report back at UDS
[14:42] <MootBot> New Topic:  ogra + persia to take this converation (on community ARM hardware) offline, and report back at UDS
[14:42] <ogra> persia, i can agree to that as a member of that team :)
[14:42] <persia> NCommander, Please reset that action to be to bring a spec to UDS about it.
[14:42] <ogra> right
[14:42] <persia> ogra, Right, but you need to confirm with everyone else on the team too :)
[14:43] <ogra> more on specs ?
[14:43] <ogra> davidm, by when, friday ?
[14:44] <ogra> or earlier ?
[14:44] <NCommander> [topic] ogra + persia to take this converation (on  community ARM hardware) offline
[14:44] <MootBot> New Topic:  ogra + persia to take this converation (on  community ARM hardware) offline
[14:44] <NCommander> bah
[14:44] <NCommander> [topic] ogra + persia to take this converation (on   community ARM hardware) offline
[14:44] <MootBot> New Topic:  ogra + persia to take this converation (on   community ARM hardware) offline
[14:44] <NCommander> ...
[14:44] <ogra> NCommander, stop playing with the bot :O
[14:44] <NCommander> ^- and make a spec on it
[14:44] <NCommander> I'm having copy and paste failures due to hidious lag
[14:44] <davidm> ogra, as much as can be done by Friday, UDS scheduling needs to get done
[14:44] <ogra> ok, friday it is then
[14:44] <NCommander> GrueMaster's DSL modem ishaving seizures
[14:45] <persia> davidm, Should folk wanting to schedule stuff just set you as approver, or something different?
[14:45] <davidm> And the areas are different so we nned to submut them ASAP
[14:45] <GrueMaster> No, it isn't
[14:45] <NCommander> davidm: UDS-N doesn't exist as a target to put specs against.
[14:45] <davidm> persia, that is the main issue I am not a scheduler this UDS
[14:45] <ogra> uh
[14:45] <davidm> though "technically" I can do it
[14:45] <ogra> who is ?
[14:45] <persia> Aha.
[14:45] <davidm> I'll get the list to you all today for each section
[14:46] <ogra> davidm, but you're an approver for our workitems still, right ?
[14:46] <ogra> i.e. we put you in for approving
[14:46] <davidm> We don't have an ARM track just the general announced tracks that our Blueprints go into
[14:46] <ogra> yes
[14:46] <persia> I've been told http://ubuntudevelopers.blip.tv/file/3539348/ explains the correct method.
[14:46] <ogra> i'm not talking about UDS
[14:46] <davidm> ogra yes for workitems I am the approver
[14:46] <ogra> good
[14:46] <davidm> ogra, in that sense you are correct
[14:46] <NCommander> davidm: (I can't select UDS-N as the sprint)
[14:47] <davidm> NCommander, I'll see when that opens
[14:47] <davidm> I would have thought today but perhaps tomorrow
[14:47] <davidm> There was an announcment on naming, so make sure you follow the requirements
[14:48] <NCommander> davidm: thanks davidm
[14:48] <davidm> Or you will have to rename to match later (which is a pain)
[14:49] <persia> NCommander, Next?
[14:50] <ogra> an annoouncement on naming ?
[14:50] <NCommander> [topic] Specification Dicussion]
[14:50] <MootBot> New Topic:  Specification Dicussion]
[14:50]  * ogra missed that
[14:50] <ogra> can anyone summarize here ?
[14:50] <persia> ogra, $track-$team-n-$whatever
[14:51] <ogra> and $tarck is the new tarck naming scheme ?
[14:51] <ogra> *track
[14:51] <persia> $team is some one-word string for the WI tracker.  $track is from summit.ubuntu.com $whatever is freeform.
[14:51] <ogra> right, thanks
[14:51] <ogra> and -n- not -natty-
[14:51] <ogra> k
[14:51] <persia> Right -n-
[14:51] <ogra> thanks
[14:52] <persia> davidm, If you have a preference for $team you want to impose, you may want to dictate something for your team to use :)
[14:52] <ogra> -arm- indeed
[14:52] <persia> Works.
[14:52] <persia> OK.  Next?
[14:52] <ogra> i need to adjust the WI tacker for it
[14:52] <ogra> past UDS though
[14:52] <ogra> we're still mobile there
[14:53] <NCommander> Anything else to bring up? I'm realy to close out the meeting soonish
[14:53] <ogra> NCommander, always in a hurry eh ?
[14:54] <davidm> persia, we are the ARM team
[14:54] <ogra> just a big thank you to the team, well done for maverick :)
[14:54] <davidm> I'll echo that most strongly, thanks for the great work.
[14:54] <persia> davidm, Thought so: just wanted verification, as (as ogra pointed out) "mobile" was used for maverick.
[14:54] <davidm> NCommander, close it down
[14:55] <davidm> persia, true but we are now more accurately named ;-P
[14:55] <NCommander> #endmeeting
[14:55] <MootBot> Meeting finished at 08:55.
[14:55] <persia> Indeed :)
[15:02] <simar> #ubuntu-bugs
[18:03] <lag> o/
[18:06] <kees> \o
[18:07] <mdeslaur> hello
[18:07] <jdstrand> \o
[18:07] <nxvl> hi
[18:12] <mdeslaur> sbeattie?
[18:13] <sbeattie> hey
[18:13] <mdeslaur> kees: you get to start
[18:16]  * mdeslaur pokes kees with stick
[18:17] <kees> hi!
[18:17] <kees> sorry, got distracted
[18:17] <kees> I'm doing audits this week, and helping the kernel get published some more.
[18:17] <kees> that's really it from me. mdeslaur! :)
[18:18] <mdeslaur> ok :)
[18:18] <mdeslaur> I'm currently building webkit 1.2.5 for karmic, lucid, maverick
[18:18] <mdeslaur> that's what I plan to do this week. I'll pick something up from the CVE list of I have time left.
[18:19] <mdeslaur> that's it!
[18:19] <kees> yay for webkit!
[18:19] <mdeslaur> jdstrand?
[18:21] <jdstrand> I am working on python-django, all mozilla products and libvirt
[18:21] <jdstrand> sbeattie: you're up
[18:22] <sbeattie> I've got an openjdk update going on this week, as well as triage.
[18:23] <sbeattie> that's it for me.
[18:23] <mdeslaur> cool
[18:23] <mdeslaur> does anyone have anything to discuss with the security team?
[18:25] <kees> ETIMEOUT
[18:25] <kees> thanks mdeslaur!
[18:26] <mdeslaur> hehe
[18:54] <smoser> o/
[18:55] <hallyn> \o
[18:55] <RoAkSoAx> o/
[18:56] <jiboumans_> o/
[18:56] <SpamapS> \o\
[18:56] <jjohansen> o/
[18:57] <zul> afternoon
[18:57] <ttx> \\o
[18:58] <hggdh> ~ô~
[18:58] <ttx> nice hat, dude
[18:58] <RoAkSoAx> lol
[18:59] <Daviey> o/
[18:59]  * ttx has mild connectivity issues, don't worry if I disapeear from the face of the Internet for a few minutes.
[18:59]  * hggdh bows to ttx
[19:00] <SpamapS> well then, shall we?
[19:00] <SpamapS> #startmeeting
[19:00] <MootBot> Meeting started at 13:00. The chair is SpamapS.
[19:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:00] <SpamapS> I see no action points from the previous meeting, so we'll move forward to...
[19:00] <SpamapS> [TOPIC] Postmortem for Maverick (ttx)
[19:00] <MootBot> New Topic:  Postmortem for Maverick (ttx)
[19:00] <ttx> hm, there was some action points though
[19:01] <ttx>   * ACTION: mathiaz to send out a call for ideas on ubuntu to the
[19:01] <ttx> puppet community
[19:01] <ttx>   * ACTION: smoser to get skaet info on how to publish EC2 images
[19:01] <ttx>   * ACTION:  Everyone to celebrate the 10.10.10 release in their own unique ways
[19:01] <SpamapS> Right, they didn't make it into the agenda...
[19:01] <SpamapS> [TOPIC] review action points from previous meeting
[19:01] <MootBot> New Topic:  review action points from previous meeting
[19:01] <ttx> SpamapS: probably the chair didn't copy them there :P
[19:02] <SpamapS> I didn't see an email from mathiaz..
[19:02] <SpamapS> and he is at hadoop world
[19:02] <jiboumans_> let's follow up with him afterwards
[19:02] <ttx> seeing fat elephants
[19:02] <SpamapS> so will carry that one forward unless somebody else saw the email?
[19:02] <jiboumans_> i didn't see the mail either
[19:02] <SpamapS> [ACTION] mathiaz to send out a call for ideas on ubuntu to the puppet community (carry over)
[19:02] <MootBot> ACTION received:  mathiaz to send out a call for ideas on ubuntu to the puppet community (carry over)
[19:02] <kim0> can I help with that
[19:03]  * smoser did get skaet info on how to do that, but still had to wake up sunday morning to help (due to my own mistakes). so 'Done'
[19:03] <SpamapS> smoser: assuming you were able to instruct skaet on EC2 image publishing :)
[19:03] <SpamapS> sweet.
[19:03] <ttx> kim0: maybe, see with mathiaz
[19:03] <Daviey> smoser: Was kinda scary at one point :)
[19:03] <ttx> a bit scary.
[19:03] <smoser> bah
[19:03] <smoser> not scary
[19:03] <smoser> everything was under control :)
[19:03] <SpamapS> I celebrated by wearing my 101010 shirt and yelling at the TV whenever the Cowboys fumbled.
[19:04] <ttx> SpamapS: you got a 101010 shirt ?
[19:04] <zul> i killed a bird to celebrate
[19:04] <SpamapS> ttx: not a 1 or 0, an old 101010 shirt from the 2005 Sysadmin of The Year Contest (I was nominated.. did not win.. too nerdy I presume)
[19:04] <ttx> ah
[19:04] <SpamapS> Ok, moving on
[19:05] <SpamapS> [TOPIC] Postmortem for Maverick (ttx)
[19:05] <MootBot> New Topic:  Postmortem for Maverick (ttx)
[19:05] <ttx> So you should have a look at your Maverick specs, and close them as "Implemented" or "Deferred"
[19:06] <SpamapS> [ACTION] ALL to mark maverick assigned specs as "Implemented" or Deferred
[19:06] <MootBot> ACTION received:  ALL to mark maverick assigned specs as "Implemented" or Deferred
[19:06] <ttx> also we need to keep a special eye on Maverick bugs
[19:06] <ttx> I expect people to stumble upon critical bugs once the release is out
[19:06] <ttx> so we need to stay ready for SRUs
[19:06] <ttx> I already noted two candidates
[19:07] <ttx> Bug 658227 and bug 600174
[19:07] <ttx> The first one being kinda urgent
[19:07] <ttx> I hoped mathiaz would be around to pick it up
[19:07] <ttx> but he is not, so it's free game
[19:08] <Daviey> Second one.. really needs 'fixing'.. but i was going to propose not being uploaded unless axis2c needs uploading for another reason
[19:08] <ttx> Daviey: agreed
[19:08] <Daviey> ie, backport from natty i guess.
[19:08] <ttx> anything else that you saw in daily triage that you think is a maverick regression ?
[19:08] <Daviey> no
[19:08] <ttx> if not, that's all for mavreick, rest in peace, long live Natty
[19:09] <Daviey> \o/
[19:09] <SpamapS> There's a comment on bug 607646 that claims it may have caused a regression, but no actual bug report with details that I've seen yet
[19:10] <ttx> SpamapS: ok, you can move on
[19:10] <SpamapS> Ok, on to Natty?
[19:10] <SpamapS> [TOPIC] Natty development
[19:10] <MootBot> New Topic:  Natty development
[19:11] <ttx> Natty will open soon
[19:11] <ttx> and with it the season of syncs/merges
[19:11] <ttx> that's the process of merging the changes in debian, or syncing to the version in debian
[19:11] <ttx> if the newcomers need any light on the process, please ask one of the old-timers.
[19:11] <ttx> Deferring to jiboumans for Natty planning
[19:12] <RoAkSoAx> will a list of merges be published?
[19:12] <SpamapS> From what I understand, maverick had a fairly low percentage of pending merges completed.. so we may have a big backlog.
[19:12] <ttx> SpamapS: server looked not too bad.
[19:12] <zul> RoAkSoAx: merges.ubuntu.com
[19:12] <Daviey> RoAkSoAx: nothing server specific, but https://merges.ubuntu.com is always a good resource.
[19:12] <ttx> RoAkSoAx: in MoM, then maybe we'll come up with a server seed crossection
[19:13] <RoAkSoAx> lo. i know that but I meant server specific merges
[19:13] <zul> RoAkSoAx: i also have a python script if you want
[19:13] <SpamapS> 298 outstanding merges in main
[19:13] <RoAkSoAx>  :)
[19:13] <zul> SpamapS: we arent doing all that
[19:13] <zul> ;)
[19:13] <RoAkSoAx> zul: for server specific?
[19:13] <zul> RoAkSoAx: yep
[19:13] <RoAkSoAx> zul: ok cool:)
[19:14] <zul> RoAkSoAx: just bug me about it after the meeting ill try to find it for you
[19:14] <RoAkSoAx> ok thanks :)
[19:14] <ttx> SpamapS: moving on
[19:14] <SpamapS> Oh no specs?
[19:15] <ttx> SpamapS: that's jiboumans's subject
[19:15] <ttx> though I can fill in if he dropped
[19:15] <SpamapS> jiboumans_: Natty specs preparation (jib)
[19:15] <jiboumans_> The time for creating blueprints for UDS sessions is upon us; looking at https://wiki.ubuntu.com/ServerTeam/NattyIdeaPool we have a lot to go on. Right now, only blueprints for topics that you think warrant discussion at UDS are needed to be created; try to group similar topics in a way that makes a good session and list them as part of the "UDS" Section under the right track and remove them from the idea pool. That should be doable for everyone somew
[19:15] <jiboumans_> this week I think.
[19:15] <ttx> ELINETOOLONG
[19:16] <jiboumans_> try to group similar topics in a way that makes a good session and list them as part of the "UDS" Section under the right track and remove them from the idea pool. That should be doable for everyone somewhere this week I think.
[19:16] <jiboumans_> Any items left in the idea pool after this week are ideally then items that don't need discussion and we can move those to blueprints at a later date just to track implementation. Any questions about next steps?
[19:16] <SpamapS> Ok, going once...
[19:17] <SpamapS> jiboumans_: thanks, moving on..
[19:17] <SpamapS> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[19:17] <MootBot> New Topic:  Weekly Updates & Questions for the QA Team (hggdh)
[19:17] <hggdh> ok
[19:17] <hggdh> we are now phasing out the 'regression-potential' tag
[19:18] <hggdh> please use only regression-release or regression-proposed or regression-updates as needed
[19:18] <ttx> ok
[19:18] <ttx> who looks at those ?
[19:19] <hggdh> we  -- QA/bugSquad will look at all current bugs set with -potential, and will update them
[19:19] <ttx> ack
[19:19] <hggdh> the docs and the LP greasemonkey scripts will be updated also
[19:20] <hggdh> apart from that, nothing new on the western front
[19:20] <SpamapS> Anything else for QA?
[19:20] <SpamapS> On to the kernel then..
[19:20] <SpamapS> [TOPIC] Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:20] <MootBot> New Topic:  Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:20] <jjohansen> I don't have anything I want to bring up
[19:20] <jjohansen> smoser: what do you have for me :)
[19:21] <smoser> hm..
[19:21] <smoser> 2 things.
[19:21] <Daviey> heh
[19:21] <smoser> 1. lucid load, i've beeen promised a fix like 2 weeks ago
[19:21] <jjohansen> is that still not in?
[19:21] <smoser> (ok, promised was a strong word, but given suggestion that it would be fixed, i relayed in bug)
[19:21] <smoser> there is no udpate to the bug
[19:22] <smoser> 2.) maverick issue bug 658461
[19:22] <jjohansen> I did the rebase, that was blocking and tested, and handed it back to brad and steve
[19:22] <smoser> well, there is no 'fix-released' comment in the bug. so i'm not aware of it.
[19:22] <jjohansen> smoser: right I would expect them to update the bug when the pushed the rebase, I'll look into it
[19:23] <smoser> we also have bug 634487. which i would really like to see fixed in lucid and maverick.
[19:23] <SpamapS> [ACTION] jjohansen to look into virtual kernel bug status (bug 658461)
[19:23] <MootBot> ACTION received:  jjohansen to look into virtual kernel bug status (bug 658461)
[19:24] <jjohansen> thanks, I'll try to take a look at it this week
[19:24] <SpamapS> smoser: I thought that was an issue on amazon's side?
[19:24] <SpamapS> or was that the reboot issues?
[19:24] <jjohansen> SpamapS: may be
[19:24] <smoser> SpamapS, there was a data corruption bug on amazon's side for user-data.
[19:24] <SpamapS> ok
[19:24] <smoser> the java bug is definitely a kernel bug (imho).  a user space process makes kernel go crazy
[19:25] <smoser> or crash
[19:25] <SpamapS> ok, anything else?
[19:25] <SpamapS> jjohansen: did you want a single action item to look into both of those bugs?
[19:25] <jjohansen> SpamapS: it could be our kernel trying to use unsupported pv-ops
[19:25] <jjohansen> SpamapS: sure
[19:25] <SpamapS> [ACTION] jjohansen to look into bug 658461
[19:25] <MootBot> ACTION received:  jjohansen to look into bug 658461
[19:25] <SpamapS> ok I'll fold it in to one in the minutes
[19:26] <zul> pv-ops is funnn..
[19:26] <SpamapS> moving on to documentation
[19:26] <SpamapS> [TOPIC] Weekly Updates & Questions for the Documentation Team (sommer)
[19:26] <MootBot> New Topic:  Weekly Updates & Questions for the Documentation Team (sommer)
[19:26] <Daviey> We miss sommer!
[19:26] <SpamapS> oh didn't see that he wasn't here
[19:27] <SpamapS> ok.. did anybody else have documentation issues they'd like to have relayed to sommer?
[19:27] <ttx> SpamapS: no
[19:27] <SpamapS> [TOPIC] Weekly Updates & Questions for the Ubuntu Community Team (kim0)
[19:27] <MootBot> New Topic:  Weekly Updates & Questions for the Ubuntu Community Team (kim0)
[19:27] <kim0> o/
[19:27] <kim0> hey folks .. I'd just like to draw attention of OpenWeek. Find the schedule at: https://wiki.ubuntu.com/UbuntuOpenWeek
[19:27] <kim0> I'm giving a cloud basics session tomorrow 16:00UTC, I will be demo'ing cloud-init and answering basic questions. Dustin, will be giving a session after it on deploying web apps to the cloud
[19:27] <kim0> Other than that, I had sent out a call for contributers, I have around 8 people who want to start contributing to ubuntu-server (Yaaay). I'll be talking to Jono tomorrow on how to best get them involved and any mentoring needed. Any volunteers to help with the process are most welcome
[19:27] <kim0> That should be all
[19:28]  * kirkland waves
[19:28] <SpamapS> kim0: thanks!
[19:28] <SpamapS> and now to everyone's favorite topic
[19:28] <SpamapS> [TOPIC] Open Discussion
[19:28] <MootBot> New Topic:  Open Discussion
[19:28] <RoAkSoAx> I you haven't read so already, I've successfully setup HA for the UEC-CLC using the cluster stack (pacemaker, heartbeat) and DRBD for replication between CLC's. Everything seems to working as expected. I'll blog post about it later this week when I finish midterms. I'm planning to discuss this at UDS (If Cluster Stack Session get's scheduled).
[19:29]  * SpamapS will be holding a cluster stack session on the beach if it doesn't get scheduled at UDS
[19:30]  * hallyn registers for that one
[19:30] <Daviey> RoAkSoAx: You rock! :)
[19:30] <SpamapS> Indeed.. cluster FTW :)
[19:30] <SpamapS> ok, if nobody else has anything?
[19:31] <SpamapS> Ok then
[19:31] <ttx> SpamapS: according to my wife, I snored last night. Bad news for you.
[19:31] <Daviey> \o/
[19:31] <SpamapS> ttx: only if yours overpowers mine
[19:31] <SpamapS> [TOPIC] Announce next meeting date and time
[19:31] <MootBot> New Topic:  Announce next meeting date and time
[19:31] <ttx> aaaargh
[19:31] <SpamapS> Next meeting will be Tuesday 2010-10-19 at 1800 UTC - here in #ubuntu-meeting
[19:31] <SpamapS> thanks everyone!
[19:31] <Daviey> o/
[19:32] <SpamapS> #endmeeting
[19:32] <MootBot> Meeting finished at 13:32.
[19:32] <RoAkSoAx> \o
[19:32] <ttx> SpamapS: yay


[01:57] <mathiaz> slangasek: what's your opinion on bug https://bugs.launchpad.net/ubuntu/+source/samba/+bug/211631?
[01:57] <slangasek> mathiaz: <opinion>"blech"</opinion>
[01:57] <mathiaz> slangasek: it seems that most of the issue are related to network manager.
[01:58] <mathiaz> slangasek: what about adding an script to umount cifs share in ifdown.d for network manager?
[01:58] <slangasek> two things: 1) network-manager shouldn't be allowed to kill off the network before unmounting remote filesystems in the general case, 2) the kernel and/or umount.cifs needs to be fixed to not have long timeouts in the case that the server is unreachable
[01:59] <slangasek> I think the latter is actually a kernel rather than userspace issue
[01:59] <slangasek> ifdown.d is probably wrong because you don't want to unmount the remote filesystems when *a* network interface goes down, you want to unmount them when the *corresponding* network interface goes down
[02:00] <mathiaz> slangasek: right - there is also the issue of processes having an file open on the mounted device
[02:01] <mathiaz> slangasek: IIUC this is why umountnfs is run after sendsigs in the shutdown sequence
[02:01] <slangasek> yes
[02:01] <mathiaz> slangasek: in the case of network manager it may not be a good idea to kill all process that have a file open on the mounted device
[02:02] <slangasek> sorry, what do you mean?
[02:02] <mathiaz> slangasek: before umount a network fs, we could try to figure which processes have a fd open on the network fs and kill them.
[02:03] <slangasek> are you talking about at shutdown time?
[02:03] <mathiaz> slangasek: to mimic the shutdown sequence where processes are killed before umounting network filesystem
[02:03] <mathiaz> slangasek: nope - when a interface is brought down
[02:03] <mathiaz> slangasek: assuming we'd add a pre-ifdown.d script to umount the network filesystem
[02:04] <slangasek> er, how are you going to write an ifdown.d script that doesn't gratuitously unmount filesystems that it shouldn't?
[02:05] <mathiaz> slangasek: well - I haven't about that yet. But it seems that adding adding an ifdown script is too complicated.
[02:05] <mathiaz> slangasek: haven't *thought*
[02:05] <slangasek> if I have more than one interface, I don't want all the NFS mounts for my internal network to disappear every time I adjust my external interface, e.g.
[02:06] <slangasek> regardless of anything else, the timeouts are a kernel/umount.cifs bug that should be fixed there
[02:06] <slangasek> and if we fix that, the only other problem is at shutdown time, AFAICS
[02:06] <mathiaz> slangasek: correct. And you'd also have to figure out a way to match which interface is used for each network filesystem.
[02:07] <slangasek> which can be addressed by fixing n-m's behavior on shutdown
[02:07] <mathiaz> slangasek: correct. people are complaining because it takes too long to shutdown.
[02:08] <slangasek> i.e., either move n-m to /sbin and add it to the ignore list for sendsigs, or arrange for n-m to not tear down the interfaces when signalled, I think?
[02:09] <mathiaz> slangasek: well - some user reported that they had issue when logging off.
[02:09] <mathiaz> slangasek: in the case of a wireless connection, is the connection brought down when the user logs off?
[02:09] <slangasek> possibly.  shouldn't that be considered a bug?
[02:11] <mathiaz> slangasek: hm - I don't know. asac and the desktop team should probably be involved into this discussion.
[02:11]  * slangasek nods
[02:11] <mathiaz> slangasek: anyway it seems that the most practical solution is to lower the timeout.
[02:11] <slangasek> that's a bandaid, though.
[02:12] <slangasek> what *should* be happening in this case is that the network route is gone, so trying to send to it will get you a no-route-to-host
[02:12] <slangasek> which can be detected and handled by the kernel
[02:12] <slangasek> so either the route isn't being torn out when it should be, and we should fix that; or the cifs driver doesn't handle no-route-to-host, and we should fix that
[02:12] <slangasek> then adjusting the timeouts shouldn't matter at all
[02:14] <mathiaz> slangasek: ok. I'll add a note to the bug with the explanation you've just given.
[02:14] <slangasek> ok
[03:44] <EvanCarroll> man bluetooth support is *so* bad overall.
[03:44] <EvanCarroll> I've literally had problems with every component of bluetooth support.
[03:47] <EvanCarroll> seems as if there are general problems with all keyboards and keymaps in ibex, as well as no ui to make a bluetooth keyboard setup for gdm. and no logs for bluetooth-applet, no decent reconnects,,, gah i rant
[03:48] <EvanCarroll> having been sold into bluetooth I'm trying to run three devices a keyboard mouse and mic/earphone phone thingy
[03:48] <EvanCarroll> so far they all have suprises.
[03:51] <cody-somerville> Its a good thing you're working on it then
[03:56] <EvanCarroll> the catch is, I'm not sure which bugs are faulty hardware, or which bugs are OS.
[03:56] <EvanCarroll> I'd have to install windows to figure it out.
[03:57] <EvanCarroll> the disconnects could be faulty hardware from the bluetooth usb dongle or from the mouse. or from the load of three devices on the adapter
[03:57] <EvanCarroll> or, most probably, linux support
[03:58] <cody-somerville> then why even go with the improbably premise until probable?
[04:01] <EvanCarroll> well. the probability is based on the guilty-by-association.. which seems to be based on things *I* know to be reproducable linux problems lingering from a bad userspace implimentation for hotswap devices.
[04:03] <EvanCarroll> like keymaps, how can unplugging a usb keyboard and plugging it back in revert a keymap, and how come when a computer comes on with a bluetooth keyboard it has to be manually connected in bluetooth-applet, and after it is connected even though the keymap is international in keyboard preferences, it is en-us in reality.
[04:04] <EvanCarroll> if you only have a bluetooth keyboard, how do you type in your password in GDM.
[04:04] <EvanCarroll> lol.
[04:29] <emgent> moin moin
[06:33] <pitti> Good morning
[06:33] <pitti> kirkland: looking
[06:37] <pitti> kirkland: that looks excellent
[06:55] <dholbach> good morning
[07:17] <geser> good morning dholbach, pitti
[07:17] <dholbach> hiya geser
[07:20] <NCommander> morning geser
[07:20] <pitti> hey geser
[07:20] <pitti> NCommander: congrats to your MOTU badge!
[07:21] <NCommander> pitti, yup, it got my my backports one too
[07:21] <NCommander> (and I highly recommend you use caution on opening your inbox pitti :-))
[07:21] <NCommander> There is one removal, and 14-16 backporting ACKs
[07:21] <pitti> NCommander: too late
[07:22]  * NCommander gives you the flamethrower of justice
[07:22] <NCommander> oh and an SRU
[07:22] <NCommander> ;-)
[07:24] <geser> Hi NCommander
[07:24] <NCommander> morning geser
[07:27] <NCommander> geser, I'm loking at your merges, any one you want me to do upfront?
[07:34] <geser> NCommander: no specific order
[07:35] <NCommander> geser, well, one of your merges became a sync since Debian rolled your fix bashisms patch
[07:35] <NCommander> so one down
[07:36] <geser> NCommander: I guess squid3 might be a sync too as that patch came from upstream and should be included in 3.0.STABLE8
[07:37]  * NCommander is trying to determine if the requestsync script actually works :-)
[07:37] <geser> NCommander: ilohamail is a fakesync due to bad versioning, so an easy one too (if you prefer the easy ones :)
[07:37] <NCommander> fakesync?
[07:40] <geser> NCommander: in cases where we don't have any changes but can't sync (different .orig.tar.gz, bad versioning etc.) we need to do an upload nonetheless (e.g. take the Ubuntu .orig.tar.gz and Debian .diff.gz in the case of a different .orig.tar.gz)
[07:40] <NCommander> What's the version number I need to upload w/?
[07:40]  * NCommander requests another sync for libnet-cups-perl
[07:42] <geser> as there aren't any changes -XbuildY should work (generally speaking)
[07:43]  * NCommander nods
[07:43] <geser> in case of ilohamail you need to upload 0.8.14-0rc3sid6 as  0.8.14-0rc3ubuntu4
[07:44]  * NCommander grabs the debian packaging
[07:44] <NCommander> so debian diff, ubuntu orig.tar.gz
[07:46] <geser> you can use also the debian .orig.tar.gz as they're both the same (it's just the versioning which went bad in the past)
[07:46]  * soren wishes people would stop writing more php webmail systems and write a Python one instead
[07:46]  * NCommander nods
[07:46] <NCommander> geser, what do I use for the -v in debuild?
[07:47] <soren> The last version known to Ubuntu.
[07:48] <NCommander> Right
[07:48] <NCommander> But there are no other ubuntu entries in the changelog
[07:49] <geser> use 0.8.14-0rc3sid5 so you get also the new Debian changelog entry into the .changes file
[07:49] <NCommander> ah
[07:49] <soren> The point is that the .changes file should list all the changes since the last version uploaded to Ubuntu.
[07:49]  * NCommander test builds, and installs
[07:49] <NCommander> Ok, now it makes sense
[07:55] <liw> lifeless, and don't you just love a discussion that bounces across channels? :)
[07:55] <lifeless> liw: only when there is enough people capable of following it
[07:58] <ara> NCommander: congratulations on your MOTU!
[07:58] <NCommander> Yup :-)
[07:58]  * NCommander takes his head off to you
[08:11] <kirkland> pitti: awesome, thanks!
[09:03] <seb128> calc: why did you reassign this mimetype issue thing to nautilus?
[09:27] <t3rm1n4l> hi
[09:28] <t3rm1n4l> may i know who is loading kernel modules for ethernet card, graphic cards?
[09:28] <t3rm1n4l> is that udev?
[10:31] <kelemengabor> hi mvo, do you have some time for i18n bugs? :)
[10:31] <kelemengabor> for example bug #289798
[10:33] <mvo> kelemengabor: oh, right - sorry that I haven't worked on it earlier
[10:33] <kelemengabor> np
[10:33]  * mvo puts it on his list for today
[10:33] <kelemengabor> any hope that such changes can make it into intrepid? or only jaunty?
[10:34] <kelemengabor> thanks
[10:34] <mvo> kelemengabor: I think we could sru it, but from a first glance it looks like we might get a ways with regenerating the pot template and uploading into into rosetta
[10:35] <mvo> kelemengabor: what do you think?
[10:35] <kelemengabor> yeah, some 160 new strings showed up for me locally
[10:36] <kelemengabor> oops, life calls me, see you later
[12:22] <pitti> crimsun: is bug 282316 fixed in jaunty's alsa-plugins?
[13:11] <ScottK> pitti: On spamassiss, the dapper task needs to stay open.  The one that got accepted didn't actually apply the patch and there's another one in -proposed for testing.  I'll reopen the task.
[13:26] <pitti> ScottK: I thought that's what I did? dapper -> fixcommitted, dapper backports -> fixreleased?
[13:27] <pitti> ScottK: anyway, that's what I *intended* to do. If I broke them, I apologize
[13:27] <ScottK> pitti: On one bug.  On the other one you did dapper fix-released.  No trouble.  It's a confusing situation.
[13:27] <pitti> ScottK: thanks for double-checking
[14:13] <ScottK> pitti: (Still double checking spamassassin) were you going to do the backports for Gutsy/Hardy too?
[14:14] <pitti> ScottK: yes, backports and other archive stuff is still on my list
[14:14] <pitti> I still didn't finish with SRUs
[14:14] <pitti> (gosh...)
[14:14] <ScottK> pitti: OK.  No rush.  Just making sure (since it's a lot of pieces to push around on that package).
[15:56] <james_w> pitti: hi, I have a user that has an apparent problem with the sources.list entry added for their printer driver
[15:57] <james_w> pitti: apparently it is not the right case. It sounds like this is a problem with openprinting's database, but should it be filed on jockey?
[15:57] <pitti> james_w: yes, please file it on jockey for now, it should filter those out; I'll forward it to openprinting
[15:58] <james_w> thanks
[16:10] <mathiaz> pitti: when an SRU bug is marked for verification-needed, should the uploader do the verification or it'd better be someone else?
[16:10] <pitti> mathiaz: usually someone else, like QA team or bug reporter
[16:14] <persia> mathiaz, Note that if nobody steps up, asking for help in #ubuntu-bugs or #ubuntu-testing can help the process.
[16:34] <pitti> Riddell: can you please commit your cdbs change to bzr?
[16:34] <Riddell> pitti: oh doh, will do
[16:34] <pitti> Riddell: for 0.4.52ubuntu7 too, please; thanks!
[16:37] <Riddell> done
[16:44] <pitti> NEW -> 611 entries
[16:44] <pitti> yeah, must be post-release time ...
[16:45]  * jdong blames NCommander  :)
[16:45] <ScottK> Good thing Lenny freeze slowed things down.
[16:45] <ScottK> ;-)
[16:45] <pitti> well, credit where credit is due, most is Debian imports :)
[16:45] <pitti> (I *hope*)
[16:49] <thvdburgt> hi all, I would like to try to add emesene support to the fast-user-switch applet. Is there a bzr-branch for the code or is http://packages.ubuntu.com/source/intrepid/fast-user-switch-applet this the most recent code?
[16:52] <pitti> tedg: ^
[16:53] <thvdburgt> ah, I notices Ted is the maintainer, tedg can you help me?
[16:54] <tedg> thvdburgt: Sure.  I'm sorry, what is emesene?
[16:55] <thvdburgt> http://www.emesene.org/ It is an Instant messenger for the msn-network
[16:57] <tedg> thvdburgt: Ah, cool.  Probably the branch you want is this one: https://code.launchpad.net/~ted-gould/fast-user-switch-applet/show_status  (note, you can get all of them by looking here: http://code.launchpad.net/fast-user-switch-applet )
[16:57] <tedg> thvdburgt: You should only have to edit src/status-manager.c to add another set of functions for emesene.
[16:58] <thvdburgt> thank you tedg I'll give it a shot :)
[17:18] <aaroncampbell> How would I configure Gtk+ to allow "accelerator changes" ?  I'm running Kubuntu, but I guess Pidgin could use this?
[17:21] <little> Are there any developers in here who can answer a question about the linux-ubuntu-modules-2.6.24-21-generic update?
[17:28] <little> Is anybody in here who knows anything about the linux-ubuntu-modules-2.6.24-21-generic update?
[17:29] <seb128> if you were asking your question maybe somebody would reply
[17:30] <little> The description for the update says, "You likely do not want to install this package directly. Instead, install the linux-generic meta-package, which will ensure that upgrades work correctly, and that supporting packages are also installed.". Is this anything to worry about, or can I go ahead and update it?
[17:33] <tseliot> little: you can go ahead
[17:34] <little> tseliot: Any idea why there's a warning?
[17:35] <tseliot> little: because we want users to install the linux-generic metapackage so that when the kernel is updated you will automatically get  linux-ubuntu-modules for the new kernel
[17:36] <little> tseliot: I never messed with the kernel when installing Hardy Heron - I let it install whatever it wanted. (:
[17:37] <tseliot> little: if you install the package without the metapackage your linux-ubuntu-modules won't match the new kernel
[17:37] <cjwatson> then you should have linux-generic already installed
[17:37] <little> I'll check for both of those before I do the upgrade, then, thanks!
[17:37] <cjwatson> that isn't a warning primarily intended for upgraders - it's in the package description so that people installing the package from scratch know the intention
[17:38] <cjwatson> it happens that update-manager can be asked to display the description
[17:38] <cjwatson> but it's a description of the package rather than of this specific update, if you see what I mean
[17:39] <little> Ah, okay, that makes sense.
[17:39] <pitti> cjwatson: installation-report ended up on my merge list, since I did a small fix; shall I do it, or is it on your radar anyway?
[17:39] <cjwatson> pitti: either's fine with me; all of d-i is notionally on my list if nobody else does it
[17:39] <little> You guys might want to re-word those warnings, then. (:
[17:40] <cjwatson> linux-ubuntu-modules no longer exists in more recent releases than 8.04, so we probably won't put too much effort into its description TBH :-)
[17:40] <cjwatson> it got folded back into the main image
[17:40] <little> Ah well. (:
[17:40] <cjwatson> I think actually we should probably rethink how update-manager displays this stuff, rather than rewording the descriptions
[17:40] <cjwatson> it's not going to be a problem unique to linux-ubuntu-modules
[17:41] <cjwatson> bug 145764 is related
[17:43] <cjwatson> I've added a comment to that bug about this case
[17:44] <little> From a user's standpoint, many users will probably just grab the update, but those of us who read somthing like that will hesitate or not install it at all. If the update in question fixes a vulnerability or other significant issue, that might leave a lot of users without the update. (:
[17:44] <cjwatson> I agree that it is a confusing presentation, just debating how to fix it properly :-)
[17:44] <little> For the record, I'm using Kubuntu Hardy Heron, so this is in Adept Manager.
[17:44] <little> I'm not sure how it displays in Ubuntu.
[17:45]  * little is into documentation
[17:45] <cjwatson> ah. could you file a bug on adept about this, then? I don't see one there
[17:46] <little> Okay, will do.
[17:46] <cjwatson> thanks
[17:48] <little> Should it be a bug on warnings in descriptions in general?
[17:50] <cjwatson> no, I don't think so
[17:50] <cjwatson> the description wasn't intended to be displayed this way, so it's hardly surprising that it seems odd
[17:50] <cjwatson> the bug is in the presentation, not the content (which is designed for an entirely different use case)
[17:50] <cjwatson> I think we'd be fighting an uphill battle to make descriptions suitable, and that doing so would not buy very much
[17:52] <little> I don't know how those descriptions are created, but maybe instead of changing them, you could simply add a blanket comment beneath any that are like that to let people know that if this is an update for an existing package, the warning doesn't apply.
[17:53] <little> If that's something that could be done by running one command that would affect all similar packages, it might not be too hard to do. (:
[18:01] <cjwatson> little: I honestly don't think that would be appropriate
[18:01] <cjwatson> little: we shouldn't need to touch the descriptions at all for this - we should simply not present them as descriptions of the update
[18:01] <cjwatson> because they aren't
[18:02] <cjwatson> and no, it wouldn't be a matter of running a command, it would be a slow and tedious process of uploading lots of packages
[18:02] <cjwatson> which is one reason I think we should fix it in the right place rather than a workaround that's in fact harder work :-)
[18:04] <little> LOL! You poor things! Isn't there a team somewhere in Ubuntu that works on simplifying all that stuff? (:
[18:06] <cjwatson> we are indeed working on improved collaborative development
[18:06] <cjwatson> still wouldn't change the fact that the package descriptions are the *wrong place to change this* :-)
[18:06] <little> I mean the final database that holds all the information about all the packages. It would be awesome if that was in plain text and accessible so you could do blanket edits. (:
[18:07] <kees> cjwatson, slangasek, or others, I'm trying to understand what seems to be vagueness in the Debian Policy Manual regarding Depends.  Here are the two sections that are confusing me:
[18:07] <kees> http://www.debian.org/doc/debian-policy/ch-binary.html#s3.5
[18:07] <cjwatson> little: we don't want to maintain that as a central database, rather than considering the package the proper source of that information
[18:07] <kees> http://www.debian.org/doc/debian-policy/ch-relationships.html (7.2)
[18:08] <cjwatson> little: the database is built dynamically from the packages
[18:08] <cjwatson> this is actually much more maintainable in reality
[18:08] <kees> first says "Sometimes, a package requires another package to be installed and configured before it can be installed. In this case, you must specify a Pre-Depends entry for the package."
[18:08] <little> cjwatson: Ah, that makes sense.
[18:08] <kees> second says "A package will not be configured unless all of the packages listed in its Depends field have been correctly configured.'
[18:08] <slangasek> kees: the second use of "installed" there should be "unpacked"
[18:09] <kees> slangasek: ah-ha!
[18:09] <cjwatson> yeah, "installed" is dpkg internal jargon for "unpacked"
[18:09] <cjwatson> and hence policy is sometimes a bit confused about the wording here
[18:09] <Koon> ah-ha!
[18:10] <kees> okay, that resolves some confusion, but now it sounds like if I have  Depends: one, two   then one and two will run their postinsts before my own
[18:10] <cjwatson> yes, unless there is a dependency loop involved
[18:10]  * slangasek nods
[18:10] <Koon> cjwatson: in which case the loop is broken arbitrarily, right
[18:10] <kees> okay, I believe that's what we're fighting, then.
[18:10] <cjwatson> Koon: right
[18:11] <cjwatson> if you have a dependency loop you need to ensure that it works either way round
[18:15] <dx9s_work> still is an unusual question.. but where does one download the ubuntu maintained patches for the kernel source code? I know I can download the kernel source code already patched by ubuntu maintainers, but where do I get what the maintainers used to patch the kernel source in the first place?
[18:15] <cjwatson> the .diff.gz for the package contains the differences between our source and upstream
[18:16] <cjwatson> they were acquired from a number of sources; the easiest way to inspect them is probably by using revision control. http://wiki.ubuntu.com/KernelGitGuide
[18:17] <dx9s_work> sooo. I have to download the source for a package that is (in itself) already source code.. two levels of source getting ...
[18:18] <pwnguin> im pretty sure the kernel team uses git
[18:18] <pwnguin> so it's not quite that bad
[18:19] <dx9s_work> pwnguin, am I making sense.. I don't want the source code to the kernel.. I want the patches (diffs) the ubuntu team applies to that source code
[18:19] <pwnguin> thats what git keeps track of
[18:19] <pwnguin> they dont publish it seperately
[18:19] <cjwatson> that's what's in the .diff.gz file
[18:20] <cjwatson> I do not believe that it is shipped as part of the linux-source binary package, which seems to be what you're thinking of
[18:20] <cjwatson> linux-source isn't really intended for this purpose, as far as I know; for more sophisticated questions like yours you are better off ignoring linux-source and just fetching it from git
[18:20] <pwnguin> cjwatson: how does it figure out what the base tarball is?
[18:20] <dx9s_work> I understand that the ubuntu patches are outside the offical kernel source (been compiling kernels from kernel.org for years)
[18:21] <cjwatson> pwnguin: the developer doing the upload supplies it
[18:21] <dx9s_work> just trying to find the easiest way to get ubuntu's diffs on that source
[18:21] <cjwatson> I've now told you it twice
[18:21] <cjwatson> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.24-21.43.diff.gz for 8.04, http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.27-8.17.diff.gz for 8.10
[18:23] <dx9s_work> cjwatson, thanks
[18:24] <pwnguin> dx9s_work: there's 12 megs of diff there
[18:24] <persia> 8.17 is in -proposed.  8.10 is currently still 7-16.
[18:25] <cjwatson> .diff.gz tells you what the patches *are*; git will let you ask questions about how they break down in more detail
[18:25] <cjwatson> depends what you need to know
[18:25] <cjwatson> some people just care about the sum total of what we change
[18:25] <dx9s_work> is each diff dependent (aka not accumulative)? (hence the 12M comment from pwnguin )
[18:26] <pwnguin> "each diff"
[18:26] <pwnguin> it's just one diff
[18:26] <pwnguin> not patches
[18:26] <pwnguin> one patch
[18:26] <cjwatson> if you want to get separate patches, use git
[18:26] <cjwatson> each .diff.gz is the accumulated change from the base tarball to that Ubuntu revision
[18:27] <pwnguin> it should also contain things like how to build the .deb
[18:28] <dx9s_work> been doing the kernel .deb thing for a little while on a newer machine
[18:28] <dx9s_work> have that bookmarked on computer at home
[18:29] <pwnguin> what is your goal here? to rebuild your kernel based on the ubuntu kernel?
[18:29] <dx9s_work> using "fakeroot make-kpkg ..."
[18:29] <dx9s_work> no .. interested in trying a few different options
[18:29] <pwnguin> so rebuild... with a few different options
[18:31] <dx9s_work> I am about 1-2 years into ubuntu (former slackware guy, and the slack-build process is different and simplier -- no dependency checking) .. just trying to do something and figured instead of brute force compiling a kernel/installing (was installing kernel outside .deb for the first year BTW).. should review the whole process ... it's 1 part learning and 1 part I am interesting in custom tweaked rt kernel
[18:32] <pwnguin> in my opinion, the first thing you should learn about the kernel is git
[18:33] <dx9s_work> I've used git a little bit in the past... and before git was even a tool written to help maintain the kernel source
[18:34] <dx9s_work> aka I'm not new to compiling the kernel... I'm new to ubuntu's way .. and still have some to learn about git ...
[18:34] <pwnguin> ubuntu's way is subject to stupidity, improvements and change ;)
[18:34] <pwnguin> git however, is probably going to be a bit more stable
[18:34] <dx9s_work> too many cooks in the kitchen?
[18:35] <pwnguin> i dont think so.
[18:35] <pwnguin> maybe even too few
[18:35] <pwnguin> anyways, i gotta bolt for work
[18:36] <dx9s_work> thanks
[18:41] <dx9s_work> who comes up with this names ... "Trembling Tortoise" .. heheh
[18:41] <little> cjwatson: I filed the bug. I hope I worded it well: https://bugs.launchpad.net/ubuntu/+source/adept/+bug/295277
[18:53] <persia> dx9s_work, If you're interested in the -rt kernel, you might want to also take a look at the linux-rt source package.
[18:53]  * dx9s_work understood
[18:53] <dx9s_work> persia, understood
[18:58] <dx9s_work> persia, that rt kernel is not *perfect* hence this WHOLE line of questioning in the first place
[18:59] <cjwatson> little: thanks; I have added some clarification
[19:00] <persia> dx9s_work, In fact it has several bugs, for which fixes would be appreciated.  It's the combination of the things in git or in the linux source with the patches in the linux-rt source that are your best bet for -rt though.
[19:00] <dx9s_work> persia, are the patches that the -rt patches use in the same git source?
[19:05] <persia> dx9s_work, No.  Those are in the linux-rt package.
[19:05] <persia> upstream -rt is in quilt, and linux-rt uses quilt to apply those (and some integration bits) to the linux-source binary package produced from the linux source, which is in git.
[19:09] <dx9s_work> I don't know what quilt is .. I know of http://rt.wiki.kernel.org/
[19:13] <cjwatson> kees: I've filed a debian-policy bug for the text to be disambiguated
[19:14] <cjwatson> dx9s_work: apt-cache show quilt
[19:17] <dx9s_work> ah
[19:18] <little> cjwatson: Thanks - well done! I didn't want to put in any explanations since bug reports generally don't want us (the general user) venturing guesses. (:
[19:23] <kees> cjwatson: oh! thanks
[19:23] <thvdburgt> tedg, how can I easily test my newly compiled version of the applet?
[19:24] <thvdburgt> I see the "old" version is in /usr/lib/fast-user-.../ how can I get the panel t pick up my version?
[19:24] <tedg> thvdburgt: killall fast-user-switch-applet then a dialog will come up to reload.  Run yours, it'll sit there a second, then hit reload.
[21:06] <little> Hey there, should users of the 64 bit release of Kubuntu Intrepid Ibex have this file: linux-kernel-devel ?
[21:15] <dharanpdeepak> any one here to help me ?
[21:16] <dharanpdeepak> i wish to start contributing to ubuntu
[21:16] <dharanpdeepak> but i don't know where to start
[21:16] <dharanpdeepak> ???
[21:16] <dharanpdeepak> helloo ?
[21:16] <dharanpdeepak> anyone in there ???
[21:18] <little> dharanpdeepak: How would you like to contribute?
[21:19] <little> dharanpdeepak: This is a good place to start: https://wiki.ubuntu.com/Teams?action=show&redirect=TheUbuntuCommunity
[21:33] <cjwatson> little: linux-kernel-devel was removed in 8.10
[21:33] <cjwatson> regardless of architecture
[21:33] <RainCT> mvo_: Hi. Yesterday I looked at that method to only retrive the diff of Sources files which can be used in Debian experimental and in a comment on the BTS you stated that it doesn't work for Ubuntu. Could you explain why please?
[21:33] <cjwatson> little: you may still have it installed if you installed it manually on 8.04
[21:33] <cjwatson> (and then upgraded)
[21:34] <cjwatson> Depends: build-essential, curl, debhelper, git-core, gitk, kernel-package, kernel-wedge, openssh-client, rsync
[21:34] <little> cjwatson: Uh oh. There is a user following my instructions for installing the NVIDIA driver and he can't find the file. Does he simply not need it? My instructions (the one in question) are here: http://littlergirl.googlepages.com/NvidiaDriverHowTo.html#step04
[21:34] <cjwatson> is all it contained so you could just install that stuff manually
[21:34] <cjwatson> and some of that was just for committing to the kernel anyway
[21:35] <little> Can he just ignore that part of that step?
[21:35] <cjwatson> looking at your page,  build-essential debhelper kernel-package kernel-wedge  would probably be sufficient
[21:35] <little> Did you catch that, thomas?
[21:35] <cjwatson> (to replace linux-kernel-devel)
[21:36] <cjwatson> and if you mention build-essential then you can remove gcc and make, as well
[21:36] <cjwatson> or rather you don't need to list those explicitly
[21:37] <thomas_> I caught it but I dont understand it.. lol
[21:37] <cjwatson> thomas_: instead of "linux-kernel-devel", pretend that that page says "build-essential debhelper kernel-package kernel-wedge"
[21:38] <little> So Intrepid users need build-essentials, debhelper, kernel-package, kernel-wedge, pkg-config, xserver-xorg-dev, linux-source-2.6.24, linux-headers-2.6.24-19 and linux-headers-2.6.24-19-generic, right?
[21:38] <thomas_> oh... haha alright
[21:38] <little> And everyone else needs what I have listed minus gcc and make and with build-essentials instead, right?
[21:38] <cjwatson> little: for intrepid, it shouldn't be 2.6.24(-19) - replace with appropriate versions
[21:38] <cjwatson> the substitutions I gave are good for 8.04 too
[21:38] <little> cjwatson: Yeah, I'll update it with the latest kernel.
[21:39] <little> thomas: I'll paste a list for you in pastebin.
[21:39] <thomas_> alright
[21:40] <little> thomas, what do you get when you type this in a terminal window: uname -r
[21:40] <thomas_> 2.6.27-7-generic
[21:41] <little> These are the packages you must have installed: http://paste.ubuntu.com/69012/
[21:41] <little> Is that right, cjwatson?
[21:42]  * little doesn't want to steer thomas wrong.
[21:42] <thomas_> alright, they are installing
[21:48] <cjwatson> little: looks fine except you wrote "build-essentials" instead of "build-essential"
[21:49] <little> Ouch, thanks, I'll fix it and tell thomas.
[21:53] <crimsun> pitti: yes, 282316 is fixed in jaunty's alsa-plugins
[21:55] <thomas_> cjwatson: when I try installing the display drivers as little suggests it gives me an error saying something like unable to find the source tree for the currently running kernel
[21:55] <thomas_> then it says something about kernel-devel
[21:55] <little> Maybe my instructions won't work in Intrepid?
[22:00] <cjwatson> thomas_: at this point I suggest the two of you should take this to a different channel
[22:00] <cjwatson> this isn't really a discussion about development of Ubuntu as such
[22:01] <cjwatson> plus I don't know any further answers here :-)
[22:02] <thomas_> alright thanks
[22:58] <mvo_> RainCT: pdiff in debian can be used because debian re-generates the packages file only twice a day
[22:58] <mvo_> (used to be once a day only)
[22:58] <mvo_> RainCT: we used to do it every 1h (not sure how often we do it now) - so it does not scale well for us as its one individual file per change
[22:59] <mvo_> RainCT: the other thing is that its most interessting for unstable, the stable Packages file does not change, only -updates -security etc but they are much smaller than the full packages file
[23:00] <mvo_> RainCT: I'm off to bed now, but I'm happy to talk about this in more detail if you are interessted
[23:00] <RainCT> mvo_: what about implementing some fallback? like keeping one week of files and for people who haven't update since over a week apt would just download everything like it does normally
[23:01] <RainCT> mvo_: I am :). When should I best ping you to talk about it? (Or will you ping me? :))
[23:02] <mvo_> RainCT: I'm here all week usually during european daytime hours :)
[23:02] <mvo_> RainCT: (and a bit more usually)
[23:02] <mvo_> RainCT: the support in apt is available, we just need something that puts the diff on the server and we are ready
[23:04] <RainCT> mvo_: "something to put the diff on the server"? How is it working on Debian if this isn't done?
[23:05] <RainCT> (we can continue tomorrow if you want to leave :))
[23:07] <mvo_> RainCT: essentially its as simple as "diff -e Packages.old Packages.new; md5sum Packages.new >> DiffIndex" (well, slightly more, but not a lot really)
[23:07] <mvo_> RainCT: it would need support from the soyuz infrastrucure
[23:08] <mvo_> RainCT: https://bugs.edge.launchpad.net/soyuz/+bug/214612
[23:08] <RainCT> Ah, so there's nothing we (ie, the community) can do?
[23:09] <RainCT> @ mvo_
[23:09] <mvo_> RainCT: not sure, I can ask the soyuz people for their opinion - but I think its less interessting for ubuntu really because of the massive churn we do
[23:09] <mvo_> or at least we would/should try to make it better
[23:12] <mvo_> RainCT: in the meantime a "me too" comment n the bug is probably the right answer
[23:14] <mvo_> RainCT: happy to talk about it later, need to get some rest now :)
[23:18] <wgrant> pitti: Around?
[23:20] <wgrant> Hmm, I'd guess not. I can't count.
[23:21] <RainCT> wgrant: he's away - "off for the weekend"
[23:21] <wgrant> Blah. Unfortunate.
[23:26] <LaserJock> persia: ok, so here's what I'm trying to accomplish
[23:26]  * persia notes that the publisher still tries to run roughly every hour
[23:26] <LaserJock> I have 1, and perhaps more, people who would like to help maintain some Edubuntu packages
[23:26] <LaserJock> I'm trying to figure out the best way to set that up so we can collaborate via VCS and still keep it sane
[23:27] <LaserJock> it was suggested that I create a edubuntu-packaging LP team and throw branches in there
[23:27] <superm1> yeah
[23:27] <persia> OK, so you do have the use case where you want many people to collaborate on uploads, but not have frequent uploads (because they can't all upload those packages).
[23:27] <superm1> just make sure that they never actually put the distro in the changelog entry until it gets uploaded
[23:28] <persia> ArchiveReorganisation would help, but in the short term, having packaging in VCS makes it easier.
[23:28] <superm1> so most people should leave it as UNRELEASED, and then whoever has rights and does upload it makes that one change
[23:28] <LaserJock> a few of the packages do have vcs-imports so I have access to upstream code
[23:28] <LaserJock> but I'm wondering if it's easier to just put debian/ in VCS
[23:28] <persia> And all the packages have Debian packaging, but none of that is VCS, right?
[23:28] <LaserJock> hmm, most that I'm particularly interested in don't
[23:29] <LaserJock> there might be a few that do
[23:29] <persia> In that case, I'd recommend just putting debian/ in VCS for now.  Proper VCS packaging is lots easier than just debian/ in VCS, but the infrastructure isn't all there if you can't get a vcs-imports feed from Debian.
[23:30] <LaserJock> right
[23:30] <persia> So you'd do a commit for each change, including merges with Debian.
[23:31] <persia> When something is in sync, just shove the debdiff as a commit when autosync publishes to keep things sane.
[23:32] <LaserJock> yeah, none of the packages are really active in Debian, such that it would be very difficult to keep up
[23:33] <persia> From what I understand of future infrastructure, there should be generated branches of Debian upload history and Ubuntu upload history from which you can derive, which would allow for proper VCS packaging, but trying to replicate that manually is just going to be painful.
[23:33] <LaserJock> ok, sounds reasonable
[23:33] <LaserJock> does creating a packaging team seem decent?
[23:34] <persia> (and possibly generated branches from Debian VCS history, but that's only gravy)
[23:34] <LaserJock> I'm not sure if other projects are doing that
[23:35] <persia> On the strength of ArchiveReorgansiation alone, I'd advocate the creation of an Edubuntu-dev group.  If you end up with too many people in it, you can always create an Edubuntu-core-dev group, where -dev can commit to branches, and core-dev upload if you need.
[23:36] <persia> Personally, I'd recommend that people first interested be expected to submit some patches (perhaps preparing candidate branches for merging) first, and only after showing a history of good contributions be added to edubuntu-dev.
[23:36] <LaserJock> persia: heh, we have over 20 Edubuntu LP teams but no -dev
[23:36] <persia> Yeah.  You went crazy on teams a couple years ago :)
[23:37] <LaserJock> is there any decent ETA on ArchiveReorganisation ?
[23:39] <persia> None I've seen announced.  At one point a member of the TB suggested it would happen for Jaunty, but Jaunty opened.  I'm currently choosing to interpret that remark as "During the Jaunty cycle".
[23:40] <cjwatson> it's on my list but no ETA yet
[23:41] <cjwatson> there's a dependency on the Soyuz development roadmap which was given a high priority but I don't have an ETA on *that*
[23:42] <persia> cjwatson, On your list for implementation, or for more spec documentation?  What needs doing beyond Soyuz, process coordination, and TB confirmation of delegated groups?
[23:45] <cjwatson> persia: mostly implementation, although still need to sort out how apt and mirroring utilities are going to play with it
[23:47] <persia> Well, the quick & dirty way is to just semantically redefine "main", but that's probably not enough to preserve ogre-model style restrictions.
[23:48] <cjwatson> ogre-model is exactly the concern


[06:07] <MaxEd> Hello. Is there any documentation about X-Ubunti-* fields in .desktop file beyond Splash screen guide? I wonder how many are there :) Also, is there any documentation for inapp APIs? They seem straightforward enough from headers, but a tutorial would be nice anyway.
[08:03] <liuxg> does anyone know why I cannot find "Desktop kit" in my SDK installation? I can only find "Ubuntu SDK Desktop　Kit"
[08:16] <ahayzen> liuxg, IIRC i ended up creating my manually
[08:16] <liuxg> ahayzen, how did you create it?
[08:16] <liuxg> ahayzen, if we do it at the instruction at https://developer.ubuntu.com/en/blog/2015/11/19/here-comes-brand-new-ubuntu-sdk-ide-tools/, the Desktop Kit is not there at all.
[08:17] <ahayzen> liuxg, Tools->Options->Build and run->Kits
[08:17] <ahayzen> it is *supposed* to be there, just sometimes isn't for whatever reason :')
[08:18] <ahayzen> liuxg, then if you add something like this https://drive.google.com/file/d/0B3XynHVKfrvMNmhmbHdmdEMxY1k/view?usp=sharing it should work
[08:20] <liuxg> ahayzen, OK. thanks. Let me try. I am not sure whether this is a bug for the SDK or not.
[08:20] <ahayzen> probably is, i'd speak with the SDK folks to check though, i've heard a few people have this issue
[08:22] <liuxg> ahayzen, yes, you are right. I finally got the Desktop kit there. thanks
[08:22] <ahayzen> liuxg, \o/ no problem
[08:23] <liuxg> ahayzen, I think this should be a bug, very annoying!
[08:23] <ahayzen> liuxg, yeah you should see if there is an existing one for it
[08:23] <ahayzen> can't spot one here https://bugs.launchpad.net/ubuntu/+source/ubuntu-sdk-ide/ ... but not sure which project it would be
[08:25] <liuxg> ahayzen, when I run a ubuntu app for desktop kit, I get the warning like file:///usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/1.3/MainView.qml:153:9: QML AppHeader: Warning: Style PageHeadStyle.qml not found in theme Ubuntu.Components.Themes.Ambiance
[08:25] <liuxg> ahayzen, do I need to install anything extra to get rid of the warnings?
[08:26] <ahayzen> liuxg, probably because you are on a old version of Ubuntu? therefore your 'desktop' has an older UITK
[08:26] <ahayzen> hence you the Ubuntu SDK Kit, which gives you the latest stuff
[08:26] <liuxg> ahayzen, no, I have removed everything, and installed the brand-new SDK.
[08:27] <ahayzen> but which version of Ubuntu are you on? Unless you are on Xenial then I don't think the desktop will give you the latest UITK, so you use the 'Ubuntu SDK Kit' for that
[08:27] <liuxg> ahayzen, for Desktop kit, it does not use the installations from the "Ubuntu SDK Desktop Kit" in which a specified Qt version is installed.
[08:28] <liuxg> ahayzen, I am now on Wily.
[08:28] <ahayzen> yeah i'm on Wily as well
[08:28] <ahayzen> use the 'Ubuntu SDK Kit' if you can
[08:28] <ahayzen> that'll give you the later stuff
[08:28] <liuxg> ahayzen, for the "Ubuntu SDK desktop Kit" everything is fine.
[08:30] <liuxg> ahayzen, I know, the problem is that the "Ubuntu SDK Desktop" has a lot of missing libraries.
[08:30] <ahayzen> yeah that is a problem i have :-/
[08:30] <liuxg> ahayzen, I have reported a bug at https://bugs.launchpad.net/canonical-developer-experience/+bug/1562724
[08:31] <ahayzen> basically impossible to run the music-app on a Wily desktop at the moment... :')
[08:31] <liuxg> ahayzen, also, I cannot event get a scope template running due to the bug https://bugs.launchpad.net/canonical-developer-experience/+bug/1562684
[08:32] <ahayzen> heh
[08:32] <liuxg> ahayzen, would you please help to confirm the bug if you have not reported it?
[08:32] <ahayzen> that is surely linked to the previous bug?
[08:32] <liuxg> ahayzen, yeah, it is found during the scope development :) so, I am trying to run the scope on desktop.
[08:33] <ahayzen> looking at those bugs, they are all linked to not being able to install packages in the sdk kit
[08:33] <ahayzen> we need the lxd solution *now* :-)
[08:34] <ahayzen> popey, who do we complain at for such issues ^^ with the SDK ? and any idea which packages/projects they go against?
[08:34] <liuxg> ahayzen, SDK is supposed to work with all of the ubuntu releases. lxd is a workaround solution. we need to push the get the bug fixed for developers.
[08:37] <ahayzen> lxd will help us a lot from what I understood of how the next-next-gen sdk might work, read 'Development tools and IDE' in this blog post https://developer.ubuntu.com/en/blog/2016/03/16/planning-the-sdk-16-10/
[09:56] <popey> ahayzen: bzoltan ultimately
[09:56] <ahayzen> ok thanks :-)
[14:09] <kenvandine> popey, my branches for music-app, clock-app and filemanager have all been merged but the bug status isn't fix released yet.  is that because clicks haven't been uploaded?
[14:11] <ahayzen> kenvandine, we usually leave them as fix committed until a click is released to the store, so yes. And i know that the music-app hasn't had a click released recently
[14:12] <kenvandine> ahayzen, cool, just checking
[23:33] <matv1> I got some translations back for my app but I'm having a hard time figuring out where to stick these .po files
[23:34] <matv1> anyone?


[02:48] <cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/team-mail/+merge/269382 could use another look; as well as the obvious changes to fix your review comments, I converted it to use async jobs to make sure that there are no security proxy problems with this branch.  (Might be easiest to look at just r17707.)
[02:49] <cjwatson> And now to bed.
[02:49] <wgrant> cjwatson: Thanks, those X-L-N-Ts make a tonne more sense now.
[02:49] <wgrant> Night.
[02:50] <cjwatson> PersonTransferJob is kind of a weird home for this, but it already had membership status change notifications ...
[02:50] <wgrant> Yep
[11:33] <cjwatson> wgrant: Was there a particular reason you preferred ArchiveJob over DistributionJob for package upload mail?  AFAIK neither is really very relevant - the values saved for the job would be PackageUpload.id, PackageUploadStatus, and summary_text
[11:33] <cjwatson> So it's maybe more modern-feeling but I'm not seeing how it would actually matter, either would be just for expediency
[13:51] <cjwatson> I guess it sort of categorises them, and it's as good as anything.
[23:09] <wgrant> cjwatson: I simply have a great distaste for anything Soyuz-related talking about distributions when the thing is in fact about an archive.
[23:09] <wgrant> See silly things like Distribution.getPublishedSources


[10:42] <andrewebdev> I'm hoping it's ok to post here. I'm trying to set up core on my rpi3 for some prototyping. During the configuration where I have to set up my account details, I get a error: error: while creating user: cannot create user
[10:43] <andrewebdev> the error immediately below that is: Get https://login.ubuntu.com/api/v2/keys/<redacted>: x509: certificate has expired or is not yet valid
[10:52] <andrewebdev> hmm, ok never mind that then. The installation finished fine even with that error. Strange
[12:14] <JamesB192> andrewebdev: is/was the clock thinking it is 1970 all over again?