[03:32] <tgm4883_laptop> Is there some reason that project bugs won't expire, even though the project is setup to have them expire?  Like bug 151612
[04:11] <IntuitiveNipple> Is there a problem with PPA package downloads with apt?
[04:12] <beuno> IntuitiveNipple, there shouldn't be. What's the problem
[04:13] <IntuitiveNipple> not sure, but had a couple of reports today of apt-get failing to fetch packages from my PPA, and I've just tried a --reinstall of one I have and it reported "Reinstallation of r5u870-dkms is not possible, it cannot be downloaded" - I can see and grab the packages manually though
[04:14] <IntuitiveNipple> My PPA is "https://launchpad.net/~intuitivenipple/+archive"
[04:14] <beuno> IntuitiveNipple, I've used PPAs a few times today, and haven't had any problems. Could be your ISP acting u[?
[04:14] <beuno> *up
[04:15] <IntuitiveNipple> not my downloads - other people reporting it from various parts of the world.
[04:16] <beuno> oh, I see
[04:16] <beuno> hm
[04:16] <beuno> spm, is there anything in the logs about that ^ ?
[04:17] <IntuitiveNipple> Originally I put it down to non-techie user error, but I'm talking to someone on IRC now who has followed my directions and it is failing for them
[04:19] <beuno> IntuitiveNipple, is the problem with newly uploaded packages?
[04:19] <IntuitiveNipple> I don't think so - r5u870-dkms has been there since mid-August
[04:20] <IntuitiveNipple> let me go back to the user... It has just worked for me now
[04:21] <beuno> IntuitiveNipple, sure, and we'll see if there's anything odd in the logs
[04:21] <beuno> thanks
[04:21] <IntuitiveNipple> thanks
[04:22] <IntuitiveNipple> beuno: Here's a forum post that says the repository failed for another package in my PPA (unfortunately no details of what happened though): http://ubuntuforums.org/showpost.php?p=5832299&postcount=2
[04:23] <beuno> IntuitiveNipple, that doesn't look like a PPA problem, but a problem with the package
[04:24] <IntuitiveNipple> hmmm
[04:24] <IntuitiveNipple> not the installer bit - I know about that! - the comment at the very start "the repository didn't seem to work"
[04:25] <beuno> IntuitiveNipple, ok. We'll see if the admins find anything odd
[04:26] <IntuitiveNipple> thanks.
[04:26] <IntuitiveNipple> This user is going to retry it in a few moments when a download has finished
[04:28] <beuno> IntuitiveNipple, ok, be sure to get his IP number to see if we can track it down
[04:28] <IntuitiveNipple> He's in Iraq - service personnel
[04:31] <IntuitiveNipple> It seems to have been transient - he's got it too now
[04:31] <beuno> ok
[04:31] <beuno> if there's something major going on, we'll see it in the log analysis at the end of the day
[04:33] <IntuitiveNipple> okay :)
[04:34] <Peng_> Augh!
[04:34] <Peng_> LP stopped mirroring my new bzr+http branch. :(
[04:34] <Peng_> Revision not present in KnitVersionedFiles object.
[04:37] <spiv> jml: ^
[04:38] <Peng_> The message has already reverted to "will not mirror" even though it's making HTTP requests right now.
[04:39] <Peng_> Ooh, done!
[04:39] <Peng_> With bug 260219, is the fix deployed now?
[04:49] <mwhudson> Peng: no
[04:49] <Peng_> mwhudson: But it should still successfully mirror, right?
[04:49] <Peng_> mwhudson: When will it be?
[05:41] <mwhudson> Peng_: good question
[06:39] <Peng_> Which question is good, and are there any good answers? :(
[06:51] <sits> Are there any launchpad admins about?
[06:52] <sits> If so could they unsubscribe (or deactivate or investigate the following account):
[06:52] <sits> https://launchpad.net/~teresadd1-0
[06:52] <sits> (User is repeatedly saying they don't want emails)
[06:54] <spm> sits: interesting problem - chasing
[06:54] <persia> sits: That user is getting the mail from being a member of the Ubuntu Audio team.  It's probably better just to change group membership than to disable the user.
[06:55]  * persia escalates to the relevant team admin, rather than needing an LP admin
[06:55] <sits> persia: I know
[06:56] <sits> persia: or rather - I can see that the user is part of the team
[06:56] <sits> but I think the user REALLY wants out
[06:56] <sits> I don't think emailing instructions how would be wise at this point
[06:56] <persia> sits: Right.  It's having the team admin deactivate the user from the team, rather than having an LP admin deactive the user from LP.
[06:56] <sits> I'm curious how the user was added to that group myself
[06:57] <persia> It's an open team: just a click away.
[06:57] <sits> oh sorry
[06:57] <persia> sits: No issue.  I just belong to the school of the smaller hammer, carefully applied :)
[06:58] <sits> persia: I can unsubscribe other people from open teams... what a novel concept
[06:58] <sits> hmm no I can't
[06:58] <persia> sits: Well, team admins can do it.  You can't, but you can raise awareness of an issue, and the team admins may take action.
[06:58] <RAOF> sits: For what it's worth, I emailed instructions a couple of days ago when she appeared on a bug I was watching.
[06:59] <persia> RAOF: Instructions to remove herself from the team?
[06:59] <spm> What's also worth considering - the same user was commenting positively on bugs about a month ago
[06:59] <sits> ok in that case I would definitely just unsubscribe the user
[06:59] <RAOF> persia: Indeed.
[06:59] <sits> it will save ugliness
[06:59] <persia> Odd.  I wonder if the person behind the email address changed for some reason.
[06:59] <RAOF> And an explaination of where the emails are coming from, too.
[07:00] <sits> kid singed up with family email address?
[07:00] <spm> persia: that's my thinking - looks like a vaguely generic address
[07:00] <spm> sits: could be - but from the address used I'd be inclined to think not
[07:00] <persia> It does look like a generic ISP address.
[07:01] <persia> spm: No?  I don't see how the address might influence that: isn't the sort of address one gets when having a line connected?
[07:04] <sits> ok thanks for your help. Hopefully the user will be unsubscribed and things will settle back down
[07:05] <persia> the user is being deactivated from the team now.
[08:18] <frk2> hi guys
[08:18] <frk2> i got a problem with merging proposed merges
[08:19] <jml> frk2: what's up?
[08:19] <frk2> well i got a developer with his branch
[08:19] <frk2> and when he proposes merging to trunk and i do mark as merged- nothing happens
[08:20] <jml> frk2: as in, all that happens is the web page now says 'merged'?
[08:20] <Odd_Bloke> frk2: I don't think Launchpad does the merging for you (yet).
[08:20] <Odd_Bloke> thumper's working on that, I think.
[08:20] <frk2> oh really?
[08:20] <jml> right.
[08:20] <jml> the current features are there for tracking
[08:21] <frk2> well that explains everything
[08:21] <Odd_Bloke> frk2: :D
[08:21] <persia> Is the converse also being implemented: that if someone performs a manual merge (using bzr merge), LP will update the branch as merged?
[08:22] <jml> yeah
[08:22] <jml> probably that before the other :)
[08:23] <persia> Cool.  I always lose track of the status of my branches, and have to schedule branch admin time.
[08:23] <Odd_Bloke> jml: Do you know that that is not done?
[08:23] <jml> Odd_Bloke: I bet one of those words is wrong.
[08:24] <Odd_Bloke> s/that that/that the converse/
[08:24] <jml> persia: yeah. we're talking about phasing out manual branch status management actually.
[08:24] <jml> persia: although we haven't made firm decisions.
[08:24] <Odd_Bloke> jml: What sort of timescale would that be on?
[08:24] <jml> Odd_Bloke: I know that the converse is not done.
[08:24] <frk2> jml, so i manually merge and then push to launchpad, thats the idea - correct? sorry im new to DVCSs :) subversion convert here :P
[08:25] <jml> frk2: that's right.
[08:25] <persia> jml: Well, I do like some of it.  It's nice to indicate whether something is a idea that one is playing with, something that is likely to be proposed for regular merges as the features come together, or an idea that no longer has value.
[08:25] <jml> frk2: or you could use a tool like pqm.
[08:25] <frk2> hmm whats pqm?
[08:25] <jml> frk2: I'll let Odd_Bloke field that one :P
[08:25] <persia> I especially like being able to mark branches "Experimental" when they are known to break stuff, to discourage merging.
[08:25] <spm> jml: you wimp! :-P
[08:26] <jml> persia: experimental is probably the one with the greatest value, imo
[08:26] <Odd_Bloke> So, PQM is a robot that does merging for you.
[08:26] <Odd_Bloke> Patch Queue Manager, BTW.
[08:26] <jml> persia: 'abandoned' is generally fairly well represented by just 'not touched in a while'.
[08:27] <persia> jml: Abandoned has a lot of value too, I think.  New/Development is tricky to determine, and Merged ought be done based on tree comparisons.
[08:27] <Odd_Bloke> It can also do nice stuff like: 'merge', 'run tests', 'if tests successful, push to public location'.
[08:27] <jml> persia: well 'new' should not be a status at all.
[08:27] <jml> persia: we already have a hojillion ways of telling how recent a thing is :)
[08:27] <Odd_Bloke> jml: I dunno, a lot of my PQM branches from over the summer haven't been touched in a while but are just waiting to be merged.
[08:27] <jml> Odd_Bloke: :(
[08:28] <frk2> so pqm submits to a pqm service?
[08:28] <persia> jml: See, I disagree.  While it's a slightly different case, I've a package in Ubuntu that I last uploaded on 10th May 2007.  I haven't touched it since, because it works, and there's only one bug (related to the ogre model, and not easily soluable).  Just beacuse I've not touched it in 16 months doesn't mean I won't touch it tomorrow if someone files a bug.
[08:28] <persia> Err.  I disagree about "Abandoned".  I agree about "New".
[08:28] <jml> persia: ahh, that's an interesting case.
[08:28] <jml> persia: out of curiosity, is the branch bound to a series?
[08:29] <frk2> jml, i'll just merge manually :)
[08:29] <persia> Also, sometimes I'll abandon something after only a couple days, because I've talked with others, and the path I was taking was entirely wrong.
[08:29] <jml> frk2: probably easiest :)
[08:29] <Odd_Bloke> frk2: You submit a branch to PQM.  It then merges that branch into your trunk and runs whatever integration tests you want (if any).  If these are successful, it pushes it to a public location.
[08:29] <frk2> yeah, and i can test the code too
[08:29] <persia> jml: I doubt it.  I'm a reluctant VCS user at best, so just occasionally push updates to others branches when they want to receive patches that way.
[08:29] <Odd_Bloke> frk2: Having first set up a PQM instance somewhere.
[08:30] <Odd_Bloke> jml: Does Launchpad allow there to be more than one branch which merges could be Merged into?
[08:30] <jml> Odd_Bloke: yes.
[08:30] <jml> Odd_Bloke: technically, any branch can be merged into any other branch.
[08:31] <Odd_Bloke> jml: Sure, but you wouldn't want 'Merged' to be based on that.
[08:31] <jml> Odd_Bloke: oh right.
[08:31] <Odd_Bloke> Sorry, should have quoted first time 'round too.
[08:32] <jml> Odd_Bloke: I'd probably say 'Merged' should mean 'merged into dev focus (aka trunk)' or 'merged into a series branch'
[08:32] <jml> Odd_Bloke: alternatively, if it's been merged into all the branches for which it has merge proposals.
[08:33] <jml> Odd_Bloke: not sure which of those approaches I like best.
[08:33] <Odd_Bloke> jml: How would that fit the model of a project (like the kernel or, maybe, Django) where you have 'foo-dev-1', 'foo-dev-2' and 'foo-dev-3' which should be merged into 'foo-integration' which will eventually be merged into the dev focus?
[08:34] <jml> persia: so, my theory wrt your "18 months untouched" branch had been that branches like that are generally already marked as special in some way
[08:34] <frk2> thanks guys!!!! back to work!
[08:34] <jml> Odd_Bloke: you can still mark them manually
[08:34] <persia> jml: Yeah, that's not actually in VCS, but it would be considered trunk.
[08:34] <jml> persia: right.
[08:35] <Odd_Bloke> jml: Sorry, I'm still talking in terms of 'Merged' auto-detection.
[08:35] <jml> Odd_Bloke: I don't think Launchpad should try guessing what the status should be in that case.
[08:35] <Odd_Bloke> (in the context of the speculative mention of removing manual management)
[08:35] <jml> Odd_Bloke: ahh
[08:35] <persia> jml: So you assert that "Abandoned" is covered by time-since-last-push and not being trunk?  What about the case where one abandons quickly, as one has started down the wrong path?
[08:36] <jml> persia: do you think there's much benefit in marking such a branch as Abandoned?
[08:36] <jml> persia: to yourself or others?
[08:36] <jml> Odd_Bloke: so, I think that "Merged" as a status is actually too ambiguous for precisely that reason
[08:37] <Odd_Bloke> Yeah.
[08:37] <jml> Odd_Bloke: it immediately raises the question "merged where?"
[08:38] <persia> jml: Certainly, especially as more activity becomes seen as branches.  It removes it from my list of active branches, which helps me to sort out what I'm actually working on.  It also tells others that it's not worth looking there if they want to experiment with other's work-in-progress (not merging to trunk).
[08:38] <Odd_Bloke> Yeah, perhaps a 'Done' status with something more to clarify how would work.
[08:38] <frk2> jml, can i 'un-merge'
[08:38] <frk2> or thats revert?
[08:38] <Odd_Bloke> Which could be "Merged to x" or "Abandoned".
[08:38] <jml> frk2: depends if you've committed already
[08:38] <frk2> i have
[08:38] <jml> frk2: if you haven't, 'bzr revert'. if you have, 'bzr uncommit'
[08:39] <frk2> cool
[08:39] <frk2> works :)
[08:39] <frk2> bazaar kicks ass
[08:39] <jml> frk2: and then possibly 'bzr revert' -- depending on what you want to do.
[08:39] <jml> frk2: that it does :)
[08:39] <jml> persia: why not just delete it?
[08:40] <persia> jml: to avoid rewriting history?
[08:40]  * persia doesn't generally like the concept of "delete".
[08:40] <jml> persia: fair enough.
[08:40] <jml> persia: this is interesting.
[08:41] <persia> jml: I'm not suggesting to remove "delete", as it's useful when one accidentally pushes one's private data, but I don't think it ought be the default workflow.
[08:41] <jml> *nod*
[08:42] <persia> Also, just because I decide some idea isn't worth pursuing doesn't mean someone else won't want to do it.  Assuming some later interface that allows for easy searching of all branches (perhaps just hints to google codesearch), having abandoned branches show (clearly labeled as such) may even be a god thing towards reduced duplication of effort.
[08:43] <jml> perhaps.
[08:45]  * jml thinks
[08:48] <jml> there definitely should be a way to say explicitly that a branch is uninteresting.
[08:49] <jml> and if Launchpad also detects that a branch is uninteresting (no one has touched it, not trunk, not a release branch etc) then care needs to be taken to make sure it plays nice with explicit status stuff.
[08:50] <jml> I sometimes wonder if experimental could be just as conveniently expressed with well-chosen names.
[08:51] <persia> I don't think so, because something could stop being experimental, but you'd want to have a static branch name.
[08:51] <jml> persia: well, no one should have been using it before then, right?
[08:51] <jml> persia: it's experimental after all;)
[08:51] <persia> jml: Except the other people with whom I'm collaborating to make it not so experimental.
[08:52] <jml> persia: surely there's no better way to celebrate a successful experiment than a round of jovial renaming and cake?
[08:52] <persia> Also, since one can subscribe to a branch, it becomes interesting to see status changes: consider a project leader who wants to know when various features might be ready to review for trunk.
[08:52] <spiv> If there's active collaboration, then it's safe to say it's an "interesting" branch for the purposes of browsing branches via LP's UI.
[08:53] <persia> Sure, but just being interesting doesn't mean that it's suitable for consideration by those using trunk.
[08:53] <jml> persia: merge proposals cover that case, I think.
[08:53] <spiv> Why would someone think it is?
[08:54] <persia> jml: Only if you assume a push-only model.  What about several teams working on stuff who want to occasionally pull from each other to avoid collisions, yet none are ready for trunk?
[08:54] <spiv> I'd tell the teams to keep separate branches for "ready" and "not ready" work.
[08:55] <persia> Or just someone who's working on something, and wants to pull some (possibly incomplete) feature from someone else to avoid duplication of work, and won't be pushing to trunk until the feature on which they depend has gone?
[08:55] <spiv> Which they probably will tend to do anyway (it's easier to work from a stable base).
[08:55] <jml> persia: I think I've missed a link of your thoughts
[08:55] <persia> OK.  I'll try again.  Imagine the following model:
[08:56] <persia> There is some trunk.  There are *lots* of developers.  Some developers are working on things that are known to break trunk.
[08:56] <persia> These are the three cases where "Experimental" vs. "Development" are useful:
[08:56] <spiv> I think my basic assumption is that people *don't* merge unfamiliar branches without first finding out some things about them.
[08:57] <persia> 1) A project leader wants to know when a given feature is ready for discussion, and can subscribe to the branch for that feature.
[08:58] <persia> 2) One developer wants to work on something that depends on an experimental feature another developer is working on: their work shouldn't be considered for trunk until the feature on which they depend is no longer experimental
[08:58] <persia> 3) A developer is working on something with a bound branch.  As they get closer to the goal, they want to be able to mark it as ready for others to test (but perhaps not ready for merge), without needing to branch it again.
[08:59] <jml> persia: ok
[08:59] <jml> persia: why don't merge proposals meet the cases described in 1 and 2?
[09:00] <jml> (btw this is a very helpful discussion for me, thank you)
[09:00] <persia> spiv: I question that assumption.  For Ubuntu maintenance, people often pull changes from other distros (Debian, Fedora, SuSE, Gentoo), and test them locally.  While there is often communication directly with upstream, or with Debian, it is considerably more rare for Fedora, SuSE, Gentoo, etc.  In these cases, it's mostly pulling a solution, testing it, and maybe applying it.
[09:01] <persia> I don't see any reason why a sufficiently large group of developers on a sufficiently large project wouldn't do the same thing.
[09:01] <spiv> persia: right, but in those cases you know something about the source.
[09:01] <persia> It's generally more efficient to look for an existing solution than to create a new one, and once a team gets large enough (>Dunbar's number), and distributed enough, communications lag can cause issues.
[09:02] <jml> I would hope that branch whiteboards would get used more often in those circumstances
[09:02] <jml> although that's nearly orthogonal to explicit statuses.
[09:03] <spiv> persia: it's "ah, debian has packaged a newer version" or "I want to synchronise my packaging to be up to date with what's happened in debian testing", or there's some other explicit reason *why* the merge was done.
[09:03] <persia> spiv: Right.  Let's assume you trust me to do cool stuff.  Wouldn't it be handy if you could see which of my branches I thought were pretty good, which were not for general use, and which were not useful when you wanted to pick a patch from me?
[09:03] <jml> I asked my question first guys :)
[09:03] <persia> spiv: No.  Ignore Debian.  Consider Fedora, SuSE, Gentoo.  It's about getting patches to add features or fix bugs.
[09:04] <persia> jml: I suppose I could use a whiteboard, but that takes longer than clicking a button, and doesn't summarise well in a long list.
[09:04] <spiv> Right, so it's "get bug fixes made by Gentoo", then.  It still strikes me as a different case to finding a branch I know *nothing* about and just merging it.
 persia: why don't merge proposals meet the cases described in 1 and 2?
[09:05] <persia> spiv: That's not what I'm saying: I'm talking about merging from a branch where you don't have non-VCS communication with the branch author.  You might know the code, but given the volume of branches for a given author, you may want to only pick the good ones.
[09:05] <spiv> persia: so finding out "pretty good" vs. "not for general use" vs. "not useful" doesn't seem like something a single "Experimental" status can communicate :)
[09:05] <jml> persia, spiv: all of this is making me think that bzr's launchpad plugin needs to grow more features.
[09:06] <persia> jml: for 1, because just because something is ready for testing doesn't mean it's ready for merge, especially for a project on which lots of other projects depend (e.g. gcc).  For 2) it's a pull merge.  The second developer needs to know when the first developer thinks it won't break stuff in order to guide timeline planning.
[09:06] <persia> spiv: I want three statuses: "Experimental", "Development", "Abandoned".
[09:06] <spiv> persia: ideally the fact that Fred's changes in branch X have been accepted into Gentoo would tell you that branch X is good, rather than hoping that Fred is keeping his statuses up to date.
[09:07] <persia> I think "New" and "Merged" should be automatic, but don't want to lose the existing manual feature.
[09:07] <spiv> Especially if you aren't in direct contact with Fred to check that they are.
[09:08] <spiv> jml: I agree that more features for that plugin would be very good.  I'd love to do all my LP branch management from a command line.
[09:08] <persia> spiv: Not really.  We might have a different model for that infrastructure than Gentoo, and Fred's patch could completely break it for Ubuntu.  The point is that I'll want to look at the set of patches from a likely OK source (e.g. Gentoo), even though I'm not in communication.  I don't expect that Gentoo will send merge requests.
[09:09] <spiv> persia: If we can't find a better way than explicit statuses, then I agree they would be ok.  But I think we should be trying to find ways to make this stuff totally automatic and effort-free.
[09:09] <persia> Let's assume for this that Gentoo is also using LP for VCS hosting.  I'll be looking at the Gentoo dev team branches.  It would be nice to see which ones are "Experimental" or "Abandoned" to reduce the search and review time.
[09:09] <spiv> Right, but if Fred's patch for Gentoo breaks Ubuntu, Fred isn't going to know that or tag his branch with that info.
[09:10] <spiv> So at some point you need to inspect the changes.  So the question is how much of that inspection effort can be automated.
[09:10] <persia> spiv: I understand the desire for automation, but I think it's better not to dispose of useful features just because it's easier.  If you default to "Development", only people who use it would ever have to know it's there.
[09:11] <persia> spiv: Yes, but if Fred's patch is expected to break Gentoo, it's not likely worth me reviewing it for Ubuntu.
[09:11] <persia> (Yes, it might be a good patch for Ubuntu, but it's more likely to not be)
[09:11] <spiv> Right.
[09:11] <spiv> So that is an interesting use case.
[09:12] <jml> persia: we should totally default to Development.
[09:12]  * jml always thinks of that as 'vanilla'
[09:12] <persia> jml: Absolutely.  That means that people who don't have a need for "Experimental" or "Abandoned" won't use them.
[09:12] <spiv> I'd think that merge proposals would model that ok though -- if Fred's branch isn't proposed for merging into Gentoo, it probably isn't ready yet.
[09:13] <spiv> i.e. if you're looking for interesting new work being done by Gentoo, start by browsing their merge proposals.
[09:13] <spiv> jml: +1 for defaulting to Development :)
[09:13] <persia> spiv: So rather than going to https://code.launchpad.net/foo-plugins to see the patches, you'd suggest I check each similar project, review which branches might be merge candidates, and build a list for review that way?  How is this easier?
[09:14] <spiv> Well, more broadly speaking, view all branches proposed for merging into anything.
[09:14] <persia> OK.  How do I sort the branches for e.g. Fedora (likely fairly safe) vs. the branches for e.g Arch (likely have some issue or they would have been requested for merge into Ubuntu)?
[09:14] <spiv> Ideally LP should have a single page per project to show you that, if that would be useful.
[09:15] <spiv> And I'd imagine that page would give you the usual nice table, with the clickable column headings that sort the table however you like.
[09:15]  * jml hugs bzr-removable
[09:15] <persia> I guess.  I have a single page per project that shows me a reasonably good overview now.  If there's a better page, I could see giving up the current page, but I don't want to give up the current page because a better page might be possible.
[09:16] <spiv> If "is proposed for merging somewhere" signifies someting important, I don't see why that attribute couldn't be highlighted on the front page.
[09:16] <spiv> In much the same way as "Status" is now.
[09:17] <persia> spiv: I agree.  I think it needs significant review.  I'd prefer to either have parallel pages, or show both pieces of information for a while to see which works better.
[09:17] <spiv> Except rather than "Status" being a simple list you manually fill out from a drop-down, it's an automatically derived thing that Launchpad shows based on what's actually happening to the branch.
[09:17] <jml> ok. now I really really want to do some plugin hacking.
[09:18] <persia> spiv: Just as a thought exercise, let's go through indication markers for each of the statuses with merge requests.
[09:18]  * persia will have to leave in 10 minutes
[09:19] <persia> spiv: How do we represent a developer indicating that the branch is useless, and should be ignored (Aboandoned)?
[09:19] <spiv> That's basically my wish: that with all the information Launchpad has about a branch (changes in it, it getting merged into other branches, proposals to merge it, bugs linked to it, people viewing it, people downloading it, etc), that I shouldn't have to then manually tell Launchpad what its status is, except maybe in exceptional circumstances.
[09:19] <persia> Oh, I agree with that.  I'm only talking about exceptional circumstances :)
[09:20] <spiv> I'd be ok with an explicit Abandoned state, but I also wouldn't expect it to be used very often.
[09:20] <persia> Right.  That matches my thoughts.
[09:20] <persia> How do we represent the case that a branch may break things, and shouldn't be used as a basis for others work?
[09:20] <spiv> Well, I really don't think there's much need to guard against that.
[09:21] <jml> persia: perhaps I'm cynical, but isn't that the default case?
[09:21] <spiv> Most breakages are really obvious.  "bzr merge; make" --> BOOM, compile error... "oh, ok, I guess that branch is busted".
[09:21] <spiv> And again, I think merging from branches speculatively is pretty unusual.
[09:22] <persia> jml: Well, when I'm working on something to target trunk soon, there's no need.  If I'm reimplmenting something in e.g. a different programming language, there's no expectation of merge *anytime* soon.
[09:22] <spiv> Perhaps important enough that we need to think about how to make it smoother, but still unusual.
[09:22] <spiv> I have enough trouble keeping up with branches I have reason to be interested in :)
[09:23] <persia> spiv: I disagree.  I see it a lot in some teams: where team members track each others' branches, and grab interesting bits.  Mostly for teams that don't have commit to trunk, and want to collaborate on a merge proposal.
[09:23] <spiv> Right, but that's not the same: that's watching a team's work.
[09:23] <spiv> You have other information to help you out there; you're probably lurking on a relevant mailing list, for instance.
[09:24] <persia> Heh.  Some of these folk need to be prodded to read ML traffic :)  This is the new immediate age: mail takes too long.
[09:24] <spiv> It's not "hey there's a branch I've never seen and know nothing about, let's see if it makes my system explode."  I just don't understand how that would ever be productive :)
[09:25] <spiv> "Hey there's a branch that touches feature X that I care about"... sure, I can see why you'd try that out.
[09:25] <spiv> But not totally arbitrary, where the only thing you know about a branch is it's URL.
[09:25] <persia> Oh.  I do it all the time with patches to fix bugs in Ubuntu.  If there's a bug that I want to fix, and I don't have a solution, I'll google for every bugtracker, patch, blog entry, etc. I can find, and try one or more patches to see if they work.
[09:25] <persia> I can read the code, so I understand when it's roughly right, but I don't necessarily know the source.
[09:26] <persia> s/source/source of the patch/
[09:27] <jml> persia: so, if you came across one of these patches and saw the word "Experimental" on it, would that change your behaviour?
[09:27] <persia> If I assume that LP imports or hosts all interesting branches everywhere, that becomes simpler, but status tagging is helpful.
[09:28] <persia> jml: Yep.  I don't pull from Fedora development or Debian Experimental unless I have some assurance that it's the right solution.  My common initial trolling points are Fedora released and Debian unstable.
[09:28] <jml> interesting.
[09:28] <spiv> So, if the branch didn't come from the official upstream branch, it might not be good enough quality for inclusion even if it appears to fix the relevant bug.
[09:28] <spiv> Or from some other blessed source.
[09:29] <persia> spiv: Rather, it's about optimising my patch review path.  I start with things known to be more stable, and then look for things that might be less stable.
[09:29] <spiv> So you're saying there are sources that are sometimes blessed and sometimes not, and you need them to be explicitly marked to know which is which?
[09:29] <spiv> Ok.
[09:29] <persia> If someone specifically indicates that something is known unstable (e.g. Debian Experimental), it's not likely a good place to start.
[09:29] <spiv> So, how I'd imagine this would go, is rather than scanning all branches first,
[09:30] <spiv> I'd scan the *release* branches of Debian, Fedora, etc first, to see if they have a fix.
[09:30]  * jml has to go.
[09:30] <spiv> And only if that search fails to find something would I look further afield.
[09:30] <persia> Well, rather that I'd like to have some indication if someone things their branch isn't ready.  I'm not that hung up on "official" sources.
[09:30] <jml> g'night gentlemen.
[09:30]  * persia has to go too.  Let's continue another time.
[09:30] <spiv> jml: g'night
[09:31] <spiv> persia: so I think searching for a fix can be done better :)
[09:31] <spiv> persia: let's continue another time :)
[09:31] <spiv> persia: thanks for the patient discussion!
[10:27]  * wgrant wonders if CVE stuff is ever going to be touched again, or if he'll end up working on it when LP does eventually become Free.
[14:38] <jcastro> barry: one more team list to unmangle: ~ubuntuforums-unanswered
[14:39] <barry> jcastro: done
[14:39] <jcastro> thanks!
[14:45] <elmo> ubuntuwhatnow?
[14:47] <Hobbsee> elmo: long form of ubuntucrack.
[14:48] <wgrant> That sounds about right.
[16:20] <andrea-bs> mrevell: I think that this FAQ should be updated: https://answers.launchpad.net/launchpad/+faq/39
[16:20]  * mrevell looks
[16:20] <mrevell> andrea-bs: Absolutely. I agree. I'll update that in the next few minutes. Thanks.
[17:25] <NCommander> beuno_, hola
[22:38] <RainCT> Hi. Where is the option to change a project name gone? :P
[22:38] <beuno_> RainCT, there should be a yellow edit button next to the title
[22:39] <RainCT> beuno: there's the "Edit details" but it only allows to change the "Display Name" and the "Title"
[22:39] <RainCT> ie, not the name used in the URL
[22:39] <RainCT> (or could it never be changed?)
[22:39] <beuno> RainCT, you can't edit the name used in the URL
[22:39] <beuno> you have to poke kiko-afk or Rinchen about it
[22:39] <beuno> or, file question requesting it
[22:39] <RainCT> ah, then I may have dreamed that there was an option for it :P
[22:39] <RainCT> OK, thanks :)
[22:40] <beuno> np  :)
[22:40] <Rinchen> ouch
[22:40] <Rinchen> someone poke?
[22:42] <RainCT> Rinchen: Don't worry :). I wanted to change a provisional project name to another provisional name, but if that has to be done manually I'll wait until I have a real name for it :P
[22:43] <Rinchen> RainCT, yes it's manual at the moment. But an easy manual
[22:45] <RainCT> Anyway, don't worry about it for now :).
[22:46]  * RainCT goes to bed, good night
[23:51] <tuxxy__> im having trouble with my mailing lsit if anyones around?
[23:55] <beuno> tuxxy__, sure, what seems to be the problem?
[23:56] <tuxxy__> hi beuno, well it seems I cannot send out mail to my own mailing list, yet team members can send to it successfully, I have tried from two different e-mail providers also and every time no one receives the mails, not even me heh
[23:57] <tuxxy__> I receive e-mails sent to the list by anyone else but I cannot send them
[23:58] <tuxxy__> https://lists.launchpad.net/64-bit/
[23:58] <tuxxy__> as you can see it is working for them but not the owner


[05:04] <mborzecki> morning
[05:21] <zyga> good morning
[05:30] <zyga> mborzecki: will you be reworking https://github.com/snapcore/snapd/pull/6874/files?
[05:30] <mup> PR #6874: cmd/snap-confine: do not mount over non files/directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6874>
[05:30] <mborzecki> zyga: hey, yes
[05:30] <zyga> cool, thanks!
[05:42] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6873/reviews
[05:42] <mup> PR #6873: gadget: improve device lookup, add helper for mount point lookup <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6873>
[05:42] <mborzecki> zyga: thanks
[05:50] <zyga> mborzecki: I just pushed https://github.com/zyga/snapd/tree/wip/lp-1828354 (diff https://github.com/snapcore/snapd/compare/master...zyga:wip/lp-1828354?expand=1 )
[05:50] <zyga> it doesn't nearly pass tests
[05:50] <zyga> I'm trying to understand which of the fragments of mimic construction breaks sharing
[06:05] <mborzecki> zyga: updated #6874
[06:06] <mup> PR #6874: cmd/snap-confine: do not mount over non files/directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6874>
[06:06] <mborzecki> zyga: tagged it for .39.1 too
[07:02] <pstolowski> morning
[07:04] <mborzecki> pstolowski: hey
[07:05] <mborzecki> pstolowski: https://news.ycombinator.com/item?id=19929986
[07:07] <jamesh> zyga: hi.  Do you know if anything came of the "desktop session agent" idea we brainstormed at the last engineering sprint?
[07:08] <jamesh> zyga: and if the answer is nothing, would it be something worth while for me to work on?
[07:16] <pstolowski> mborzecki: uhmmm
[07:17] <pstolowski> mborzecki: they even mention xplane, wow
[07:25] <mborzecki> pstolowski: so you know, when you put that antenna on your balcony ;)
[08:32] <Chipaca> interesting read, if you're into that sort of thing: https://songlh.github.io/paper/go-study.pdf
[08:32] <Chipaca> zyga: i know you probably are ^
[08:36] <mup> PR snapd#6873 closed: gadget: improve device lookup, add helper for mount point lookup <Gadget update> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6873>
[08:36] <zyga> jamesh: hey, not 100% sure if that's the topic but I think we agreed to use snap userd a lot more; having said that we're not doing anything towards  that
[08:37] <zyga> Chipaca: thank you, queued
[08:39] <jamesh> zyga: this was the idea of having a unix socket activated service in the user session that snapd could talk to
[08:40] <jamesh> zyga: this could either be userd, but wouldn't necessarily be the same thing.
[08:40] <zyga> jamesh: note, I'm at a sprint now, partial focus
[08:40] <jamesh> zyga: ah.
[08:40] <zyga> jamesh: I think that's the agreement
[09:39] <zyga> jamesh: I don't think we've ageed on anything byeond the general idea that there's a two way communication between system-wide snapd and per-user "aid"
[09:41] <jamesh> zyga: okay.  Would it be useful to start adding the infrastructure for the user agent?  From my memory, we discussed socket activated user session service speaking an HTTP API similar to snapd
[09:41] <zyga> mborzecki: so because that wip  branch I  posted  is arguably huge  and the test there is hard to follow, I'm making a standalone shell script that illustrates the issue so  that we can discuss this properly next week
[09:42] <zyga> jamesh: I think you need to get an ack from pedronis before you do that
[09:42] <mborzecki> zyga: ack
[09:42] <zyga> jamesh: explain that this is going towards bi-directional communication and this is the protocol idea and if you get an ack, work on  it
[09:43] <zyga> jamesh: I would refrain from proposing thnigs that need design review before there's written agreement on what it is
[09:44] <jamesh> zyga: okay.  Would the forum be the best place to do  that?
[10:29] <zyga> jamesh: yes, and a call as  well
[11:00] <Girtablulu> Chipaca: are you around?
[11:00] <Chipaca> Girtablulu: yes
[11:01] <Girtablulu> remember my issue on solus with snapd 2.39 and creating the snapshot by removal?
[11:02] <Chipaca> Girtablulu: yes
[11:02] <Chipaca> well, no, but yes
[11:02] <Chipaca> i didn't remember it was you :-)
[11:02] <Chipaca> but i remember the issue
[11:02] <Chipaca> mborzecki: is --prune in 2.39.1?
[11:02] <cachio> Chipaca, hey, if you want to enjoy  a bit you can take alook to https://github.com/snapcore/spread/pull/77
[11:02] <mup> PR spread#77: Add testflinger backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/77>
[11:02] <Chipaca> cachio: sure!
[11:03] <Chipaca> cachio: and i get the impression you asked me to do something last night and i never did :-/
[11:03] <Girtablulu> well talked to JoshStrobl and he had a look and made this patch https://dev.getsol.us/source/snapd/browse/master/files/0001-Force-usage-of-sudo-over-runuser-on-Solus.patch, and he said we have to look into the util-linux if it's setup wrong on Solus
[11:03] <cachio> Chipaca, hehehe, it is ok
[11:03] <cachio> no hurry
[11:03] <mborzecki> Chipaca: isn't that wip still? pstolowski will know
[11:03] <Chipaca> mborzecki: i meant purge, and it's not even in master, so yeah
[11:03] <cachio> Chipaca, I need a final review for #6618
[11:03] <mup> PR #6618: tests: validates snapd from ppa <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6618>
[11:04] <Chipaca> Girtablulu: wow
[11:04] <pstolowski> mborzecki, Chipaca: yes, not even in master, needs Samuele's review
[11:04] <Chipaca> Girtablulu: thanks for the update! that's very interesting
[11:04] <Chipaca> pstolowski: yep yep
[11:05] <Girtablulu> Chipaca: np you said I should come back if a solution is found :)
[11:05] <Chipaca> Girtablulu: it does sound like something's awry in solus's plumbing, but glad that's getting sorted one way or another
[11:05] <cachio> pstolowski, hey, yesterday I could make work the user my keys to sing the models
[11:06] <cachio> but then testing I realized I need to make some changes for core18
[11:06] <cachio> because the vms are not starting with the user1
[11:07] <cachio> I'll try to have it working before standup
[11:08] <Chipaca> cachio: do systems start with numbers in testflinger?
[11:09] <cachio> Chipaca, no
[11:09] <cachio> names are alphanumeric
[11:09] <Chipaca> cachio: the change to validSystem seems bogus then
[11:10] <cachio> Chipaca, yes, you are right
[11:10] <cachio> should be something like [a-z]+[0-9]+
[11:11] <Chipaca> cachio: the * seems intentional also
[11:11] <Chipaca> which you removed
[11:11] <Chipaca> but dunno
[11:11] <cachio> Chipaca, no, because the name enforced has a - between
[11:12] <Chipaca> ?
[11:12] <Chipaca> ah
[11:12] <Chipaca> you mean in testflinger systems can't have -s?
[11:12] <cachio> I need [a-z]+[0-9]+-[a-z0-9*]
[11:12] <Chipaca> no you don't :-)
[11:12] <cachio> Chipaca, the name enforced by default is like
[11:12] <Chipaca> cachio: what do you actually need? give me examples please
[11:13] <cachio> rpi-3-64
[11:13] <cachio> and we need rpi3-64
[11:13] <cachio> because then we use the rpi3 as name for testflinger
[11:14] <Chipaca> ah
[11:14] <cachio> Chipaca, rpi3 is the device name on tf
[11:14] <Chipaca> cachio: and do you know what systems have an '*' in them?
[11:14] <Chipaca> wondering what that was there for
[11:14] <cachio> Chipaca, no idea, I never seen one with *
[11:15] <Chipaca> let's ask gustavo :)
[11:15] <cachio> Chipaca, yes :)
[11:15] <Chipaca> niemeyer: in spread, why does the validSystem regexp allow explicit asterisks in the system name? "^[a-z*]+-[a-z0-9*]+(?:[-.][a-z0-9*]+)*$"
[11:15] <Chipaca> niemeyer: what's the use case for this? (examples? tests?)
[11:18] <Chipaca> cachio: in any case what you want is probably "^[a-z][a-z0-9]*-[a-z0-9]+(?:[-.][a-z0-9]+)*$"
[11:18] <Chipaca> cachio: modulo *s inside the []s pending gustavo's reply
[11:18] <Chipaca> cachio: that is, changing the [a-z]+ to a [a-z][a-z0-9]*
[11:18] <Chipaca> meaning there can be numbers in the first chunk as long as it doesn't start with numbers
[11:19] <cachio> perfect
[11:19] <Chipaca> cachio: simplest way forwards is to assume the *s are there for a reason, and replacing the [a-z*]+ with [a-z*][a-z0-9*]*
[11:19] <cachio> change done :)
[11:20] <niemeyer> Chipaca: Might be a bug depending on where this is used, but systems filtering allows wildcards
[11:20] <Chipaca> ah! +ubuntu-* etc?
[11:20] <Chipaca> cachio: there you go :)
[11:20] <cachio> Chipaca, niemeyer nice
[11:21] <Chipaca> cachio: so
[11:21] <cachio> I never tried it :)
[11:21] <Chipaca> cachio: ^[a-z*][a-z0-9]* instead of ^[a-z*]* and the rest stays the same
[11:22] <niemeyer> cachio: I'm pretty sure snapd tests depends on this
[11:22] <Chipaca> of course that means you couldn't say rpi*
[11:23] <Chipaca> e.g. tests/main/xdg-open/task.yaml:systems: [-ubuntu-core-*]
[11:23] <Chipaca> cachio: ^
[11:23] <cachio> niemeyer, we run snapd tests like doing google: that should use the * as wildcard right?
[11:23] <Chipaca> cachio: it's for the filtering in tasks
[11:24] <niemeyer> cachio: No, that uses ... because wildcards are special for shells
[11:25] <Chipaca> cachio: I suspect you forgot to push to snapd#6618
[11:25] <mup> PR #6618: tests: validates snapd from ppa <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6618>
[11:26] <cachio> niemeyer, ok, thanks for the explanation
[11:27] <Chipaca> niemeyer: ditto, thanks
[11:27] <niemeyer> nps!
[11:27] <cachio> Chipaca, right, pushing
[11:32] <cachio> Chipaca, pushed
[11:35] <pstolowski> cachio: ack, thanks for update!
[11:43] <cachio> pstolowski, I just pushed the new models I am trygin to make that work
[11:44] <cachio> pstolowski, to run the test you need to set the variable SPREAD_NEW_CORE_CHANNEL to edge
[11:44] <pstolowski> cachio: ack, ty, i'll try that
[12:03] <mborzecki> off to pick up the kids
[12:04]  * Chipaca lunches
[12:13] <popey_> how long should a refresh from of core from stable to candidate (2.39) take? It's taking forever here.
[12:13] <popey_> "snap changes" hasn't returned anything at all.
[12:14] <popey_> Consider re-refresh of "core"   is all it says in the terminal where I am refreshing core
[12:19] <popey_> perhaps it's regenerating all apparmor profiles or something?
[12:19] <popey_> (yes, looks like that's what it's doing, incredibly slowly)
[12:20] <pstolowski> popey_: possible, ps aux and check for apparmor parser? i just checked and it was almost instant, but i have very few snaps
[12:23] <popey_> pstolowski: yes, i see a lot of apparmor parser in syslog. i have 260 snaps and this is taking an age and I'm not getting any feedback from the "snap refresh core --candidate" about what's happening
[12:23] <popey_> if I was a normal person, I would likely have turned my computer off right now
[12:23] <popey_> (not that a normal person has 260 snaps ofc) :D
[12:24] <popey_> \o/ finished
[12:24] <popey_> that was about 20 mins. not bad for 260 snaps :D
[12:26] <pstolowski> popey_: i agree, no feedback is problematic
[12:27] <pstolowski> something worth exploring/imrpoving
[12:28] <pstolowski> bbiab
[12:54] <jdstrand> popey_: this gets precisely to the snapd team's roadmap item to make this faster (cc zyga). snapd is calling apparmor_parser for *every* interface connect in every snap command rather than once per snap command
[12:55] <jdstrand> popey_: which makes it particularly terrible for you and as snaps get more popular
[12:55] <jdstrand> popey_: but, it's known and understood and now marked as a deliverable for the next cycle (last I saw)
[12:56] <popey_> \o/
[12:56] <popey_> https://www.youtube.com/watch?v=ZtAzeoA0UgE

[13:01] <Chipaca> pstolowski: mborzecki: cachio: standup?
[13:05] <kenvandine> zyga: is bug 1825883 fixed in 2.39 or is there still some work to do?
[13:05] <mup> Bug #1825883: stale copy of plug and slot attributes is kept in connection state <snapd:In Progress by zyga> <https://launchpad.net/bugs/1825883>
[13:07] <Chipaca> mborzecki: i thought for mkfs.extN you could avoid the root/non-root weirdness via root_user
[13:08] <mup> PR snapcraft#2537 closed: dotnet plugin: fix parsing of newer sdk releases <Created by ianmetcalf> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2537>
[13:08] <mborzecki> Chipaca: is that an option for mkfs?
[13:09] <Chipaca> mborzecki: yes
[13:09] <Chipaca> mborzecki: under extended options
[13:09] <mborzecki> Chipaca: isn't that the owner of / only?
[13:11] <Chipaca> mborzecki: what else does it do that needs fakeroot?
[13:12] <mborzecki> Chipaca: ownership of all entries dropped into the fs, it's basically doing `mkfs.ext.4 <magic-options> -d <rootfs>`
[13:12] <mborzecki> s/ext.4/ext4/
[15:31]  * cachio lunch
[16:08] <mup> Bug #1829558 opened: Unable to install fwupd <Snappy:New> <https://launchpad.net/bugs/1829558>
[16:31] <zyga> kenvandine: pstolowski|afk did the fix in reduced capacity for 2.29 but I don’t remember if that is .0 or .1
[16:36] <Chipaca> zyga: 29, or 39?
[16:36] <kenvandine> i'm sure it had to be 39
[16:41] <Chipaca> kenvandine: I _think_ it's e4c706fb7bf9f19279d54f1ce610ef2bbfaae8b1/b2c48938155f8e05f53843fe718e6f326c0362ec but I can't see that in any tag
[16:41] <Chipaca> kenvandine: mvo will know for sure
[16:42] <Chipaca> if i'm right, then not in any tag → not in 2.39; hopefully 2.39.1
[16:42] <Chipaca> but if you need certainty (heh) ask mvo
[16:43] <kenvandine> i'll talk to him on monday
[17:01] <Chipaca> EOW, ttfn
[17:53] <cachio> pstolowski|afk, I pushed the change in the model to make the nested vms start correctly
[17:53] <cachio> and other changes
[17:54] <cachio> the problem is that the qemu is not appearing when doing snap connections system
[17:54] <cachio> pstolowski|afk, it is easy to reproduce by running: SPREAD_NEW_CORE_CHANNEL=edge spread -debug google-nested:ubuntu-18.04-64:tests/nested/core/hotplug
[17:54] <cachio> still missing the change to reuse the test script
[17:55] <cachio> pstolowski|afk, but first I want to make it pass :)
[18:17] <pstolowski|afk> cachio: thanks, I’ll check it, the symptoms are as if my fix isn’t present or was not sufficient
[18:18] <cachio> pstolowski|afk, when was it merged?
[18:18] <cachio> it should be on edge
[19:03]  * cachio afk


[00:57] -BottyMcBotFace:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-weather-plugin 0.10.1 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-weather-plugin-0-10-1-released-tp57414.html (by Sean Davis-6)
[01:38] <bluesabre> Well, nice Pidgin x.x
[01:47] <JackFrost> Hmm?
[01:47] <bluesabre> Got shortly kicked for flood :D


[03:58] <jak08> about how long does it take for a bacground to be approved?
[10:15] <lapo> hi
[03:31] <gepatino> hi, is this the right place to make a suggestion on icons?
[03:41] <lapo> maybe :-)
[03:42] <lapo> gepatino: tangerine?
[03:46] <gepatino> yea
[03:46] <gepatino> sorry for the delay
[03:46] <lapo> gepatino: no problem, shot the suggestion :-)
[03:46] <gepatino> lapo, have you seen the little icon for network-monitor?
[03:46] <lapo> if you have to rant it is probably my fault :-)
[03:47] <gepatino> :)
[03:47] <gepatino> the one that shows two monitors conected?
[03:47] <lapo> it uses my network workgroup icon
[03:48] <gepatino> i think it could be more clear if these little monitors show full plain colors while transfering data
[03:48] <lapo> I'm thinking about doing a specific icon for that one I don't see network-workgroup good for it
[03:48] <gepatino> like in breezy, when transmiting, the screens get pale blue
[03:48] <gepatino> ok
[03:49] <lapo> gepatino: we could use network-transmit istead of network-workgroup
[03:49] <gepatino> or maybe one screen in red and the other in green (or wathever two color you think appropiate) to whow uploads and downloads.
[03:49] <lapo> gepatino: this is not something we can change thos you should open a bug against the appication
[03:49] <gepatino> lapo, sorry, haven't see that one
[03:50] <gepatino> lapo, but, is it a bug? I mean is not that bad to have the icon we have now
[03:50] <gepatino> lapo, just a suggestion
[03:54] <lapo> It's a bug :-)
[03:54] <gepatino> ok... so it'll be reported
[03:54] <gepatino> thanks
[03:55] <lapo> thanks for reporting! :-)
[03:55] <gepatino> you're doing a great job, artwork in dapper is just beatifull
[03:56] <gepatino> have a nice weekend!
[07:57] <lapo> ciao
[11:53] <ertz> hello..


[07:46] <march_happy> Hi there! I am trying to install Pantheon in Ubuntu Studio. However after I finished I cannot use my Chinese input method. Fcitx never shows up. Any ideas for debugging?
[07:49] <march_happy> And do you have a Telegram channel for better communication?
[18:15] <Lucky-MF> anyone been using tracktion?


[00:20] <bryceh_> RAOF, happen to know what the procedure is for switching between fglrx and ati?  The only howtos I ran across looked rather hairy (and a bit oldish)
[00:21] <RAOF> bryceh_: IIUC the ati control panel has a button that you press.
[00:21] <bryceh_> hmm, ok
[00:22] <bryceh_> I suppose if people have problems we just point them at AMD...
[00:25] <bryceh_> RAOF, btw sarvatt didn't think it'd be worth having people test that -intel patch quite yet
[00:25] <RAOF> Ah, ok.
 Sarvatt, did that -intel patch get taken care of by anyone already?  Should I roll up a ppa and solicit testers?
 bryceh_: nope not yet, it'll need a bit of cleaning up for 2.14.0 because of has_kernel_flush
[00:30] <bjsnider> bryceh_, wouldn't jockey allow you to deactivate fglrx at which time you'd be using ati by default?
[01:10] <Sarvatt> bryceh_: oh I just meant we're gonna need to backport the commit and cant just cherrypick it, we definitely do need to get it in I was just busy at the time
[01:11] <Sarvatt> or we could just revert http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=cc930a37612341a1f2457adb339523c215879d82 :P
[01:12] <Sarvatt> bryceh_: you mean like for the hybrid stuff in fglrx now? that runs on scripts we dont ship that rename libs.
[01:15] <Sarvatt> (so it doesnt do anything)
[01:20] <Sarvatt> its really incompatible with how we package fglrx, not sure whats going to happen with it but tseliot was discussing it with them and might have some info on it. they back up and replace the system libs when you pick ati and move things back when you want to switch to intel
[01:20] <Sarvatt> it also doesnt work for switching between fglrx and ati, only for fglrx and intel hybrids
[01:25] <bryceh_> Sarvatt, ok yeah I suspected this as the case
[14:27] <mdeslaur> hmm...is it a known issue that with today's iso, jockey shows the nvidia driver as being installed, even though I am clearly using nouveau?
[14:30] <tseliot> mdeslaur: what's the output of "jockey-text -l" ?
[14:30] <mdeslaur> tseliot: it says "xorg:nvidia_current - blah blah (Proprietary, Enabled, In use)"
[14:30] <Sarvatt> have you rebooted since installing it?
[14:31] <mdeslaur> and underneath "xorg:nouveau - blah blah (Free, Disabled, Not in use)"
[14:31] <Sarvatt> (stupid question but have to ask, sorry)
[14:31] <mdeslaur> Sarvatt: yes
[14:31] <tseliot> mdeslaur: what about the output of "update-alternatives --display gl_conf" ? (please put it on pastebin)
[14:31] <mdeslaur> Sarvatt: oh, I didn't change _anything_ in jockey...that's what it came up as by default
[14:32] <tseliot> mdeslaur: also your jockey.log  in /var/log/ might help
[14:33] <mdeslaur> tseliot: ok., hold on...I'll file a bug and put all those in it
[14:34] <tseliot> thanks
[14:37] <mdeslaur> tseliot, Sarvatt: bug 759804
[14:37] <ubot4> Launchpad bug 759804 in jockey (Ubuntu) "after fresh install, jockey thinks nvidia binary driver is in use (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/759804
[14:38] <tseliot> mdeslaur: you're still using nvidia, at least its GL libraries
[14:39] <tseliot> you can't be using nouveau as it's blacklisted when nvidia is enabled
[14:40] <tseliot> so, in short, Jockey is right ;)
[14:40] <Sarvatt> the nvidia kernel module isn't built
[14:40] <mdeslaur> tseliot: did you look at the xorg log file?
[14:42] <tseliot> mdeslaur: it seems that the kernel module wasn't loaded. What does "dkms status" say?
[14:43] <mdeslaur> tseliot: it doesn't say anything
[14:44] <tseliot> mdeslaur: please try "sudo dpkg-reconfigure nvidia-current" and see what happens. I bet that somehow dkms failed
[14:44] <mdeslaur> Error! There are no instances of module nvidia-current 270.30 located in the DKMS tree
[14:45] <mdeslaur> ok, it seems to have built it now
[14:45] <mdeslaur> I'll try rebooting
[14:46] <tseliot> ok
[14:47] <mdeslaur> ok, looks like I'm running -nvidia now
[14:47] <mdeslaur> hmm...not a nice bug
[14:48] <janimo> RAOF, I see you commented on this one https://bugs.freedesktop.org/show_bug.cgi?id=32254 . Is the fix supposed to be in natty, the comment does not mention which branch the fix went into
[14:48] <ubot4> Freedesktop bug 32254 in Other "EGL+OpenGL API failed to work" [Normal,Resolved: fixed]
[14:49] <tseliot> mdeslaur: can you close your bug report, please? I don't think we can figure out what happened before...
[14:49] <mdeslaur> now jockey says "This driver is activated but not currently in use"
[14:49] <mdeslaur> tseliot: I can reinstall and reproduce at will I bet you
[14:50] <Sarvatt> janimo: because it went into master, it'll be in 7.11, no it wont be in natty
[14:50] <janimo> Sarvatt, ah thanks. Too bad though
[14:51] <tseliot> mdeslaur: if you can reproduce it, please attach your /var/lib/dkms/nvidia-current/270.30/build/make.log
[14:51] <mdeslaur> tseliot: ok, I'm reinstalling now, and will attach that log
[14:52] <tseliot> mdeslaur: as regards the fact that Jockey says that the driver is not in use, I'd like to see your new jockey.log
[14:53] <mdeslaur> tseliot: sure, one sec
[14:56] <mdeslaur> tseliot: done
[14:57]  * tseliot has a look
[15:18] <mdeslaur> tseliot: I have reinstalled, and hit the issue again
[15:18] <mdeslaur> tseliot: there is no log file in /var/lib/dkms
[15:19] <tseliot> mdeslaur: you must have something in /var/lib/dkms/nvidia-current/270.30/build/
[15:19] <mdeslaur> the only thing I have in /var/lib/dkms is a file called dkms_dbversion
[15:19] <mdeslaur> that's it
[15:20] <mdeslaur> no other subdirectory
[15:20] <tseliot> mdeslaur: your last jockey.log should contain some errors
[15:21] <mdeslaur> tseliot: huh?
[15:21] <mdeslaur> tseliot: do you want my new jockey.log file?
[15:21] <tseliot> mdeslaur: yes, if you installed the driver using jockey
[15:21] <mdeslaur> tseliot: I don't touch _anything_ in jockey. I just open the window, and click close
[15:21] <mdeslaur> jockey already thinks nvidia is installed
[15:22] <Sarvatt> did you check the enable 3rd party software box during the install?
[15:22] <mdeslaur> Sarvatt: yes, I did
[15:22] <mdeslaur> Sarvatt: would you like me to reinstall without checking it?
[15:23] <tseliot> mdeslaur: ok, if you do this manually, please capture the output of the operation so that I can see what dkms says
[15:24] <Sarvatt> thats ok, wont help figure out why the heck its getting in the state where it thinks its installed and activated but isnt really, it wont install if you dont check that box
[15:24] <mdeslaur> tseliot: you want me to trigger dkms and capture the output?
[15:25] <tseliot> mdeslaur: I'd like you to reproduce the issue and capture the output
[15:25] <Sarvatt> he just did
[15:25] <tseliot> let me check again
[15:25] <mdeslaur> tseliot: I'm not sure what you mean....the output of _what_?
[15:25] <tseliot> mdeslaur: I guess you remove the driver and then re-install it with apt, right?
[15:26] <Sarvatt> tseliot: the problem is when you check the activate the 3rd party drivers box during the install it tries to install the blobs and for some reason its not actually installing it but jockey thinks its installed and activated
[15:26] <mdeslaur> tseliot: not at all
[15:26] <tseliot> mdeslaur: how do you do it?
[15:26] <mdeslaur> tseliot: I don't do _anything_. I install, and then open jockey. That's it.
[15:26] <Sarvatt> he only opens jockey to see what the status is and it says activated and in use
[15:27] <tseliot> mdeslaur: "install" how?
[15:27] <Sarvatt> from a livecd
[15:27] <mdeslaur> tseliot: from a livecd (well, from a usb key)
[15:27] <tseliot> aah, ok
[15:27] <tseliot> mdeslaur: that's not supposed to work
[15:27] <Sarvatt> he's installing onto a disk, that part is supposed to work
[15:27] <mdeslaur> tseliot: what's not supposed to work?
[15:28] <Sarvatt> not trying to install it in a live session where it's not supposed to work
[15:28] <mdeslaur> nono, I'm not trying to do anything in a live session....I'm installing a laptop from the livecd
[15:29] <tseliot> mdeslaur, Sarvatt: right but while this *should* work it never did. It's likely a bug in the installer which doesn't copy your compiled module
[15:30] <tseliot> then when you boot into your installed system you get no nvidia module
[15:30] <tseliot> *kernel module
[15:30] <Sarvatt> so this has always been a problem and didnt just start happening?
[15:30] <tseliot> yep
[15:30] <tseliot> (the former)
[15:31] <tseliot> this problem is something I can probably fix though:  https://launchpadlibrarian.net/69240249/Screenshot-Additional%20Drivers-1.png
[15:32] <Sarvatt> cool, thats the main problem
[15:32] <Sarvatt> oh wait, thought that was the activated and in use pic
[15:32] <mdeslaur> so, for our 60% of users that have an nvidia card, and click the "3rd party" checkbox, they will have no way of activating the -nvidia drivers
[15:32] <Sarvatt> what he's saying is when you do a fresh install, nvidia thinks its installed and in use and you cant activate it tseliot
[15:32] <mdeslaur> Sarvatt: yes, there are two different issues
[15:33] <tseliot> Sarvatt: yes, it's that picture
[15:33] <tseliot> yep
[15:33] <mdeslaur> issue #1: dkms doesn't get triggered for -nvidia during install. Issue #2: once -nvidia dkms module is rebuilt, jockey thinks -nvidia is not in use
[15:34] <tseliot> actually
[15:34] <Sarvatt> mdeslaur: #2 might be intentional until you reboot and it'd show activated and in use
[15:34] <mdeslaur> Sarvatt: I did reboot between rebuilding the module and opening jockey again
[15:35] <Sarvatt> apologies if you're saying its still saying that after reboot, i didn't follow it all
[15:35] <Sarvatt> ahh sorry
[15:35] <tseliot> issue #1: modules built by dkms are not copied to the installed system.
[15:35] <tseliot> issue #2: Jockey doesn't detect the driver as activated and in use in some cases
[15:36] <mdeslaur> tseliot: yes, exactly
[15:36] <tseliot> mdeslaur: while I can fix issue #2, you should talk to cjwatson about issue #1
[15:36] <tseliot> it might be useful to ping pitti too
[15:37] <mdeslaur> I'll add ubiquity to the bug
[15:38] <tseliot> mdeslaur: I think it would also be worth updating the bug description with these 2 issues
[15:39] <Sarvatt> its gotta be specific to nvidia, otherwise wl wouldn't work and it does
[15:40] <tseliot> ah
[15:41] <Sarvatt> i need to double check that, i might have been using brcm80211 in these recent installs instead and not have noticed
[15:45] <tseliot> it would be interesting to know
[16:54] <Sarvatt> bryceh_: think 40-xserver-xorg-video-intel.rules is triggering too much? http://paste.ubuntu.com/593618/ :)
[18:15] <bryceh_> Sarvatt, heh
[18:15] <bryceh_> Sarvatt, probably about time for us to turn it off anyway
[18:18] <Sarvatt> running the rule and dumping was triggering these http://paste.ubuntu.com/593614/ and they stopped when i got rid of the udev rule
[18:21] <Sarvatt> RAOF: hrm software-center started working without 113_fix_tls.diff again
[18:22] <Sarvatt> the tls patch was causing problems on amd64 with mesa master so i haven't been adding it in edgers
[18:27] <dbarth> bryceh_: hey bryce; hi
[18:27] <dbarth> i'm suddenly getting some x crashes since monday or so, and i can only get that kind of backtrace in the xorg log: http://pastebin.ubuntu.com/593615/
[18:28] <dbarth> no real test case, but the info is that it's almost the first time in the cycle that i've had crashes with my server at all
[18:28] <bryceh_> hmm interesting
[18:29] <bryceh_> dbarth, RAOF posted a new (bugfix) release of mesa on Monday
[18:29] <dbarth> ah right, i heard about it
[18:29] <dbarth> so do you want me to downgrade and see for a day or two?
[18:29] <Sarvatt> not fixed in that, i'm digging up the bug number for that one
[18:30] <dbarth> i don't want to add another bug report to the pile with so little info
[18:30] <bryceh_> dbarth, your /var/log/dpkg.log should have the details of what exactly got upgraded; I'd probably start by downgrading packages to isolate what package regressed
[18:30] <dbarth> and wait a little bit to see if the sudden crashes go away
[18:30] <dbarth> ok, i'll do that
[18:30] <dbarth> thanks
[18:30] <Sarvatt> dbarth: that backtrace is a known problem, i've only been able to reproduce it closing the lid for >30 minutes here
[18:30] <Sarvatt> trying to find the bug for it so you can track it still
[18:31] <Sarvatt> only happens in a unity session
[18:31] <dbarth> Sarvatt: ah thanks
[18:31] <dbarth> uh, /that/ doesn't sound good
[18:35] <Sarvatt> dbarth: hrm I take that back, got it confused with the other one where X doesn't crash, https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/740126
[18:35] <ubot4> Launchpad bug 740126 in compiz (Ubuntu Natty) (and 1 other project) "compiz hangs randomly several times per day (affects: 4) (heat: 24)" [High,Confirmed]
[18:35] <Sarvatt> i've seen that backtrace a few times in the past few days though, robert_ancell had it http://paste.ubuntu.com/592987/ checking to see if he filed a bug
[18:36] <dbarth> Sarvatt: ah that one is the xcb hang
[18:36] <dbarth> (or let me check)
[18:37] <dbarth> well, it's an xcb hang
[18:37] <Sarvatt> that xcb hang was what I was saying I could reproduce and only had happen in unity, sorry about that :)
[18:37] <dbarth> nw
[18:37] <dbarth> but i'm aware of 2 of those
[18:37] <dbarth> one that was involving an xgetwindowproperty
[18:37] <dbarth> and that we workarounded
[18:37] <dbarth> and that other one
[18:38] <dbarth> but which may actually be triggered by another change we made to fight the stacking issues
[18:38] <dbarth> there is a daily build of compiz where you can turn the stackattack otpion off
[18:38] <dbarth> and that may help with this bug
[18:38] <dbarth> ie not trigger it that often
[18:39] <dbarth> Sarvatt: is there a bug that i could subscribe to for the backtrace?
[18:42] <Sarvatt> i'm not seeing one, it'd be appreciated if you could file one against xorg-server and we can dupe it later if we find it
[18:44] <Sarvatt> neither of the 2 people i've seen the backtrace from ended up filing a report and i'm not seeing a one filed against xorg xorg-server or compiz
[18:44] <Sarvatt> guess i should check intel, both of the other reporters were on intel
[18:46] <bryceh_> I don't see one against -intel
[18:47] <bryceh_> jeesh so many bugs
[18:49] <bryceh_> Sarvatt, on https://bugs.freedesktop.org/show_bug.cgi?id=34014 check comment 28  :-/
[18:49] <ubot4> Freedesktop bug 34014 in Driver/intel "[i915gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000004)" [Major,Resolved: fixed]
[18:50] <Sarvatt> bryceh_: ugh...


[08:33] <Dan> I just came across a broken link on this page: https://help.ubuntu.com/community/AptGet/Howto - additional link 6 at the bottom of the page (How to speed up package updates using apt-fast).
[08:57] <GunnarHj> Dan: Thanks for pointing it out! I replaced it with a working one.
[09:07] <Dan> thanks :)


[00:42] <OvenWerks> Eickmeyer[m]: https://lists.linuxaudio.org/archives/linux-audio-announce/2020-April/002798.html
[00:44] <Eickmeyer[m]> Interesting.
[00:44] <OvenWerks> pretty exciting that someone has put that together
[00:45] <OvenWerks> it has been stock macos and ios for years now
[00:46] <Eickmeyer[m]> Yeah. When I was at my last job, we pretty much had mac/windows environments and I was starting to work on MIDI-IP stuff. This would've brought Linux into that mix.
[00:46] <OvenWerks> linux has had ipmidi for a while
[00:47] <Eickmeyer[m]> Right, but not really zeroconf.
[00:47] <OvenWerks> qmidinet we have
[00:47] <OvenWerks> right
[00:47] <Eickmeyer[m]> What I'm saying is that this would've made it braindead-simple what I was working on.
[00:48] <Eickmeyer[m]> Might be something worth including in 20.10.
[00:49] <OvenWerks> yes, though probably with the right glue.
[00:49] <OvenWerks> I will have to see.
[00:50] <OvenWerks> I have been working on documentation for Ardour for all the stuff I added since 5.12
[00:51] <OvenWerks> I thought I had been keeping up but didn't really think how my foldback stuff affected OSC
[00:53] <Eickmeyer[m]> Do you think studio-controls could be that right glue?
[00:54] <OvenWerks> I will need to try it out to really know
[00:55] <OvenWerks>  I don't know the protocol well enough to know how automated it already is
[00:56] <OvenWerks> It could be that if another computer sets up a connection, it just shows up in alsa or jack
[00:58] <OvenWerks> I would at some point like to create a patch bay similar to patchage or Carla but have it show "possible" connections that are not on the jack grid yet (or alsa)
[00:59] <Eickmeyer[m]> Interesting concept.
[00:59] <Eickmeyer[m]> I'm sure Filipe would be OK with copying the code from Catia.
[01:00] <OvenWerks> not just for rtpmidi, but also for USB audio devices that are not yet connected using zizta-ajbridge (there is a new version BTW) and AVB or aes 67 end points that are available but not yet connected.
[01:01] <OvenWerks> in other words the discovery info of possible connections
[01:02] <OvenWerks> The patch pannel would start the connecting SW at the time the connection was asked for.
[01:02] <OvenWerks> and then connect it
[01:03] <Eickmeyer[m]> That's a really cool concept.
[01:03] <Eickmeyer[m]> If anyone can pull it off, it's you.
[01:04] <OvenWerks> I would probably use the patchbay method used by Ardour (and many other patch bays) rather than patchage or qjackctl connections
[01:05] <Eickmeyer[m]> That's fair. It's not a bad patchbay method. Patchage/Carla connections are easier for my head to wrap-around, personally, because I think in terms of connecting devices together.
[01:05] <OvenWerks> Eickmeyer[m]: they are both great for small numbers of ports
[01:06] <OvenWerks> Eickmeyer[m]: have you tried to play with even a 10strip Ardour session using one of those patch bays?
[01:06] <Eickmeyer[m]> That's true. When connecting a lot of ports at once, the Ardour method is better.
[01:06] <Eickmeyer[m]> Hehe, I've done 32-strip.
[01:08] <Eickmeyer[m]> Really, more like 36-strip after adding a few effects busses.
[01:08] <OvenWerks> right, it is doable, but a lot of wires in patchage and a lot of scrolling in qjackctl
[01:09] <Eickmeyer[m]> I don't touch qjackctl anymore. :P
[01:12] <OvenWerks> but if you look at pretty much all of my sw, it is control stuff
[01:13] <OvenWerks> I have not done any dsp for example
[15:42] <Eickmeyer> OvenWerks: Wishlist-item for Controls: a system tray indicator that shows Jack's state.
[15:42] <Eickmeyer> Came up while your client was dead.
[15:45] <OvenWerks>  :P
 Eickmeyer: https://askubuntu.com/questions/1225047/ubuntu-studio-20-04-firewire-compatibility relevant
 for your attention
 (I'mma close as Offtopic because 20.04 but something you might wnat to look at)
[15:45] <OvenWerks> systray stuff was already hard the indicator stuff (when I looked at it) was to new to find reasonable documentation on it
[15:52] <Eickmeyer> teward: We removed the non-ALSA firewire support, proved to be too problematic to support ancient, no-longer-being-produced devices.
 ack i'll write that reply
[15:53] <OvenWerks> @teward001 I am already writing something
[15:53] <Christoffer[m]> How is the team, who are the people and their positions or responsebillities. Who else does marketing/social media/communication for Ubuntu Studio?
[15:53] <Eickmeyer> teward: Also, Ask Ubuntu is an official support channel for all flavors.
 @OvenWerks Eickmeyer already got it
 @Eickmeyer yes, I know.  I'm a moderator there
 *throws salt on you*
 but it's a 20.04 question ;)
 there's restrictions on those
[15:54] <OvenWerks> @teward001: doesn't support means we can't help if you can't get it to work.
 @OvenWerks [<OvenWerks> @teward001: doesn't support means we can't help if you can't get it …], this is true, however that's also still irrelevant to MY point - an answer of "Firewire isn't supported anymore" is a valid answer in those cases
[15:54] <Eickmeyer> Christoffer[m]: Marketing/social media/communication is mostly myself and @azbutlutlu.
 but it's a 20.04 question which is one we usually snipe :P
 but in this case it's able to be answered
 it showed up in the flags so :P
 (again I'm a moderator on Ask Ubuntu - I SEE YOUR IPS!)
 *shot*
[15:55] <Eickmeyer> Weird flex, but ok
[15:57]  * OvenWerks thinks he had a nicer answer.... but couldn't login
[15:59] <Christoffer[m]> I see
[15:59] <Christoffer[m]> I take it you are basically the community manager as well?
[15:59] <Eickmeyer[m]> Christoffer: I'm the Project Leader.
[16:00] <Eickmeyer[m]> In Ubuntu terms, I'm the flavor lead and point-of-contact.
[16:00] <Eickmeyer[m]> That's mostly an intra-Ubuntu thing.
[16:00] <Christoffer[m]> Eickmeyer
[16:01] <Eickmeyer[m]> ....yes?
 what eickmeyer is trying to say is that he is the communication with me trying to hold mastodon side upright and being second eyes on release notes or website related things when I can.
 ^ Facts
 that is pretty much the summary of the current situation on pr/communications
 I also try to do or at least review art/design when I can. eickmeyer does leading and packaging he knows better than I who does what on technical side. (I only know owenwerks is basically THE ubuntustudio-controls. <3)
 i'm sort of the support role, testing, helping with packaging, sponsoring package uploads when people in the team don't have upload rights, etc.
[17:00] <Eickmeyer[m]> Christoffer: ^
 but i also bother the heck out of Eickmeyer just because ;)
[17:00] <Eickmeyer[m]> I'd consider OvenWerks the development lead.
 i agree with that
 (Thomas thanks for graciously explaining that instead of laughing at me for still not having caught up to what is happening here)
 oh i'm laughing at you
 i'm just not making it known xD
 fair enough xD
 Don't take it personally, @azbulutlu . @teward001 laughs at everytone and everything.
 *everyone
 and sometimes I just rage at everyone too
 esp. on bad days :P
 but that's just me
 ^ Facts
 in all fairness I am laughing at myself. and lol
 <3
[17:06] <Christoffer[m]> ahh, that also does community management and social media
[17:23] <Eickmeyer[m]> Christoffer: Does that help with what you need?
 (also christoffer when you sort out the pgp thing do email me for the mastodon password.)
[17:59] <Christoffer[m]> Ahh, I see
[18:00] <Christoffer[m]> It's easier when one kind of know where people are at and stuff
[18:00] <Christoffer[m]> I'll sort the email stuff soon^^
[18:01] <Christoffer[m]> Who is the media contact?
[18:02] <Christoffer[m]> I'm guessing it's you Eickmeyer
[18:02] <Eickmeyer[m]> ERR:DrAppt
[18:03] <Christoffer[m]> huh?
[18:03] <Eickmeyer[m]> Christoffer: Yes, that's correct.
[18:03] <Eickmeyer[m]> I have a telephone doctor appointment right now.
[18:04] <Christoffer[m]> Okay
[18:21]  * Christoffer[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/eOpUreunfudZVKFzbmspjBNX >
[18:21] <Christoffer[m]> My conferance room tool of choice is Jitsi.
[18:21] <Eickmeyer[m]> Well, I'm pretty much homeschoolilng my son at this point, so it's very difficult at this time.
[18:22] <Eickmeyer[m]> Christoffer: for the Telegram bridge, you'll need to use a @ to ping them.
[18:22] <Eickmeyer[m]> @azbulutlu ^
[18:23] <Christoffer[m]> ah!
[18:23] <Christoffer[m]> Thanks!
[18:23] <Christoffer[m]> Yeah, it doesn't need to be as soon as possible, but I rather get the question out of the way.
[18:24] <Christoffer[m]>  * Yeah, it doesn't need to be as soon as possible, just rather getting the question out of the way so I can move on.
[18:26] <Eickmeyer[m]> If we can worry abou that stuff after the 20.04 release, I'd prefer it since we'll have some time between then and when GG opens.
[18:26] <Christoffer[m]> Ah, i see
[18:27] <Eickmeyer[m]> For now, do what you can on your own and present it to us then. Simply use good judgement. :)
[18:31] <Christoffer[m]> Personally it would be the most superb to have it done before the release as the release is the biggest message to push and with a good strategy and plan one can enhance the engagement and reach. But I do acknowledge constraints and I trust in your judgement as the project leader.
 also I just discovered I DO have a matrix account. trying very hard to get on devel channel via ther
 there*
[18:32] <Christoffer[m]> When it comes to what I can do on my own it's incredibly helpfull to have input from you guys to decide as i don't have a full picture and don't know what the team is going for. Like IDK if you guys think this and that group is something you want to go for.
[18:33] <Eickmeyer[m]> @azbulutlu check your invite. :)
[18:34] <Eickmeyer[m]> YAY!
[18:34] <Christoffer[m]> Eyy
[18:34] <Eickmeyer[m]> eylul, Christoffer : You can transfer the password via direct message, just make sure it's encrypted using the direct message properties.
[18:35] <Eickmeyer[m]> Nice little Matrix feature. :)
[18:35] <Christoffer[m]> 🥳
[18:36] <Eickmeyer[m]> Ok. Looks like you're not bridged? Something's not right.
[18:37] <Eickmeyer[m]> eylul: ^
[18:37] <Eickmeyer[m]> You're not showing up on the IRC side.
[18:37] <Eickmeyer[m]> I can invite you to a room to see why you're not bridging correctly.
 I had joined as a guest that might be why
[18:42] <Eickmeyer[m]> Ohhhh... yeah, maybe.
[18:44] <Eickmeyer[m]> Doesn't look like it.
[18:46] <Eickmeyer[m]> Can't see you in the IRC side. Can't see you on Telegram either.
[18:46] <Eickmeyer[m]> I mean, I can see you on Telegram in IRC, just not your Matrix in IRC.
[18:47] <Eickmeyer[m]> It might be because you have to authenticate to Freenode's nickserv.
[18:48] <Eickmeyer[m]> Hehehe
[18:50] <dax> shouldn't have any effect, since the IRC channel isn't +r
[19:02] <Eickmeyer> dax: That's probably right.
[19:02] <Eickmeyer[m]> Nope, didn't work.
[19:03] <Eickmeyer[m]> I think it might be broken in the IRC bridge. Happened to me once before.
[19:03] <dax> gotta love the matrix bridge
[19:03] <dax> but yeah, my guess would be their IRC ghost user either didn't connect or didn't try joining for some reason
[19:04] <Eickmeyer> dax: Most likely. I've had that happen and they had to fix it internally in the bridge.
[19:04]  * OvenWerks finds IRC just works ;)
[19:04] <Eickmeyer> OvenWerks: You say that repeatedly, but most of the general public has no idea it even exists.
 *agrees with ovenwerks but needs to fix the logging with a solution that is not znc*
[19:05]  * OvenWerks also uses a text only client (irssi) which would confuse some people
 @azbulutlu [*agrees with ovenwerks but needs to fix the logging with a solution that is not …], I find Quassel is quite easy.
[19:09] <Eickmeyer> I'm considering switching to weechat though, but it's not a priority.
[19:17] <Eickmeyer> eylul: Nope, didn't work.
[19:17] <Christoffer[m]> eylul: can't read your message before you accept my verification request
[19:17] <Eickmeyer[m]> 😠
[19:18] <dax> Eickmeyer: what's their MXID?
[19:18] <Eickmeyer> dax: eulul:matrix.org
[19:18] <Eickmeyer> *@eylul:matrix.org
 Christoffer I accepted it about 5 minutes ago.
[19:20] <Christoffer[m]> Says to me you haven't responded
[19:20] <Eickmeyer> dax: @rodericuus:matrix.org was having the same issue in #ubuntustudio-offtopic's Matrix equivalent.
[19:20] <dax> today?
[19:20] <Eickmeyer> dax: Yes. Just earlier.
[19:20] <Eickmeyer> About 15 minutes ago.
 *just gives up* can you send it again?
[19:20] <Christoffer[m]> IDK what it's about. Could be a homeserver thing, matrix.org has a tendency to be slow
[19:22] <Eickmeyer[m]> I'm trying to get Matrix staff to look at this now.
 christoffer which device are you at? mobile or desktop?
 #MatrixIsBroken heh 😜
[19:22] <Eickmeyer[m]> They're pretty responsive usually.
[19:22] <dax> i just poked freenode staff to ask if matrix filled up their i-line again
 I broke matrix
[19:23] <dax> 'cause that's my current suspicion
[19:23] <Eickmeyer[m]> dax: Sounds about right.
[19:24] <Christoffer[m]> I'm on my pinebookpro 😎 using the webbrowser version of riot
[19:25] <Christoffer[m]> on the privacytools.io matrix homeserver
[19:25] <Eickmeyer[m]> Christoffer: Yeah, that doesn't really matter too much in this case.
[19:29] <Eickmeyer[m]> eylul: Christoffer is showing up properly in IRC.
 nice
 yeah not sure why this is happening but I dont want to clog devel list with this anymore
[19:30] <Eickmeyer[m]> It's OK. I'd rather we troubleshoot communication problems since that inhibits devel anyhow.
[19:32] <Christoffer[m]> I actually did a legacy thing before. Tried to accept this one but took forever to confirm it
 if you can see the contents now let me know?
[19:34] <Christoffer[m]> I can't
[19:35] <Eickmeyer> Christoffer[m]: Do you use Telegram?
 *starts laughing*
[19:36] <Christoffer[m]> It kind of annoys me that the matrix.org server is the weak link (IDK if it is this time, but usually is)
[19:36] <Christoffer[m]> They don't really to spread out the users like with joinmastodon.org either
[19:37] <Christoffer[m]> No. I'm on Matrix and XMPP
[19:37] <dax> Assuming it's the matrix<->IRC bridge, that's a single point of failure hosted by matrix.org. The current matrix bridging model doesn't allow for decentralized bridging.
[19:37] <Eickmeyer[m]> https://send.firefox.com/ might be an idea.
[19:37] <Christoffer[m]> And with email those are all my communication things
[19:37] <Christoffer[m]>  * It kind of annoys me that the matrix.org server is the weak link (IDK if it is this time, but usually is)
[19:37] <Christoffer[m]> They don't really try to spread out the users like with joinmastodon.org either
[19:38] <Eickmeyer> dax: Yeah, it's a pain, but it's better than Telegram bridging in my experience.
 we need a password solution
[19:39] <dax> anyway. asked fn staff, the response i got was "looking at it now", dunno if i'll get further info
 like I don't know nextcloud?
 thanks dax
 @azbulutlu [we need a password solution], Did you see the Firefox Send link I posted?  That might be good for sending an encrypted file.
 @azbulutlu [like I don't know nextcloud?], I have a nextcloud instance.
 checking it now
 doesn't nextcloud have a password management addon?
 @azbulutlu [doesn't nextcloud have a password management addon?], It does and I use it.
[19:44] <dax> Eickmeyer: apparently their i-line isn't full. If/when you get a response from matrix.org, I'd be interested to know what the reason ends up being.
[19:50] <Eickmeyer[m]> dax: I'm still waiting for a response.
 ok.. a few bytes of information finally got transmitted via matrix
 \o/
 *headdesk*
[19:52] <Christoffer[m]> Thanks are a-ok
[19:52] <Christoffer[m]>  * Things are a-ok
 *is still laughing*
 ok so basicaly current solution has been to manually post that there is a blog post on twitter and it being mirrored to mastodon. the mirror to mastodon is very recent. replies remains in each community and nothing else is cross posted. if you want to do both manually sure, but I know I missed posts before because I missed them on the b
[19:58] <studiobot> log
 :)
[20:03] <Christoffer[m]> 👍