[14:31] <didrocks> o/
[14:31] <eslerm> o/
[14:32] <sarnold> good morning
[14:32] <dviererbe> o/
[14:33] <didrocks> ok, I think this is only us, let me lead the meeting
[14:34] <didrocks> #startmeeting Weekly Main Inclusion Requests status
[14:34] <meetingology> Meeting started at 14:34:24 UTC.  The chair is didrocks.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:34] <didrocks> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
[14:34] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:34] <didrocks> #topic current component mismatches
[14:34] <didrocks> Mission: Identify required actions and spread the load among the teams
[14:34] <didrocks> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:34] <didrocks> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:34] <didrocks> c-m-p: I don’t see anything new, the whole mm/pp stack is in discussion with the desktop team
[14:35] <didrocks> c-m: all good too, nothing to add
[14:35] <didrocks> #topic New MIRs
[14:35] <didrocks> Mission: ensure to assign all incoming reviews for fast processing
[14:35] <didrocks> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
[14:36] <didrocks> the status is incorrect on all of them
[14:36] <didrocks> jbicha: please, look at https://github.com/canonical/ubuntu-mir for the correct status, it should be New once ready for review
[14:36] <sarnold> is it? the process states section has "new/confirmed" even on step 1
[14:37] <didrocks> oh, I still had the old wiki version in mind :)
[14:37] <jbicha> In this case, I specifically chose Confirmed, but LP automatically upgrades bugs to Confirmed if someone clicks "this affects me" :/
[14:37] <didrocks> ah, that was maybe why it was changed to it
[14:37] <didrocks> ok, my bad then :)
[14:38] <didrocks> sorry for the false ping
[14:38] <didrocks> ok, so we need to split them
[14:38] <didrocks> but as I’m the only non security member here, I think nobody else can take any other?
[14:39] <didrocks> and I don’t want to assign for joalif or jamespage with them being away
[14:39] <jbicha> the 5 packages are fairly similar to each other
[14:39] <didrocks> I can take a second for the next pulse but can’t act more, I already have one
[14:39] <sarnold> yeah, at this point it's probably just a question of "how many does didrocks want?" :)
[14:40] <didrocks> sarnold: we agreed with management to take 2 by pulse
[14:40] <didrocks> this pulse was already full, so next pulse, I already have 1
[14:40] <sarnold> heh
[14:40] <didrocks> + another one
[14:40] <sarnold> sounds like the start of the cycle, indeed
[14:40] <didrocks> but it means I can’t take anymore for the next 2 pulses
[14:40] <didrocks> sorry 2 weeks*
[14:41] <didrocks> so meh, let’s do that, and maybe that will convince people to add more people to the MIR team :)
[14:41] <didrocks> I think libglibmm is the one making more sense, isn’t it jbicha?
[14:41] <jbicha> that's fine with me to start there
[14:42] <jbicha> oh it actually depends on libsigc++-3.0 though
[14:42] <didrocks> jbicha: I see that most of them have a bunch of lintian warnings, some could be fixed if we are working on debian, is it the case?
[14:42] <jbicha> libsig actually has a symbols file already :)
[14:42] <sarnold> \o/
[14:43] <jbicha> my opinion is that the lintian warnings are harmless, but yes I can fix things in Debian if needed
[14:43] <didrocks> jbicha: at worst with lintian override? that way, you get a clean list, and when a new one is introduced, you will notice it rather than being list in the existing list
[14:43] <didrocks> thanks!
[14:43] <didrocks> ok, taking libsigc++ first
[14:44] <didrocks> if joalif or jamespage reads afterwards, please, take one on the list ^
[14:44] <sarnold> "national-encoding"?
[14:45] <didrocks> #topic Incomplete bugs / questions
[14:45] <didrocks> Mission: Identify required actions and spread the load among the teams
[14:45] <didrocks> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir
[14:45] <jbicha> sarnold: I try to ignore m4 files
[14:45] <sarnold> jbicha: ahh, apparently, as did I, I saw the 'x86_64-linux-gnu' and assumed it was an .so :)
[14:46] <didrocks> ok, on the incomplete list, only tagging and other in progress comments as far as I can see
[14:46] <didrocks> let’s move on
[14:46] <sarnold> duktape assigned to band_ali, probably for todos?
[14:46] <didrocks> right
[14:46] <sarnold> and cargo, similar, tagged
[14:46] <didrocks> yep
[14:46] <didrocks> #topic Process/Documentation improvements
[14:46] <didrocks> Mission: Review pending process/documentation pull-requests or issues
[14:46] <didrocks> #link https://github.com/canonical/ubuntu-mir/pulls
[14:46] <didrocks> #link https://github.com/canonical/ubuntu-mir/issues
[14:47] <didrocks> unsure I will have time to go to your PR dviererbe this week, but nice to see this work!
[14:47] <dviererbe> No problem :)
[14:48] <didrocks> I think for typos, an approval from a peer is enough to merge
[14:48] <sarnold> ooo is there an easy way to see the rendered flowchart?
[14:48] <dviererbe> Just go to my repo
[14:48] <dviererbe> https://github.com/dviererbe/ubuntu-mir/tree/modernize-process-states-overview
[14:48] <sarnold> dviererbe: ah!
[14:48] <eslerm> \o/
[14:48] <didrocks> that’s nice, I didn’t know that was rendered by GH!
[14:49] <dviererbe> I just learned about that this week
[14:49] <didrocks> just used mermaid today and rendered a svg…
[14:49] <didrocks> so ok, I have some PR to open :)
[14:50] <didrocks> ok, let’s move to the next section
[14:50] <didrocks> #topic MIR related Security Review Queue
[14:50] <didrocks> Mission: Check on progress, do deadlines seem doable?
[14:50] <didrocks> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
[14:50] <didrocks> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
[14:50] <didrocks> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
[14:50] <didrocks> Internal link
[14:50] <didrocks> - ensure your teams items are prioritized among each other as you'd expect
[14:50] <didrocks> - ensure community requests do not get stomped by teams calling for favors too much
[14:50] <didrocks> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[14:50] <didrocks> sarnold:  anything to mention at this point?
[14:51] <sarnold> didrocks: eslerm finished cpdb-libs last week \o/ :) and we've assigned tasks around
[14:51] <didrocks> ironic that for once, you are more on the security side than the reviewer side :p
[14:51] <eslerm> I'm working on dbus-broker
[14:51] <didrocks> oh, that will make seb128 happy
[14:51] <eslerm> someone signed up for cargo, but since it is incomplete I'll suggest other cargo dependencies
[14:52] <didrocks> unsure we got a conclusion on the maintaince side yet
[14:52] <didrocks> yeah
[14:52] <didrocks> ok, so good progress on that front :)
[14:52] <didrocks> #topic Any other business?
[14:52] <sarnold> the one missing piece from dbus-daemon does seem like a large risk..
[14:52] <didrocks> exactly
[14:53] <didrocks> and we need to know where we are heading to, to prevent doing a MIR security review check for nothing
[14:53] <sarnold> we're not interested in *two* running dbus daemons, one for system and one for user
[14:53] <eslerm> I could hold off for now
[14:53] <didrocks> maybe check with seb128 first, as he was the one checking with foundation IIRC
[14:54] <didrocks> apart from breaking dbus (oh wait… broker, not breaker :p) anything else to note?
[14:54] <eslerm> I'll ping ~mir-security-review-priority on MM
[14:54] <didrocks> sounds good to me
[14:54] <sarnold> I think eslerm ought to continue onwards; dbus is an integral part of everything, and getting issues with it sorted out as early as possible seems like a good approach
[14:54] <eslerm> I'll just do what Seth suggests :D
[14:54] <didrocks> ack!
[14:55] <sarnold> and even if we decide to stick with what we've got because it meets gdm's needs, maybe we'll find useful things for upstream to work on before we return
[14:56] <sarnold> oh yes! we missed the .../issues/ section earlier
[14:56] <sarnold> https://github.com/canonical/ubuntu-mir/issues
[14:56] <sarnold> I just added one about team members :) and eslerm added one a few days ago https://github.com/canonical/ubuntu-mir/issues/22
[14:56] -ubottu:#ubuntu-meeting- Issue 22 in canonical/ubuntu-mir "re-ACK after a set time period" [Open]
[14:56] <didrocks> https://github.com/canonical/ubuntu-mir/issues/24 has been "opened" for years
[14:56] -ubottu:#ubuntu-meeting- Issue 24 in canonical/ubuntu-mir "More team members" [Open]
[14:57] <didrocks> yeah, agreed on 22, but it’s also blocked on 24 still
[14:57] <didrocks> anyway, I think we should discuss processes when more team members are around, wdyt?
[14:57] <eslerm> +1
[14:57] <dviererbe> +1
[14:57] <sarnold> now that it's written down somewhere, I can trust cpaelzer will be annoyed enough by it to try to drive that through to an answer of how we do this :)
[14:57] <didrocks> heh, sounds good!
[14:58] <sarnold> that's it for me
[14:58] <didrocks> ok, going once…
[14:58] <didrocks> going twice…
[14:58] <didrocks> and here we go! Thanks everyone :)
[14:58] <sarnold> thanks didrocks, dviererbe, eslerm, jbicha  :)
[14:58] <didrocks> #endmeeting
[14:58] <meetingology> Meeting ended at 14:58:40 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-05-30-14.34.moin.txt
[14:58] <dviererbe> Thanks everyone!
[14:58] <eslerm> thanks for hosting didrocks \o/
[14:58] <didrocks> yw! Have a good week
[18:56] <rbasak> o/
[18:57] <amurray> o/
[19:00] <seb128> hey! :)
[19:00] <rbasak> seb128: o/ you're up to chair I think?
[19:00] <seb128> yes
[19:01] <seb128> #startmeeting Technical Board
[19:01] <meetingology> Meeting started at 19:01:04 UTC.  The chair is seb128.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[19:01] <meetingology> Available commands: action, commands, idea, info, link, nick
[19:01] <seb128> #topic Action Review
[19:02] <seb128> ups
[19:02] <seb128> #topic Apologies
[19:02] <seb128> I don't see any on the list/wiki
[19:02] <seb128> Lukasz doesn't seem to be online though
[19:03] <seb128> anyway, let's move one
[19:03]  * vorlon waves
[19:03] <seb128> #topic Action Review
[19:03] <seb128> ACTION: amurray to follow up with backporters team on Mattia's draft charter proposal
[19:03] <seb128> amurray, did you get a reply since the previous meeting?
[19:03] <amurray> No - I've sent two emails to the backporters team asking them to ack mattia's proposal but had no response still
[19:04] <seb128> :-/
[19:04] <rbasak> :-(
[19:04] <rbasak> At the last meeting I said this:
[19:04] <rbasak> It'd be nice to see a conclusion on this. I wonder if it would be appropriate to set a deadline at some point, and if no reply then we just use the current draft and call it done. I wouldn't mind it being long eg. months, but it'd be nice to have _some_ end point.
[19:04] <seb128> I'm +1 with that
[19:04] <rbasak> We've already adjusted the draft to their suggestion, dropping what I had originally proposed.
[19:05] <vorlon> also +1
[19:05] <rbasak> Could we agree that this draft becomes final at some future date now, and encourage the backporters team to engage with us if they disagree?
[19:05] <amurray> I agree - how about I send one more follow-up later today and stipulate that if we get no response within another 2 weeks (that would be over 1 month since my original email asking for their ack) then this will become final
[19:05] <rbasak> eg. two months from today, so 30 July.
[19:05] <rbasak> Sure.
[19:06] <vorlon> I think that should be the default.  We want the involved teams to be on board with what we rule, but if they're not going to engage, it's the TB who has the authority here
[19:06] <rbasak> I'm easy on the actual date as long as we set one :)
[19:06] <seb128> I was going to suggest start of July, seems similar timeframe
[19:06] <rbasak> Sounds like we're all on the same page, so as amurray is driving I suggest he sets the date as he feels appropriate.
[19:06] <seb128> +1
[19:07] <amurray> sure - I prefer going with say 2 weeks to avoid this dragging on much longer
[19:07] <rbasak> Sure
[19:08] <seb128> so June 13 ?
[19:08] <rbasak> FWIW, we should also work with some of the other teams to establish some similar documentation. I'm not trying to single out the backporters team here! In the past few years, questions have arisen on the scope of the DMB's role, as well as AAs.
[19:09] <amurray> I suggest June 12th - that way it falls just before the next TB meeting
[19:09] <rbasak> +1
[19:10] <rbasak> Though, to be clear, I don't think it should take a further TB meeting to agree. We're agreeing it now :)
[19:10] <rbasak> (but I welcome further discussion at a TB meeting should it arise)
[19:10] <amurray> indeed - but this way at that meeting we have a clear outcome with any luck
[19:11] <seb128> #agreed  amurray to send one more follow-up later today to the backporters team and stipulate that if we get no response before June 12th then this will become final
[19:11] <meetingology> AGREED: amurray to send one more follow-up later today to the backporters team and stipulate that if we get no response before June 12th then this will become final
[19:11] <vorlon> also means that if there is any feedback given on the current draft we can quickly ratify those changes
[19:12] <rbasak> seb128: o/
[19:12] <seb128> k, let's move on?
[19:12] <seb128> rbasak, yes?
[19:12] <rbasak> Minor point: "if we get no response before" -> that sounds like if they respond, then it won't become final.
[19:12] <seb128> how do I edit an agreed? :p
[19:13] <rbasak> But I think we just agreed to make it final regardless, on 12 June, unless the TB (and only the TB) decide otherwise before that date.
[19:13] <rbasak> You can use #undo
[19:13] <seb128> #undo
[19:13] <meetingology> Removing item from minutes: AGREED
[19:13] <rbasak> Then #agreed something else
[19:13] <seb128> thanks
[19:14] <seb128> #agreed  amurray to send one more follow-up later today to the backporters team and stipulate that we set June 12th as the limit for changes to the draft unless the TB decides otherwise
[19:14] <meetingology> AGREED: amurray to send one more follow-up later today to the backporters team and stipulate that we set June 12th as the limit for changes to the draft unless the TB decides otherwise
[19:15] <seb128> better?
[19:15] <rbasak> Sure
[19:15] <rbasak> Thanks
[19:15] <seb128> thanks!
[19:15] <seb128> moving on
[19:15] <seb128> ACTION: seb128 to help draft an exception to the "must build on all architectures" requirement for snaps
[19:15] <rbasak> I'll discuss the status of the draft in a bit.
[19:15] <rbasak> But we're a bit blocked on this now :-/
[19:16] <seb128> sorry, I've still been struggling with finding time for those items but rbasak started editing which pushed me to go back to it now
[19:16] <seb128> ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage
[19:16] <seb128> similar
[19:16] <seb128> ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
[19:16] <rbasak> Carry this please - I've been focused on the other thing
[19:16] <seb128> ACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step
[19:17] <rbasak> Carry again I guess, as he's not here
[19:17] <seb128> Lukasz is not around today so that's another carry over
[19:17] <seb128> #topic Scan the mailing list archive for anything we missed (standing item)
[19:17] <seb128> nothing recent on the list
[19:17] <rbasak> I see some emails from amurray :-P
[19:17] <seb128> lol
[19:17] <seb128> #topic Check up on community bugs and techboard bugs
[19:18] <rbasak> Oh, did we lose the progress item on the third party repository requirements doc in general? I'd like to discuss that please.
[19:18] <amurray> same
[19:19] <seb128> rbasak, I was expecting that it come as an AOB since we don't have a specific item on the agenda for it
[19:19] <rbasak> ack
[19:19] <seb128> but yes we should add it back as an action
[19:19] <seb128> #info No new community bug activity
[19:19] <seb128> #topic Select a chair for the next meeting
[19:20] <seb128> next would be vorlon and if we follow the ordering on the launchpad page Lukasz as a backup
[19:21] <seb128> #info vorlon will chair next, with sil2100 as backup
[19:21]  * vorlon nods
[19:21] <seb128> #topic third party repository requirements status update
[19:21] <seb128> rbasak, ^
[19:22] <rbasak> I have been working on the doc and I think it's ready. Apart from the appendices and the wording of the "build on all architectures exception" for the desktop packages that I think, we agree we need.
[19:22] <vorlon> fwiw I have another topic for AOB after this
[19:22] <rbasak> Next, I'd like to publish this for wider feedback.
[19:22] <rbasak> Before I do that, could the TB please review the main body of the document and check you're happy with it?
[19:22] <rbasak> Perhaps we could give all TB members an opportunity to do that before our next meeting?
[19:22] <vorlon> sounds good to me
[19:22] <amurray> rbasak: so I noticed there is nothing in the document regarding testability- ie. how do we integrate a seeded snap with britney?
[19:23] <rbasak> And unless there are any further comments from the TB, I'll present that as the TB's draft position, pending further feedback.
[19:23] <rbasak> amurray: I'm not sure I follow
[19:24] <amurray> do we want to stipulate that a seeded snap must be able to be tested / have some tests that can be run to ensure it is "stable" before being released?
[19:24] <rbasak> I think we should definitely do those things. But I'm not sure it should be within the scope of this doc - just as we leave the specifics of how to test debs up to Ubuntu developers.
[19:25] <rbasak> For example a package can be a deb in the Ubuntu archive with no tests whatsoever - that's currently permitted, even if it's not best practice.
[19:25] <seb128> well we have a MIR process, it sort of opens the question of it should apply to snaps that we want seeded
[19:25] <rbasak> Currently the MIR team may decide to permit something in main without tests though, without involvement of the TB.
[19:26] <rbasak> So in my mind, for a seeded snap, we're leaving that kind of decision to the Ubuntu developer making the change (in the seed, presumably).
[19:26] <rbasak> It's a good question though.
[19:27] <amurray> I don't want to be too specific here - but I do want to make sure that we can maintain quality for any third party packages and I see testing as a big part of that
[19:27] <rbasak> Do you think we should require something? And if so, would we require this for debs as well?
[19:27] <rbasak> amurray: I see your concern addressed by "Proposed requirement C: the package maintainer agrees to maintain the package for the lifetime of the Ubuntu release" already
[19:27] <rbasak> And the paragraph that says "the precise meaning of "maintain", is enforced by trust only"
[19:28] <rbasak> IOW - we agree that this is important, but we aren't dictating the specifics
[19:28] <vorlon> agreed w/ rbasak on this
[19:28] <seb128> but should a pre-installed snap get a +1 from the MIR team?
[19:29] <vorlon> I like that idea but think we should discuss it with the MIR team first to make sure they're comfortable taking on that duty
[19:30] <amurray> for debs we have britney and proposed-migration that enforces a level of quality on SRUs (assuming there are dep8 tests etc) by doing automated testing - if cups becomes a snap, how do we make sure it doesn't regress on updates in future releases? a lot of stuff depends on cups so I see this as important (as a topical example)
[19:30] <rbasak> I have no objection to a process requirement to get a review from some appropriate team
[19:30] <rbasak> But whether that's the TB, the MIR team, or some new kind of snap-MIR team, is an open question I think.
[19:31] <rbasak> Another option might be to start softer - by requiring such changes to be announced eg. to ubuntu-devel@ and be done before eg. feature freeze. That would allow the TB to object, but without the friction of a team requiring an approval.
[19:32] <rbasak> Or indeed to give some notice before doing it
[19:32] <rbasak> (or committing to doing it)
[19:33] <rbasak> amurray: would that address your concern with your cups example?
[19:33] <amurray> yes I think that would work
[19:34] <amurray> thanks
[19:34] <rbasak> So I'm open to any of the above. I would add it as a snap-specific policy requirement in the document (so into appendix C)
[19:34] <rbasak> Which of those options should I take?
[19:35] <rbasak> Personally I think I'd favour "soft, with notice" if that works for everyone?
[19:35] <amurray> +1
[19:36] <seb128> +1
[19:36] <vorlon> +1
[19:37] <rbasak> I'll write that up then. Thanks!
[19:37] <amurray> thank you :)
[19:37] <rbasak> So, to summarise, homework for the TB: you have until the next meeting to study the doc and raise any other concerns you may have at the next meeting.
[19:38] <rbasak> And I'll write up the "snap MIR" process (just notice) requirement into appendix C.
[19:38] <rbasak> Any other comments on this topic for today?
[19:38] <vorlon> none from me
[19:39] <seb128> #agreed the TB members have until the next meeting to review the third party repository requirements document and raise concerns
[19:39] <meetingology> AGREED: the TB members have until the next meeting to review the third party repository requirements document and raise concerns
[19:39] <seb128> #topic AOB
[19:39] <seb128> vorlon, ?
[19:40] <vorlon> last meeting we talked about the question of core teams governance
[19:40] <vorlon> I had just sent an email to the private thread, which I understood folks had the action to review and reply to?
[19:40] <vorlon> I haven't seen any responses yet :)
[19:40] <rbasak> Oh, right
[19:41] <rbasak> IIRC, we said we'd make it public today?
[19:41] <seb128> yes, in fact I wanted to mention that, it's another of those action items I failed at acting on
[19:41] <vorlon> going back to meeting log to see what we said
[19:41] <seb128> would people be ok to postpone until the next meeting?
[19:42] <vorlon> https://irclogs.ubuntu.com/2023/05/16/%23ubuntu-meeting.html#t19:10
[19:42] <seb128> Lukasz hasn't been around/commented on it
[19:42] <rbasak> Sure. The thread hasn't had any activity recently. Perhaps we could agree that all further discussion on that topic can be expected to be public?
[19:42] <vorlon> weeks were given and no objections were raised, so maybe "replay the thread but publicly" is the correct next action here?
[19:42] <rbasak> +1
[19:42] <seb128> wfm
[19:42] <amurray> +1
[19:43] <vorlon> in which case I guess it would be an action for seb128 to kick it off? :)
[19:43] <vorlon> if I correctly understand what is meant by "replay"
[19:43] <rbasak> That was my wording IIRC, and yes I think you do.
[19:44] <seb128> #agreed seb128 to resend 'core teams governance' email to the public techboard list
[19:44] <meetingology> AGREED: seb128 to resend 'core teams governance' email to the public techboard list
[19:44] <rbasak> Because if seb128 posts it, then I can provide basically the same reply I did privately, and then the public will be able to follow my position/opinion on it.
[19:44] <seb128> #undo
[19:44] <meetingology> Removing item from minutes: AGREED
[19:44] <seb128> #agreed seb128 to resend the 'core teams governance' email to the public techboard list
[19:44] <meetingology> AGREED: seb128 to resend the 'core teams governance' email to the public techboard list
[19:44] <seb128> any other AOB?
[19:45] <amurray> nothing from me
[19:45] <vorlon> nor me
[19:45] <rbasak> None from me.
[19:45] <seb128> ok, it's a wrap then, thanks everyone!
[19:45] <rbasak> Thank you all for a productive meeting!
[19:45] <seb128> #endmeeting
[19:45] <meetingology> Meeting ended at 19:45:21 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-05-30-19.01.moin.txt
[19:45] <sarnold> (heh "any other AOB" :)
[19:45] <vorlon> thanks, all!
[19:45] <seb128> sarnold, :p
[19:45] <vorlon> sarnold: "AOOB"
[19:45] <sarnold> lol
[19:45] <amurray> thanks folks


[00:01] <mhall119> sbalneav, do I remember correctly that you're a Gnome developer?
[00:54] <Ahmuck> any suggestions for webdav/caldav/groupdav?
[00:55] <Ahmuck> i've looked at a couple, sogo, bedework
[00:55] <Ahmuck> iirc, one of them can work in conjuction with moodle
[00:55] <Ahmuck> and schooltool
[01:57] <mhall119> I think there is an apache module for webdav
[05:15] <sbalneav> mhall119: Yes
[05:15] <stgraber> sbalneav: we have an issue ;)
[05:16] <sbalneav> what's up?
[05:16] <stgraber> sbalneav: basically, if sabayon is installed you never get to a gnome desktop
[05:16] <sbalneav> !?
[05:16] <sbalneav> I've got it installed right now
[05:16] <stgraber> I've been doing test rebuild for the last 2 hours and I'm currently dropping sabayon off the seed and meta so we can get a working alpha-2
[05:16] <stgraber> yeah, on a desktop it's fine
[05:17] <stgraber> it's failing in the live environment
[05:17] <sbalneav> Oh, ok, I've never tested it there.
[05:18] <stgraber> only issue is that it's extremely difficult to debug ...
[05:18] <sbalneav> does the current dvd have it on?
[05:18] <stgraber> if you happen to have the image 20100103 you'll notice the issue, for testing I rebuilt that same image myself => still the use, then without sabayon => working desktop
[05:18] <stgraber> yeah, that's why I've been rushing to drop it so we at least have a bootable alpha-2
[05:19] <sbalneav> k, how do I rsync the current dvd so I can test it.
[05:19] <stgraber> actually, I've been spending two hours trying to debug it before choosing to drop it off the dvd ;)
[05:19] <sbalneav> it's the apply that'll be failing
[05:19] <stgraber> that's what I suspected too but it's not the case and that's where it gets very very weird
[05:20] <stgraber> I have an image here with sabayon installed, the Xsession.d script removed and it's still failing to load a desktop
[05:20] <sbalneav> well, it has to be the sabayon-apply, that's the only thing that would get run
[05:20] <alkisg> Good morning guys. What ltsp version is in alpha-2? Is the one with the ldm segfaulting problem fixed? (the 2 nbd-client processes) - some people are asking to test the fat clients script...
[05:20] <stgraber> alkisg: I didn't upload a new ltsp yet, I'll be doing that after alpha-2 is released
[05:21] <stgraber> sbalneav: rsync -tzhhP rsync://cdimage.ubuntu.com/cdimage/edubuntu/dvd/20100113/lucid-dvd-i386.iso .
[05:21] <stgraber> that'll get you the broken image
[05:21] <stgraber> it's been confirmed on both amd64 and i386
[05:21] <alkisg> Ugh so it's broken :( ok I'll tell them to wait for a new LTSP upload, and to update before installing ltsp.
[05:21] <sbalneav> stgraber: ok, rsyncing now
[05:22] <sbalneav> just go ahead and drop it, I'll figure out what's causing the failure.
[05:22] <alkisg> stgraber: I'd like to test and do the 010-fat-client => 030-fat-client commit before your next ltsp upload, do I have 1-2 days to do so?
[05:23] <stgraber> alkisg: I'm planning on uploading it tomorrow afternoon, once I've nbd-proxy running properly, so for you that's almost a day ;)
[05:24] <alkisg> It'll suffice, thanks :)
[05:24] <sbalneav> I was figuring if it was on the disk it would install on the text based installer. I wasn't expecting it to be in the live environment.
[05:24] <stgraber> sbalneav: we added it to the edubuntu-desktop package as a recommends, so it's everywhere
[05:24] <sbalneav> ah
[05:24] <sbalneav> well, if it's breaking things on live, by all means, ditch it.
[05:25]  * sbalneav scratches head
[05:25] <alkisg> sbalneav: there isn't any >= 1000 uid user on the live cd, would that matter?
[05:25] <stgraber> I'm doing some tests here, trying to alter a broken image during its boot sequence so I can debug it
[05:25] <sbalneav> sabayon-apply pretty much just bails if there's no users.xml or groups.xml
[05:25] <stgraber> regenering a whole DVD image takes me almost an hour so it makes debugging extremely painful ;)
[05:25] <sbalneav> right.
[05:26] <sbalneav> for debugging, could we mount -bind something ?  I'm assuming you can log in on a text console
[05:26] <stgraber> you can't logon
[05:26] <stgraber> vt1 is a broken X, vt2 is some console showing "Authentication failure", vt7 is another broken X
[05:27] <stgraber> other VTs are dead
[05:27] <sbalneav> ouch
[05:27] <stgraber> yeah, I'm really wondering how sabayon can do that ;)
[05:27] <stgraber> because I get all VTs working correctly once it's gone ;)
[05:27] <sbalneav> shouldn't be possible
[05:27] <stgraber> ok, found a way to change a broken DVD at boot time, let's try to get some debug info ;)
[05:28] <sbalneav> geez, teach me to take an evening off to go to Robbie Burns night at lodge :)
[05:29] <stgraber> only thing I get is "Authentication failure" repeated 10 times on vt1 and broken X ...
[05:29] <stgraber> let's reboot and drop sabayon, then I'll try dropping the sabayon user and group, then the python code, then ...
[05:30] <stgraber> alkisg: we'll need some iso testing during night here in Canada, will you be able to test the Edubuntu DVD images ?
[05:31] <stgraber> alkisg: if you have already one somewhere, you can use the command I gave sbalneav to update it
[05:31] <stgraber> alkisg: I'd really like to have an Edubuntu alpha-2 release as we didn't have alpha-1 and we are very very close to release time
[05:32] <alkisg> stgraber: will do. When should I rsync? In a few hours?
[05:33] <stgraber> alkisg: look at http://iso.qa.ubuntu.com/qatracker/build/edubuntu/all
[05:33] <alkisg> OK, I have the amd64 version, I'll test that.
[05:34] <stgraber> I just marked them both as invalid, they'll be marked as ready for testing once they are rebuilt
[05:34] <stgraber> ok, Xsession.d is really not at fault, trying to drop the user and group now
[05:38] <sbalneav> if [ "$1" = "configure" ] ; then
[05:38] <sbalneav>     if ! getent group sabayon-admin >/dev/null; then
[05:38] <sbalneav>         groupadd --system sabayon-admin
[05:38] <sbalneav>     fi
[05:38] <sbalneav>     if ! getent passwd sabayon-admin >/dev/null; then
[05:38] <sbalneav>         useradd --system --home /var/run/sabayon-admin \
[05:38] <sbalneav>             -c "Sabayon user" --gid sabayon-admin sabayon-admin
[05:38] <sbalneav>         mkdir -p /var/run/sabayon-admin
[05:38] <sbalneav>         chown sabayon-admin:sabayon-admin /var/run/sabayon-admin
[05:38] <sbalneav>     fi
[05:38] <sbalneav> fi
[05:38] <sbalneav> that's the postinst for sabayon
[05:38] <sbalneav> which is what it's been, packaging wise, for a while
[05:39] <sbalneav> the only thing I've done to the postinst is add --system
[05:39] <sbalneav> since the user and groupids should be < 1000
[05:42] <sbalneav> I notice on my system the userid and groupid are 999, which is unusual for a system id
[05:43] <sbalneav> could that be a problem?   what's the live user's id?
[05:45] <stgraber> sbalneav: on removal, it says that the sabayon-admin group doesn't exist
[05:45] <stgraber> and if I remove sabayon after the initramfs script it still doesn't work
[05:45] <stgraber> so something is conflicting with sabayon inside the initramfs ...
[05:46] <sbalneav> Well, I don't know how live cds actualy work, but as a normal package, it doesn't put anything anywhere CLOSE to an initramfs.
[05:47] <stgraber> ok, seems like the ubuntu user isn't getting created for some reason
[05:47] <sbalneav> it's gotta be something with the userids and group ids or homedir it creates
[05:49] <stgraber> uid is 999
[05:49] <stgraber> for the livecd user
[05:49] <stgraber> and so is sabayon-admin's
[05:50] <stgraber> the uid for the livecd user is hardcoded in the script
[05:50] <sbalneav> how's sabayon getting 999
[05:51] <sbalneav> hmm
[05:51] <sbalneav> other scripts seem to use adduser
[05:51] <sbalneav> wheras the sabayon postinst uses useradd
[05:51] <stgraber> no idea but that's the uid it got when installed in the live environment ...
[05:52] <sbalneav> ok, if I update the postinst, and push something to my ppa, do we have enough time to try?
[05:52] <sbalneav> or are you ready to collapse
[05:52] <sbalneav> this can wait 'till the next alpha
[05:52] <stgraber> we won't make it for alpha-2, the DVD is already building and it takes at least two hours before we can retry another one
[05:52] <sbalneav> ok, well, we know what the problem is: faulty sabayon postinst
[05:53] <stgraber> though I'd like to have that fixed ASAP so the next DVD build after alpha-2 can be tested to make sure we have that fixed
[05:53] <sbalneav> I'll fix it right now
[05:53] <sbalneav> gimme 10
[05:54] <stgraber> well, calling useradd isn't "wrong", adduser is a debian-specific script on top of useradd
[05:54] <stgraber> what I just don't get is why --system assigns the highest uid and not the lowest
[05:57] <stgraber> though all packages seem to use adduser
[05:57] <stgraber> so let's use adduser and it'll fix everything (at least it should)
[05:58] <stgraber> oh, or just add: -K UID_MIN=1
[05:58] <stgraber> that should fix the issue
[06:00] <stgraber> nope, doesn't work, just use adduser ;)
[06:00] <sbalneav> yep, one sec
[06:01] <stgraber> and also use addgroup instead of groupadd
[06:01] <stgraber> as the gid will be the next issue we'll have otherwise ;) (I noticed it's also 999 so would also conflict)
[06:03] <sbalneav> I've just converted it to a adduser --group
[06:04] <sbalneav> single lne
[06:04] <sbalneav> Stole it from the nbd postinst script
[06:04] <sbalneav> package is building now
[06:07] <sbalneav> works
[06:07] <sbalneav> uids are low now
[06:07] <sbalneav> 118 or so
[06:07] <sbalneav> on my box here
[06:07] <sbalneav> what's faster, grabbing something from my ppa, or me pasting the postinst here
[06:07] <sbalneav> #!/bin/sh
[06:07] <sbalneav> set -e
[06:07] <sbalneav> if [ "$1" = "configure" ] ; then
[06:07] <sbalneav>     if ! id sabayon-admin >/dev/null 2>&1; then
[06:07] <sbalneav>         adduser --system --group --home /var/run/sabayon-admin \
[06:07] <sbalneav>             sabayon-admin
[06:07] <sbalneav>     fi
[06:08] <sbalneav> fi
[06:08] <sbalneav> #DEBHELPER#
[06:08] <stgraber> I can upload that in like 10s
[06:08] <stgraber> though we found what was causing useradd to use 999
[06:08] <stgraber> it's a bug in /etc/login.defs
[06:09] <sbalneav> ah, so we've uncovered a bug in another program with our packaging :)
[06:09] <sbalneav> geez, stgraber, this has caused you a headache for sure.  Man, am I sorry.
[06:10] <stgraber> no problem ;)
[06:11] <stgraber> slangasek and persia are now debating about adduser and useradd not respecting /etc/login.defs and having their own configuration ;)
[06:11] <sbalneav> the original packaging from the old programs used useradd, but before, they didn't use --system
[06:11] <stgraber> something is clearly broken and will need fixing
[06:12] <sbalneav> you must have had that convo in the secret ubuntu-dev channel
[06:12] <sbalneav> it's not in regular ubuntu-devel :)
[06:12] <stgraber> it's in ubuntu-testing actually ;)
[06:12] <sbalneav> ah
[06:12] <sbalneav> heh
[06:15] <sbalneav> so does that seem to fix things?
[06:15] <sbalneav> spose we'll have to wait till the next daily build :(
[06:15] <stgraber> it should
[06:16] <sbalneav> so we won't have this for alpha 2 then.
[06:16] <stgraber> ok, sabayon uploaded
[06:17] <stgraber> nope, we won't have it for alpha-2 but we'll have the build just after and people updating their alpha-2 will get it too
[06:18] <sbalneav> perfect.
[06:18] <sbalneav> Well another bug squashed.
[06:19] <sbalneav> Sabayon seems cursed.
[06:19] <sbalneav> broken like heck, fix it.
[06:19] <sbalneav> Sabayon works, gksu breaks.
[06:19] <sbalneav> fix that
[06:19] <sbalneav> sabayon works, gksu works, useradd breaks :)
[06:20] <stgraber> hehe
[06:21]  * stgraber goes to revert his change on the seed + meta
[06:22] <stgraber> seed done
[06:28] <sbalneav> stgraber: Next BTS, all your drinks and dinners are on me :)
[06:28] <sbalneav> ok, the old fart's exhausted
[06:28] <sbalneav> I'm off to bed, you get some sleep too
[06:29] <stgraber> good night :)
[06:29] <stgraber> drings and dinners, sounds interesting :) I'll need to make a note of that ;)
[06:30] <stgraber> *drings (yeah, it's late)
[06:30] <stgraber> *drinks (..... keyboard)
[10:54] <alkisg> highvolt1ge: I think the edubuntu live dvd is still broken due to sabayon, can you help? (e.g. remove it from the seeds)?
[10:54] <alkisg> Or should we wait for stgraber?
[10:54] <alkisg> (it'll be too late then, won't it?)
[12:25] <highvolt1ge> alkisg: my sync will finish shortly then I could test as well, but stgraber will have to make the seed changes
[12:26] <alkisg> highvolt1ge: ok, that was with the i386 build, I'll try now with the amd64 one
[12:27] <ogra> you guys should really subscribe to lucid-changes ;)
[12:27] <ogra> edubuntu-meta (1.76) lucid; urgency=low
[12:27] <ogra>   * Refreshed dependencies
[12:27] <ogra>   * Added sabayon to desktop-gnome-recommends
[12:28] <ogra> seems he just added it today
[12:29] <alkisg> ogra: he removed it because it broke autologin and then added it right afterwards because they supposedly found a fix :-/
[12:29] <ogra> ah
[12:30] <alkisg> But that fix was in useradd or something like that (stgraber talked to some ubuntu devs in #ubuntu-testing, I didn't see the convo)
[12:30] <ogra> sabayon (2.29.5~rc1-0ubuntu2) lucid; urgency=low
[12:30] <ogra>   * Change postinst to user adduser instead of useradd (by Scott Balneaves).
[12:30] <ogra>     (Fixes Live CD bug where sabayon would have the same UID as the live user)
[12:30] <alkisg> Anyway now sabayon user id = 999, the same as the live user id, and that makes login impossible
[12:30] <ogra> check if your iso has that sabayon version on it
[12:31] <alkisg> k
[12:31] <mhall119> sbalneav, jono just posted that Canonical is looking to hire a couple Gnome devs
[12:32] <alkisg> ogra, I got a question though, "how can I check sabayon version in a CD where I cannot login?" :D
[12:32] <alkisg> Mount iso, mount squashfs and chroot?
[12:33] <ogra> the manifest file
[12:33] <alkisg> Ah, looking...
[12:33] <ogra> on cdimage where you downloaded your iso ;)
[12:33] <ogra> (manifest for live, .list file for alternate)
[12:34] <alkisg> sabayon 2.29.5~rc1-0ubuntu1
[12:35] <alkisg> Hmmm so the cd spin whatsyamacallit that stgraber did before he slept didn't get the new version
[12:37] <alkisg> highvolt1ge: so we need to request a new build of the dvd...
[12:53] <highvoltage> stgraber: eek, did you get much sleep at all?
[13:15] <stgraber> highvoltage: a bit over 4 hours ;)
[13:16] <stgraber> alkisg: I requested another respin, we should have another image in 1-2 hours including a working sabayon
[13:16] <stgraber> sbalneav will be happy ;)
[13:17] <alkisg> stgraber: nice! Now get back to bed :)
[13:19] <stgraber> nah, I'm at the office now, starting to work for a full day + server hardware change this evening so I'll be leaving quite late ;)
[13:24] <alkisg> While trying the new fat client script, I'm getting a lot of those messages, should I be worrying?
[13:24] <alkisg> debconf: (Failed to open fd 3: Bad file descriptor at (eval 24) line 3)
[13:26] <stgraber> as long as it's during ltsp-build-client, that's fine
[13:26] <alkisg> Yes, and it complains about initializing the passthough environment. Thanks, I'll ignore it
[13:48] <dgroos> Good morning
[13:50] <alkisg> highvoltage: any objections on commiting this updated fat client script in a while, when I'm done testing? http://ltsp.pastebin.com/m7bc4e0c5
[13:50] <dgroos> I'm still getting no success with iTALC--I still get the message: Somebody tried to access this computer but could not authenticate itself successfuly! I've done a complete removal of iTALC, I've tried installing both on the server and on the client--no luck.  Currently I'm installed on the client.
[13:55] <dgroos> googling hasn't helped, nor has this page: https://help.ubuntu.com/community/UbuntuLTSP/iTalc.  I'm guessing it's a key problem, but don't know how to check/fix.
[13:55] <alkisg> dgroos, alpha 2 is to be out in a few hours, so if you don't get enough help on troubleshooting iTalc today, try again tomorrow
[13:55] <alkisg> That wiki page needs to be deleted :D
[13:55] <alkisg> Usually `sudo apt-get install italc-master` on the server, and logoff/logon is ALL that is needed.
[13:55] <alkisg> But people start installing it to the chroot and things get complicated... :)
[13:56] <dgroos> I'll purge and give a re-try, thanks.
[13:56] <dgroos> Good luck everyone on alpha 2--Thanks for your work!
[13:56] <alkisg> Also try a complete reboot to make sure there aren't hang processes around
[14:03] <highvoltage> alkisg: that looks much nicer!
[14:03] <highvoltage> alkisg: thanks
[14:50]  * sbalneav hugs stgraber
[14:50] <sbalneav> stgraber: how late were you up last night?
[14:51] <sbalneav> ogra
[14:51] <sbalneav> alkisg
[14:52] <alkisg> Hi sbalneav
[14:52] <sbalneav> the problem was, sabayon was using useradd for adding users
[14:52] <sbalneav> but useradd wasn't respecting login.defs, and so was creating the sabayon user as uid 999
[14:52] <sbalneav> which is what the live cd's hard-code the live id to be.
[14:52] <alkisg> I saw that much, but was useradd fixed?!!
[14:53] <sbalneav> No, don't think so.
[14:53] <alkisg> I thought the debian utils didn't respect login.defs by design...
[14:53] <alkisg> (/etc/adduser.conf)
[14:53]  * ogra loks up from bootloader hacking
[14:53] <ogra> oh, hi sbalneav :)
[14:53] <alkisg> ogra, bootloader? Are we going to have a new syslinux version? :P :D
[14:54] <ogra> alkisg, u-boot ...
[14:54] <ogra> all ARM stuff
[14:54]  * alkisg gets his arm dictionary...
[14:55] <sbalneav> anywho, most other postinsts seem to use adduser and not useradd, so I just converted it to that.
[14:55] <sbalneav> I've never changed much in the packaging, other than the deps as they've changed.
[14:56] <sbalneav> so that's a bug that's been there a while.
[14:56] <sbalneav> but seeing as how sabayon's been broken for 3+ years... :)
[14:57] <stgraber> sbalneav: 2am or so
[14:58] <alkisg> sbalneav: well since postinst is a debian thing anyway, it makes sense to use adduser... I'll resync in a few hours and test again :)
[15:02] <sbalneav> stgraber: You young kids and your stamina :)
[15:04] <alkisg> Hmm can some guru help here? http://ltsp.pastebin.com/m2f291da6
[15:04] <alkisg> That's right after the fat client script tries to run `tasksel install ubuntu-desktop`
[15:05] <alkisg> 030-fat-client: http://ltsp.pastebin.com/m21c6359a
[15:09] <ogra> alkisg, isnt APT_GET_OPTS already set properly ?
[15:09] <ogra> oh, you re-enable it
[15:09] <ogra> nm
[15:10] <alkisg> ogra, it is, should I use apt-get $APT_GET_OPTS install ubuntu-desktop instead of tasksel?
[15:10] <ogra> n o, tasksel is the right way
[15:12] <ogra> i wonder if you couldnt do the last step a bit more elegantly with a file in /usr/share/gconf-defaults/
[15:13] <stgraber> Edubuntu 14.1 is on the mirror now
[15:14] <sbalneav> so we made it in for alpha-2 even with the sabayon respin?
[15:15] <ogra> sbalneav, non-official distros can even make A2 tomorrow
[15:15]  * sbalneav dances with ogra maniacally
[15:15]  * sbalneav give stgraber a big wet sloppy kiss
[15:15] <sbalneav> \o/
[15:15]  * ogra grins
[15:16] <stgraber> sbalneav: looks like we did yeah
[15:17] <ogra> congrats guys !
[15:17] <alkisg> ogra, about the file, that's why I put a # TODO there. The problem is the apt dying without explanations :-(
[15:19] <alkisg> Congrats everyone :)
[15:19] <alkisg> Can I spawn a shell with all the environment variables at that point?
[15:20] <ogra> alkisg, well, "tasksel: aptitude failed (100)" ... why did it fail, the error must be either above or in a log
[15:20] <ogra> the umount is only fallout
[15:20] <ogra> just add a line to your plugin that does it ...
[15:20] <ogra> before the tsksel runs
[15:20] <ogra> then run it manually
[15:21]  * alkisg looks at /opt/ltsp/i386/var/log/apt/history.log ...
[15:22] <alkisg> Ugh, I can't find anything useful there, so I'll just call a `sh` at that point.
[15:58] <highvoltage> stgraber: so these are the 14.1 images right? http://cdimage.ubuntu.com/edubuntu/dvd/current/
[15:58] <stgraber> yep
[15:59] <highvoltage> it should be a quick sync at least :)
[16:23] <alkisg> Damn when I spawn a shell during ltsp-build-client, and run tasksel manuall from there, everything works fine, I even get a whiptail GUI... :-/
[17:08] <sbalneav> ok, I've officially (in my upstream roll) released 2.29.5
[17:08] <sbalneav> or sabayon
[17:13] <highvoltage> my rsync is taking way longer than expected :/
[17:17] <ogra> you wanted a DVD ;)
[17:20] <highvoltage> heh :D
[17:25] <stgraber> sent 448.44K bytes  received 359.61M bytes  261.94K bytes/sec
[17:25] <stgraber> so you need 360MB to get from 13.1 to 14.1
[17:27] <highvoltage> I synced with 14.0 earlier though
[17:36] <alkisg> stgraber: I tested the amd64 version and seems fine, do I need to "submit" my test results somewhere?
[17:36] <highvoltage> http://iso.qa.ubuntu.com/qatracker/build/edubuntu/all
[17:36] <ogra> alkisg, isotracker
[17:37] <alkisg> Uh, I prolly have to test teh "Install (debian-installer LTSP)" stuff as noone did it yet
[17:39] <alkisg> "Enter your Ubuntu QA username." ?
[17:40] <ogra> thats where you type in your ubuntu QA username :)
[17:40] <alkisg> So much for the openid launchpad stuff :)
[17:44] <ogra> finally a proper avatar summary http://i834.photobucket.com/albums/zz268/fotoslamenza/Fotos-fds/43/photopodborka_152.jpg :)
[17:46] <highvoltage> *g*
[18:59]  * alkisg gives up on `tasksel install edubuntu-desktop-gnome`, I can't find any logs about the "tasksel: aptitude failed (100)" problem anywhere... :(
[21:23] <highvoltage> so alternate i386 fails
[21:23] <highvoltage> (with LTSP installation)
[21:23] <highvoltage> it can't find the package ltsp-server-standalong
[21:24] <ogra> is it in the pool dir ?
[21:24] <ogra> or completely missing from the CD
[21:24] <highvoltage> one moment...
[21:25] <highvoltage> ogra: seems that it's not in the pool directory
[21:25] <ogra> well, then its missing from the seed somehow
[21:25] <highvoltage> ogra: in pool/main/l/ltsp there's an ltsp-client-builder and ltsp-server, but not ltsp-server-standalone
[21:26] <ogra> at this point thats rather something for a release note though, talk to slangasek (when he gets up again)
[21:27] <highvoltage> ok
[21:27] <ogra> and prepare some text for a note :)
[21:28] <highvoltage> "Whatever you do, don't choose the LTSP option from the installer!!!!"
[21:28] <ogra> heh
[22:08] <stgraber> highvoltage: we shouldn't even have that LTSP install option anymore, so it's really not an issue, we should just release note it
[22:08] <stgraber> we only have ltsp-server on the DVD as it's what will be needed for LTSP once it's moved to the live environment and dropped from the on-dvd archive
[22:08] <stgraber> and only reason why the on-dvd archive still contains everything is because I haven't found a way to get rid of that extra 1.5GB of package ...
[22:13] <nixternal> oi oi edubuntu'erz!!
[22:14] <nixternal> I have had the week from hell...I have done so much work, but I couldn't tell you what the heck I did :/
[22:15] <nixternal> I checked out Edubuntu docs and started to cry a little bit :(  needs a bit of work, but I don't think it needs a ton of work, considering we can leverage ubuntu-docs, though we might want to actually fork their docs and change screenshots, or something like that
[22:16] <nixternal> actually, not fork them, because they have translations, maybe have edubuntu-docs install ubuntu-docs first, and then replace screenshot images...if it is at all that important, as they look the same except for color
[22:23] <highvoltage> stgraber: ok
[22:25] <highvoltage> nixternal: I don't think people are too picky about wallpapers, since that's the first thing most people change anyway
[22:25] <highvoltage> nixternal: I guess we should have a docs day too
[22:26] <stgraber> highvoltage: we did mention planning one at some point after FF
[22:26] <highvoltage> stgraber: indeed, wow and it's crawling closer ever faster
[22:27] <highvoltage> nixternal: I think it's just been one of those kind of weeks
[22:34] <nixternal> that it has...trying to finish up a ton of stuff before FF
[22:34] <nixternal> have about 10 MIRs I have yet to do :)


[06:40] <oSoMoN> good morning desktoppers
[06:50] <jibel> Hi all
[06:51] <oSoMoN> salut jibel
[07:01] <duflu> Morning oSoMoN and jibel
[07:01] <duflu> Did time zones change recently?
[07:02] <duflu> Or am I just confused when Didier doesn't log in super early?
[07:06] <oSoMoN> hey duflu
[07:07] <oSoMoN> no change in time zones as far as I'm concerned, it's probably Didier's absence that's confusing you indeed
[07:07] <seb128> good morning desktopers!
[07:08] <oSoMoN> salut seb128
[07:08] <seb128> lut oSoMoN, en forme ?
[07:08] <oSoMoN> seb128, ça va, et toi?
[07:08] <duflu> Morning seb128
[07:08] <seb128> ça va nickel :)
[07:08] <seb128> hey duflu, how are you today?
[07:08] <duflu> Ha. I should have noticed pulseaudio HEAD^ was tagged v12.99.2
[07:09] <duflu> seb128, going OK. How are you?
[07:09] <seb128> I'm fine thanks
[07:09] <seb128> duflu, or use our version page :)
[07:09] <seb128> would be nice if it would be possible to filter a specific set of packages you are interested in though
[07:10] <duflu> I do. Like with bugs and merge requests, just don't subscribe. Poll instead :P
[07:10] <duflu> Though I subscribe to plenty of bugs already. Just not all
[07:15] <duflu> seb128, I just remembered we prefer to base our PulseAudio on Debian's pristine-tar. So to avoid branching that a pristine-tar of 12.99 would ideally be put in salsa first
[07:15] <duflu> .99 is often included there
[07:15] <seb128> duflu, right
[07:22] <seb128> marcustomlinson, hey, I'm reviewing the libreoffice update in NEW
[07:22] <seb128> -help-common has
[07:22] <seb128> Replaces: libreoffice-common (<< 1:6.1.0~alpha1-1)
[07:23] <seb128> shouldn't that be updated to the previous version in Ubuntu? e.g 1:6.2.5-0ubuntu1
[07:37] <seb128> RAOF, hey, there is a new colord 1.4.4 version available, do you think you could do the update when you get some spare cycles?
[07:39] <RAOF> seb128: Sure!  Looks like the arm64 build is still busy though...
[08:36]  * seb128 needs to hack into jasmesh's phone to set up a weekly calendar reminder :)
[08:37] <marcustomlinson> https://launchpad.net/ubuntu/+source/libreoffice/1:6.3.0-0ubuntu1/+build/17408406
[08:37] <seb128> marcustomlinson, right, my comment on NEW from earlier is from that update, that's where -help-common was added in Ubuntu right?
[08:37] <marcustomlinson> seb128: sorry I lost the scrollback
[08:37] <marcustomlinson> seb128: yes that was added
[08:38] <seb128> marcustomlinson, https://irclogs.ubuntu.com/2019/08/13/%23ubuntu-desktop.html#t07:15
[08:38] <seb128> marcustomlinson, I think you need to update the C/R versions
[08:38] <seb128> otherwise those are not going to work for Ubuntu user upgrading from 6.2 to current
[08:38] <seb128> since it's << 6.1
[08:39] <marcustomlinson> seb128: ah
[08:39] <marcustomlinson> ok will fix that
[08:39] <seb128> thx
[08:39] <seb128> don't upload only for that, as said I need to do the poppler transition and we will need an upload for it
[08:40] <seb128> but first let me try in a ppa :)
[08:40] <GunnarHj> Good morning seb128!
[08:40] <GunnarHj> I would like to put language-selector in a repository. Thinking that it would fit here:
[08:40] <GunnarHj> https://code.launchpad.net/~ubuntu-desktop/+git
[08:40] <GunnarHj> but thought I'd ask first.
[08:41] <seb128> hey GunnarHj, how are you?
[08:41] <GunnarHj> seb128: I'm fine, thanks. Hope you are too.
[08:41] <seb128> GunnarHj, sounds good to me to have it in the desktop section yes
[08:41] <seb128> I'm good yes, thanks
[08:42] <GunnarHj> seb128: Then I'll make an attempt to put it there - without history, that is.
[08:42] <Laney> hi duflu oSoMoN seb128 GunnarHj
[08:42] <seb128> hey Laney, how are you?
[08:43] <Laney> doing alright
[08:43] <seb128> Laney, I can help this afternoon with the e-d-s transition if that's still needed
[08:43] <seb128> trying to clear off some other updates this morning still before though
[08:43] <Laney> you/
[08:43] <Laney> yes pls
[08:43] <seb128> k, will do
[08:43] <Laney> or gnome-desktop rebuilds needed in that silo too
[08:44] <seb128> k, I will try to help with that as well
[08:44] <oSoMoN> marcustomlinson, seb128: sorry I overlooked that when I reviewed the debdiff yesterday, thanks for catching it seb128
[08:44] <seb128> oSoMoN, np!
[08:44] <Laney> GunnarHj: is there no proper bzr branch for that?
[08:44] <GunnarHj> Laney: Nope. Martin killed it some years ago. Not sure why.
[08:45] <Laney> we had the LP bzr branches then
[08:45] <seb128> https://bazaar.launchpad.net/~ubuntu-core-dev/language-selector/ubuntu/view/head:/README
[08:45] <seb128> ubuntu: are the auto imported ones right?
[08:45] <Laney> they were, don't exist any more
[08:46] <Laney> GunnarHj: maybe one of the git-ubuntu branches would be an OK one to start from
[08:46] <Laney> at least you'd get the history as one commit per upload
[08:47] <GunnarHj> Laney: Yeah, I can try start out from one of those.
[08:47] <marcustomlinson> seb128: oh so you don't need me to upload a new 1:6.3.0-0ubuntu2 for LO?
[08:47] <seb128> marcustomlinson, not now, let's wait for the poppler soname change, we need a rebuild anyway
[08:48] <marcustomlinson> ok
[08:48] <seb128> we can keep 6.3 in eoan-proposed meanwhile
[08:48] <Laney> GunnarHj: and the '+source' namespace is probably the right one to be using
[08:49] <Laney> lp:~ubuntu-desktop/ubuntu/+source/languge-selector
[08:52] <GunnarHj> Laney: Ok. Let's see if I can fix it.
[08:52] <Laney> neato
[09:08] <jamesh> Laney: with the e-d-s API break you mentioned, does that affect the D-Bus IPC interface as well as the library ABI?
[09:09] <jamesh> i.e. is this just a case of getting rid of the old client libraries, or will old apps refuse to talk to new EDS and vice versa?
[09:15] <Laney> jamesh: The Calendar D-Bus API has changed too: some methods and signals have been renamed
[09:16] <Laney> I don't know of anything in the archive that talks to that directly - things go via bindings
[09:16] <jamesh> Laney: so, we've currently got calendar-service and contacts-service snapd interfaces
[09:17] <Laney> e-d-s does this kind of thing most cycles FWIW
[09:17] <ricotz> marcustomlinson, hi, the B/R are wrong and please use (<< 6.3)
[09:18] <marcustomlinson> ricotz: yes you're right good catch
[09:20] <jamesh> Laney: we definitely have a gnome-calendar snap, but I don't think we've ever seeded it
[09:21] <Laney> I'm not sure what they do for Flatpak
[09:21] <Laney> but e-d-s isn't a stable interface ... probably applications bundle it
[09:21] <jamesh> I'm not sure how widely it is installed
[09:22] <jamesh> It has been relatively stable for a while: xenial to bionic has been fine
[09:22] <jamesh> we've also got a gnome-contacts snap
[09:23] <ricotz> marcustomlinson, hmm :(, please literally use (<< 6.3.0)
[09:24] <marcustomlinson> okidokie
[09:24] <ricotz> thx
[09:24] <ricotz> with epoch ;)
[09:25] <marcustomlinson> yeah
[09:26] <Laney> The C ABIs have certainly changed in that timeframe - if the D-Bus API hasn't been affected, then we got lucky
[09:26] <Laney> that's why the bus names are suffixed with a number
[09:26] <Laney> AddressBook is at 9 currently ...
[09:31] <jamesh> I suspect the interfaces would allow a snap built with new client libraries to talk to new EDS without change, since it looks like the versioning is only in bus names rather than interface names
[09:31] <jamesh> but we will need to decide what to do with the gnome-calendar/gnome-contacts snaps
[09:32] <jamesh> You can still see some of the CORBA roots in the EDS API design
[09:36] <GunnarHj> Laney: Good enough?
[09:36] <GunnarHj> https://code.launchpad.net/~ubuntu-desktop/ubuntu/+source/language-selector/+git/language-selector
[09:48] <Laney> GunnarHj: Looks good from a quick glance
[09:48] <Trevinho> morning!
[09:49] <GunnarHj> Laney: Good. I make a change later today and check if it works as expected.
[10:46] <duflu> Morning Trevinho
[10:46] <duflu> Night Trevinho :)
[11:20] <seb128> hey Trevinho
[11:21] <Trevinho> hi seb128
[11:33] <seb128> Laney, Trevinho, would be nice if you could clear the 3 remaining july cards in trello :)
[11:35] <Laney> ok
[11:35] <seb128> thx
[13:22] <seb128> Laney, you probably know, when opening a bug on the BTS by sending to submit@ can you include some commands like the blocks one?
[13:22] <seb128> or can you CC control@? or do you need a follow up email?
[13:30] <seb128> k, it's meeting time right?
[13:31] <seb128> startmeeting Desktop Team Meeting 2019-08-13
[13:31] <seb128> #startmeeting Desktop Team Meeting 2019-08-13
[13:31] <meetingology> Meeting started Tue Aug 13 13:31:15 2019 UTC.  The chair is seb128. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[13:31] <meetingology> Available commands: action commands idea info link nick
[13:31] <seb128> Roll call: didrocks (out), duflu (out), jamesh (out), jibel, kenvandine (out), laney, marcustomlinson, oSoMoN, tkamppeter, trevinho, robert_ancell (out)
[13:31] <marcustomlinson> \o
[13:31] <oSoMoN> o/
[13:32] <Laney> hi
[13:33] <seb128> k, let's get started, quite some people on holidays atm
[13:33] <seb128> #topic rls-bb-bugs
[13:33] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[13:33] <seb128> https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1740894
[13:34] <seb128> That was a failed SRU because it requires systemd change and would make some configs stop working while fixing others
[13:34] <seb128> I will follow up with OEM
[13:34] <seb128> that's the only one on this list
[13:35] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html
[13:35] <seb128> there is a new split bug for the era thing/gucharmap and seems mathieu/gunnar on looking at it
[13:35] <seb128> I will just assign to mathieu
[13:36] <seb128> and that's it for bionic
[13:36] <seb128> #topic rls-dd-bugs
[13:38] <seb128> (sorry had some machine hang issue, thx libreoffice build pushing the ssd...)
[13:38] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-incoming-bug-tasks.html
[13:38] <seb128> no desktop here
[13:38] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-tracking-bug-tasks.html
[13:38] <seb128> same gucharmap era
[13:38] <seb128> #topic rls-ee-bugs
[13:39] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-incoming-bug-tasks.html
[13:39] <seb128> no desktop
[13:39] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-incoming-bug-tasks.html
[13:39] <seb128> the bugs there are assigned
[13:39] <seb128> #topic update_excuses_by_team.html#desktop-packages
[13:40] <seb128> Laney, your turn, sorry I/we failed to review the ones currently in the board last week
[13:40] <seb128> post-holidays & pre-ff busy time :/
[13:41] <Laney> no worries
[13:41] <Laney> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
[13:42] <Laney> I didn't look at the greyed out stuff yet
[13:42] <Laney> but in the non greyed stuff most is pre existing from the previous weeks
[13:42] <Laney> or part of transitions which I think are being handled by others
[13:42] <Laney> aptdaemon/1.1.1+bzr982-0ubuntu28: arm64 (log, history), i386 (log, history), ppc64el (log, history)
[13:43] <Laney> that's the only weird one I think, not sure what is happening there sO i'll make a new card for that one
[13:43] <Laney> it seems something happened with systemd in proposed while I was away that broke a lot of stuff?
[13:44] <seb128> yeah, they uploaded 243~rc1
[13:45] <seb128> which at least hits https://github.com/systemd/systemd/issues/13272
[13:45] <seb128> which b_alint raised here/consider as a gdm packaging bug
[13:45] <seb128> but I didn't look at the details of other issues in the update, I guess foundations is on it...
[13:45] <Laney> saw a card for that
[13:45] <Laney> but this was not just test failures in systemd itself
[13:45] <Laney> tons of other tests were failing
[13:46] <seb128> we should check with foundations if they are aware of those problems/on it
[13:46] <Laney> Balint said something in #ubuntu-devel about uploading a new systemd later
[13:46] <Laney> so I guess it's being worked on
[13:46] <Laney> bottom line for me was that proposed was a bit weird
[13:46] <seb128> good, let's wait for then and I will check with him if that's still not good enough
[13:46] <Laney> hopefully will be recovering
[13:47] <seb128> ack
[13:47] <Laney> that's why we have it I guess
[13:47] <seb128> thx Laney
[13:47] <seb128> #topic AOB
[13:47] <seb128> obvious one from me, but feature freeze is coming next week and we are on a tight schedule at this point
[13:47] <seb128> at least for the new GNOME uploads
[13:48] <seb128> also for nvidia UI changes (Olivier is starting on that)
[13:48] <seb128> and for some dock changes Marco is working on
[13:48] <seb128> if you have other features you still need to land/feel like we are getting late now is a good time to raise it/discuss our options
[13:48] <seb128>
[13:48] <seb128> that was from me I guess
[13:49] <seb128> Laney, anything that you feel like need more hands/discussion on the GNOME update front?
[13:49] <seb128> I think Marco/you/me are mostly on it and know what needs to be done, is that good enough?
[13:50] <Trevinho> I'm fine with how we're handling it
[13:51] <Laney> it's OK enough but there are still a fair few more packages to handle
[13:52] <seb128> right, we have a few people on holidays and I think everyone is busy, if anyone wants to take some time to help with that please just mention it on the channel any time and we can organize
[13:52] <seb128> oh also
[13:52] <seb128> jibel, you are back? can you look at the outdated daily ISO?
[13:53] <seb128> it seems to fail on
[13:53] <oSoMoN> happy to help with GNOME updates, just let me know which ones
[13:53] <seb128> 2019-08-05 20:25:16,456 ssh DEBUG: Setting up python (2.7.15~rc1-1) ...
[13:53] <seb128> 2019-08-05 20:25:16,456 ssh DEBUG: Setting up utah-common (0.19~git20190712.c2af2d5~ubuntu16.04.1) ...
[13:53] <seb128> 2019-08-05 20:25:16,456 ssh DEBUG: Standard error follows:
[13:53] <seb128> 2019-08-05 20:25:16,456 ssh DEBUG: dpkg: dependency problems prevent configuration of utah-common:
[13:53] <seb128> 2019-08-05 20:25:16,456 ssh DEBUG: utah-common depends on python (>= 2.7); however:
[13:53] <jibel> seb128, yes, I'm back. I promoted latest image to current. But still haven't found the reason of the breakage
[13:53] <seb128> 2019-08-05 20:25:16,456 ssh DEBUG: Package python is not installed.
[13:53] <seb128> jibel, ^ that's from the utah log joshua got
[13:53] <seb128> and it doesn't make any sense to me
[13:53] <seb128> it installs python and then says it's not available
[13:53] <seb128> I guess someone needs to log into the env and do those steps by hand and look what's going on
[13:53] <seb128> jibel, thx
[13:54] <jibel> yeah, that's a different failure from before my holidays which was a squashfs error
[13:54] <seb128> oSoMoN, great, thx, I will ping after the meeting then
[13:54] <oSoMoN> ok
[13:54] <seb128> k
[13:54] <seb128> any other topics?
[13:56] <seb128> seems not? let's wrap then
[13:56] <seb128> thanks team
[13:56] <seb128> #endmeeting
[13:56] <meetingology> Meeting ended Tue Aug 13 13:56:05 2019 UTC.
[13:56] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2019/ubuntu-desktop.2019-08-13-13.31.moin.txt
[13:56] <Laney> seb128: https://www.debian.org/Bugs/Reporting#control regarding your previous question
[13:56] <marcustomlinson> thx
[13:56] <Laney> you can do either of what you suggest
[13:56] <seb128> Laney, I had that on screen but it was not clear to me if I could include them in the original email sent to submit@
[13:57] <Laney> yeah you can, if you prefix with Control:
[13:57] <seb128> ok, thanks for confirming
[13:57] <Laney> think you have to leave no blank line after the Package: lines and stuff
[13:57] <seb128> Laney, I uploaded syncevolution and abiword for the eds transition
[13:57] <Laney> nice one
[13:58] <Laney> bet the stupid ubuntu only stuff needs work
[13:58]  * Laney avoided those ones
[14:00] <Laney> on the ISO stuff
[14:00] <Laney> how do you get to those errors if you start from https://platform-qa-jenkins.ubuntu.com/view/Eoan/job/ubuntu-eoan-desktop-amd64-smoke-default/ ?
[14:00] <seb128> Laney, I'm looking at the indicator-datetime and evolution-indicator
[14:01] <seb128> Laney, good question for jibel, I don't know, the log I had were the ones from joshua and paride
[14:03] <seb128> Laney, the BTS email seems to have worked :)
[14:03] <Laney> nice!
[14:03] <Laney> ok he linked to https://platform-qa-jenkins.ubuntu.com/job/ubuntu-bionic-desktop-amd64-smoke-default/427/artifact/log/utah-server-debug.log
[14:03] <Laney> bionic?!?!
[14:05] <jibel> Laney, https://platform-qa-jenkins.ubuntu.com/job/ubuntu-eoan-desktop-amd64-smoke-default/99/artifact/log/utah-85730.syslog.log but there is no unmet dep in the log
[14:05] <jibel> and the late command is successful
[14:06] <Laney> jibel: thanks, I found those ones too
[14:07] <Laney> think the python thing might have been a false lead maybe
[14:08] <jibel> maybe the demotion of python2 to universe broke something
[14:09] <seb128> that was suggested in some discussions while you were on holidays, it's on the same day it was demoted that it started failing
[14:09] <seb128> but those tests are on bionic infra so it doesn't make much sense
[14:10] <seb128> also universe is enabled by default on desktop install so python should be available in the installed system even once demoted
[14:10] <seb128> weird :/
[14:10] <Laney> it's a bionic *iso*
[14:10] <Laney> I don't think that log we got is evidence for that claim
[14:12] <seb128> yeah, we clearly need more debug info/be able to manually get into the env and see what is wrong there
[14:17] <jibel> I'm looking at eoan, why are you talking about bionic?
[14:18] <jibel> there hasn't been any built of bionic since the release of .3
[14:19] <jibel> and the infra is on 16.04
[14:19] <Laney> Josh sent an email with a log about python stuff in it, and it was thought this was the failure
[14:20] <Laney> but I just looked at it and he was talking about bionic for some reason, probably got confused
[14:20] <jibel> ok
[14:20] <jibel> build*
[14:22] <jibel> Laney, it's an error on shutdown. There is a squashfs error that prevents the VM from rebooting.
[14:22] <jibel> Laney, FTR I triggered a test from jenkins and watched the VM in virtmanager
[14:22] <Laney> ohh
[14:22] <Laney> you can just add venonat in virt-manager?
[14:22] <jibel> yes
[14:22] <Laney> hah
[14:23] <Laney> let me try this
[14:23] <jibel> with the vpn on
[14:24] <Laney> hmm, not as my user at least, permission denied
[14:24] <jibel> Laney, once you're connected open the console of utah-85765-...
[14:24] <jibel> ah let me check what's wrong with your permissions
[14:25] <Laney> yeah can't use virsh either
[14:26] <jibel> Laney, try again
[14:26] <jibel> hold on
[14:26] <jibel> Laney, try now
[14:28] <Laney> that works
[14:28] <Laney> how come you don't need to be in those groups?
[14:29] <Laney> O_O yeah OK I see those errors now
[14:29] <jibel> a whole new world opens in front of you ;)
[14:30] <Laney> don't like it, want to go home
[14:42] <Laney> nice login screen after restarting the machine ...
[15:07] <Laney> not really much further
[15:37]  * Laney shrugs
[15:37] <Laney> was trying to run an old kernel but I can't boot the stupid thing any more
[16:23] <Laney> ok, well, I got the squashfs error locally now
[16:28] <jibel> how did you do that?
[16:29] <Laney> copying the preseed file that utah uses
[16:29] <Laney> probably somehow triggered by how that does the reboot
[16:32] <Laney> there were some squashfs changes/problems/something with recent kernels weren't there?
[16:41] <Laney> jibel: I just got it with a normal install too, ubiquity-dm
[16:48] <Laney> ok, you can get it by just rebooting an ISO
[16:48] <Laney> potentially have to wait for snapd to finish seeding
[16:58] <jibel> Laney, how do you reboot? just clicking "reboot" at the end of installation?
[16:58] <Laney> jibel: yeah
[16:58] <Laney> then it doesn't actually reboot, and if you hide plymouth, there those messages are
[17:00] <jibel> Laney, only from u-dm or also from a live session?
[17:00] <Laney> done both now
[17:01] <Laney> live only after waiting for snapd to finish, otherwise I guess that blocks the shutdown long enough to make the unmounting happen nicely or something
[17:12] <Laney> jibel: https://paste.ubuntu.com/p/qT27YHWTY6/ <- you can get console output if you give "console=tty0 console=ttyS0" and then connect with "virsh console <name of domain>"
[17:12] <Laney> it's really just boot live session, wait 2 minutes, reboot from the GNOME menu
[17:12] <Laney> feels like we should be asking the kernel team for help
[17:13] <jibel> Laney, thanks for your help, I'll file a bug and ask the kernel team
[17:14] <Laney> cheers
[17:14] <Laney> guess I should go prune a tree now, see you tomorrow
[17:14] <jibel> have a nice evening, see you all tomorrow


[02:23] <sagaci> about to file a bug, is it ok to link to a screenshot of the bug?
[02:54] <ali1234> sagaci: you can add it as an attachment, then it won't get lost. but generally it's fine...
[02:55] <ali1234> sometimes i link to youtube videos of bugs :)
[02:55] <ali1234> make sure there's nothing private in the screenshot though
[02:58] <sagaci> righteo thanks, didn't even see the attachment link :P
[09:37] <somethinginteres> hi all, wanting to test a diff patch at https://bugs.launchpad.net/ubuntu/+source/festival/+bug/778619 - how would a newbie such as myself go about applying the diff to test it? Thanks. Looked at the man pages already but looking for specific guidance on this case.
[09:37] <ubot4> Launchpad bug 778619 in festival (Ubuntu) "Festival TTS starts 'paused' for blocks of text (affects: 1) (heat: 8)" [Undecided,New]
[14:13] <trinikrono> hey is a triager around i believe i have a bug that can be triaged
[14:13] <trinikrono> its bug 835920 and i just added the bugwatch, that should be sufficient right?
[14:13] <ubot4> Launchpad bug 835920 in checkgmail (Ubuntu) (and 1 other project) "CheckGmail with 2-step verification doen't work (affects: 2) (dups: 1) (heat: 16)" [Undecided,Confirmed] https://launchpad.net/bugs/835920
[14:16] <charlie-tca> trinikrono: you should comment on the bug that you have triaged it and sent it upstream
[14:16] <trinikrono> charlie-tca: i just put one :D
[14:17] <trinikrono> do you think that it has enough info to be considered triaged?
[14:17] <charlie-tca> Okay, I will mark it, then. Importance desired?
[14:17] <charlie-tca> sure, it is upstream already, right? also it has a duplicate, which confirms it.
[14:18] <charlie-tca> done
[14:18] <charlie-tca> Thanks for working on bugs. It does help!
[14:19] <trinikrono> charlie-tca: i would say low because it does not seem to be affecting a lot of users, only people wanting to use two step auth
[14:20] <charlie-tca> I can agree with that.
[14:22] <trinikrono> thanks charlie-tca
[14:23] <charlie-tca> You are welcome.
[14:42] <trinikrono> charlie-tca: if you are not busy can you look at bug 762392
[14:42] <ubot4> Launchpad bug 762392 in nautilus (Ubuntu) "Nautilus Crashes On Opening Directory With Large Number Of Files (affects: 1) (heat: 3)" [Undecided,New] https://launchpad.net/bugs/762392
[14:42] <trinikrono> i am thinking to tell the reporter to run nautilus from the command prompt and see what it says when it crashes
[14:44] <trinikrono> i saw this page also http://live.gnome.org/Nautilus/Development/Bugs
[14:45] <trinikrono> where it says if nautilus crashes it makes a debug file
[14:46] <charlie-tca> I would have the reporter do that. Then they can attach nautilus-debug-log
[14:46] <charlie-tca> but, make sure to tell them to remove that .conf after or it will keep building the logs
[14:58] <trinikrono> where does the log end up charlie-tca in the ~/ folder?
[14:59] <charlie-tca> That is where I think it will be, yes
[14:59] <charlie-tca> It should be in the same directory as the .conf file
[15:04] <trinikrono> charlie-tca: i put it too incomplete and asked for them to check out the wikipage and attach the file
[15:04] <trinikrono> so hopefully that would cover it for now
[15:04] <trinikrono> since apport did not collect anything useful
[15:05] <charlie-tca> yeah, that should be good
[15:05] <charlie-tca> Without something showing what is happening, it is not going to be possible to fix it
[15:06] <trinikrono> :D thanks i am off now charlie-tca
[15:06] <charlie-tca> Thank you for helping
[19:20] <denva-ingram> Hiya everyone, I have reported a bug but it seems that no one has a answer for, could anyone help me sort it out?
[19:21] <denva-ingram> bug is https://bugs.launchpad.net/linux/+bug/816145
[19:21] <ubot4> Launchpad bug 816145 in linux (Ubuntu) (and 1 other project) "Atheros AR5001 wireless card "wireless is disabled by hardware switch" (affects: 4) (dups: 1) (heat: 16)" [Medium,Incomplete]
[19:27] <xteejx> Evening all!
[20:36] <penguin42> can someone set importance on bug 551432 - I won't do it myself because I'm one of the people suffering from it and I'm about out of ideas to debug it
[20:36] <ubot4> Launchpad bug 551432 in virt-manager (Ubuntu) "virt-manager create disk image with LVM hangs for ever (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/551432
[20:38] <charlie-tca> Okay, what importance you want?
[20:40] <penguin42> well I guess it's either medium or low depending if virt-manager is a 'core application'
[20:40] <penguin42> (although for me it's a pit....)
[20:40] <penguin42> it's in main, so I guess it's core - Medium
[20:41] <charlie-tca> done
[20:42] <penguin42> Thanks - it's time I learn't some more python :-(
[20:46] <charlie-tca> python? No one said I have to learn python to do this now... ;)
[20:54] <penguin42> oh it's just virt-manager is written in python - and a window is falling down a crack somewhere and I don't understand why
[21:15] <mdeslaur> penguin42: what virt-manager version are you getting that issue on?
[22:10] <penguin42> mdeslaur: 0.9.0-1ubuntu3
[22:10] <mdeslaur> penguin42: ah! thanks
[22:11] <penguin42> let me just gather that stuff you asked for
[22:16] <penguin42> ok, done - back in 10min
[22:23]  * penguin42 returns
[22:25] <penguin42> mdeslaur: Would you expect virsh vol-list main    to give me something useful - it doesn't
[22:25] <mdeslaur> penguin42: did you create the "main" pool? do you have any idea what /dev/main is?
[22:26] <penguin42> mdeslaur: It's an lvm2 volume group
[22:26] <mdeslaur> oh, I see...are you storing stuff directly on lvm volumes?
[22:26] <penguin42> mdeslaur: In there are  'archhurd  crypt  debianvm  fedora13  fiddle2disk  more  server1a  server1a-lucid  testing' many of which are the disks used for VMs - yes
[22:27] <mdeslaur> hmm...I'm going to need to install a machine with some lvm volumes to try and reproduce this...a few people have mentioned problems with lvms before
[22:28] <mdeslaur> penguin42: has it ever worked?
[22:28] <penguin42> mdeslaur: Yes, it worked great on Natty
[22:28] <penguin42> mdeslaur: I've been running with this setup for about 18months - since I got this machine
[22:30] <mdeslaur> penguin42: I'll try and reproduce this as soon as I get back from vacation...sorry about that...
[22:30] <penguin42> mdeslaur: although I can't remember when I last created a VM was - probably a few months
[22:30] <penguin42> mdeslaur: That's fine - can you give me some suggestions as to where to look for more debug; what I don't get is virt-manager is creating the window but it's not getting mapped, so what should be causing it to get mapped?
[22:33] <mdeslaur> let me look at the code, one sec
[22:35] <mdeslaur> something is createvol.py is going wrong I guess
[22:37] <penguin42> yeh that's what I guessed - I've scattered debug prints everywhere and nothing seems to be exiting any of the functions early, the cleanup/finish functions aren't getting called
[22:39] <mdeslaur> penguin42: what if you add "logging.debug("DAG: vol_class is %s" % self.vol_class)" to createvol.py line 44
[22:40] <penguin42> is line 44 the one after self.vol_class =   ?
[22:40] <mdeslaur> yep
[22:40] <mdeslaur> just to see if it manages to get something sane there
[22:41] <mdeslaur> penguin42: oh, can you also start virt-manager with "virt-manager --debug --no-fork" to see if that works any better?
[22:41] <penguin42> 2011-08-28 23:41:48,453 (createvol:46): DAG: vol_class is <class 'virtinst.Storage.LogicalVolume'>
[22:42] <mdeslaur> ok, that's fine I guess
[22:42] <penguin42> mdeslaur: It happily gets all the way to the end of that function,
[22:44] <penguin42> oooh!
[22:45] <penguin42> mdeslaur: I think I might see what's going on
[22:45] <mdeslaur> do tell :)
[22:45] <penguin42> ok, I partially take that back - but I've got a change in behaviour
[22:46] <mdeslaur> by doing what?
[22:46] <penguin42> mdeslaur: I've got virsh vol-list to work, by changing the debug levels of lvm
[22:47] <penguin42> 'New Volume' still isn't working - but at least it's now listing the volumes I had
[22:47] <penguin42> mdeslaur: It seems to be sensitive to the 'command_names' option in /etc/lvm/lvm.conf
[22:47] <mdeslaur> ah, yeah...it's probably parsing the output of lvm tools, and is sensitive to configuration and/or redhat differences
[22:48] <mdeslaur> I'll need to reproduce this when I get back and go through it all
[22:48] <penguin42> mdeslaur: Yeuch parsing the output of the lvm commands is grim!
[22:48] <mdeslaur> so that would actually be in libvirt
[22:48] <penguin42> ok, but 'New Volume' still doesn't work any better
[22:50] <penguin42> but, that's work-aroundable since I can do it with LVM commands
[22:50] <penguin42> (which then makes me wonder if New Volume has ever worked there and I've always done it on lvm commands?)
[22:51] <mdeslaur> so...maybe you should get libvirt logging running and look in the libvirt logs...that would explain why virt-manager isn't printing anything useful
[22:51] <penguin42> mdeslaur: I did - the libvirt logs are HUGE
[22:51] <mdeslaur> virt-manager is probably incorrectly handling data that libvirt is returning
[22:52]  * penguin42 decides to start by filing a bug about the sensitivey to the 'command_names' lvm debug option
[22:53] <penguin42> it's an option in the lvm config file, so is a perfectly valid thing to use - although to be honest I'd expected that to change only the output of logging
[22:56] <mdeslaur> yeah...storage_backend_logical.c in libvirt parses the output of various lvm commands
[22:56]  * penguin42 grabs a bucket - surely there is an API for that
[22:57] <penguin42> or use udisks
[22:57] <mdeslaur> are you running en_US?
[22:57] <penguin42> en_GB
[22:58] <penguin42> oh dear that would get very messy
[23:00] <mdeslaur> yeah, I think storage_backend_logical.c needs to be looked at to make sure all the regexes in there actually work with the tools we have in oneiric and will different locales
[23:00] <mdeslaur> *sigh*
[23:00] <penguin42> if it's parsing the output of lvm commands it'll probably break just by thinking about it
[23:01] <mdeslaur> it probably doesn't handle spaces in filenames, that's for sure
[23:02] <mdeslaur> anyway, I have to stop looking at this now...
[23:02] <penguin42> I think one of the bugs here is that the command_names option in lvm actually changes the output of the command, not (just?) the stuff that's logged - so I'd happily take that as an LVM bug
[23:02] <penguin42> mdeslaur: Thank you!
[23:04] <mdeslaur> np, I'll take a look when I get back. thanks!
[23:04] <penguin42> mdeslaur: For reference bug 836329 is the sensitivty to command_names, I'm also going to mark it as affecting lvm and let the lvm and libvirt side fight out which one is wrong :-)
[23:04] <ubot4> Launchpad bug 836329 in libvirt (Ubuntu) "lvm volumes not listed if lvm has command_names option = 1 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/836329
[23:04] <mdeslaur> thanks!


[08:49] <davmor2> Morning all
[18:27] <Italian_Plumber> hello.  I commented on this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/502433 .... will it be useful for me to download and try the alpha3 release to see if the problem may have been fixed?
[18:27] <ubot4> Launchpad bug 502433 in linux (Ubuntu) "Lucid: b43 fatal DMA error on Dell Mini 9 (affects: 6)" [Medium,Triaged]
[18:32] <ara> Italian_Plumber, the alpha3 hasn't been released yet
[18:33] <ara> Italian_Plumber, but it is always good to try with the latest daily iso, yes
[18:34] <Italian_Plumber> well yeah I meant... when the alpha3 comes out. :)
[18:35] <Italian_Plumber> I'd want to wait on the daily until there is some indication that somoene did something that shoould have fixed it...
[18:35] <Italian_Plumber> how would I determine that?
[20:19] <ara> stgraber, ping
[21:11] <xteejx> Hey guys! This X driver testing thing at https://wiki.ubuntu.com/X/Testing/ProprietaryDrivers/WeeklyProgram ... what are we meant to do, it doesn't actually say. I'm guessing we just install Lucid from daily ISO and run it and see if the proprietary drivers work? It says about test results, etc though I'm confused....
[23:49] <stgraber> ara: pong
[23:50] <ara> hey stgraber :)
[23:50] <stgraber> it really feels weird to have you on IRC this late ;) usually I'm always too late.
[23:50] <ara> :)
[23:50] <ara> stgraber, I have to take the most of it!
[23:50] <ara> stgraber, the different instances like xorg, kernel, bla, bla, bla...
[23:50] <ara> are they difficult to add a new one?
[23:50] <stgraber> nope, just look at qawebsite_site
[23:51] <stgraber> and add another one to that table
[23:51] <stgraber> it's just a row per website
[23:51] <ara> stgraber, and the dns?
[23:51] <ara> that has to be added by is
[23:51] <ara> isn't it?
[23:51] <stgraber> *.qa.ubuntu.com should be poiting to quandong already
[23:52] <stgraber> except www and testcases
[23:52] <stgraber> yep, blah.qa.ubuntu.com arrives on quandong, so it should be fine ;)
[23:54] <ara> stgraber, cool, I'll try that and I will see what happens


[04:01] <iotenthusiast> What is the format of a snap image .  I've received this error from the store "not allowed by 'deny-connection/plug-attributes' in base declaration declaration-snap-v2_plugs_deny-connection (browser-sandbox, browser-support)"  but i'm not sure what it means.
[11:13] <DanChapman> Have i declared something incorrectly https://git.launchpad.net/dekko/tree/snapcraft.yaml or is it an issue in the store review?
[11:30] <morphis> DanChapman: it means that by default you're not allowed to use the 'allow-sandbox: true' attribute of the browser-support interface
[11:31] <morphis> DanChapman: see https://github.com/snapcore/snapd/blob/master/interfaces/builtin/basedeclaration.go#L181
[11:32] <morphis> DanChapman: you can get around this if you ask during the store review if you can still use it, then the store folks will create a snap-declaration assertion which then allows you to use that attribtute
[11:41] <vigo_> fgimenez, ping
[11:53] <mup> PR snapd#2506 opened: cmd/snap-confine: disable old tests <Created by zyga> <https://github.com/snapcore/snapd/pull/2506>
[11:54] <mup> PR snapd#2507 opened: tests: port first regression test from snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2507>
[12:08] <DanChapman> morphis: ah ok then, that's great Thanks! :-) I will ask in the review if i can use it.
[12:08] <morphis> DanChapman: depending on which snapd version you have you can try to connect via $ snap connect --dangerous ...
[12:20] <fgimenez> hey vigo_ :)
[12:20] <teoincontatto> Hi, there! I'm in the process of creating the SNAP for ToroDB, a java application that run as a service and replicate/transform data from MongoDB to PorstgreSQL (torodb.com). I have created a first SNAP that run as a "simple daemon".  I don't see any way to run the daemon with another user that is not root. I don't see specific documentation to udenrstand why we can/should not create an user and use it to run the service as when
[12:22] <vigo_> fgimenez, how do you flash images for pi3 and db? with dd right?
[12:23] <fgimenez> vigo_, yes, for all of them
[12:24] <vigo_> fgimenez, ok and how you do it?
[12:25] <vigo_> I've noticed that there are different ways to dd the image, in different documents I visited
[12:28] <fgimenez> vigo_, "sudo dd if=~/Desktop/ubuntu-core-16-pi2.img of=/dev/sdc bs=4M oflag=sync status=noxfer", this is recommended in the db docs and works fine for the pi's too
[12:29] <vigo_> fgimenez, excellent, that's what I wanted you to confirm :) I use that from setting up the board doc
[12:29] <olli> sergiusens, kyrofa do you guys have any insights for teoincontatto
[12:30] <fgimenez> vigo_, great :) there's also the godd snap, probably simpler and more friendly, but haven't tried it yet
[12:31] <ogra_> vigo_, you need to make pretty sure that the device isnt auto-mounted in the background by nautilus or so before dd'ing ... and you dont need to unxz ... xzcat ubuntu-core-16-pi3.img.xz | sudo dd of=/dev/sdc bs=64M is what i use
[12:32] <ogra_> but yeah, use the gdodd snap ... fgimenez is correct ... thats definitely the safest
[12:32] <ogra_> iirc it tests for background mounts and such ... and has a progress bar ;)
[12:33] <vigo_> ogra_, thanks for confirming, I know from vrruiz that godd also works fine :). I still use dd but sure I'll try also godd
[12:35] <vigo_> fgimenez, remember those boot logs that sometimes appears in "Press enter to configure" page¿
[12:35] <vigo_> is there a bug to track it already?
[12:40] <mup> PR snapd#2508 opened: interfaces/apparmor: ignore snippets in classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/2508>
[12:43] <mup> PR snapd#2509 opened: overlord/ifacestate: remove stale comments <Created by zyga> <https://github.com/snapcore/snapd/pull/2509>
[12:46] <mup> Issue snapd#2510 opened: spread tests fail when invoked in a sub-directory (generate-packaging-dir) <Created by zyga> <https://github.com/snapcore/snapd/issue/2510>
[12:53] <mup> PR snapd#2511 opened: spread: find top-level directory before running generate-packaging-dir <Created by zyga> <https://github.com/snapcore/snapd/pull/2511>
[13:04] <Elleo> has the syntax for "stage:" changed recently? I get this when attempting to use it as per the docs: "Issues while validating snapcraft.yaml: The 'parts/stage' property does not match the required schema: ['-etc/presage.xml'] is not of type 'object'"
[13:49] <Elleo> ahh, just had the wrong indentation :)
[14:45] <mup> PR snapd#2512 opened: Release snapd 2.20.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2512>
[14:58] <mup> PR snapd#2513 opened: don't use deprecated http.Transport.Dial <Created by teknoraver> <https://github.com/snapcore/snapd/pull/2513>
[15:25] <jdstrand> DanChapman: 'allow-snadbox: true' is reserved. you can drop that. you might need to set an environment variable to make the chromium sandbox not do its namespace sandbox
[15:26] <jdstrand> DanChapman: if you are using oxide, there is an env var. you might ask the oxide guys (I don't remember it otoh)
[15:36] <DanChapman> jdstrand: ok. So it's fine for that to be false, ill change that then. I already set OXIDE_NO_SANDBOX in the launcher script which i think is the env var you mentioned. Thanks!
[15:38] <jdstrand> DanChapman: yes, please use OXIDE_NO_SANDBOX=1 and drop allow-sandbox: true
[15:38] <jdstrand> DanChapman: it should work then
[15:43] <kalikiana_> jdstrand: As you're discussing this I remember wondering before: why is it that the real sandbox can't be used and the recommendation is to disable it? That looks a little upside down to my naive mind
[15:44] <kalikiana_> Is there more work needed on the snapd side?
[15:44] <jdstrand> kalikiana_: because the snappy sandbox and the chromium sandbox don't work well together. we have to grant a *lot* of privileges to the snap for it to use the chromium sandbox
[15:45] <jdstrand> kalikiana_: it is work in the kernel and also in chromium to coordinate better with snapd
[15:47] <jdstrand> kalikiana_: also, for a web app or webview, the snappy sandbox is more than enough (it is a proper sandbox after all). allow-sandbox if for a trusted browser like chrome, webbrowser-app, etc to be able to do privileged operations to then drop them immediately
[15:57] <kalikiana_> Hmm okay.
[16:21] <mup> Issue snapd#2514 opened: snap-confine tests fail on 14.04 <Created by zyga> <https://github.com/snapcore/snapd/issue/2514>
[16:39] <nacc> kyrofa: thanks!
[16:40] <mup> PR snapd#2515 opened: snap run: create "current" symlink in user data dir <Created by stolowski> <https://github.com/snapcore/snapd/pull/2515>
[16:40] <kyrofa> nacc, no problem, hopefully that feature is helpful. I know I'm tired of writing python for one-liners
[16:42] <nacc> kyrofa: yeah, i have i think three snaps I did a few months ago that become much more obvious and (presumably) a snapcraft.yaml with that change
[17:20] <mup> PR snapd#2516 opened: tests: cancel the scheduled reboot on ubuntu-core-upgrade-no-gc and restore state <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2516>
[17:29] <mup> PR snapd#2506 closed: cmd/snap-confine: disable old tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2506>
[20:25] <mup> PR snapd#2507 closed: tests: port first regression test from snap-confine <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2507>
[20:31] <joe> hello all
[20:33] <walidof> hello all
[20:33] <walidof> i need help for first login to ubuntu core
[20:34] <walidof> i need localhost login name / pass
[20:34] <walidof> i try add : ubuntu - ubuntu - toor - root - startx
[20:35] <walidof> and the problem not solved
[20:36] <mup> PR snapd#2508 closed: interfaces/apparmor: ignore snippets in classic confinement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2508>
[20:36] <mup> PR snapd#2509 closed: overlord/ifacestate: remove stale comments <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2509>
[20:37] <mup> PR snapd#2517 opened: tests: add hello-classic test <Created by zyga> <https://github.com/snapcore/snapd/pull/2517>
[20:39] <mup> PR snapcraft#985 closed: Better message for missing snapcraft.yaml in origins <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/985>
[21:10] <mfeatherston> During snap installs I keep getting connection reset by peer.  Is there any known issue with the store right now?  I don't get this from apt-get on other systems here.
[21:10] <mfeatherston> if I retry it eventually goes through
[21:13] <kyrofa> mfeatherston, the store and the archives are hosted in different places
[21:14] <kyrofa> nessita, do you know of any store issues?
[21:18] <nessita> kyrofa, no issues as far as I know
[21:19] <kyrofa> mfeatherston, ^^ . Alright, thanks nessita :)
[21:19] <mfeatherston> ok, thanks!
[21:20] <kyrofa> mfeatherston, http://status.snapcraft.io/ might be helpful
[21:22] <mfeatherston> heh, good to know, but that came back with "Our service is temporarily unavailable. We are currently working to restore it."
[21:23] <kyrofa> mfeatherston, huh, interesting, I just visited it
[21:23] <ssweeny> now we need a status.status.snapcraft.io
[21:23] <mfeatherston> ahh, I reloaded and it came up
[21:23] <mfeatherston> heh
[21:24] <kyrofa> I'm not sure what to say about that :P
[21:25] <mfeatherston> it's a page from Zoho saying "We'll be right back".  Either way that part is working now.
[21:26] <kyrofa> nessita, that sounds odd ^^
[21:27] <mfeatherston> If I look at the packet capture of my snappy system it tries to change the TCP window size and the remote server is sending me a reset
[21:41] <mfeatherston> I'm wrong about the window size thing, that isn't consistent.  The resets are fairly reproducible and I've tried multiple NICs though.  I'll try this from another Internet connection later tonight.
[22:06] <mup> PR snapcraft#991 closed: Updated ant plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/991>
[22:15] <mup> PR snapcraft#1007 opened: lifecycle: clean without parsing if possible <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1007>
[22:39] <Fohlen1> heya there .. I am trying to build a snapcraft plugin for https://github.com/Fohlen/conan-snapcraft. When using it with https://github.com/inexor-game/code/blob/fohlen/snapcraft/tool/snap/snapcraft.yaml I'm prompted with
[22:39] <Fohlen1> 'NoneType' object has no attribute 'copy'
[22:39] <Fohlen1> which is not a quiet detailed error log though .. and I'm a bit stumbling where/how to get started with that
[22:40] <kyrofa> Fohlen1, can you pastebin the output of running `snapcraft -d`, please? (debug)
[22:42] <Fohlen1> uh. the help command didn't show that it exists! http://pastebin.com/hpwN49cp
[22:42] <kyrofa> Ah, Sauerbraten! That brings back memories
[22:42] <kyrofa> Fohlen1, hmm, what version of Ubuntu are you on?
[22:42] <Fohlen1> 16.04
[22:43] <Fohlen1> err. kyrofa. from the autotools example I've just seen that I miss the return statement in schema
[22:43] <kyrofa> Fohlen1, it's down in the Options of the help page, by the way
[22:43] <kyrofa> Fohlen1, indeed, if you're not returning a schema it gets None
[22:44] <kyrofa> Which of course, can't be copied :)
[22:49] <Fohlen1> kyrofa: lovely! :)
[22:52] <Fohlen1> kyrofa: is there anywhere a more extensive documentation about the plugins, or will I need to stumble through the source-code myself?
[22:52] <Fohlen1> (might use code autocompletion for that, but it's still painful)
[22:53] <kyrofa> Fohlen1, this is the official docs for it: https://github.com/snapcore/snapcraft/blob/master/docs/plugins.md
[22:53] <kyrofa> Fohlen1, but referring to the in-tree plugins will probably be most helpful
[22:54] <Fohlen1> alrighty
[23:09] <Fohlen1> kyrofa: I can happily report that it works now!
[23:09] <kyrofa> Fohlen1, excellent!
[23:09] <Fohlen1> maybe sometime soon we can offer a new game using snap! :)
[23:10] <kyrofa> That'll be great!
[23:24] <mup> PR snapcraft#1008 opened: Add a simple straightforward conan.io plugin <Created by Fohlen> <https://github.com/snapcore/snapcraft/pull/1008>
[23:45] <mup> PR snapcraft#999 closed: Updated autotools plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/999>