[14:06] hi guys! [14:06] i see this: https://launchpad.net/ubuntustudio/+series we seem to have dropped using that at 14.10... [14:07] i'm thinking about setting up one of those for this one, any contras or objections? [14:11] sakrecoer: Is our calendar any different from others? Is there an overall timeline set up? [14:12] the reality is that even though we have not kept up with vanilla on some betas, their freezes etc. still affect us. certainly with trying to sync new versions of packages etc. [14:15] That is why we should figure out package changes now, get them in our seeds right away. So far as our own packages... basically we should be working stuff for 17.04 right now unless they are very simple and can be done before feature freeze. (working if not bug free) [14:17] sakrecoer: I never found any use for it. The milestones can be useful when targeting bugs and blueprints to it, but there's mor eor less just one important milestone - which is Final Release [14:17] Basically we have 4 months for most of our change work. I have been caught in this before and made package changes too late for more than one cycle with the same package :P [14:20] sakrecoer: Also, no hurry with the blueprints. I would first focus on writing stuff down as feature definitions, to get everthing on print [14:20] sakrecoer: And, if I were doing blueprints this time around, I would probably only create them for the few things that would benefit from that [14:22] sakrecoer: The thing with blueprints is that you can split the work into tasks that people can choose to do individually. If the feature definition is to be done by 1 or 2 people who are well aware of what and how they want to do it, the blueprint becomes superfluous [14:22] sakrecoer: You could however start with a blueprint for the ubuntustudio-y-topic, which will depend on all others [14:23] sakrecoer: That blueprint will have no tasks, it's just a way to collect all the blueprints for y into a tree, where the "ubuntustudio-y-topic" is the root [14:24] sakrecoer: I would wait with doing the blueprints until at least a couple of weeks from now, and finish all plans in a month from now, including feature definitions and blueprints [14:25] ..following the vanilla schedule, somewhat [14:27] from my point of view, even if the blueprint was a handful of work items shared by two or three people, it's useful for both tracking what's done, what needs to be done but also as a window for others that might be interested in helping out [14:32] There's that, but only if we register the blueprints with the Ubuntu project, which we haven't done lately [14:32] ..out of convienence [14:32] ok thanks knome zequence OvenWerks .. i think i want to use as much help i can get from the available tools to keep scheduling and track keeping. [14:32] (or if we setup our own overview system) [14:33] sakrecoer: You could check how Xubuntu has done their blueprints, to get some inspiration I guess - they do add them to the Ubuntu project [14:33] But, that means, they won't be inside our own projects at all [14:33] (which is where they naturally belong) [14:34] knome: does xubuntu combine blueprints with Trello? And if so, how? [14:34] no [14:34] we have http://dev.xubuntu.org/ [14:35] for a more filled example, see http://dev.xubuntu.org/?s=x [14:35] Right, I had forgot that [14:35] knome: Ah, someone set that up for you in your team? [14:35] i did [14:35] zequence: guess who :) [14:36] cub: qa has been using trello - the qa lead isn't so sure anymore :) [14:36] I was going to see about doing that, but never got around to it [14:36] zequence, the code is available in launchpad under the xubuntu-website project... [14:36] Not sure we need all that much, tbh. We're still a fairly small team [14:36] knome: Ok, thanks [14:36] I like the xubuntu site [14:37] I suppose, if it's not too much work, we could just copy and change branding and configs [14:37] tbh, even if i say myself, the tracker is one of the most useful tools for overall development the xubuntu team has [14:37] that looks very cool knome ! [14:37] I'd agree - and I'm not him :) [14:38] Such a tool would need to be tied into the blueprints automatically, manual work will always fail [14:38] fun thing is, to have such system, we would have to create a blueprint for it's implementation :D [14:38] but I suppose knome tool does that? [14:38] cub, does what? [14:38] zequence: yeah we discussed it before but as it was more or less just you and OvenWerks doing stuff it made no sense. :P [14:39] knome: connect to your launchpad blueprints [14:39] in the tool we add a database row, one per series; in that we specify the umbrella blueprint and it automatically gets everything else under it [14:39] cub: Yes, and still it may not be overly helpful [14:40] Maybe, maybe not? In my department we have a 2 person team running kanban board for everything they do. [14:40] sakrecoer: I think make your decision about blueprints once you have put together the feature definitions for y. That will tell you how much it really is [14:40] anyways, time to head home [14:41] My guess is, it will be pretty straight forward, and it's easier just to look at the few blueprints we have [14:41] The blueprints I've done for previous releases -> Most of them were totally just there for show, and just makes it harder to get an overview [14:42] well, i guess i got to disagree here [14:42] but of course it depends how you present the blueprints [14:42] knome: Have you looked at them? [14:42] knome: Not sure how else you can have an opinion [14:42] i've seen them [14:43] i can have an opinion on everything without seeing anything... whether you think it's valuable is a different thing [14:43] zequence: that makes sense; kindof useless to have a blueprint for a work-field where nothing will be done. But i'd i think i want to be quick at keeping things tidy. [14:44] Well, I think the absolutely most important thing is getting things down in feature definitions first. And, then worry about implementing and organizaing the work [14:44] as another point of entry, the xubuntu team does both of those at the same time [14:45] i had a interesting discussion about the diff between freedom of speech and freedom of opinion saturday. so i have to agree on that knome :) [14:45] Philosophically, I don't think anyone would disagree at any time [14:45] It would be philosophically impossible [14:45] zequence: sure, but for example, i culd already set-up the blueprint for audio and graphics. [14:46] ...since we already have a few points there.. [14:47] sakrecoer: You mean package selection? Doesn't make sense to me. It's one change in the bzr branch, once we've decided on package changes [14:47] The meta package selection is actually one of those blueprints I would not be doing again, for that reason [14:47] Thinkt he wiki page works a lot better [14:48] If you can split the work into different tasks, and each task takes a certain amount of time, then it makes sense to have a blueprint [14:49] Or, you can have a generic blueprint just called "audio" and one for "video", which includes tasks to implement several feature definitions, one being the wacom scripts [14:49] But, those would then not reflect on our packages, or any specific project aside from the "Ubuntu Studio" project [14:51] Anyway, there's no hurry with blueprints at all. It can wait another week or two. I would focus on worrying more about what we are actually going to be changing, and not so much how we organize the changes. [14:51] So, discussions and feature definitions. That's to me the best start [14:52] But, of course, new ideas will be emerging throughout the cycle, so things need to be added [14:53] For example: do we want our own custom DE? [14:53] And, what should it do? What features should it have? [14:54] That could be one feature definition, and later a blueprint, but one which would involve lots of different packages [14:58] ok, i'll think about it. :) meanwhile, indeed, i will take that DE issue to the mailing list :) [15:00] there is something weird with the mailing list btw, i changed my adress to be sent to my @ubuntustudio.org adress, but in the source it says all mail is sent to my @sakrecoer adress.. [15:00] maybe something in the way the @ubuntustudio forwarding is set up... [15:02] yeah, that is it, nvm... [15:08] sakrecoer: Also, not all blueprints need to be for a specific milestone. Like the website overhaul blueprint [15:10] zequence: i get it :) there is a realy thin line between package definition and feature difition, or am i missing a bigger picture? [15:11] sakrecoer: package selection is done from the policy we have https://wiki.ubuntu.com/UbuntuStudio/Policy#Selecting_preinstalled_packages [15:11] I should add we choose the best and most common applications for each workflow [15:12] I would say changes to the multimedia seeds (which is what package selection is) is one single thing, since it can be implemented with one bzr commit [15:12] It's one task [15:13] But, something I have wanted for someone to do for ages (and I haven't myself) is go through the whole multimedia section and look for packages that we are not including - perhaps because we didnt know about them [15:14] And, that is a much bigger job, which can be split into several tasks [15:14] Or, several areas, at least [15:14] That should really be done every cycle [15:14] hehe, "No duplication of tools" looking at our 4 video sequencer :D [15:14] Best time is probably jusb before Debian Import Freeze [15:15] sakrecoer: Depends on what you mean by duplication, but sure, there is probably one too many there [15:15] Blender, though it can do video editing is not what you want to use for simple Youtube videos [15:15] "If two applications do the same exact thing, only one of them should be included. " so i gues it qualifies :) [15:15] anyways its a side track sorry [15:16] sakrecoer: No, I think it's important [15:16] Like, we have LMMS, but you can't compare that to Ardour. And we also have qtractor [15:17] LMMS for the really simple stuff, qtractor because of midi mostly, and Ardour for multitracking audio, though all of them can do the same things to some degree [15:18] The same would apply for things like Openshot and Kdenlive. Openshot is really simple, while kdenlive lets you do a lot more [15:18] But, why then do we have pitivi? [15:18] So, there's a problem right there [15:19] And, again, I would not count Blender into the mix since it is first and foremost a 3D modelling application, which can do almost everything else too (but you probably don't want to use it for everything else) [15:20] zequence: good points! [15:20] i was actualy writing pretty much exactly that to the list :) [15:20] This is how we have done so far. But, we might have failed with pitivi. Don't remember how that happened [15:22] zequence: there was a promiss that pitivi would become a more "professional" VSE, which it seems to have accomplished.. [15:24] sakrecoer: So, then the question is, should it replace kdenlive? Or, is there something one of them does that the other one can't? [15:24] I haven't used it. So, I really don't know [15:25] Is it perhaps simple to use like Openshot as well? [15:25] There's always good to have both a pro tool and a beginner tool for the same workflow, unless there is a tool which can do both [15:26] i haven't really investigated myself yet. i always use blender for video now a days... Maybe pitivi is up to kdenlive level, but i can't say yet... i guess, i'll shoot my mail, and let the discussion begin :) [15:27] Yep [15:28] I actually added two more things to the policy, to clarify the policy that has been used until now https://wiki.ubuntu.com/UbuntuStudio/Policy#Selecting_preinstalled_packages [15:29] thanks zequence ! :) [15:33] sakrecoer: Very reasonable arguments on the mail list, I think [15:35] flocculant: in terms of trello, one of the advantages of it is that you can not only comment and put them in correct status bins, so I have seen it being useful on selection of new feature, type of things. it can get very messy with a lot of items through. [15:35] zequence: :) [15:35] (also hi zequence and sakrecoer.) [15:35] autumna: Hellp [15:36] Hello* [15:36] was that a typo or is there something that I can-- [15:36] haha [15:36] that typo could have gone both ways [15:36] :D [15:37] hi autumna ! [15:37] I guess so :) [15:37] ok re proposing package proposals, are we discussing things that are going to be installed by default, or things that are not currently in the repositories but could be? a combination? [15:38] i'd say a combination, autumna :) [15:38] autumna: Only what is going to be installed by default. We don't control what is in the repos [15:38] add, remove or replace :) [15:38] ah, ok, yeah in that way... [15:38] :) [15:38] If something should be in the repos, it needs to be added in Debian first. Then it appears here automatically [15:38] I see [15:38] ..as long as the license is free [15:39] I have been fiddling with the simplescreenrecorder as a secondary alternative to vokoscreen, but i wasn't sure if that is something we can do, since the package wasn't (well so far wasn't maybe that is changing) in the repos from what I can tell. [15:40] Anyone can get a package into Debian. Just report a bug for it, package it, and get a sponsor to upload it. But, none of us has been doing that [15:40] We only need one screen recorder, dont we? [15:41] zequence: yes. and i have to say vokoscreen looks like a very cool option... [15:42] (just imho) [15:42] It's the only one that worked for me, and it does work well [15:42] I managed to get vokoscreen to get audio delays. plus simplescreenrecorder can access jack directly... (for a definition of directly) [15:42] autumna: audio delays? The audio wasn't in sync? [15:42] yeah. [15:42] That happens on Kazam for me, but not on vokoscreen yet [15:42] when getting the audio output of the computer. [15:44] I was pushing it a bit hard but simplescreenrecorder also.. supposedly allows recording from openGl. its original intended use seems to be live game recording. [15:45] ok that was a grammar fail there. [15:47] I should double check. Did a very long recording a while back [15:47] I was running a video, and a webcam. :D [15:47] I was using another application to record the webcam [15:47] So, two at the same time [15:48] ..while recording with Ardour and a bunch of plugins [15:48] interesting. [15:48] I do use a laptop, it is a gaming laptop, so pretty good but still. [15:48] vokoscreen was nice cause 1) it worked, 2) the file size was small, and good quality [15:48] This is an old Pentium Dual Core, at least 10 years old [15:49] ok now I am truly confused. [15:50] autumna: what kind of latency were you using? For recording, a higher latency makes sense. [15:51] ovenwerks: what do you mean with latency? in audio setup? in vokoscreen? (relatively newbie in audio setups) [15:53] autumna: in jack [15:54] I run jack with the defaults [15:55] autumna: I run jack as my pulseaudio "device" [15:55] I have set pulse up to see no alsa devices... even ones it doesn't use. [15:55] *listens* [15:56] I have found before that having pulseaudio see more than one device that may be at different sampling rates (variations of 48k for example) there tends to end up being problems with pops clicks and or xruns. [15:57] I.. have a script that ties to pulse audio to jack and makes the jack_out default sink. and I set the buffer to 1024, that's about the only changes I do. I am not sure how to make pulse audio not see any alsa devices through [15:57] Two cards running at 48k are not the same sample rate it will differe slightly. [15:58] pactl unload-module module-udev-detect [15:58] pactl unload-module module-alsa-card [15:58] zequence: i saw ~ubuntustudio-dev was added to the etherpad (thanks btw). but i liked your idea of adding ~ubuntustudio-documentation there. Doc-team has less members i guess, maybe it is not very important..? [15:59] The first will tell pulse not to monitor for new USB devices added the second unloads any alsa devices now loaded. [15:59] sakrecoer: I just didn't want to join myself to yet another group... [15:59] (what I ran into was lag in recording with vokoscreen was more of a audio at times more like.. temporarily lagging but it might be overlapping problem) [15:59] ok these are getting added to my launch jack script one sec [15:59] OvenWerks: oh but i'm sure it is a good thing to have the dev team in there :) [16:00] it just that sometimes people how are good with docs, aren't very good with dev-things.. [16:00] sakrecoer: yes, I fugured that team will be doing the actual adding. [16:01] sakrecoer: it is not that hard to add a group. [16:01] you just have to be a member :) [16:01] OvenWerks: i see that, i'll just add the doc group and see what happens :) [16:02] * sakrecoer gives flocculant and knome a cute-look :3 [16:02] So long as the group is moderated [16:02] (also thanks OvenWerks. I'll try these changes and try both video apps later this weekend) [16:03] OvenWerks: oops.. doc-team is open... [16:03] there is no big rush to it, so i'll just set it to moderated.... [16:08] ok another question: is there a list somewhere of all the packages already in the 16.04? [16:08] seeds [16:08] autumna: https://code.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.yakkety [16:09] autumna: this does not include packages we include because they are depended on by other packages... [16:10] *nods* [16:10] autumna: however, it is a good policy to include any package we want in seeds even if it gets pulled in as a depend [16:10] autumna: That way if we remove the application that pulls it in, we don't loose it [16:10] *nods* [16:10] that makes sense. [16:11] autumna: Our ubuntustudio metas are creted from that package. [16:13] * autumna explores while listening [16:15] autumna: in the past we have tried to include one good example of each type of application rather than having every possible media creation package. There were plans to upgrade ubuntustudio-installer so that we had an installer that shows all the meadia creation packages available that are not installed rather than the whole repo. [16:16] *nods* so these seeds are the preinstalled items? [16:16] right now it mostly allows installing the studio metas if you are putting them in a different DE/flavour and we no longer include it in the distro. [16:16] autumna: yes [16:17] sakrecoer: It would be better if ubuntustudio-documentation was in the etherpad team, and we then made all other teams members of the -documentation team [16:17] That way, all of us get automatic rights for the wiki, which we absolutely should have [16:18] sakrecoer: As said earlier, means making -documentation a moderated group - otherwise it would not be secure [16:18] -installer is not a very nice package/utility right now. More of a quick hack. [16:19] OvenWerks: very potentially crazy idea. could we somehow drag software boutique, or another similar (hopefully simpler) curated software app, and use that I wonder. [16:20] Ack! I just noticed a new option in lauchpad. "Create snap package" (the only application I would concider doing that for right now is GCDMaster [16:20] autumna: I am all for it. [16:21] ok I am making a list of things I promised to look into. :D because it is becoming a queue [16:21] autumna: I looked for an already existing installer at the time, but couldn't find any with the possiblilty of giving package lists on the command line or in a config file [16:22] (aside from USC) [16:22] OvenWerks: Yes, it's possible now. But, let's not do that for Ubuntu Studio stuff yet, before we know what snap can do [16:22] oh right [16:22] OvenWerks: I read an article about how snap is quite insecure on X. So, only great for MIR and Wayland right now [16:22] zequence: I would like to stay totally away from snap [16:23] OvenWerks: I would like to hear your opinions about that. Maybe on the mail list? [16:25] zequence: MIR... the space station? [16:25] sakrecoer: I think the word means Peace, or something like that. But, yes, it is named after that. [16:26] MIR is the new window manager for unity, which Canonical introduced a few cycles ago, but is only used for touch devices still [16:26] Ubuntu flavors are all still powered by the X window system [16:26] Gnome is working hard at making Wayland its default [16:27] It's still kind of Beta, but fairly well implemented, I think [16:28] I am a bit worried about that switch [16:29] autumna: Why is that? [16:29] autumna: why? [16:29] I am not sure if it will affect wacom apps and other screenapps [16:30] There was some controversy about it when the whole thing was announced a while back. Lots of people were not pleased, since they were all hoping everyone would be using Wayland [16:31] There may be some problems with video, and drivers, but hopefully all that will be worked out before anyone changes [16:32] Ok, better do some studies here. Talk to you guys later :) [16:32] bye zequence [16:36] zequence: i added all the moderated team to the documentation team. bascially all, except “Ubuntu Studio” team and “Ubuntu Studio Testing” team [16:37] zequence: however, if it allows us save/keep applications suffering from bitrot it may be worthwhile. [16:39] autumna: my response to MIR is to remember upstart. [16:40] *googles upstart* [16:40] autumna: I think that if debian makes wayland default, ubuntu will follow [16:40] upstart is like initd or systemd [16:41] ah [16:42] OvenWerks: ok I am not sure exactly what you mean by remembering upstart. :) [16:42] autumna: I think some flavours like kubuntu and maybe lubuntu (qbuntu?) will keep xorg alive [16:43] *nods* [16:43] ubuntu went from init to upstart and spoke very strongly about debian going upstart, but when debian went systemd, ubuntu has followed. [16:43] wouldn't the graphic driver support also influence the situation through? [16:43] aah [16:43] ok got it. (and I totally missed that discussion) [16:45] autumna: I think if the whole linux world goes wayland... ubuntu will get too. [16:46] autumna: There are as you suggested, some differences in that ubuntu has gotten some of the HW/game devs on side, but I don't know how much influence that will have in the long run. [16:48] *nods* [16:50] it does at least look like through everyone is being cautious, so that's good [16:51] I am just worried because already I know very few graphic artists using linux. [16:52] autumna: wayland is moving too slow I think. If it takes much longer it will be out of date before it arives. [16:53] autumna: I have been hearing about wayland for years. I think every generation of GPU sets it back again [16:53] I see [16:55] OvenWerks: yeah it has been discussed for a while, but doesn't that also mean it is maturing? [16:56] OvenWerks: and becoming more stable and supported before the switch happens? [16:56] * autumna really is not that up to date on the details of this topic [16:57] autumna: wayland? I hope so, but time doesn't wait. If MIR works well enough... it is possible the linux world will grab it... on the other hand if it is seen to be too much a node to closed source bits, That will make it ubuntu only. [16:57] /snode/nod [16:58] autumna: even in the open source world fastest to market means something. [16:59] OvenWerks: *Nods* [16:59] on the other hand, sometimes something better that comes later (takes longer) does do well [17:00] OvenWerks: I don't see a replacement of X as something where speed will be as important tbh. I mean this is not an end user software. [17:01] (btw shall we move this to off topic?) [17:01] is there more to say? [17:01] :) [17:01] ha.. point taken [17:02] autumna: The point where this impacts Studio would be if xubuntu goes MIR or wayland [17:03] (assuming Studio is still based on xubuntu) [17:03] OvenWerks: yeah there is that last bit, also even before that. [17:04] OvenWerks: I know we are not in the majority but it might affect before where the driver supports goes, for graphics people. [17:05] OvenWerks: wacom support, and I assume for anyone who does extensive 3D (or even some types of 2D), graphic drivers are decision factors as well? [17:05] I think snap is going to be the first thing. [17:06] autumna: it would be interesting to know how the profesional graphics servers deal with this stuff [17:06] OvenWerks: that's something I hadn't thought of and yeah. [17:06] (machines with more than one gpu) [17:08] I think that the application takes direct control of the extra GPUs (which have no video out BTW) to use them as rendering co-processors. [17:08] maybe? although.. there are.. desktops.. that has 2 GPUs as well. so there might be some support of that on graphic driver level? [17:09] autumna: so far as I know that is already there in the video drivers we have. [17:10] but that is two video cards that have video out so that someone can have more than three screens [17:12] *nods* [17:14] yeah no I would have to read up on the details. My experiences with these setups is firmly from the point of end user and gamer. [17:14] :) [17:14] * OvenWerks tries to remember where he saw video works stations... thought it was here: https://www.blackmagicdesign.com/products but no. [17:16] video cameras sure have gotten cheap: https://www.blackmagicdesign.com/products/blackmagicursa [17:17] pretty! [17:45] hi [17:46] Can any one help me on ubuntu studio [17:46] ? [17:53] niks: The support channel is #ubuntustudio. [17:54] nope, I wanted to know that how can i contibute to ubuntu studio devlopment [17:55] that works. [17:55] niks: Testing, coding, artwork, documentation? [17:56] niks: Start by subscribing to the devel mail list, and make sure to read it and hang here for now, and you should have no problem catching on [17:56] niks: We're just starting preparations for the next cycle of development [17:57] I have subscribed to mailing list [17:57] thanks [18:10] krytarik gave me this cool list of things to do: http://paste.openstack.org/show/XEDOtbepOEQP9rf8jBWv/ would you guys like to look at it and tell me if you agree to them? :) [18:10] to them *points :p [18:14] sakrecoer: Isn't it better that krytarik just does the fixes in code, and keeps in mind that it needs to be desktop agnostic? [18:15] As long as it's a matter of fixing things, there's really nothing to discuss. The uploader will need to review and approve, and that is myself [18:16] sakrecoer: But, again, renaming files, just for the fun of it? [18:16] No thanks. That's a waste of time [18:17] If the changes mean some form of change, then it is a matter of adding those to the correct feature definition, before the changes are made [18:17] I mean, change as in not a fix [18:17] Cause, those need to be reviewed by whoever is in charge of that area. A team lead, or the project lead [18:19] sakrecoer: So, in short, krytarik should follow the same procedure for suggesting changes as the rest of us [18:19] But, again, fixes are fixes. Filename changes are not fixes though - those are changes. [18:26] zequence: the idea here is to add those points to the blueprints for their respective assignee [18:28] sakrecoer: Why? Bugs should be reported and fixed. Feature should be planned before implementing [18:29] sakrecoer: I see mostly bug fixes there. No plans needed [18:29] well, that is why i submitted to you: to plan it [18:29] you as the group... [18:29] Again, bug fixing does not need any planning. But, could require some coordination [18:30] I would say Ross is the best person in our team for coordinating bug fixes - making sure someone is doing it [18:30] ok, i guess i missunderstood the blueprint thing, thought a TODO point would have to be discussed first. [18:30] For bugs? no [18:30] No planning or discussion needed [18:30] Just fix them [18:31] Either report them, and have someone else fix them, or report them yourself and fix them, or just fix them [18:31] What's there to discuss? [18:32] Fixing bugs, and implementing features are two totally different things [18:34] Sometimes implementing a feature may also fix a bug, but that is still not the same thing [18:35] alright, but the blue is supposed to help us keep track of which bugs we need to fix among other things, no? [18:35] blue*print [18:35] No [18:35] Different teams should subscribe to the bugs that concern their own packages, and fix them as the bugs arrive [18:36] Also, we have the ubuntustudio-bugs team that is subscribed to the bugs for lots of multimedia packages, and can help fixing bugs for those too [18:36] blueprints is not used to keep track of bugs [18:37] ok :) [18:37] it's for organizing tasks for planned changes, which usually means implementing some form of feature that did not exist before in our OS [18:38] Critical bugs should be fixed ASAP for stable releases [18:39] Other fixes can wait. And a very good time to check which bugs still need to be fixed is after Feature Freeze. [18:40] noted :) [18:40] But, if krytarik wants to do fixing now, it's perfectly alright. I mean, it never hurts to do things right away [18:42] I just hope he does not rename files for no reason, that's all. We have already seen why that is not a good idea [18:43] And, those would not be bug fixes anyway [20:10] wow ok xinput-calibrator seems to be working just fine. *goes to find the wacom tablet*