[15:01] <skellat> o/
[15:04] <dholbach> hey hey
[15:04] <karni> hey guys
[15:04] <karni> I can hear you, waiting for the video
[15:05] <dholbach> who wants to join in?
[15:05] <dpm> hi all!
[15:05] <skellat> dholbach: I'm available
[15:05] <dholbach> skellat, karni: want to join in? https://plus.google.com/hangouts/_/72cpjt7f417s88a1r34uiqoni4
[15:05] <karni> Thanks
[15:07] <dholbach> we take notes here: http://pad.ubuntu.com/uds-1311-appdev-1311-app-dev-schools-materials
[15:07] <dholbach> and please speak up if you want to get involved or have questions
[15:14] <karni> +1 on what dpm said
[15:19]  * skellat is running low on tea
[15:21] <skellat> Hello YoBoY
[15:21] <YoBoY> hi skellat
[15:21] <YoBoY> (hi everyone :))
[15:22] <dholbach> YoBoY, want to join in on the hangout?
[15:22] <YoBoY> nop, just login for later ^^" sorry
[15:22] <dholbach> ah ok :)
[15:54] <Vipindev> Hai, Even though there is topic difference, I have doubt, if I am just starting being a C++ programmer, how it be from Ubuntu, No documentation so far I got, help me.
[15:57] <karni> Vipindev: Regarding your question, c++ is a good start. We utilize that for Unity scopes and QML plugins. QML is fairly easy to learn, it's JavaScript'ish
[15:57] <karni> Vipindev: Although you won't be able to write an Ubuntu phone app from scratch in C++, I believe.
[15:58] <karni> We use QMl for the UI
[15:58] <karni> the front end. C++ for fleshing out the more interesting bits.
[16:01] <dpm> hi Vipindev, I think the easiest thing to start writing apps for Ubuntu is to use QML
[16:01] <dpm> Vipindev, you can certainly use C++, but at this point we're still building the documentation for C++ and trying to make it easier to cross-compile
[16:02] <dpm> Vipindev, so if you're just getting started, I'd recommend to look into QML first
[16:02] <dpm> Vipindev, http://developer.ubuntu.com/apps/qml/
[16:03] <dholbach> starting in 3m: http://summit.ubuntu.com/uds-1311/meeting/22033/appdev-1311-tutorial-videos/
[16:03] <Vipindev> OK. Thank you for your kind information.
[16:05] <dholbach> does anyone want to join in?=
[16:05] <skellat> o/
[16:06] <dholbach> https://plus.google.com/hangouts/_/76cpintgnk20a0m0mqe6q3llb0
[16:07] <dholbach> popey,  are you going to be in this session?
[16:07] <popey> yes, trying to join
[16:07] <popey> running another session
[16:08] <ali1234> yes we can hear you :)
[16:08] <dholbach> popey, gotcha
[16:09] <dholbach> previous session: http://pad.ubuntu.com/uds-1311-appdev-1311-app-dev-schools-materials
[16:15] <ali1234> +1 you'll get more downtime hosting the videos yourself
[16:23] <winael> Hi talking about the subtitle module of youtube, it very difficult to use in public mode
[16:23] <winael> it's more easly to export subtitles on po and use launchpad
[16:24] <popey> yes, i think we'd use lp
[16:25] <winael> for What is Maas and What is Juju video I used LP and po2srt srt2po tools and it was just fantastic to use. Just the owner of the video must import subtitlles on youtube
[16:31] <ali1234> popey: use meld, not imagemagick
[16:32] <ali1234> melt sorry, not meld :)
[16:33] <dholbach> :)
[16:50] <ali1234> that's to be expected
[16:50] <ali1234> i'm always saying how writing the app is the easiest part...
[16:50] <popey> ☻
[17:01]  * skellat is out to lunch
[17:02] <j_f-f> thanks @all
[17:04]  * NikTh is away: I'll be back.. later.
[18:02] <dpm> For anyone wanting to join the session starting in ~3 mins, here's the link to the hangout! -> https://plus.google.com/hangouts/_/72cpjlftuq26uskpdleqdr5cpo
[18:02] <cprofitt> thanks dpm
[18:02] <dpm> hey cprofitt, yw :)
[18:06] <dpm> https://plus.google.com/hangouts/_/72cpjlftuq26uskpdleqdr5cpo
[18:06] <YoBoY> I can't stay for this session :(
[18:06] <YoBoY> Hi
[18:06] <skellat> Catch us on the replay
[18:06] <pleia2> o/
[18:06] <PaulW2U> loud and clear !
[18:07] <YoBoY> ha ha :) thanks
[18:16] <cprofitt> so, this is to produce a 'bucket' of projects that loco teams can be involved in? Perhaps different levels of 'technical difficulty' as well?
[18:16] <skellat> Yes
[18:16] <skellat> "Suggested/Possible Projects for October"
[18:16] <skellat> et cetera
[18:18] <cprofitt> Having been through several seasons of my loco there has been a varying level of technical ability in the members
[18:19] <pleia2> I'd like to see some kind of "packs" for live loco events too, when I did a QA jam I pretty much had to collect and design it myself (with the help of balloons), if I could download something that had tools and info about running such an event it would be great
[18:19] <cprofitt> so having some 'different' types of events to point at or use that fit the level of the people that are currently active would help
[18:19] <cprofitt> for example: bug jams are a bit intimidating to non-technical users
[18:19] <cprofitt> +1 pleia2
[18:20] <chilicuil> and collecting materials for those evens too, +1 to pleia2 idea
[18:20] <dpm> Ah, here's the pad for everyone who wants to contribute: http://pad.ubuntu.com/uds-1311-community-1311-loco-projects
[18:20] <chilicuil> I actually though it was going to be addressed by  jono community packs (I must admit I had not looked at what materials those packs have if it's that were created)
[18:21] <pleia2> chilicuil: I thought those were more ubuntu promo things (promoting ubuntu, not contributing)
[18:21] <pleia2> but honestly there wasn't much in the pack last I looked
[18:22] <pleia2> bah, disconnecty etherpad
[18:23] <cprofitt> yeah... I lost it too
[18:23] <cprofitt> not reconnecting either
[18:23] <dpm> yeah, same here
[18:24] <cprofitt> that is an issue in all groups -- beginners, familiar, power users, advanced user
[18:24]  * popey pings is
[18:24] <cprofitt> you have an issue with ensuring that you keep them all engaged
[18:24] <skellat> Yes, we do
[18:24] <skellat> This is an opening part to getting people more engaged
[18:25] <cprofitt> I was once asked -- who is your audience:
[18:25] <cprofitt> current users or people not currently using Ubuntu
[18:25] <cprofitt> those are important differences
[18:27] <pleia2> for this session I'd say it's not brand new people, more about keeping current users engaged
[18:27] <cprofitt> some communities are more local or more on-line
[18:28] <popey> IS are looking at etherpad
[18:28] <pleia2> thanks popey
[18:28] <pleia2> yay testing
[18:28] <cprofitt> we have the basics: Bug Jams, App Jams, etc
[18:29] <cprofitt> ISO testing, Alpha/Beta Testing, Language (translations)
[18:29] <eps> *cough* xpdf *cough*
[18:30] <chilicuil> talking about translations, would be really cool to start by translating in community ubuntu.com =)
[18:31] <pleia2> https://help.ubuntu.com/community wiki cleanup/improvements
[18:31] <cprofitt> +1 pleia2 documentation jams
[18:31] <cprofitt> there are global jams, but loco teams can do local jams out of cycle
[18:32] <chilicuil> I think some of the most active groups already are doing local jams, are you suggesting to run multiple global jams? or to encourage more jams outside of the formal ones?
[18:33] <popey> pad is back
[18:33] <cprofitt> no, not running more global jams... but the recipe for a jam should be relatively the same for global and local jams
[18:34] <cprofitt> if we make a 'package' it does not have to be isolated to a global event
[18:34] <pleia2> some what of a side note, more notice for when global jams are happening would be good, last couple cycles we had only a month or so notice and that's not enough time to plan and schedule something
[18:35] <pleia2> need to find space, get materials and volunteers, announce and advertise event
[18:35] <toddcnb> +1
[18:35] <cprofitt> loco 'leaders' should not be the ONLY organizers
[18:35] <cprofitt> they are contacts
[18:36] <rickspencer3> o/
[18:37] <toddcnb> we have several team leaders to share the load
[18:37] <pleia2> rickspencer3: you're in the right place
[18:37] <rickspencer3> thanks pleia2
[18:37] <cprofitt> no you are in the right place
[18:37]  * rickspencer3 not sure if pleia2 means irc or Washington DC ;)
[18:38] <pleia2> hehe
[18:38] <pleia2> California 4ever
[18:40] <pleia2> we've mostly been playing with phones+tablets just on wifi
[18:40] <pleia2> cool re: emulator
[18:47] <cprofitt> is there a way for locos to be able to get 'demo' machines from vendors -- I did it myself by contacting System76, but not sure if there is a way to make it something pre-defined
[18:47] <cprofitt> or perhaps just put up contacts for people to use to get demo devices
[18:48] <cprofitt> other than the wiki -- should loco.ubuntu.com get a section for this?
[18:49] <cprofitt> gotta run to a meeting folks... good session thanks
[18:50] <dpm> thanks cprofitt!
[18:50] <pleia2> later cprofitt
[18:51] <toddc> need to keep arch users in loco's
[18:51] <skellat> toddc: We also need to give them a reason to stick around
[18:51] <cprofitt> +1 popey -- I think it is less issues and it is easier to use Linux
[18:51] <toddc> loco's should welcome all distro users
[18:52] <cprofitt> in our LUG we have moved more to FOSS apps running on Linux over distro specific stuff
[18:53] <cprofitt> now I really need to go :)
[18:53] <skellat> Bye cprofitt
[18:53] <pleia2> yeah, we have LUGs here for other distros, but I live in a tech-heavy place so we can easily sustain distro-specific groups
[18:54] <toddc> azloco works with lots of local LUG's as co-events so muti distro are supported
[18:55] <pleia2> toddc: yeah, we do too
[18:55] <pleia2> and lugs will email us when they need "what's new in ubuntu" speakers :)
[18:56] <toddc> 90% are new linux users so people with skills are hard to retain and hard to do more than installfests that we currently not have manpower to keep the requests for events
[18:58] <pleia2> #ubuntu-locoteams
[18:58] <pleia2> ?
[18:58] <rickspencer3> what was the announcement?
[18:59] <rickspencer3> aaaaah
[18:59] <rickspencer3> gotcha
[18:59] <rickspencer3> :)
[19:00] <high_fiver> thanks guys
[19:00] <skellat> The upcoming summit, once LoCo Council announces it, will in fact take place on summit.ubuntu.com.  Consider my words as a leak as a formal announcement is yet to be made.
[19:01]  * skellat disappears to prepare for LoCo Council's 2000 UTC meeting on #ubuntu-meeting
[19:02] <jono> ballock_, hey
[19:03] <jono> are you running the enterprise roundtable?
[19:03] <ballock_> guess not, same story as last time
[19:03] <jono> ballock_, who is?
[19:03] <jono> I can't set up the hangout, so I want whoever registered it to do it
[19:04] <ballock_> Not sure, Ove settled it with Daniel I guess.
[19:04] <ballock_> Can't see Ove either.
[19:04] <jono> ballock_, I don' think he did, Daniel can't set it up
[19:04] <jono> I tried msging him
[19:04] <jono> ok, well if he shows, I will set the link in summit so it is visible
[19:04] <jono> ballock_, do you want to set up a hangout on air and get it started?
[19:05] <ballock_> Can't, my corporate gmail doesn't have google on air.
[19:05] <ballock_> Unless... IRC is good enough?
[19:06] <stgraber> can I get the hangout URL? (not sure who's running that one)
[19:06] <jono> stgraber, we need someone to run it
[19:06] <jono> I can't run it
[19:06] <stgraber> jono: ah, I guess I could, let me see if my Canonical account was setup for OnAir stuff yet
[19:06] <jono> thanks stgraber
[19:07] <jono> dpm, ^
[19:07] <dpm> jono, stgraber, ack
[19:08] <stgraber> https://plus.google.com/hangouts/_/7ecpilcc71kqmqk3ilink45toc
[19:08] <stgraber> dpm: I don't have edit rights for that meeting on summit so can't add the URL
[19:08] <jono> stgraber, what is the broadcast URL?
[19:08] <jono> stgraber, I will set it for you
[19:08] <stgraber> jono: http://youtu.be/jwhaQik222k
[19:09] <jono> stgraber, done
[19:13] <gQuigs> Thursday Active Directory: http://summit.ubuntu.com/uds-1311/meeting/22055/client-1311-activedirectory/
[19:27] <pmatulis> stgraber: is there anything to do regarding AD integration beyond authentication?  i.e. can a linux system be integrated more than that?
[19:30] <geofft> what sort of configurations do you guys do?
[19:30] <geofft> and is this the sort of thing that Ubuntu ought to patch packages for to add some hooks for, in a stable fashion?
[19:30] <geofft> if a lot of people are trying to configure the same thing?
[19:30] <stgraber> https://plus.google.com/hangouts/_/7ecpilcc71kqmqk3ilink45toc if anyone else wants to join
[19:45] <welbourne> What was the XMPP client Stephane said Ubuntu prefers over Pidgin ?
[19:45] <geofft> Empathy
[19:47] <welbourne> Thanks geofft :-)
[19:47]  * welbourne has poor hearing ...
[19:48] <nandersson> Hi, what is the future for IM in Ubuntu Touch/Ubuntu 14.04. Will "Friends" be the default IM-client?
[19:48] <rickspencer3> o/
[19:50] <stgraber> hey rickspencer3
[19:50] <rickspencer3> hi stgraber
[19:50] <rickspencer3> :)
[19:52] <pmatulis> stgraber: thank you for your answer
[19:52] <stgraber> rickspencer3: do you know what the plan is wrt to IM in 14.04, will generic IM still be empathy or is that something Friends would take over?
[19:53] <xnox> friends is not for IM, but rather for facebook/twitter/g+
[19:54] <xnox> empathy is default at the moment, and it can use protocols from pidgin via libpurple.
[19:55] <xnox> stgraber: telephany can reuse _all_ protocols from pidgin via libpurple.
[19:56] <xnox> (needs UI et/al)
[19:56] <xnox> stgraber: it may be more sense to add pidgin UI on ubuntu-touch.
[19:58] <xnox> stgraber: friends is evolution of gwibber.
[20:00] <xnox> ..
[20:01] <xnox> so it will not be rename / downgradable ? e.g. the way HWE are optional.
[20:01] <xnox> stgraber: new libreoffice has often new dependencies.
[20:01] <gQuigs> xnox: LibreOffice?
[20:01] <xnox> gQuigs: yeah.
[20:01] <xnox> gQuigs: e.g. libreoffice-X.Y, etc.
[20:01] <gQuigs> xnox: that was the plan as I understood it; but again it hasn't been approved by the tech board
[20:02] <xnox> gQuigs: similar to how we have boost1.53, and boost1.54 etc.
[20:02] <stgraber> xnox: yeah, I'm mostly waiting on a formal proposal to the TB so we can review this. TBH if I'm on the board at that point, I doubt I'd support much more than a regular MRE + backport for new major releases.
[20:02] <xnox> gQuigs: in that case it's better, as users will be able to stay on previous one if they want to.
[20:02] <gQuigs> xnox: I'm not totally sure
[20:02] <geofft> stgraber, others: I'm kind of curious what sorts of things you customize in academic and other deployments
[20:02] <xnox> stgraber: don't wave imaginary sticks =)
[20:03] <geofft> and preferably if your cfengine / bcfg2 repos are public :)
[20:03] <xnox> ..
[20:03] <xnox> well if anyones existing templates "break", because a bug was "fixed" in libreoffice, it's a no-go.
[20:03] <gQuigs> xnox: then we would need to security updates for all the old versions...
[20:03] <gQuigs> xnox: the proposal was more like with Firefox
[20:04] <stgraber> geofft: I have a public bcfg2 repository but it's not education targeted, it's my own personal network (which is still rather massive ;)). For education, the standard need is authentication, centralized storage and printing configurations, default user session parameters (firefox, dconf, ...), package lists and extra certificates
[20:05] <stgraber> I was mostly working with K12 with mostly two kind of customers, those that to one-to-one (one laptop per student) and those that did shared desktops
[20:05] <gQuigs> work items at the end: https://blueprints.launchpad.net/ubuntu/+spec/client-1308-rolling-libreoffice
[20:05] <stgraber> those doing one-to-one would typically not restrict the session very much and usually give admin rights to the users
[20:06] <stgraber> the other case is the complete opposite, where rights are extremely limited and with requests going as far as locking the background and the icons on the desktop :)
[20:06] <gQuigs> xnox: LO new versions is stabilized through a full Regular Release;  it's then brought "Firefox style" to the LTS
[20:06] <ballock_> geofft: Tieto currently customizes authentication, firewall (with network detection), antivirus, SSL CA certificates, central HDD encryption storage, ntp, package repositories, printers,
[20:07] <geofft> authentication is Kerberos+LDAP?
[20:08] <ballock_> SSSD against AD
[20:08] <stgraber> it'd vary, some districts were using AD, so I'd just use sssd, some were using the Apple directory (openldap) and some were using eDirectory or some other random LDAP solution
[20:08] <stgraber> in most cases, sssd was the best choice anyway as it supports all of those and is the only client that does proper creds caching in my experience
[20:09] <stgraber> geofft: https://github.com/stgraber/bcfg2-memento is the public (no machine information and config) part of my repository
[20:10] <stgraber> geofft: I then derive from that one for 3 deployments with some specific configs per deployment
[20:10] <geofft> I'm wondering what sorts of things it'd be most useful to add support in upstream packages. That stuff plus defaults for mail clients is most of what Debathena configures
[20:11] <geofft> IIRC our pain points on upgrades have been mostly things like Firefox config, branding changes over transitions like gdm -> gdm3, and custom printers
[20:11] <geofft> http://debathena.mit.edu/package-list/#component-debathena-config is basically a list of what we configure
[20:11] <geofft> source is all at https://github.com/mit-athena/
[20:12] <stgraber> geofft: I've seen the proliferation of .d directories as something extremely benefitial, the least files I have to fully override the better
[20:12] <stgraber> geofft: I suspect a lot of software support includes in their config but the Debian package just doesn't ship with a .d + include rule by default
[20:12] <stgraber> trying to generalize that would make people's life much easier
[20:12] <ballock_> stgraber: totally agree
[20:12] <geofft> yeah, .d rules would help us a ton
[20:13] <geofft> /etc/services.d is something I'd really want but Debian's netbase maintainer doesn't want it :(
[20:13] <geofft> ... which reminds me, I think a guy I know at CMU wrote a separate NSS module for that. maybe that's worth packaging.
[20:16] <ballock_> fyi: there's a launchpad group and mailing list for the interested ones:
[20:16] <ballock_> https://launchpad.net/~enterprise-ubuntu
[20:16] <geofft> right! I was going to join that, thanks
[20:17] <ballock_> There's a number people representing enterprise deployments.
[20:18] <ballock_> It doesn't seem to have a coordinator, though
[20:18] <ballock_> so it is mostly active around UDSes
[20:28] <pmatulis> anyone can promote an unofficial ubuntu enterprise task force or make more specific ubuntu enterprise blueprints
[20:29] <ballock_> pmatulis: I vote for. The question is who/how?
[20:30] <ballock_> With my limited engineer capabilities I guess I did the best I could
[20:30] <ballock_> by joining a couple of UDSes, making some roundtable-like discussions and blueprints
[20:31] <ballock_> For now I guess the launchpad group I mentioned is the best of those achievements
[20:31] <pmatulis> ballock_: you don't need to be an engineer to do the things i mention.  obviously you would acquaint yourself as much as possible with the subject but you don't need to be a superhero
[20:32] <ballock_> Well, I actually meant I'm more an engineer than a manager or evangelist.
[20:32] <pmatulis> the important thing is to galvanize the topic at hand
[20:32] <ballock_> (still I'm not a developer)
[20:32] <ballock_> I believe there's interest.
[20:32] <ballock_> There's people from a good number of companies,
[20:33] <ballock_> there's French gendarmerie, which I believe to be running the biggest Ubuntu deployment
[20:33] <ballock_> We do have a communication channel
[20:34] <ballock_> but I don't know if we totally share the same goals or can consent on the same goals
[20:34] <ballock_> I can't even say how much potential the groups has
[20:34] <ballock_> nor how to get more people interested in this
[20:34] <ballock_> I guess that to gain more attention we need to have "something" that we can offer to potential members
[20:35] <ballock_> but "advice" might not be good enough
[20:35] <ballock_> there's plenty of forums, google and stuff
[20:35] <ballock_> they are answering more specific questions
[20:36] <ballock_> pmatulis: What's your vision on this?
[20:36] <geofft> I'm leaving for lunch now, but I'll definitely look through the list archive and the wiki pages. It looks like there are quite a few people there!
[20:37] <ballock_> geofft: yup, and I guess we will yet meet on the authentication session
[20:38] <pmatulis> you can't force people or promise them anything.  idea: send to mailing list that you (!) are interested in forming a focus group consisting of people who are espcially motivated/interested and maybe having the occasional google hangout.  but creating a "web" of blueprints under the ubuntu-enterprise umbrella is a necessity.  otherwise things remain vague
[20:39] <ballock_> I guess last UDS Jono mentioned we could get somebody from... the Leadership board? to join
[20:39] <jono> ballock_, join what?
[20:40] <ballock_> oh, speaking of the devil :)
[20:40] <ballock_> I mean, can we have somebody that would "spark" the actions
[20:41] <ballock_> The group is there, the interest is there
[20:41] <ballock_> It's just the question of 'what do we do now'
[20:41] <ballock_> (and how)
[20:42] <ballock_> pmatulis: I like the blueprints idea
[20:43]  * dm8tbr seconds
[20:43] <ballock_> but I didn't work with blueprints workflow
[20:47] <ballock_> ok, leaving for now, but I guess we'll keep in touch
[20:48] <ballock_> thanks for the nice chat and your thoughts on this
[20:48] <ballock_> talk to you later


[17:28] <Ravindhran> yes
[17:28] <lotuspsychje> Ravindhran: i assume you logged into wayland, if so please try login into xorg to compare
[17:42] <Ravindhran> anybody here
[17:42] <lotuspsychje> Ravindhran: did you read my line?
[17:43] <donofrio> is there new support for powerpc/ppc in 20.10?
[17:44] <lotuspsychje> Ravindhran: <lotuspsychje> Ravindhran: i assume you logged into wayland, if so please try login into xorg to compare
[17:44] <lotuspsychje> donofrio: this channel is only for 21.10 support
[17:44] <donofrio> if so I'll be glad to test on my g5  (five of them) along with my imac's
[17:45] <donofrio> lotuspsychje, I'm only asking about 20.10
[17:45] <lotuspsychje> not here donofrio
[17:45] <donofrio> lotuspsychje, I'm only asking about 21.10
[17:45] <donofrio> my bad mistyped
[17:45] <lotuspsychje> kk
[17:45] <donofrio> So I should ask - is there more support for PowerPC/PPC in 21.10?
[17:47] <lotuspsychje> donofrio: the testing iso's of 21.10 are here; http://iso.qa.ubuntu.com/qatracker/milestones/424/builds
[17:48] <donofrio> alright time to test!!!
[17:49] <donofrio> eek only "el?"
[17:49] <donofrio> I don't think g5 is el ;(
[17:58] <donofrio> any hope last version was /ubuntu-ports/dists/xenial/main/installer-powerpc ?  would be overjoyed to have 21.10
[18:28] <tomreyn> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-December/001199.html
[18:28] <tomreyn> powerpc wont magically return
[18:53] <donofrio> any way we can get back PowerPC EB?  why drop it?
[18:54] <donofrio> best way to find bugs in code is Multi-Arch if I recall
[18:54] <donofrio> especally with endian
[21:31] <kiwiircguest40> Are daily builds kernels/nvidia drivers set up for secure boot?
[21:32] <kiwiircguest40> I get it's a pre-release, but i rather not manually sign anything.
[21:35] <tomreyn> it'll probably be faster to just give it a try rather than waiting here for an answer
[21:38] <kiwiircguest40> I wonder, do the live ISOs include the driver? That'd probably be preferable.
[21:40] <kiwiircguest40> http://cdimage.ubuntu.com/daily-live/current/impish-desktop-amd64.list
[21:40] <kiwiircguest40> seems they do, im just gonna go for it. Thanks anyway :)


[05:59] <EleanorEllis> I am running Ubuntu Studio 16.04. I want to install webcamoid 8.0.0 but the version in the 16.04 repositories is only 6.2.0 but apparently version 8.0.0 is in the Ubuntu 17.10 repositories. Can I install from there?
[05:59] <EleanorEllis> Alternatively it's in Debian Testing
[05:59] <EleanorEllis> and Debian Unstable
[06:06] <cfhowlett> EleanorEllis, bad idea to mix version sources. better to install from source
[10:40] <studio_> hi guys, i need help with this error on Ardour 5: [ERROR]: LADSPA: impossibile caricare il modulo "/usr/lib/ladspa/gsm_1215.so" (/usr/lib/ladspa/gsm_1215.so: undefined symbol: gsm_destroy)
[11:36] <EleanorEllis> I need to remove my google account from evolution (added through gnome online accounts) but can't. I even completely removed gnome-online-accounts and the google plugin in Synaptic (my package manager) but the google account is still there.
[12:05] <EleanorEllis> ^ Sorted now: someone in #evolution helped me
[15:00] <n-iCe> hello!
[15:00] <n-iCe> does ubuntustudio comes with video editors?
[18:32] <n-iCe> hello
[18:32] <n-iCe> is openshot the last version?
[18:32] <n-iCe> or the ubuntu repos version
[18:32] <n-iCe> which has a lot of bugs
[18:32] <n-iCe> anyone knows?
[19:14] <L00P3X> after some crashes whit plugins on ardour i just made a fresh ubuntustudio install after using lubuntu whit studio-meta-audios... but seems to not help me out :\ when i add a calf plugin to a midi track arour "core dumbs" whitout a crash report.. seen some video adding it this way so it's maybe it's this 32bit machine? i do miss something before running carf on a track? here an ardour5 terminal log.. https://pastebin.com/eGCm1b4B
[19:16] <L00P3X> i used to: open jack.. run ardour as jack.. add a midi track whit yoshimi.. record some midis.. add calf plugin to track..  core dumped..
[19:46] <L00P3X> sorry, i've got to go..


[01:37] <michi> robru: Question for you…
[01:37] <robru> michi: hey what's up?
[01:37] <michi> Just trying to understand how things work.
[01:38] <michi> We have some silos stuck on testing because their dependencies can’t be satisfied.
[01:38] <michi> So britney isn’t happy.
[01:38] <robru> michi: where?
[01:38] <michi> Once the dependencies appear, how do we know? Does it re-test automatically once the dependencies are OK?
[01:38] <michi> silo 37.
[01:38] <michi> See the excuses for xenial
[01:39] <michi> scopes-shell won’t test because qtcreator-plugin-ubuntu is out of date, I think.
[01:39] <michi> I’m just trying to understand how to recover from this situation once the dependencies are OK again.
[01:39] <michi> Do we need to manually re-trigger a build?
[01:39] <michi> Or does Britney automatically wake up to the fact that it now makes sense to try again?
[01:39] <cjwatson> don't retrigger a build, people with appropriate privs can retry
[01:40] <michi> cjwatson: thanks
[01:40] <cjwatson> it will ... sometimes automatically retry, it depends on what changed
[01:40] <michi> so we just wait until things are fixed magically?
[01:40] <cjwatson> too many levels down and it won't notice
[01:40] <robru> cjwatson: michi is talking about autopkgtests, not depwaits in ppas
[01:41] <cjwatson> yes I know
[01:41] <robru> ok
[01:41] <cjwatson> it's still true
[01:41] <cjwatson> if an immediate dependency changes then that will in itself trigger new tests
[01:41] <cjwatson> but a change to a dependency of a dependency won't
[01:41] <michi> So, we basically just sit and do nothing?
[01:41] <robru> right
[01:41] <michi> OK.
[01:42] <michi> dobey mentioned that britney is struggling a bit right now.
[01:42] <michi> Where can I look at it?
[01:42] <cjwatson> that looks vaguely like the known jsoncpp ABI thing?
[01:42] <robru> michi: my 'right' was aimed at cjwatson
[01:42] <michi> Ah
[01:42] <cjwatson> michi: that's not britney struggling, that's the autopkgtest workers (different bit of the system, former uses the latter).  http://autopkgtest.ubuntu.com/running.shtml
[01:43] <robru> michi: britney logs are here: https://requests.ci-train.ubuntu.com/static/britney/last-run.txt it's currently taking an hour to do a run. this is caused by high load, but it's not actually causing any problems other than slowness
[01:43] <michi> Ah, cool
[01:43] <michi> cjwatson: Where do you see the json problem?
[01:44] <jamesh> maybe things would run faster if we had less tests?
[01:44] <cjwatson> I mean, robru knows more about how britney is set up in bileto, but dobey was specifically talking about autopkgtest queues earlier and just used the wrong name
[01:44] <cjwatson> michi: people talking about it today
[01:44] <cjwatson> and context and stuff
[01:44] <michi> Yes, I know, but I don’t actually know what happened with json
[01:44] <michi> Some ABI break
[01:44] <michi> But in detail?
[01:45] <robru> michi: yeah there's two different things going on here. your tests run in the autopkgtest system, britney polls it for results in regular intervals. currently that interval is "every 65 minutes" due to high load. in the past it was 25 minutes.
[01:45] <cjwatson> michi: I don't see it named in this particular test, but I know it's causing installability problems of this kind.  for detail I'm afraid you'll have to hunt around for more, I'm just stopping by briefly here.
[01:45] <michi> cjwatson: Cool, thanks.
[01:45] <robru> michi: really who you want to talk to about autopkgtest issues is pitti
[01:46] <michi> robru: The queue for britney looks ten miles long.
[01:46] <michi> Thanks.
[01:46] <cjwatson> a lot of those are relatively short, but it's probably a day's worth of queue :-/
[01:46] <michi> Aha
[01:46] <robru> michi: yeah I haven't had time to dig in, theoretically there's 17ish silos to process and they take 4ish minutes each, in order (can't be parallelized due to staggering memory usage)
[01:46] <michi> OK. So the upshot of it all is that we do nothing and just wait until silo 37 is ready.
[01:47] <michi> So be it :)
[01:47] <robru> michi: I dunno, if it still says 'regression' after a day and the queue died down a bit I'd poke somebody to retry them
[01:47] <cjwatson> in principle a lot of that has got to be parallelisable because most of the data structures should be based on the primary archive and therefore shared, in practice that's very hard to set up ...
[01:48] <michi> robru: OK. But I don’t want to needlessly get on people’s nerves.
[01:48] <michi> So, is there any way for me to check when it makes sense to talk to someone?
[01:48] <michi> And whom?
[01:48] <michi> pitti?
[01:48] <robru> michi: yeah pitti is the guy for digging into autopkgtests
[01:49] <michi> Aha.
[01:49] <robru> michi: I dunno how to tell when really, i'm not really familiar with that 'test dependency' error, and I think it's suspect that it all passed in vivid but failed in xenial.
[01:49] <michi> the problem is that a whole bunch of stuff is stuck behind scopes-api which got broken by an update to cap’n proto, which in turn broke abi-compliance-checker.
[01:49] <michi> Now everything is piling up because we can’t get silo 37 landed, and nothing that uses scopes can land either.
[01:50] <michi> robru: right. Vivid is fine
[01:50] <robru> michi: yeah I'd get pitti on it if this is blocking a lot of other stuff for you
[01:50] <cjwatson> I would suggest retrying when https://launchpad.net/ubuntu/+source/ubuntu-touch-meta/1.258 hits the release pocket + half an hour
[01:50] <michi> do you know his TZ?
[01:50] <cjwatson> pitti is in .de
[01:50] <robru> yeah
[01:50] <cjwatson> but the early side
[01:50] <michi> OK, thanks
[01:50] <michi> So late afternoom my time.
[01:52] <cjwatson> hilariously ubuntu-touch-meta is blocked on autopkgtest failures due to basically the thing it fixes.  *that* probably needs pitti to disentangle
[01:52] <robru> cjwatson: heh, was just going to say
[01:52] <robru> michi: http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#ubuntu-touch-meta
[01:53] <michi> Christ
[01:54] <michi> How does something like this *ever* land with that many dependencies?
[01:54] <robru> michi: "that many"? what are you looking at?
[01:55] <michi> There are tons of autopkg tests that ubuntu-touch-meta lists in its excuses
[01:55] <michi> Don’t they all have to pass before this can land?
[01:56] <jamesh> michi: the only thing mentioned under ubuntu-touch-meta is the click scope tests
[01:56] <michi> Ah, I get it now
[01:56] <robru> michi: http://i.imgur.com/hUnVrbx.jpg yeah
[01:57] <michi> Yep. I was under the mis-apprehension that everything the whole list had to pass.
[01:57] <michi> you can tell that I don’t know much about the packaging machinery :(
[01:58] <robru> michi: anyway follow that up with pitti, he can poke that through if that's the appropriate thing to do.
[01:58] <michi> Yes, thanks!
[01:58] <robru> you're welcome
[02:14] <cjwatson> As jamesh alluded to earlier, this was all a lot easier when we just uploaded straight to the archive without any automated tests running on the built packages. :-P  (But I think on the whole people prefer that we don't do that any more ...)
[02:15] <jamesh> it's a shame libjsoncpp could be uploaded without fixes to all the packages that sit on top of it then ...
[02:15] <cjwatson> Well, it hasn't reached xenial yet, it's only in xenial-proposed.
[02:16] <cjwatson> Unfortunately ubuntu-touch-meta has explicit dependencies on a particular ABI, which is anomalous for metapackages.
[02:16] <cjwatson> There are reasons for it, but it does tend to exacerbate this kind of problem.
[02:18] <robru> cjwatson: yeah kind of a funny situation, good that the change didn't break xenial, but seeing as how everything builds against -proposed anyway, it's sort of ground everything else to a halt
[02:19] <jamesh> yeah.  We wouldn't have been able to get something like that into -proposed for one of our own packages with problems like that
[02:21] <robru> cjwatson: TODO: make all debian imports go through silos ;-)
[02:24] <cjwatson> robru: hahahaha
[02:24] <cjwatson> robru: next step, work out how they interleave
[03:07] <dobey> hmm
[03:27] <jamesh> it looks like the autopkgtest queue length for armhf is steadily going down, but ppc64el is stuck at 1157
[03:27] <jamesh> is something broken there?
[05:31] <robru> michi: don't worry about that "version mismatch" message, i think you just lost a race condition, should sort itself out within 15 mins.
[05:31] <michi> robru: Aha.
[05:31] <michi> OK, thanks.
[05:31] <robru> you're welcome
[05:40] <Mirv> robru: \o/ yes, 023 got automated signoff now. thanks, train rules!
[05:40] <robru> Mirv: haha thanks. We've come a long way!
[05:52] <jamesh> robru: I don't suppose you're in a position to kick the ppc64el autopkgtests?
[05:53] <robru> jamesh: nope i think you need pitti for that
[05:53] <jamesh> thought that might be the case :(
[05:54] <Mirv> robru: and now... another corner case! https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-032/excuses.html - removed binary, will be removed from archives but britney would need to run...
[05:55] <Mirv> jamesh: I may be able, there is now a button for those with upload rights. link?
[05:55] <jamesh> Mirv: I've just been watching http://autopkgtest.ubuntu.com/running.shtml
[05:55] <robru> Mirv: I've seen that message before, i think that can be fixed without bileto changes
[05:55] <jamesh> Mirv: the armhf queue length has steadily been decreasing from about 700 this morning
[05:56] <jamesh> Mirv: the ppc64el queue was stuck at 1157, and now seems to be up to 1160
[05:56] <robru> Mirv: he doesn't want a retry, he wants the entire machinery kicked because it's stuck
[05:56] <jamesh> it doesn't seem to be doing anything
[05:56] <robru> Like physically kicked
[05:57] <Mirv> jamesh: ah kicking, not rerunning... yes you need pitti
[06:01] <robru> Mirv: try deleting old superseded source packages from your ppa. The version being complained about doesn't seem to exist in Ubuntu so i think it's just complaining about ppa contents
[06:01] <Mirv> robru: but how? (fixed) the normal fix is to remove the obsolete binary from archives. although I'm not sure why it's saying that already there, since usually it's just a reason stated in addition to the tests run
[06:01] <Mirv> robru: sorry, reading your msg :)
[06:01] <Mirv> robru: ah, yes it seemed really weird. trying to delete superseded packages then, makes sense (in the weird PPA way)
[06:02] <Mirv> robru: indeed! I've seen that before - in such a situation it will not get auto-deleted in PPA even if superseded. ok, let's wait 12h for the new results :)
[06:03] <robru> Mirv: you should see new results in 1 to 2 hours, but then it will trigger autopkgtests of course after that
[06:04] <Mirv> robru: yeah, I was assuming how long time it will take until getting all reverse deps of qtbase finished
[06:06] <Mirv> anyway, no hurry, I put it churning those britney results early precisely for that reason. I've tested the silo but that's really a silo that can't see too much testing so I'll just continue.
[07:19] <michi> jamesh: could you look at this one? https://code.launchpad.net/~michihenning/thumbnailer/fix-admin-relative-paths/+merge/284192
[07:19] <michi> It’s fairly simple.
[07:26] <michi> jamesh: Whoa, something’s happening with ppc queue.
[07:34] <jamesh> michi: commented on the MP.
[07:34] <michi> I just saw, thanks!
[07:35] <michi> If a relative path is passed to vs-thumb, it bombs.
[07:35] <michi> That’s why the canonicalization on the client side.
[07:36] <jamesh> right, but you're canonicalising twice.  Maybe just checking for absolute paths in one of those cases would do.
[07:36] <michi> Yes, just looking at that.
[07:37] <michi> But the client could be broken too and pass a relative path to the qt lib
[07:37] <michi> So, I guess it would be sufficient to do it in the qt lib, and not in vs-thumb
[07:38] <michi> Or not… Thinking...
[07:38] <michi> Sight, it’s been a while.
[07:38] <jamesh> nothing in that branch touches vs-thumb
[07:38] <michi> So, originally, I stumbled across this because thumbnailer-admin get didn’t work with relative paths.
[07:39] <jamesh> there is already a canonical() call inside thumbnailer-service, so vs-thumb should be protected.
[07:39] <michi> thumbnailer-admin goes through the client lib.
[07:39] <michi> So, canonicalising in the client lib is correct.
[07:39] <michi> And, when I use vs-thumb for testing manually, I’d like it to work too.
[07:39] <michi> canonicalising in thumbnailer-service is pointless because that has the wrong directory
[07:39] <michi> current directory
[07:40] <jamesh> in your branch, thumbnailer-admin is canonicalising the path, and then passing that canonicalised pathname to a method that also canonicalises it
[07:40] <jamesh> canonicalising in thumbnailer-service is not pointless, since it is in a different security context
[07:40] <jamesh> it is doing so for a different reason
[07:42] <michi> ?
[07:42] <michi> If the client sends a relative to the service, the service will end up with a completely different canonicalized path.
[07:42] <michi> That’s why the change in thumbnailer.cpp
[07:42] <michi> around line 103 of the diff
[07:44] <michi> But, yes, the service side still canonicalises the path to not get confused with different keys for the same file.
[07:44] <michi> So, the service rejects non-absolute path names now, which is what we want I think.
[07:44] <jamesh> michi: my understanding is that the canonical() call already in thumbnailer-service was to improve cache hits in case the client passed a symlink file name in
[07:44] <michi> No other change there.
[07:44] <michi> Yes, right.
[07:44] <michi> Don’t disagree with that.
[07:44] <jamesh> michi: adding a requirement for is_absolute() there is fine by me too.
[07:44] <michi> But it was possbile previously to send it a relative path, which turned into garbage on the service side.
[07:44] <michi> Right, cool :)
[07:45] <jamesh> but I wouldn't remove anything on that side, because it shouldn't rely on any work done on the untrusted client side.
[07:45] <michi> Correct.
[07:45] <jamesh> my comment on the MP was that on the client side you were doing canonical() twice
[07:45] <michi> So, I think what *can* be removed is the check in thumbnailer-admin.
[07:46] <michi> Because the lib does that too.
[07:46] <michi> Are we on the same wavelength now?
[07:46] <jamesh> either remove the canonical() call in thumbnailer-admin, or make the client lib just throw on !is_absolute()
[07:47] <michi> I think the safer option is to leave the lib as is and remove it from thumbnailer-admin.
[07:47] <michi> That way, if someone talks directly to the lib, we avoid a round-trip to the service.
[10:19] <sil2100> pstolowski, michi, dobey: hey! I see that the acc-disabling silo is failing on autopkgtests, are you guys looking into that?
[10:19] <michi> sil2100: Been looking at it all day :(
[10:19] <michi> It’s a break in qt-something.
[10:20] <michi> The autopkg tests weren’t making progress for almost the entire day.
[10:20] <michi> Because the PPC test machine died.
[10:20] <michi> So nothing got through.
[10:20] <michi> silo 37 is what we really would like to get unblocked.
[10:22] <michi> sil2100: Been tinkering with abigail most of the day.
[10:22] <michi> Making progress. Found a bug today. The main dev at RedHat is looking at it.
[10:25] <sil2100> ;/
[10:25] <pstolowski> "badpkg: Test dependencies are unsatisfiable."
[10:26] <pstolowski> Broken libscope-harness2:amd64 Depends on libunity-scopes1.0 [ amd64 ] < none -> 1.0.3+16.04.20160209-0ubuntu1 > ( libs )
[10:26] <pstolowski>   Considering libunity-scopes1.0:amd64 2 as a solution to libscope-harness2:amd64 0
[10:26] <pstolowski>   Holding Back libscope-harness2:amd64 rather than change libunity-scopes1.0:amd64
[10:34] <sil2100> hm, I'm not an expert in autopkgtests
[10:35] <sil2100> Mirv: you seem to have more experience, could you help me parse that ^ ? :)
[10:50] <Saviq> sil2100, can you please press ♻ on the scope click regression in http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity8
[10:52]  * Saviq finds it quite weird this is limited to core-devs
[10:55] <sil2100> o/
[10:55] <sil2100> Yeah, it shouldn't
[10:55] <sil2100> Retried
[11:18] <Mirv> sil2100: I'm also not too expert in finding the actual problem from the logs.. experimenting in chroot helps, like with the python problem
[11:18] <sil2100> pete-woods: hey!
[11:19] <sil2100> pete-woods: do you know if we still use unity-voice anywhere? Is that project maintained and necessary?
[11:20] <Mirv> Saviq: more exactly it's limited to "those with upload rights to the package". there needs to be some limitations, but maybe additional rights could be considered at some points. pitti would know the rationale.
[11:21] <pete-woods> sil2100: we don't use it anywhere, no
[11:21] <Mirv> I'll try to look more into the failures in a bit
[11:22] <pete-woods> sil2100: it used to be used by HUD, but at request we removed it, as the functionality was only available on the phone
[11:22] <pete-woods> and HUD was also removed from the phone
[11:22] <sil2100> Yeah
[11:22] <sil2100> Ok, I wonder if we could remove it from the archive
[11:23] <pete-woods> if could certainly at least be bumped into universe from main
[11:23] <pete-woods> but I'd rather not remove it completely, in-case suddenly HUD needs to do voice recognition again
[11:26] <cjwatson> pete-woods: unity-voice is already in universe.
[11:27] <Laney> The problem is that some APIs it uses have changed and so it needs maintaining
[11:27] <Laney> You could ~easily bring it back if required
[11:33] <sil2100> I would say it's no use having it in the archive just for the sake of having it
[11:33] <sil2100> The lp project can stay so as Laney said, it can be re-released whenever needed
[11:36] <pete-woods> okay, fair enough, feel free to nuke it then
[12:19] <Mirv> sil2100: michi's silo 037 problem is because of the libjson transition. not sure what to do, maybe agree that vivid autopkgtests show green and override to get it into QA queue anywya.
[12:19] <michi> Mirv: Are you sure it’s because of json?
[12:19] <Mirv> sil2100: there's a clash with the two sides of things that the builds are with proposed and autopkgtests without proposed but with the PPA. that's intended and most of the time provides the best results.
[12:19] <michi> I thought I saw an excuse about qt-something
[12:20] <Mirv> michi: the PPA depends on libjson1 which is only available in -proposed, but the autopkgtests run without proposed so that there wouldn't be failures coming from outside the silo.
[12:20] <Mirv> michi: can you point me to it? the autopkgtest logs however have a lot of things in them that seem suspicious but are simply observations and not a cause for a failure.
[12:20] <michi> Ah
[12:20] <michi> Let me see if I can find it.
[12:21] <Mirv> sil2100: but the libjson transition should simply be finished, that's the real fix
[12:22] <michi> Mirv: I’m looking at https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-037/excuses.html
[12:22] <michi> Scroll to the bottom.
[12:22] <michi> Then look at the i386 regression for scopes-shell<EMAIL_ADDRESS>[12:22] <michi> Right at the bottom of that, it bitches about qt-something
[12:23] <sil2100> Mirv: the scopes silo is the only thing left for the libjsoncpp transition
[12:24] <sil2100> Mirv: the only packages left with the old libjsoncpp0v5 dependencies are in this silo and this silo was supposed to fix it
[12:24] <sil2100> (as we needed them to be re-built)
[12:24] <Mirv> sil2100: ah. in that case I think we might simply stare at this beauty https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-037/excuses.html and ask QA to get it into their queue manually
[12:25] <sil2100> Mirv: hah ;) Yeah, I just couldn't understand why this is failing, since all the required leftover packages that needed a rebuild were in this silo, so I expected autopkgtests to install all that are in the silo
[12:25] <Mirv> michi: the fact that it runs something (certain autopkgtests) is not that the failure in those running would be related to the failing package. _all_ reverse dependencies of unity-scopes-shell that have autopkgtests are always executed, and that includes qtcreator-plugin-ubuntu (SDK install some scope package) and unity8.
[12:25] <michi> Mirv: cjwatson mentioned earlier today that, when something won’t work because a dependency of a dependency isn’t available, it needs manual intervention.
[12:26] <Mirv> sil2100: because the libjson itself is not in the silo, but only in -proposed
[12:26] <Mirv> sil2100: and autopkgtests run without proposed
[12:26] <sil2100> Aaaaaaah, ok, I keep forgetting about the -proposed bits
[12:27] <michi> Mirv: If we are buliding against proposed, the bloody autopkg tests had better run against proposed too, otherwise this is a thoroughly pointless exercise!
[12:27] <sil2100> Yeah, I don't know why I forgot about it, I got bitten by it last week already
[12:27] <Mirv> sil2100: well it changed yesterday evening so ... :D
[12:28] <Mirv> sil2100: so after consulting with pitti we agreed to disable proposed from autopkgtests, because that causes a lot of non-PPA-related failures (failures that need to be fixed in -proposed before the other things migrate from there). but the counterside is this that if something from proposed is actually required...
[12:28] <michi> I really think it doesn’t make sense to run autopkg against xenial, when the code was built with xenial-proposed.
[12:28] <Mirv> sil2100: so this implementation made it possible for my silo 23 to get automatic signoff after 1,5 weeks of related train fixes :)
[12:29] <michi> Both success and failure of a test are pretty much meaningless in that case.
[12:29] <sil2100> jibel, davmor2, rvr: hey guys! Regarding silo 37 - could you guys manually shove it into the QA queue? The failing xenial tests are caused by us not using what's in -proposed
[12:29] <sil2100> jibel, davmor2, rvr: it's all part of a transition in xenial
[12:30] <davmor2> sil2100: take it the fix that was meant to land still didin't then
[12:30] <davmor2> didn't fix it that is
[12:30] <michi> Am I missing something here?
[12:30] <cjwatson> Mirv: Surely all this is libjsoncpp, not libjson?
[12:30] <michi> We are testing with old packages for code that built with newer packages and expect to get meaningful answers?
[12:30] <Mirv> cjwatson: sure, yes
[12:31] <cjwatson> michi: The point here is to ensure that integrating new code doesn't break stuff already in the archive.  Of course that's important and expected to be meaningful.
[12:31] <michi> Hmmm…
[12:31] <cjwatson> michi: In cases where we're integrating a block of multiple packages then as a general rule (modulo bugs) we try to test the newer ones, though.
[12:31] <michi> This feels dubious to me.
[12:31] <Mirv> sil2100: the proposed thing was bug #1541334
[12:31] <ubot5`> bug 1541334 in autopkgtest (Ubuntu) "Do not run silo tests against all of -proposed" [Undecided,Fix released] https://launchpad.net/bugs/1541334
[12:31] <michi> I mean, pretty much anything could happen.
[12:32] <cjwatson> Yes.  It's software.
[12:32] <michi> It’s essentially undefined what answers come back from a test.
[12:32] <cjwatson> Nonsense!¬
[12:32] <michi> The code tests with packages it wasn’t built against.
[12:32] <cjwatson> We can investigate and override cases where mistakes happen.
[12:32] <michi> That doubleplusungood.
[12:32] <cjwatson> Rubbish.
[12:32] <michi> How so?
[12:33] <cjwatson> If the packages you're fearful of need to be rebuilt, then that's a thing you need to know.
[12:33] <michi> Hmmm…
[12:33] <cjwatson> If tests fail, then it may well indicate that your landing is incomplete.
[12:33] <michi> So, I call into libx at v1
[12:33] <cjwatson> Simply ignoring that on the basis that it's "essentially undefined" is deeply dubious practice.
[12:33] <michi> I write tests, blah, blah.
[12:34] <michi> Then something goes and runs my tests built against v1 with autopkg tests from v0
[12:34] <michi> Sorry, with autopkg tests that call into into v0
[12:34] <michi> So: bool f()
[12:34] <michi> returns false in v0, and true in v1
[12:35] <cjwatson> In most cases, these things are integration tests.  They're not testing specific functions like that, they're testing that the package as a whole is still functional.
[12:35] <michi> How can I make any QA assurance now?
[12:35] <michi> Yes, I know.
[12:35] <michi> But this entire approach has landmines all over it.
[12:35] <cjwatson> There are some edge cases where one needs to change the autopkgtests to take account of interface changes, and those cases we can override.
[12:35] <cjwatson> But you still want to know about them.
[12:36] <michi> Well, for the record, I think I can safely predict that this will blow up in unpredictable ways some of the time.
[12:36] <cjwatson> If the package containing these autopkgtests has changed, then typically the newer tests will be run.
[12:36] <cjwatson> That's nice.
[12:36] <michi> I think that’s a thoroughly bad idea.
[12:36] <michi> Yes, newer tests are better than older ones.
[12:36] <cjwatson> What are you actually proposing, in concrete terms?
[12:36] <michi> But if they call into something that is now essentially undefined because it is unexpected, anything can happen.
[12:36] <cjwatson> That's not helpful.
[12:36] <cjwatson> What are you actually proposing, in concrete terms?
[12:37] <michi> If something was built with v1, it needs to test with v1
[12:37] <michi> this approach effectively switches dependencies underneath autopkg tests, unless I’m misunderstanding something.
[12:37] <cjwatson> In general that will happen if there was a documented interface change (i.e. soname change or whatever).
[12:37] <michi> Really?
[12:37] <michi> We change version all the time, with minor behavioral changes in an API.
[12:38] <michi> These are definitely not soname changes.
[12:38] <cjwatson> Most of which has zero effect on autopkgtests.
[12:38] <michi> Yes, because most people write sloppy autopkg tests that pay lip service to what an autopkg test should actually be doing, namely, to test the full functionality of a package.
[12:39] <cjwatson> That's kind of a retcon.
[12:39] <michi> I count myself among the sinners...
[12:39] <michi> retcon? What’s that? I don’t know the term.
[12:39] <cjwatson> Retroactive continuity
[12:39] <michi> Ah :)
[12:39] <cjwatson> As in, declaring something to have always been the case after the fact.
[12:39] <michi> Yes I get it :)
[12:40] <cjwatson> The real point of autopkgtests was to test packages in their as-installed state, rather than just in the build tree.
[12:40] <michi> Right.
[12:40] <michi> So the main point is to test that installation worked, rather than the code, which should have been thorougly tested much earlier.
[12:40] <michi> I get that.
[12:41] <michi> Except that software has its ways.
[12:41] <Saviq> sil2100, no dice, try again? http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity8
[12:41] <Saviq> at least there's no queue now
[12:41] <michi> To blow up in the most unbelievable ways, due to chains of impossible coincidences.
[12:41] <michi> Anyway, I got my five cents worth in. Thanks for listening! :)
[12:42] <cjwatson> The point here is that if your package doesn't require a newer version of the thing that depends on it to migrate, then you *do* need to make sure that the older version still works
[12:42] <cjwatson> Because otherwise you can end up letting integration failures through
[12:42] <michi> Correct. But these dependencies get switched underneath me without any warning too.
[12:42] <cjwatson> And in general it's even less likely that the newer version of autopkgtests for libx will work against an older version of libx
[12:43] <michi> We get broken all the time by packages we call into that do something different suddenly.
[12:43] <cjwatson> So you have to run the older test code
[12:43] <michi> It is *highly* likely that v2 of one of our dependencies will break us when v1 is still working.
[12:43] <michi> Happened to us just yesterday.
[12:43] <michi> And we never asked for v2
[12:43] <cjwatson> Great, so hopefully that's a test failure.
[12:43] <sil2100> Saviq: done
[12:43] <michi> Nope, it isn't
[12:44]  * sil2100 off to prepare lunch
[12:44] <cjwatson> Or insufficient tests.
[12:44] <cjwatson> Now, if your landing is part of a set with a newer version of libx, then we'd want to run the newer tests for libx and newer code for libx
[12:44] <michi> abi-compliance-checker crashes because of totally legitimate and correct and backward compatible changes in another package that abi-compliance-checker doesn’t not even know exists.
[12:44] <michi> And, as a result, our unit tests fail.
[12:45] <cjwatson> "nope, it isn't [a test failure]", "and as a result our unit tests fail"
[12:45] <cjwatson> which is it?
[12:45] <michi> See, we have a new version of cap’n proto in xenial-proposed.
[12:45] <michi> that’s a perfectly good and legitimate and compatible update.
[12:45] <michi> And acc has a but that causes it to barf when it compiles the new capn proto headrs.
[12:46] <michi> And, because we are diligent, we run ABI compliance checks as part of our unit tests.
[12:46] <michi> And, suddenly, we fail in xenial-proposed.
[12:46] <cjwatson> that's not autopkgtests though
[12:46] <michi> And we didn’t even know that capn proto had changed, or that, suddenly, someone was building our code against xenial-proposed.
[12:46] <michi> No.
[12:46] <michi> But it’s the same thing.
[12:46] <cjwatson> no, it's really really not
[12:47] <cjwatson> one of the things that autopkgtests are really good for that entirely didn't exist in any form previously is to allow packages to make assertions about the behaviour of their dependencies and have those stick
[12:47] <michi> It’s spooky action at a distance.
[12:47] <cjwatson> if capnproto were making assertions about the behaviour of acc in an autopkgtest, then failures there would prevent a newer version of autopkgtest from migrating to xenial
[12:47] <michi> Yes, I understand the reasoning. And I’m totally supportive of autopkg testins.
[12:47] <michi> capnproto does not know acc exists, and vice versa.
[12:48] <cjwatson> Anyway, I'm getting very confused by the way you're shifting between different facets of the argument here, so I'm going to go and do something more useful ...
[12:48] <michi> acc call gcc to compile the capn proto header files.
[12:48] <michi> And that fails.
[12:48] <michi> Ultimately, it’s a bug in acc.
[12:48] <michi> I’m not trying to make trouble. Just pointing out that this is dangerous.
[12:48] <michi> Now, one thing that would really be useful:
[12:49] <michi> Have Jenkins start building on the side for <next-adjective>-proposed, but without hard failures.
[12:49] <cjwatson> the problem is that you're pointing out lots of different things that are not actually technically the same thing, and using them in support of each other
[12:49] <michi> Then we’d get an early heads up when packages in -proposed cause trouble.
[12:49] <cjwatson> it's nearly impossible to follow an argument structured like this
[12:49] <michi> All I know is that we only found out on Monday that there was a problem.
[12:49] <michi> Because things started building in -proposed.
[12:49] <michi> So, the problem is that we find out late.
[12:50] <michi> If we could have some CI support, it would alert us to any problems much sooner.
[12:50] <cjwatson> that seems reasonable
[12:51] <michi> For example, the capn proto chane has been sitting in proposed for months.
[12:51] <michi> But we didn’t even know that this was coming.
[12:51] <michi> Then, we get all surprised when, suddenly, nothing passes tests anymore, and whole ton of people can’t land stuff because our package fails its tests due to an unknown change to a dependency.
[12:52] <cjwatson> Any reason the capnproto change hasn't landed properly?  It looks like it breaks several phone-related packages.
[12:52] <michi> I’m trying to catch that sort of thing earlier, so we can be proactive.
[12:52] <michi> I have no idea.
[12:52] <cjwatson> One thing that would help is to not let things languish in -proposed.
[12:52] <cjwatson>     * amd64: camera-app-autopilot, gallery-app-autopilot, indicator-network-autopilot, indicators-client, libscope-harness-dev, libscope-harness2, libunity-scopes-cli, libunity-scopes-dev, libunity-scopes-qt-dev, libunity-scopes-qt0.2, libunity-scopes1.0, python3-scope-harness, qtcreator-plugin-ubuntu, qtcreator-plugin-ubuntu-autopilot, ubuntu-experience-tests, ubuntu-pocket-desktop, ubuntu-push-autopilot, ubuntu-sdk, ...
[12:52] <cjwatson> ... ubuntu-sdk-libs-dev, ubuntu-touch, ubuntu-touch-session, unity-plugin-scopes, unity-scope-click, unity-scope-click-autopilot, unity-scope-mediascanner2, unity-scope-scopes, unity-scope-snappy, unity-scope-tool, unity8, unity8-autopilot, unity8-common, unity8-desktop-session-mir
[12:52] <michi> sil2100 wasn’t totally sure whether the guy wo pushed the change actually tested all the reverse deps.
[12:52] <cjwatson> that's the uninstallable list from the new capnproto
[12:52] <cjwatson> not only are they untested, they're uninstallable
[12:52] <cjwatson> very likely because of the soname change
[12:53] <michi> Probably
[12:53] <michi> We just disable one unit test, and that “fixed” it.
[12:53] <cjwatson> needs a rebuild of libunity-scopes1.0
[12:53] <michi> At the cost of no longer running abi compliance checks.
[12:53] <michi> We pushed a branch for that yesterday. silo 37
[12:55] <cjwatson> a thing I generally advocate for is keeping -proposed as empty as possible so that it's more obvious when this sort of thing is languishing
[12:55] <michi> that would be good, yes.
[12:56] <michi> It’s not going to happen without some rules and some process to enforce it though.
[12:56] <michi> to me, it’s all about catching problems early.
[12:56] <cjwatson> well, that was what I was trying to do with the whole +1 maintenance effort
[12:56] <michi> If we find out three days before a release freeze when something fails in a silo, that’s no good.
[12:57] <cjwatson> but it also requires getting people to care about things outside their little bubble
[12:57] <michi> Sends everyone into headless chicken mode.
[12:57] <michi> Agree.
[12:57] <michi> I have no simple answers :(
[12:58] <michi> But I know from bitter experience that, if we catch something early, that’s exponentially cheaper than catching it late.
[12:59] <michi> Looking at the list of reverse deps for capn proto, quite a few of those are simply because scopes-api uses capn proto, I think.
[13:00] <michi> But, getting focus...
[13:00] <michi> Is there a way to get silo 37 unblocked?
[13:00] <michi> the test failure is fixed now.
[13:00] <michi> So, whatever is holding up silo 37, it ain’t us, to the best of my knowledge.
[13:00] <cjwatson> let's see
[13:01] <cjwatson> I'll see what happens if I pick a random one of those tests and rerun it
[13:01] <cjwatson> but we still have a new ubuntu-touch-meta only in -proposed, so I'm a little doubtful
[13:02] <michi> Hmmm...
[13:03] <michi> The regression tests for scopes-shell fail for xenial in silo 13 because of this, I think<EMAIL_ADDRESS>[13:03] <michi> Right at th end of the log.
[13:04] <michi> qtcreator-plugin-ubuntu
[13:04] <cjwatson> I think that's ubuntu-sdk-libs being uninstallable which is basically due to the same thing
[13:04] <cjwatson> We probably just need to force the tests to be run with a slightly larger trigger set
[13:04] <michi> Is that the same problem as for ubuntu-touch-meta?
[13:04] <michi> I’m not aware of all the dependencies/groupings :(
[13:06] <cjwatson> Yeah
[13:07] <michi> OK.
[13:07] <michi> So there is nothing we can do for the moment.
[13:08] <michi> Somehow, qtcreator-plugin-ubuntu needs to pass first.
[13:08] <michi> I have no idea how to accomplish that.
[13:15]  * cjwatson tries running unity-scope-click tests with unity-scopes-api added to the trigger
[13:37] <cjwatson> michi: (now waiting to be able to see the output of the test I triggered)
[13:37] <michi> cjwatson: We just decided to unbundle scopes-api from silo 37.
[13:37] <ogra_> hmm, i'm running the ubuntu-pd image on my N7 now ... are the Xorg app launchers supposed to do anything ?
[13:37] <michi> We are going to land the scopes-api fix separately, which should unblock a whole bunch of other packages.
[13:38] <ChrisTownsend> ubuntu-qa: Hi, any ETA on when testing will commence for https://requests.ci-train.ubuntu.com/#/ticket/982 ?
[13:38] <ogra_> (i definitely dont even get feedback clicking something like gedit or firefox)
[13:38] <michi> cjwatson: What test did you trigger?
[13:39] <michi> cjwatson: Ah: tries running unity-scope-click tests with unity-scopes-api added to the trigger
[13:40] <michi> I don’t even know what a trigger is in this context :(
[13:40] <cjwatson> michi: can you explain why you're unbundling?  I really think that will make matters strictly worse
[13:40]  * cjwatson checks
[13:40] <michi> The list of reverse deps you pasted earlier had a bunch of packages in it that are failing only because of the inability of scopes-api to make progress.
[13:40] <jibel> ChrisTownsend, is it for OTA9.5 or 10? there is no milestone
[13:41] <michi> silo 37 bundles the scopes-api change with a bunch of other fixes.
[13:41] <cjwatson> michi: but it isn't going to be possible for unity-scopes-api to make independent progress
[13:41] <cjwatson> michi: please don't unbundle it
[13:41] <michi> silo 37 doesn’t make progress because there is a problem with one of scopes-shell’s dependencies.
[13:41] <jibel> our plate is already full but if it's urgent we can allocate some time.
[13:41] <jibel> ChrisTownsend, ^
[13:41] <cjwatson> michi: it's one of the things that has to be rebuilt against libjsoncpp1; therefore it has to go together with the other things being rebuilt against libjsoncpp1
[13:41] <michi> cjwatson: The *only* change for scopes api is that we have disabled the failing test.
[13:42] <michi> Oh Christ… :(
[13:42] <ChrisTownsend> jibel: Umm, who decides that?  I guess OTA9.5 as it's needed asap.
[13:42] <michi> Are you sure that *scopes-api* is breaking because of json? I have seen no evidence of that.
[13:42] <cjwatson> michi: it's also a rebuild against libjsoncpp1, perhaps incidentally but necessarily
[13:42] <michi> As best as I know, scopes-api works as well with the new json as with the old one.
[13:43] <cjwatson> michi: it's not that it's breaking, but promoting the libjsoncpp change requires everything to be rebuilt in sync
[13:43] <michi> Oh my God :(
[13:43] <michi> pstolowski: ^
[13:43] <cjwatson> michi: if you unbundle unity-scopes-api, not only will it make little progress on its own but it will also make it strictly more difficult to make progress on unity-scope-click
[13:43] <michi> I don’t know how to help anymore.
[13:43] <cjwatson> so please don't
[13:43] <cjwatson> just leave it, I'm working on your silo
[13:44] <michi> I really tried all day to move this ahead somehow, but I keep running into dead ends :(
[13:44] <michi> pstolowski: Please co-ordinate with cjwatson about this.
[13:44] <michi> I’m about to sign off.
[13:44] <cjwatson> the trigger in this case is what the autopkgtest system considers to be the cause of the test attempts; in this case it's used to construct apt pins for packages to pull from later than xenial
[13:44] <cjwatson> adding a trigger is how we arrange for multiple things to be tested in combination
[13:44] <michi> cjwatson: You just threw more Chinese at me than I can read. I’m way out of my depth here...
[13:45] <cjwatson> but that gets way harder if they're in separate silos, we'd basically have to forcibly ignore test results
[13:45] <michi> Ok, re-reading this, I sort of get the gist of it.
[13:45] <cjwatson> in this case they're necessarily combined in terms of the dependency graph, so keep them together
[13:45] <michi> the autopkg tests for scopes-api will pass in the silo.
[13:45] <michi> We actually run them as part of our unit tests.
[13:46] <cjwatson> yeah, they should do as soon as I figure out the correct trigger to pass
[13:46] <michi> I’m virtually certain that our autopkg test will pass even with proposed.
[13:46] <cjwatson> I'm just being slowed down by not being able to see results immediately
[13:46] <michi> Because I strongly suspect that the autopkg test for scopes API won’t touch any code path related to json.
[13:46] <cjwatson> that seems likely
[13:47] <michi> So, we *might* just get away with a separate scopes-api landing from silo 24.
[13:47] <cjwatson> seriously, no
[13:47] <michi> I’ll leave it up to you and pstolowski to decide.
[13:47] <cjwatson> please please please do not muck with this
[13:48] <michi> I’m about to go to bed. It’s nearly midnight here. I won’t physically be able to muck with anything for the next seven hours.
[13:48] <cjwatson> that was a collective plea :)
[13:48] <michi> I’m out of my depth here, so I’m happy to leave it to you.
[13:48] <cjwatson> I'm reasonably sure I can get 37 sorted out, it will just take a little time
[13:49] <cjwatson> and I will get back to you/pstolowski if I run into a problem that isn't just infrastructural
[13:49] <michi> Just one thought to keep in mind for the next sprint, maybe. The complexity of what has just happened tells me that we must be doing something wrong. I thing the root problem might be late detection of issues caused by new packages in proposed. If we can get to and test with proposed early, I suspect we’ll mitigate the problems.
[13:49] <michi> cjwatson: Thanks!
[13:50] <cjwatson> I think the basic thing that went wrong here is allowing too many separate transitions to become entwined due to inattention to the size of -proposed
[13:50] <cjwatson> (possibly collective)
[13:50] <michi> Yes.
[13:50] <michi> And us not even knowning about the oncoming train, such as capn proto and acc.
[13:51] <michi> So, we were in blissful ignorance all along, until yesterday, even though the actual problem has been there for months.
[13:52] <cjwatson> the other thing is, if this weren't phone, I'm pretty sure somebody would've just fired off rebuilds ages ago and been done with it
[13:52] <cjwatson> but because phone is all super-careful about everything, the people who try to generally care about -proposed backlog are often averse to dealing with it
[13:52] <cjwatson> and as a result this can end up backing up in a way that wouldn't have been a problem if dealt with earlier :-/
[13:53] <dobey> hmm
[13:53] <jibel> ChrisTownsend, someone will verify it today.
[13:54] <ChrisTownsend> jibel: Ok, thanks.
[13:55] <dobey> well i guess the queue is emptied now
[13:55] <ChrisTownsend> jibel: Just for my info, is there a freeze going on that would normally cause this to be delayed?
[13:55] <ChrisTownsend> jibel: ie, if there wasn't a critical bug being fixed?
[13:57] <jibel> ChrisTownsend, there is no freeze, just a busy week.
[13:57] <ChrisTownsend> jibel: Ok, I understand
[14:04] <dobey> cjwatson: so you understand these pkgProblemResolver errors? i'm a little confused about them
[14:09] <dobey> hmm, what a mess
[14:10] <cjwatson> dobey: more or less.  excessive isolation for things that need to be tested in combination
[14:11] <dobey> cjwatson: ah. and you're doing some work to hopefully squeeze things through?
[14:11] <dobey> (sorry if this is repetitive, but i just got on line and trying to catch up :)
[14:17] <cjwatson> dobey: that is my hope
[14:23] <dobey> cjwatson: great. thanks!
[14:30] <AlbertA> trainguards: could someone retrigger the xenial/amd64 build in this silo ppa: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-064/+packages
[14:31] <robru> AlbertA: done
[14:31] <AlbertA> robru: thanks!
[14:31] <robru> AlbertA: you're welcome
[14:42] <pstolowski> cjwatson, hey, i see you and michi had a lengthy conversation... the conclusion is not to try to land unity-scopes-api with a separate silo right?
[14:43] <cjwatson> pstolowski: indeed, I think that will only make matters worse
[14:44] <cjwatson> pstolowski: doing that won't decouple it, it will just mean we have to figure out how to do cross-silo autopkgtesting and argh
[14:44] <pstolowski> cjwatson, fair enough.. i fully trust your judgement
[14:45] <davmor3> ping davmor2
[14:46] <davmor2> pong davmor3
[14:48] <dobey> oh no, the machines are taking over
[14:53] <davmor3> ChrisTownsend, ping well this is xchat mako \o/
[14:53] <ogra_> neat !
[14:53] <ChrisTownsend> davmor3:  Awesome!  Thanks for confirming!
[14:54] <davmor3> jibel, so looks like this is working for the ever \o/ now to test the rest :)
[15:15] <cjwatson> robru: So, I need to copy some packages from -proposed into a silo in order that they can all be autopkgtested together.  Do I need to add them to the source packages list in the request, or does that not matter if they're already in -proposed anyway?
[15:16] <jibel> rvr, didn't you approve silo 46 (click) 2 days ago?
[15:16] <robru> cjwatson: the source packages list in the request will be auto-filled, just copy the packages
[15:17] <cjwatson> robru: thanks, will try it
[15:17] <robru> yw
[15:27] <dobey> oh wow that's kind of awful
[15:28] <dobey> cjwatson, robru: does that mean the CI machinery is going to want to have the new capnproto and jsoncpp in vivid-overlay too?
[15:29] <robru> dobey: only if you've pushed packages to vivid overlay that depend on them? I dunno
[15:30] <dobey> robru: well i see the status says "Ready to build" in vivid for those packages now since cjwatson copied the xenial-proposed binaries in
[15:31] <robru> dobey: what request are you even talking about. i don't see it
[15:31] <cjwatson> is it possible it doesn't understand that those source packages are only needed in xenial and not vivid?
[15:31] <cjwatson> robru: 975
[15:31] <dobey> robru: 975
[15:32] <dobey> cjwatson: right, that's what i'm thinking
[15:32] <robru> cjwatson: dobey: well you guys have the silo set as a dual silo, so that means it wants everything in xenial and vivid
[15:32] <cjwatson> there's another approach available for this, but this would be the simplest one
[15:33] <cjwatson> robru: no way to make an exception for a few packages then?
[15:33] <dobey> really the autopkgtests should be running against proposed
[15:33] <robru> cjwatson: no, a dual silo is a dual silo. but if those are manual packages you can just copy the vivid versions into the silo and it'll be happy with that.
[15:34] <cjwatson> dobey: well, I'd like to avoid pulling in random other stuff I don't know about
[15:34] <cjwatson> and pitti tells me silos in general deliberately don't because that causes other problems
[15:34] <dobey> cjwatson: right, but i mean, i don't see how this hasn't been a problem already, given the PPAs build against -proposed.
[15:34] <cjwatson> dobey: maybe it has occasionally and has been worked around in similar ways
[15:35] <cjwatson> robru: does that seem reasonable to you?  it potentially results in duplicate packages in the overlay
[15:35] <dobey> robru: will it be happy if the same versions are already in the target?
[15:35] <dobey> i guess it will be ok
[15:35] <cjwatson> it'll be fine in xenial, I just don't want to create cruft in vivid
[15:35] <robru> cjwatson: what do you mean duplicate? if they're packages that are already in the overlay just copy what's in the overlay. train will just see it as a successfully published package rather than something needing to be built
[15:35] <dobey> cjwatson: i guess they won't be duplicate in the overlay. it'll just treat them as already copied
[15:36] <cjwatson> robru: I suspect these are only in the base archive, not the overlay
[15:36] <cjwatson> no particular reason they would've been overlaid at any point
[15:36] <cjwatson> well, not all of them anyway
[15:36] <dobey> well yeah
[15:36] <dobey> -meta will be in the overlay
[15:36] <dobey> but jsoncpp and capnproto probably not
[15:36] <robru> cjwatson: ok, my recommendation is just copy whatever from vivid archive and then delete from overlay ppa after publishing the silo.
[15:36] <cjwatson> mkay
[15:37] <cjwatson> thanks
[15:37] <robru> yw
[15:37] <dobey> i think we do just need to fix these autopkgtests to always run against proposed though
[15:38] <cjwatson> pitti has just finished telling me how the effects of that were worse
[15:38] <cjwatson> 15:13 <pitti> as that is in many cases unintended and led to too many blockings
[15:38] <cjwatson> so I mean you can argue it out with him, but he seems to have taken a decision based on data ...
[15:39] <dobey> well, that blockage is going to happen when things get published to -proposed anyway; but sure, it will maybe make things block a bit more in silos
[15:45] <davmor2> ChrisTownsend: approved libertine
[15:45] <ChrisTownsend> davmor2: Thank you very much!
[15:58] <dobey> hmm, i guess it's not entirely happy about that
[16:01] <cjwatson> I don't know if the "diff missing" stuff actually matters
[16:01] <cjwatson> had to copy in cmake too, so there'll be another cycle here
[16:06] <cjwatson> but at least unity-scopes-api and qtcreator-plugin-ubuntu are now passing
[16:06] <cjwatson> (not green on excuses yet but they should be when it next updates)
[16:13] <Trevinho> Laney: can you ACK https://requests.ci-train.ubuntu.com/#/ticket/873 ?
[16:25] <dobey> cjwatson: ok, cool, hopefully it is happy now then
[16:26] <cjwatson> hmm
[16:26] <cjwatson> robru: "Diff missing" is going to prevent this getting anywhere, isn't it?
[16:26] <robru> cjwatson: define "getting anywhere"
[16:27] <cjwatson> robru: reaching the "Successfully built" state
[16:27] <dobey> robru: "qa: ready"
[16:27] <robru> cjwatson: it's not going to stop britney running on it
[16:27] <robru> cjwatson: also trivially fixed by running the build job with "DIFF_ONLY" set
[16:28] <cjwatson> aha
[16:28]  * cjwatson will do that
[16:43] <Laney> Trevinho: what is:
[16:43] <Laney> -	rm -f debian/tmp/usr/share/compiz/networkarearegion.xml
[16:43] <Laney> -	rm -f debian/tmp//usr/lib/compiz/libnetworkarearegion.so
[16:43] <Laney> ?
[16:46] <Trevinho> Laney: it was a plugin that we didn't use in ubuntu anymore since long time.. It was still built, though. So I just disabled it from CMake instead of removing the built bits
[16:48] <Laney> ok!
[16:52] <Laney> Trevinho: I should publish it?
[16:56] <dobey> yay, got past installation now
[17:03] <cjwatson> dobey,pstolowski: can you have a look at<EMAIL_ADDRESS>?
[17:05] <pstolowski> cjwatson, yes, that's the test flakiness that is going to be disabled with https://code.launchpad.net/~dobey/unity-scope-click/temp-no-int-tests/+merge/285079
[17:05] <dobey> cjwatson: ah, i can fix that. i need to disable it in two places
[17:06] <cjwatson> well, the test is retrying anyway for reasons, if it's just flaky then maybe it will pass next time
[17:06] <dobey> cjwatson: well, the MP in that silo is supposed to disable the tests for now. but i forgot we were actually running them against the installed scope in the autopkgtests too, so need to update the branch to disable there and rebuild unity-scope-click in that silo
[17:08] <cjwatson> dobey: ok
[17:08] <dobey> cjwatson: and just started the rebuild. hopefully it will be quick
[17:09] <cjwatson> ta
[17:09] <cjwatson> it'll retrigger unity8 autopkgtests, so that'll take a while
[17:09] <cjwatson> but with any luck this should all go through without my intervention now
[17:10] <cjwatson> and hopefully this can get quickish QA
[17:11] <dobey> right
[17:15] <dobey> ok, i'm going to go get lunch.
[17:37] <robru> alright! fun times. anybody need the train urgently for the next 2 hours? I'm gonna do a big rollout...
[17:38] <robru> (britney/autopkgtests/ppas unaffected, just source builds might be a bit delayed)
[17:58] <Trevinho> Laney: yeah, if you can...
[17:58] <Laney> ok
[18:00] <Trevinho> Laney: why that? ^
[18:02] <Laney> shrug
[18:02] <Laney> it's working now
[18:06] <Trevinho> :)
[18:12] <dobey> robru: ugh, your timing sucks ;)
[19:58] <dobey> huh
[20:02] <dobey> i think i found a bug in the autopkgtests running in silos, but i'm not quite sure how/where to report it
[20:03] <dobey> or it's not a bug and things are slow enough to just be annoying/confusing
[20:11] <dobey> i wonder if the currently "running" stuff has passed yet
[20:15] <dobey> ok, who can i bug from qa right now
[20:16] <dobey> alesage: can you be our qa savior?
[20:18] <alesage> dobey, not sure yet, more info pls
[20:21] <dobey> alesage: xenial -proposed is highly blocked at the moment, and silo 37 fixes it. we've been trying to get everything sorted so qa can review it (it's a dual landing silo), and it's about ready. but we want to get it through asap to get things unblocked
[20:22] <dobey> so there are some silos that can't build on xenial at the moment as a result of this blockage, which means they can't land until it's unblocked
[20:24] <alesage> dobey, not sure what you're asking for
[20:25] <dobey> alesage: to get https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-037/excuses.html onto the qa trello, tested, and passed, so we can publish it and unblock everyone
[20:25] <dobey> err
[20:25] <dobey> https://requests.ci-train.ubuntu.com/#/ticket/975
[20:25] <dobey> not the excuses
[20:27] <alesage> dobey, unlikely we'd get to it until someone better qualified can answer :) , also not able to parse test failures
[20:27] <dobey> alesage: the one failed on that excuses page is the older unity-scope-click build; the newer one would pass.
[20:28] <dobey> (and did pass)
[20:38] <dobey> alesage: whom would be better qualified to answer, that would be awake in our TZs?
[20:38] <dobey> well, awake and working, as opposed to awake and at the pub
[20:40] <alesage> dobey, we're all busy with a release atm, unlikely to find an ear until EU AM
[20:42] <dobey> :(
[22:53] <cjwatson> dobey: I just poked it
[22:54] <cjwatson> dobey: (I only bothered with armhf)
[23:46] <cjwatson> dobey: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-037/excuses.html \o/
[23:46] <cjwatson> I guess the train will notice in a bit
[23:47] <cjwatson> michi: 37 passes autopkgtests now.  What I eventually did was copy various other packages into the silo from -proposed which had previously needed to be rebuilt against libjsoncpp1, in order that the system knows to test them all together.
[23:47] <cjwatson> The copy back to -proposed when you publish should be a no-op.


 @AdamOutler I'm thinking of replacing the sb8200 for the cm1000. What do you think?
 Linux distro hacked on GitHub, “all code considered compromised” – Naked Security … https://nakedsecurity.sophos.com/2018/06/29/linux-distro-hacked-on-github-all-code-considered-compromised/
 RIP Gentoo
 I don't know @govatent  have you seen issues that are resolved?
 I'm having tons of disconnects
 Called arris they say it's Comcast. Comcast says signals are fine
 So im gonna swap it for a cm1000 if I still have issues I'll yell at Comcast
 I'm not having issues that I know of.
 I would probably know
 Does anyone need one of my large sd/micro/USB holders in red?
 I'm testing settings for warpage and I think I got it down.  Last one was perfect.  I'd like to run it again but I don't want to throw it away.
 How big did you manage to go?
 Only 3 on the MPSM. But I could go 4,5...9 on my larger printer
 Heated bed was causing warpage. Bed must be 55C to prevent warpage and minimum extruder temp which produces good material.
 It depends on the filament, I go between 50C and 65C for PLA/PETG and ~80C for ABS
 65 is too high for any PLA I've used.
 hey, @KMyers do you have any wood filament?
 Not alot but in 10 rolls I've been through, 60 was the max and it warped a little.
 It responds well to some of the PLAs I have, I rarely go that high but I do at times
 @Ivoriesablaze, I do indeed
 can you make my print out of that?
 The controller holders? I would advise you choose a different model as the wood is not as strong as normal PLA so the interlocking links would be bad
 ah, ok
 carbon fiber?
 Yeah.  It's brittle because of the wood particles
 @Ivoriesablaze, Carbon Fiber is best for looks, not strength in this case. Look for a different model if you want it done in one of those
 Abs
 do you have plain black?
 I do
 Anything special about these?  Cup holder?  Candy dispenser?
 Its a game controller holder but it has interlocking links to allow multipe to hang from one
 Oh.  I was thinking like locking holders into the side.  Got it.
 I might chance wood with a high infill depending on the design and sheer lines
 Any 90° turns?
 @Ivoriesablaze do you have the link for the model handy? I have the STLs on my other machine and am not near it at the moment
 one sec
 https://www.thingiverse.com/thing:1618293
 @govatent what's up with VMware not supporting unity mode on linux, huh???
 That's a definite maybe for wood.  But I would bet on it.  Black PLA or PETG I would likely be best due to the potential for flexation during setting the controller on it.
 @govatent are you at the honey pot thing?
 I was going to go, but I am working on my Android Auto setup with fiberglass
 @ahoneybun thanks for the idea!
 Ah the Pi thing?
 Yep
 @KMyers !!!!!!!!! HNNNNNGHHHH !!!!!! https://www.thingiverse.com/thing:2490185
 @Ivoriesablaze I haven't tried. What issue did you run into?
 @AdamOutler is that an HM talk about honey pots? Don't forget I now live in Denver
 @AdamOutler best buy allowed me to get another sb8200. So far I'm not getting hundreds of correctables. I may have had a bad modem
 Oh crap. Yeah.
 That makes sense.
 There's no unity mode for Linux host
 Roger that


[14:47] <akgraner> Good Morning
[14:47] <akgraner> :-)
[14:47] <akgraner> I'm going to be working on some links for a couple hours
[14:48] <akgraner> People have mentioned UWN is too LONG
[14:48] <akgraner> so I am thinking 2-3 sentences for all the sections except - General Community News and LoCo News
[14:49] <akgraner> nhandler, what is the best way to set up an are on the new fridge so that UWN will have a searchable area
[14:50] <nhandler> akgraner: Do you mean so that we can search all of the UWN articles for a particular topic?
[14:50] <akgraner> it you click on the UWN link and it will take you to a page where you can then see the current issue and have it searchable by topic
[14:50] <akgraner> at first I just want to get a current issue added and see how we can search it etc
[14:51] <akgraner> once we get that fixed - we can then go back and bring in the archives - I have people ask me for ways to search back issues all the time
[14:51] <nhandler> akgraner: I don't think WP lets you search like that. It sounds more like something you would use Ctrl+F for (or a javascript hack that we could add)
[14:52] <akgraner> (I know I know it's a hell of a lot of work  - so there is no hurry  - just seeing what is possible)
[14:52] <akgraner> ahhh ok
[14:52] <akgraner> I'll poke around at it this weekend
[14:52] <akgraner> and see if I can't some more content
[14:53] <nhandler> akgraner: Maybe add a note to the top of the UWN reminding people about using Ctrl+F to search it
[14:53] <akgraner> I think we could probable tell people about it in issue 207 - and start testing it publicly if we can get content added over the next week
[14:53] <akgraner> nhandler, no what people were asking is how to see a list of say all LoCo stories from each issue etc
[14:53] <akgraner> without having to open everyone one of them
[14:54] <akgraner> I am not sure it's an easy thing
[14:54] <nhandler> akgraner: Ah, ok. That is definitely possible. I'm not sure if the simple search we currently have would support it, but we could probably find an advanced search box that lets you restrict the search to a certain category/tag
[14:54] <nhandler> And then have all UWN in that category or with that tag
[14:55] <akgraner> yep
[14:55] <akgraner> so like I said - priority is adding more content and getting it to a point where we can test it out and see what people like and don't like and get some feedback
[14:56] <akgraner> so I'll work on adding content to the sections that are already there
[14:56] <akgraner> Does that sound doable this week?  or is it too aggressive you think?
[14:57] <akgraner> not for you to do all the work or anything just wondering your opinion on that goal and timeline
[15:00] <nhandler> akgraner: I just downloaded the fridge rss feed and imported it to the new site. That should give us some content to play around with
[15:01] <akgraner> Thanks!  I know one of the biggest complaints about the UWN Feed is it takes 3 clicks to get to the full issue
[15:01] <akgraner> which is why I wanted to get the full issue on it's own page on the site
[15:02] <akgraner> we don't have to put the full issue on the Front page
[15:02] <nhandler> akgraner: Let me play around with that a bit later. Having a page for UWN is definitely possible though
[15:03] <akgraner> nhandler, thanks!
[15:14] <akgraner> Daviey, ping
[15:14] <Daviey> o/
[15:14] <akgraner> Daviey, nm looks like Jamie pinged you about mootbot-uk?
[15:15] <Daviey> jah
[15:15] <akgraner> Daviey, I am giving Jamie the link to the how to so he knows what files to look for and all that stuff
[15:16] <Daviey> splendid!
[21:06] <akgraner> hey folks!  looks like I'll be working on the news letter tomorrow :-)  sometimes re-organizing doesn't always go as I had hoped :-)
[21:13] <akgraner> where the heck does time go?
[21:14] <akgraner> ahhhhhhh!!!!!