[06:51] <MooDoo> howdy all
[09:03] <brobostigon> morning boys and girls.
[09:09] <zmoylan-samj3> morning mammals
[09:12] <foobarry> noticed an annoying feature with ff57
[09:12] <leecowdrey> just one ;) ?
[09:12] <foobarry> my github tabs all say " You signed out in another tab or window. Reload to refresh your session"
[09:12] <foobarry> on a status bar at the top
[09:13] <leecowdrey> oooh so no connection re-use then....
[09:13] <foobarry> its our github enterprise so many a bug in GHE
[09:13] <foobarry> maybe#
[09:35] <daftykins> i've heard someone complain about third party cookies / tracking protection causing drama too - may be worth a look
[10:42] <adambialy> rosiak: no they stays "down" pooling graph spiking and then silence...
[10:43] <daftykins> wrong channel?
[10:44] <zmoylan-samj3> it's code. it means red fox has met grey squirrel :-)
[10:45] <daftykins> ah haaar
[10:46] <daftykins> zmoylan-samj3: A-frame roof beam has had its' resin poured this morning \o/
[10:47] <zmoylan-samj3> and no amish were harmed in the process \o/
[10:47] <daftykins> only if that barn over there holds... *squints to the horizon*
[10:48]  * zmoylan-samj3 chews on grass stalk and mutters 'yarr'
[10:49] <daftykins> still have to call the carpentry place about the splits in the wood of one of the new windows :(
[10:50] <zmoylan-samj3> wooden framed windows? quaint
[10:50] <daftykins> yeah, 16th/17th century listed property so mandatory
[10:52] <zmoylan-samj3> didn't they have window tax back then? brick it up. slap 50' tv o wall inside connected to cam outside. authentic-ish :-)
[10:53] <daftykins> XD
[10:54] <zmoylan-samj3> 1696. just barely https://en.m.wikipedia.org/wiki/Window_tax
[11:00] <daftykins> ah you must be a devil in pub quizzes
[11:08] <zmoylan-samj3> never been in one. was my bosses phone a friend on who wants to be a millionaire
[11:08] <zmoylan-samj3> but he used that option for someone else for a sports answer
[11:10] <zmoylan-samj3> he asked me a question the next day and i knew the answer. would have gotten him to next round
[11:10] <zmoylan-samj3> right time for quick limp...
[11:17] <daftykins> :D
[11:48] <foobarry> what the heck is wrong with google play music? so expensive
[12:51] <diplo> Just got Amazon music for 99p for 3 months :)
[12:51] <diplo> unlimited that is
[12:52] <foobarry> tried to buy a lightning deal yesterday
[12:52] <foobarry> they wanted £4 postage.
[12:52] <foobarry> removed from basket
[13:35] <zmoylan-pixi> now some amazon picker has to take it from basket and put it back on shelf... :-P
[13:36] <daftykins> and if they don't do it within the alotted time, a siren will sound and their shock collar will charge up!
[13:37] <zmoylan-pixi> shock collars per picker is expensive, one robot to shock them all...
[13:37] <daftykins> now that's thinking like Bezos
[13:40] <zmoylan-pixi> watching it hum past seeking it's next target is motivating
[13:42] <daftykins> and here it is in action, chasing those pickers - https://gfycat.com/teemingtalkativehammerkop
[13:55] <zmoylan-pixi> and it positively will not stop until you cast ward stupid programmer...  https://nerdist.com/trap-a-self-driving-car/
[15:14] <diddledan> fun: https://www.wordfence.com/blog/2017/11/wordpress-plugin-banned-crypto-mining/
[15:33] <m0nkey_> Just create a firewall rule to block said known crypto miners
[15:34] <m0nkey_> btw, i got a new domain yesterday
[15:53] <daftykins> m0nkey_: is it amusing?
[16:05] <m0nkey_> heh, no.
[16:06] <m0nkey_> just wasn't expecting it to be available


[20:01] <stgraber> soren: ping
[20:01] <soren> o/
[20:01] <soren> #startmeeting Technical Board
[20:01] <meetingology> Meeting started Mon Apr  1 20:01:44 2013 UTC.  The chair is soren. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[20:01] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[20:01] <soren> Sorry I
[20:01] <stgraber> hi soren!
[20:01] <soren> m late. Massive technology fail at my house right now.
[20:02] <soren> One internet connection, luckily I had backup.
[20:02] <soren> Bluetooth keyboard dead.
[20:02] <soren> Luckily, I have a backup.
[20:02] <soren> There's a pattern there somewhere.
[20:02] <soren> Anyway.
[20:02] <stgraber> well, let's hope it won't get any worse during the meeting then ;)
[20:02] <soren> Welcome.
[20:02] <soren> cjwatson, mdz, kees: ?
[20:03] <stgraber> looks like pitti is off IRC today
[20:03] <soren> Yeah.
[20:03] <soren> Sorry, don't have all my bookmarks on this backup laptop, so digging around a bit.
[20:04] <soren> #topic Action review
[20:04] <soren> wait for it..
[20:05] <soren> I don't see any action items in the minutes?
[20:05] <soren> Moving on.
[20:05] <soren> #topic MRE for Xserver
[20:06] <soren> Who's representing?
[20:06] <ScottK> soren: Review of Mark's release reorg proposal didn't get finished last time.
[20:06] <soren> ScottK: Alright, let's talk about that next.
[20:07] <soren> Just pinged bryce in #ubuntu-devel.
[20:07] <soren> I guess we can talk about the missing points from Mark's proposal until Bryce turns up.
[20:07] <soren> Oh.
[20:07] <soren> bryce: Hi :)
[20:07] <bryce> was just wondering about this
[20:07] <bryce> hi soren
[20:08] <soren> bryce: So we were just starting on this topic now.
[20:09] <mdz> soren, here
[20:09] <soren> https://lists.ubuntu.com/archives/technical-board/2013-March/001559.html
[20:09] <soren> #link https://lists.ubuntu.com/archives/technical-board/2013-March/001559.html
[20:09] <soren> Has everyone had a chance to read it?
[20:10] <soren> I've read it, but I must say I feel limimited by my ignorance of how all these things fit together.
[20:10] <bryce> soren, happy to answer questions
[20:10] <soren> Does anyone feel sufficiently informed to be able to ask intelligent questions? :)
[20:10] <stgraber> I just did and I personally think it's entirely reasonable
[20:11] <stgraber> bryce: do I remember correctly that you also run some kind of tests against the cert lab?
[20:12] <bryce> we've been doing SRUs of xserver patches for years, and have found the upstream microreleases themselves to be well done now (better than some years ago).  The one reason we hadn't requested MRE in the past was due to lack of test frameworks, but over the last couple years that's been fixed.
[20:12] <bryce> stgraber, not me personally.  there are tests that could be run, but don't know if the cert lab runs them.
[20:13] <bryce> stgraber, we do run the tests locally on our own hardware though.
[20:13] <stgraber> bryce: ah, that may have been that. I remember that for mesa at least you said you'd pretty good coverage of the various vendors to do hardware testing before actually pushing an SRU
[20:14] <bryce> yep
[20:15] <soren> I'm not entirely sure I understand the scope of this request.
[20:15] <bryce> and our proposal is to handle the xserver testing the same way as we're doing with mesa, since that process seems to be working out quite well
[20:15] <soren> The title says "xserver", but is it really all the various xserver-xorg-video-* drivers, too?
[20:15] <stgraber> bryce: do you have a list of source packages that'd be covered by that MRE?
[20:15] <bryce> soren, no just the xorg-server package
[20:16] <soren> Hm. Ok.
[20:16] <bryce> stgraber, this is only for one source package - 'xorg-server'
[20:16] <stgraber> k
[20:16] <soren> I'm a bit puzzled.
[20:16] <bryce> since it's just micro releases, those are just bug fixes so never any impacts on any other source packages.
[20:16] <soren> So these aren't drivers at all.
[20:16] <bryce> nope, just the server
[20:17] <soren> Ok.
[20:17] <soren> Well, in that case: Sure, no problem at all.
[20:17] <bryce> frankly the X drivers don't really have much "interesting" code left in them.  We rarely SRU X driver fixes any more.
[20:18] <bryce> the "interesting" driver code is now included in the kernel, so those fixes are already taken care of by the normal kernel processes
[20:18] <soren> Are those things mostly in the kernel, then?
[20:18] <soren> Or this "mesa" thing that everyone talks about?
[20:18] <soren> :)
[20:19] <bryce> ah, tldr version is, there's really 3 drivers for graphics - one in the kernel (drm kms), one in mesa (the 3D stuff), and one in X (the 2D 'DRI' drivers)
[20:19] <bryce> these days it's the 3D drivers and kernel drivers where all the interesting bugs are.  The 2D X bits tend to be fairly boring and stable.
[20:20] <soren> I see.
[20:20] <soren> Cool, thanks for clarifying.
[20:20] <soren> Well, that clears up all my concerns, really.
[20:20] <soren> If it
[20:20] <soren> 's just xserver itself, I'm cool with it.
[20:20] <soren> Anyone else?
[20:21] <stgraber> I'm perfectly fine with the current proposal
[20:21] <stgraber> mdz, cjwatson, kees: ^
[20:21] <mdz> sounds more than reasonable
[20:21] <soren> I'll give them a minute to weigh in.
[20:22] <soren> Alright, sold.
[20:22] <soren> Does anyone want to do the honours of updating the wiki?
[20:22] <soren> Otherwise I'll do it as part of doing the minutes.
[20:23] <soren> bryce: Thanks for your time!
[20:23] <bryce> soren, thank you!  :-)
[20:23] <soren> #topic PArts of Mark's proposal that were missed in the last meeting
[20:23] <mdz> soren, I'lldo it
[20:23] <soren> ScottK: Care to elaborate.
[20:23] <soren> mdz: Thanks very much!
[20:24] <ScottK> We covered support period for regular releases.
[20:24] <ScottK> We covered terminology (regular/LTS)
[20:24] <mdz> soren, oh, hmm, it ought to have a link to the minutes in there, so it's probably better if you do it after you've posted them
[20:24] <soren> mdz: Ah, good point.
[20:24] <soren> mdz: Thanks for trying :)
[20:25] <stgraber> ScottK: and we covered the "devel" symlink to current dev release too
[20:25] <ScottK> Yes.
[20:25] <ScottK> Still typing.
[20:25]  * stgraber waits
[20:25] <ScottK> We also considered the discussion about kernel updates as ~ what we do now.
[20:25] <ScottK> I think there was informal consensus that the rapid moving stuff he refers to should either be done through backports if appropriate ofr PPAs.
[20:26] <ScottK> No new "rules" needed.
[20:26] <ScottK> I think the significant point of action that remained was on the point about updates to libraries in an LTS if the API is "stable"
[20:26] <ScottK> err
[20:26] <ScottK> required upgrades to newer versions of platform components,  ...
[20:26] <ScottK> That's how it starts.
[20:27] <ScottK> I think that's the one point remaining that would require a policy change to execute.
[20:27] <soren> do you happen to have a link handy to the entire thing?
[20:28] <ScottK> Sure
[20:28] <ScottK> https://lists.ubuntu.com/archives/technical-board/2013-March/001527.html
[20:28] <soren> #link https://lists.ubuntu.com/archives/technical-board/2013-March/001527.html
[20:29] <mdz> yes, I believe we covered #2 and #3 and did not start on #1
[20:29] <mdz> (in the previous meeting)
[20:29] <stgraber> so on principle I'm not completely opposed to the proposal of updating to newer versions of core components provided they don't change API or the way user interact with those, for example changing a command line tool and causing options to get renammed/removed/changed isn't acceptable to me
[20:29] <soren> ScottK: Thanks for the introduction to the topic.
[20:30] <mdz> as ScottK says, it seems like the first point under #1 doesn't require a policy change
[20:30] <ScottK> We did discuss this in Kubuntu and came to this position: https://lists.ubuntu.com/archives/technical-board/2013-March/001553.html
[20:30] <stgraber> and I personally think that the Unity example in the e-mail is a rather bad one as at least for me Unity isn't associated with stable API and no change visible to the user ;)
[20:30] <mdz> stgraber, I agree in principle, though I'd be a bit concerned about the practicality of auditing interfaces
[20:30] <soren> #link https://lists.ubuntu.com/archives/technical-board/2013-March/001553.html
[20:31] <ScottK> I am particularly concerned about this point since base on our experience with Qt4 in Kubuntu, we are pretty dead certain that post-release updates to Qt (4 or 5) are a REALLY bad idea.
[20:31] <soren> Auditing interfaces as well as defining which interfaces are considered "key".
[20:32] <ScottK> It's not just the interfaces that need to be stable.  It's the behavior behind the interfaces.
[20:32] <mdz> that's part of the interface, as I'm using the term
[20:32] <ScottK> Updating core components seems to me to be approximately the oppposite of what one would want to in an LTS.
[20:32] <ScottK> After all, people use LTS instead of the regular release because they want stability and consistency.
[20:33] <soren> Well, sort of.
[20:33] <stgraber> I also have the feeling that allowing this and having the SRU team do the very close auditing required by such things would in practice be more time consuming than cherry-picking the fixes and getting explicit approval for absolutely required API additions
[20:34] <soren> It's not uncommon to have LTS users ask for new versions of things. They expect it to t be longlived more than strictly consistent.
[20:34] <soren> We've traditionally considered this view to be ultimately incoherent.
[20:35] <soren> But it's certainly not an uncommon view, there is /some/ divergence in what people expect of an LTS.
[20:35] <ScottK> soren: Right.  They often want the thing they want to be new and everything else to be stable.
[20:35] <soren> ScottK: Spot on.
[20:35] <stgraber> right, wanting LTS and wanting the latest version of the system doesn't quite work ;) leaf packages can be backported and we should try and encourage that. For specific self-contained stacks, PPAs also work rather well, but getting newer versions of core/heavily-shared components is very risky business
[20:36] <soren> Indeed.
[20:37] <soren> I wonder if there would be a useful way to grant an extended MRE for certain things.
[20:37] <soren> Like unity as in Mark's example.
[20:37] <soren> "Extended MRE" == and MRE that isn't limited to micro releases.
[20:37] <ScottK> In Kubuntu we generally backport KDE major releases to previous releases in a PPA.  It's quite popular, but it also frequently comes with regressions.
[20:38]  * ScottK would never do it in the Ubuntu archive.
[20:38] <ScottK> soren: Such an exception exists for clamav, so it's been done before.
[20:38] <ScottK> That is a pretty unusual case though.
[20:38] <soren> When applying for such an exception, the APIs would need to be specified in the request.
[20:39] <soren> And ideally some sort of external API test suite should be provided that would help us verify that the API indeed doesn't change.
[20:39] <ScottK> The clamav one was more about regression testing to validate consistency of behavior.
[20:40] <soren> ScottK: clamav was special in many ways. The exception was granted not because of someone's desire for newer, cooler stuff, but simply out of necessity since new databases woudln't work with older clamavs.
[20:40] <ScottK> Agreed.
[20:40] <soren> So while the technicalities might be related, the motivation was entirely different.
[20:41] <ScottK> Some exceptions you grant because upstream is sane.  Sometimes it's the opposite.
[20:41] <soren> *g*
[20:42] <soren> I feel that this is something that we must consider on a case-by-case basis at the TB level.
[20:42] <soren> Perhaps Unity would be a good guinea pig (if we're willing to entertain the concept at all).
[20:43] <soren> Does anyone feel qualified and motivated to write up a more specific proposal?
[20:43] <ScottK> Personally, I'm deeply concerned that someone will think this is going to be a wonderful approach for Qt5 in 14.04 and I'm pretty sure it won't.
[20:44] <soren> ScottK: I'm confident your opinion on that subject will have an impact on any decision on the subject.
[20:44] <ScottK> If I had a vote, I'd vote for maintaining the current policy - in the Unity case, the safe performance patches have already be backported vai SRU.
[20:45] <ScottK> I'd suggest to defer deciding on it until there's an actual case that needs it.
[20:45] <soren> The proposal as given in Marks e-mail is too vague for us to vote on it.
[20:45] <ScottK> Then the TB can evaluate that and see what they think both about it and a more general policy.
[20:46] <soren> I'm cool with that. It seems like we're generally willing to at least consider it, so if anyone wants to pursue it for a particular component, they should be encouraged to propose it.
[20:47] <soren> Does anyone else have anything to say on this subject?
[20:48] <soren> Guess not.
[20:48] <stgraber> nope. I'm always happy to discuss specific exceptions to our policies and I agree that for this, it's probably best to wait until someone actually need it before we go ahead and discuss changing policies.
[20:49] <soren> Excellent.
[20:49] <soren> Moving on.
[20:49] <soren> #topic Scan the mailing list archive for anything we missed (standing item)
[20:49]  * soren does so
[20:49] <soren> I don't see anything.
[20:49] <soren> #topic Check up on community bugs (standing item)
[20:49] <soren> None.
[20:49] <soren> Yay.
[20:50] <soren> #topic Select a chair for the next meeting
[20:50] <soren> I've completely lost track of the order
[20:50] <mdz> I believe stgraber is next
[20:50] <stgraber> yep
[20:50] <soren> stgraber: You're next according to my alphabet, but you seem to have been chairing a lot recently :)
[20:51] <soren> Alright.
[20:51] <stgraber> soren: I think I only chaired once in January so far, so I don't mind chairing the next one if that gets us back in alphabetical order ;)
[20:51] <soren> Cool :)
[20:51] <stgraber> and TB meetings are way easier to chair than DMB ;)
[20:52] <soren> Err... What's the meetbot magic to denote decisions?
[20:52] <stgraber> #agreed?
[20:52] <soren> Yes! That!
[20:52] <soren> #agreed stgraber to chair next meeting
[20:52] <soren> stgraber: Thanks :)
[20:52] <soren> Any other business?
[20:53] <soren> Alright, thanks for showing up everyone.
[20:53] <soren> #endmeeting
[20:53] <meetingology> Meeting ended Mon Apr  1 20:53:09 2013 UTC.
[20:53] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-04-01-20.01.moin.txt
[20:53] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-04-01-20.01.html
[20:53] <stgraber> thanks!


[00:00] <knome> i can't agree more. i had no problem going to copenhagen paid by canonical, but still i think it was all a huge waste of money
[00:00] <knome> not the whole event, but many of the things
[00:00] <knome> expensive accommodation and per-diems to start off with a few things
[00:00] <ScottK> If they kept the interval at 6 months, I might agree it was just financial.
[00:01] <ScottK> 3 months makes no sense.
[00:01] <ochosi> i think the 3 months is mostly a "distraction" to keep ppl from complaining too much
[00:01] <knome> maybe their rationale is to increase quantity to make up some quality
[00:02] <ochosi> you can't just take something away without giving them something in return
[00:02] <knome> 3 months doesn't make sense for the xubuntu team. we're barely starting our engines in that time!
[00:02] <knome> (and no, i'm not telling canonical should adjust their plans to fit the xubuntu team)
[00:03] <TheDrums> And if they change to the rolling idea?  (IIRC, that was just a side comment too)
[00:04] <knome> TheDrums, i belive that would support the 3-month cycle, and i believe that's what ScottK also has in his mind
[00:04] <ochosi> TheDrums: you mean rick-rolling?
[00:04] <knome> i just double-checked the date to make sure it's not april fools
[00:04] <ScottK> TheDrums: It's my assumption that'll be the next announcement.
[00:05] <knome> that would've been a good one though...
[00:05] <TheDrums> That could make things fun for the flavors.
[00:06] <ScottK> I think they'll be unrecognizable when it's all done.
[00:07] <xnox> ScottK: online UDS is 2 days every 3 months vs 4/5 days every 6 months. Closer to a sprint than a half-marathon.
[00:07] <ScottK> My current best idea it to remove KDE from the archive and just distribute the different versions from different PPAs.
[00:07] <xnox> ScottK: I'm sure there will be people against that.
[00:07] <ScottK> xnox: So what am I doing at this first one?  Planning 13.10?  A little soon for that.
[00:07] <ScottK> xnox: Then they shouldn't cancel the releases we depend on.
[00:08] <knome> xnox, i'm sure there are people against everything.
[00:08] <ScottK> Canonical will do what it will do and we'll have to figure out the best way to adjust.
[00:09] <ScottK> I don't think they get the right to change the whole release process and tell us we can't change things as a result.
[00:10] <xnox> ScottK: i am not sure what will be planned. Now that ubuntu touch has landed out-of-archive one big chunk would be integrating that into raring images. But that's not as important for flavours.
[00:10] <knome> ScottK, i can empathize
[00:10] <slangasek> ScottK: why removing KDE from the archive?
[00:11] <slangasek> it's obviously for the Kubuntu team to decide what works best for them, but I don't understand the reasoning there wrt moving things to ppas
[00:11] <ScottK> I think that if we're trying to manage a no release between LTS situation, it' simpler to remove everything except kde4libs and then have one PPA per the four KDE releases that wiould then be happening per Ubuntu release.
[00:12] <slangasek> (and I'm not sure how that squares with the rules for official flavors / use of Ubuntu marks, regarding everything building from the archive)
[00:12] <ScottK> It's just my opinion, not the Kubuntu team.
[00:12] <slangasek> ah, I see
[00:12] <ScottK> You mean like Ubuntu touch?
[00:12] <slangasek> yeah, like that
[00:13] <ScottK> Ubuntu brands have been used lots of times for non-archive builds.  If someone wants to make us call it Ubuntu Kubuntu Remix, then fine.
[00:13] <slangasek> well, the standing "remix" language specifically only allows for archive builds, which was my point :)
[00:13] <xnox> ScottK: there is more qt coming into the archive (all of Ubuntu touch), and PPAs don't have armhf/powerpc. And somehow I don't think Blue Systems will be in favour of a Remix.
[00:13] <cjwatson> Removing all but kde4libs from the archive would make a fair number of other things unbuildable due to bindings and such; it's all fairly intertwingled.
[00:14] <ScottK> xnox: Blue Systems doesn't control Kubuntu.  They don't really have any say at all.
[00:14] <ScottK> cjwatson: I'm just talking outloud at the moment.
[00:14] <xnox> ScottK: ok.
[00:14] <ScottK> It happens one of their employees is on the Kubuntu Council, but only one, IIRC.
[00:15] <ScottK> cjwatson: I'm speculating in the face of an information deficit.
[00:15] <ScottK> It would be nice if the whole story came out at once.
[00:17] <knome> as always, it seems that the communication from canonical seems to be badly organized
[00:18] <tumbleweed> it would be nice if we knew what next week's UDS is for. I see a couple of haphazard blueprints, and no sprint on LP
[00:18] <cjwatson> ScottK: understood
[01:25]  * cjwatson quickly rebuilds kubuntu-active/daily-live, since it broke
[01:53] <cjwatson> Has queuebot lost its notion of stable release queues?
[02:18] <stgraber> cjwatson: that can happen, let me poke it
[02:19] <stgraber> cjwatson: hmm, it's getting some 401 from LP, let's try a restart
[02:22] <cjwatson> stg	Thanks
[02:23] <cjwatson> gah, lag
[02:23] <cjwatson> stgraber: Thanks
[08:27] <ogra_> cjwatson, thanks ! working fine now
[08:27] <ogra_> Riddell, http://cdimage.ubuntu.com/kubuntu-active/daily-preinstalled/current/ please test, if its fine i'll enable the cron job (and default-arches)
[09:26] <psivaa> cjwatson: infinity: today's server images have the kernel mismatch issue, please let me know if you are respinning them for me to watch the smoke tests. Just reported bug 1134123 to tag the failures
[09:26] <ubot2`> Launchpad bug 1134123 in Ubuntu CD Images "Raring server installations fail with kernel mismatch with 20130227 images" [Undecided,New] https://launchpad.net/bugs/1134123
[09:46] <cjwatson> psivaa: Yeah, I suppose I shouldn't have processed some kernels through NEW just before going to bed
[09:47] <cjwatson> And I guess somebody processed NBS or something
[09:48] <cjwatson> Hm, no
[09:48] <cjwatson> Well, I'll sort it out after I get back from the shop, to allow linux/armhf time to publish
[09:49]  * ogra_ wonders if anyone ever read the cdimage user mail on nusakan
[09:49] <ogra_> i get the "you have new mail" notice since a few days
[09:50] <cjwatson> Once a year or so :)
[09:50] <ogra_> heh
[09:51] <cjwatson> Ah, yeah, buildlive still witters at us in cronmail
[09:51] <cjwatson> Once I get buildlive converted to new code I'll probably move that to proper logging
[09:51] <psivaa> cjwatson: ack, thanks
[10:04] <Riddell> ogra_: ooh thanks, testing
[10:20] <psivaa> OEM config short-cut is not present in the desktop images today, reported bug 1134162 for that
[10:20] <ubot2`> Launchpad bug 1134162 in ubiquity (Ubuntu) "/home/oem/Desktop/oem-config-prepare-gtk.desktop is not present in the desktop images" [Undecided,New] https://launchpad.net/bugs/1134162
[10:20] <psivaa> cjwatson: xnox: ogra_ ^
[10:21] <xnox> yeah.... I actually don't know how the shortcuts appear on the desktop, I take it that ubuntu-cdimage project is better for such bug, as my guess is that shortcuts are added at cd building.
[10:22] <xnox> wait, this is oem. config. it should be there.
[10:22] <ogra_> yeah
[10:22] <ogra_> and if anything gets added casper does it, not the build process
[10:22] <xnox> i see.
[10:23] <ogra_> at least in terms of .desktop files
[10:23] <xnox> ogra_: tough chance on having a shortcut if oem-* packages are not installed though =)
[10:24] <xnox> hmm. but it was apt-install'ed.
[10:25] <ogra_> right, either unity changes somehow or we dont install the .desktop file anymore
[10:25] <xnox> ogra_: should oem-* be on the manifest? it's currently missing.
[10:25] <ogra_> i think it should, compare with an older one
[10:26] <xnox> (in squashfs or in the pool, that's the other question)
[10:26] <psivaa> xnox: ogra_ : this issue is with both precise and raring in today's images
[10:26] <ogra_> xnox, in squashfs
[10:26] <ogra_> afaik
[10:26] <xnox> psivaa: oem-config is on the iso in ./pool/main/u/ubiquity/oem-config_2.13.12_all.deb
[10:27] <xnox> let me sync new images.
[10:28] <psivaa> xnox: ahh ok, that may explain why the static validation tests are filing with ./pool is not being present in the images
[10:29] <xnox> psivaa: right, maybe that should be fixed first ;-)
[10:30] <psivaa> xnox: do you need a new bug for that or is the above bug enough to account that? :)
[10:32] <xnox> psivaa: i think it's best to move that bug above to ubuntu-cdimage project.
[10:32] <psivaa> xnox: ack
[10:33] <xnox> psivaa: where do you see static validation errors?
[10:34] <xnox> psivaa: are there raring validation jobs?! https://jenkins.qa.ubuntu.com/search/?q=static
[10:35] <psivaa> xnox: they are both precise and raring but not published
[10:36]  * ogra_ wonderas if we lost the live-ship seed or some such ... pool is filled by it usually
[10:48] <xnox> ogra_: it's interesting there is ./dists/ with usual set but the Packages.gz is empty and there is no pool at all on the cd =)
[10:48] <xnox> psivaa: i expect installing 3rd party software in offline mode not to work either as it depends on the /pool/ as well.
[10:49] <psivaa> xnox: ok, i have not tried that yet. will do in a little while
[10:50] <xnox> psivaa: no need. Image is borked.
[10:50] <psivaa> xnox: ack
[10:50] <xnox> (half-borked for non-essential features)
[10:52] <cjwatson> I'll look shortly
[10:52] <cjwatson> No doubt it's my fault
[11:05] <doko> so what keeps the php-horde packages out of raring?
[11:07] <Laney> their uninstallability
[11:08] <xnox> doko: the fact that -passwd and -whups need removing. As they depend on 4.x stack & php-horde has moved on to 5.x stack.
[11:08] <xnox> doko: or finding / uploading -passwd & -whups that can be installed with 5.x stack.
[11:09] <xnox> doko: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695898
[11:09] <ubot2`> Debian bug 695898 in php-horde-passwd "php-horde-passwd: not installable in sid, depends on old php-horde" [Serious,Open]
[11:10] <xnox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695899
[11:10] <ubot2`> Debian bug 695899 in php-horde-whups "php-horde-whups: not installable in sid, depends on old php-horde" [Serious,Open]
[11:10] <xnox> and -wicked apperantly as well.
[11:11] <doko> Laney, which reminds me ... haskell in -proposed ;)
[11:12] <Laney> yep, feel free to help :-)
[11:13] <doko> next +1 maintenance cycle =)
[11:55] <cjwatson> Maybe I should teach proposed-migration that udebs may not depend on debs ...
[14:44] <ogra_> cjwatson, hmm, my ubuntu-touch sync script runs sync-mirrors as the last command, it looks like this doesnt happpen (i see the synced dir on nusakan but not on cdimage) do i need to add a PATH to my script (i thought running it as cdimage the PATH would be set correctly)
[14:46] <cjwatson> ogra_: bug 1133315
[14:46] <ubot2`> Launchpad bug 1133315 in Ubuntu CD Images "Export PATH as soon as possible to use cdimage tools" [Undecided,New] https://launchpad.net/bugs/1133315
[14:46] <cjwatson> Let me see about fixing that
[14:47] <cjwatson> Actually, that's something else
[14:47] <ogra_> well, it seems to have actually died before
[14:48] <ogra_> else it would have sent the log by mail
[14:48] <cjwatson> cjwatson@nusakan:~$ sudo -u cdimage env | grep PATH
[14:48] <cjwatson> PATH=/home/cjwatson/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[14:48] <cjwatson> cjwatson@nusakan:~$ sudo -u cdimage -i env | grep PATH
[14:48] <cjwatson> PATH=/home/cdimage/bin:/home/cjwatson/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[14:48] <cjwatson> Or something along those lines
[14:48] <cjwatson> Or you could just set PATH, which I think is what I would do
[14:48] <cjwatson> Note how cdimage's crontab sets PATH at the top
[14:49] <cjwatson> Not sure why that isn't set in your script in that case
[14:50] <ogra_> cjwatson, yeah, the script had a bug right before sync-mirrors
[14:52] <cjwatson> Ah, OK, I didn't read you properly
[15:45] <Laney> can someone please promote libarchive13?
[15:46] <cjwatson> Laney: done
[15:46] <Laney> merci
[17:02] <doko> Laney, do you have an idea where to start with the haskel migration?
[17:04] <Laney> it's already well underway
[17:04] <Laney> but there's at least one sub transition
[17:04] <Laney> I've been pulling the latest stuff from exp, rebuild testing and then syncing
[17:04] <doko> I think I added another one.
[17:04] <Laney> starting at the top of the table
[17:04] <Laney> if there's no new package (a sub transition for stuff we already synced), just do a no-change rebuild
[17:04] <doko> libgc1c3,
[17:05] <Laney> some of the things at the top fail to build and require upstream changes (I fixed a few of those already)
[17:05] <doko> and now kaya ftbfs, but as it looks, for unrelated reasons
[17:05] <Laney> check if stuff ftbfs in experimental too, that's usually a good sign that it needs porting
[17:06]  * xnox ponders if we can automate rebuild tries in a ppa or some such.
[17:07] <Laney> i thought about writing a script to do that locally
[17:07] <Laney> read .ben file, try rebuilding, dch --rebuild if successful
[17:22] <infinity> The biggest problem with the Haskell transition is that people overzealously sync/upload too quickly and let arches get out of sync.
[17:23] <infinity> And then you sometimes get to rebuild a chain 17 packages deep to fix it again.
[17:23] <infinity> Such a pain.
[17:23] <Laney> Yeah, wait for the slowest arch
[17:23] <Laney> yay sagari
[17:24] <infinity> Usually, the problem isn't speed, it's FTBFS and people not checking.
[17:24] <infinity> But speed sometimes too, yeah.  Especially when queues are slammed, like today.
[17:25] <cjwatson> Let's drop amd64, it's too far behind
[17:25] <infinity> +1
[17:26] <infinity> Well, no.
[17:26] <infinity> -1
[17:26] <infinity> Let's drop i386 and give all its buildds to adm64.
[17:26] <infinity> amd, too.
[17:26] <ogra_> just replace it with arm64
[17:27] <infinity> Speaking of the confusion between amd64 and arm64, I wonder if everyone else is as excited as I am about AMD getting into the AArch64 race.
[17:27] <infinity> Like, someone who actually knows how to fab and market server-class CPUs...
[17:30] <infinity> I look forward to a future when all our ARM buildds are AMD-based HP DL(mumble)s.
[17:30] <ogra_> ++
[17:31] <ogra_> and then later AMD arm64 laptops with radeon graphics :)
[17:40] <xnox> the most sold processors in the world are still 8-bit, more than 60% market share last time I checked.
[17:41] <xnox> 16bit is still teething in.
[17:50] <slangasek> "give all its buildds to adm64"? infinity has his own port now?
[17:50] <slangasek> though I didn't think he was that old
[17:52] <ScottK> Doesn't help much if it's octal either.
[17:55]  * slangasek thbts at bug #1134461
[17:55] <ubot2`> Launchpad bug 1134461 in base-files (Ubuntu) "/var/mail is real instead of symlink :: /var/spool/mail is symlink instead of real" [Undecided,Invalid] https://launchpad.net/bugs/1134461
[18:03]  * xnox failed to parse "thbts"
[18:06] <slangasek> xnox: a raspberry
[18:07]  * ScottK thought it was a "Bill the cat" imitation.
[18:07] <ScottK> ;-)
[18:07] <ScottK> Of course you all may be too young for that reference.
[18:17] <slangasek> ScottK: the preceding 'ack' was absent
[18:17] <ScottK> Good point.
[18:30] <infinity> cjwatson: *blink*... Did britney have an aneurysm?  The outdates it lists for linux are NBS...
[18:30]  * infinity wonders if the .dsc is wrong.
[18:31] <infinity> Nope.
[18:50] <infinity> cjwatson: Oh, that's because of the NBS in -proposed.  Bother.  I guess I'll clean that manually.
[18:52]  * infinity fixes.
[19:05] <cjwatson> infinity: Lack of reports for -proposed?  I wonder what happened to that work ...
[19:10] <infinity> Dunno.  But now I want them for $stable-proposed too.
[19:11] <infinity> Cause I realised that my change to make linux-* not show on sru-report (for many good reasons) also meant it stopped showing removal commands for it, and now I have built-up cruft.
[19:12] <infinity> "Why, thank you, good sir."
[19:15] <cjwatson> You could make linux-* not show in the main tables but still show removal commands for them.  Just exclude in a different place.
[19:16] <infinity> cjwatson: Well, I wanted "not show" to also mean "not pointlessly walk bugs", and there seemed to be only one place to do that.
[19:16] <infinity> cjwatson: But, yes, some refactoring could fix that.
[19:16] <cjwatson> Yeah, that might involve a pair of changes, or refactoring.
[20:30] <infinity> stgraber: Since slangasek and cjwatson don't seem to be around, want to wield your TB bat and add daviey to ~ubuntu-sru, so he can drive the tools while I'm training him?
[20:32] <stgraber> infinity: will do in a minute when I have a web browser again (doing PXE tests on my laptop at the moment)
[20:32] <infinity> Hah.
[20:34] <stgraber> infinity: added
[21:03] <bdmurray> Can somebody tell me where 'libappindicator_0.4.92-0ubuntu2.diff.gz already exists in Primary Archive for Ubuntu'?
[21:04] <jbicha> bdmurray: https://launchpad.net/ubuntu/+source/libappindicator/0.4.92-0ubuntu2
[21:08] <infinity> bdmurray: It's been superseded, but once a version's used up, it's gone.