 I got up at 4am and was trying to nap a bit, and you?
[11:30] <BluesKaj> hi marcoagpinto, EoflaOE
[11:31] <EoflaOE> I am fine marcoagpinto
[11:31] <marcoagpinto> >:)
[16:51] <lotuspsychje> !info nvidia-driver-435 bionic
[16:51] <lotuspsychje> !info nvidia-graphics-drivers-435 bionic


[15:34] <Torikun> G'day
[17:55] <raevol> i hate compiz so much
[18:21] <grantbow> why do you hate compiz?
[18:31] <raevol> grantbow: it crashes on me daily
[18:31] <raevol> or something causes it to crash...
[18:31] <raevol> and by crash i mean locks up and i have to mash keys to get to a tty to kill it to save my work to reboot
[18:38] <kallecarl> are there any Ubuntu Touch folks here?
[18:50] <kallecarl> anyone developing for Touch using Qt may be interested in Qt Developer Days www.qtdeveloperdays.com/northamerica
[18:51] <kallecarl> opportunities to recruit contributors or to find companies who are developing with Qt
[18:51] <kallecarl> San Francisco Airport Marriott November 6 - 8
[18:59] <grantbow> nice announcement, that should find it's way to the email list too


[00:00] <nacc> yeah
[04:07] -queuebot:#ubuntu-release- Unapproved: pollinate (trusty-proposed/main) [4.23-0ubuntu1~14.04 => 4.23-0ubuntu1~14.04.1] (no packageset)
[04:08] -queuebot:#ubuntu-release- Unapproved: pollinate (xenial-proposed/main) [4.23-0ubuntu1~16.04 => 4.23-0ubuntu1~16.04.1] (ubuntu-server)
[04:13] -queuebot:#ubuntu-release- Unapproved: pollinate (yakkety-proposed/main) [4.23-0ubuntu1 => 4.23-0ubuntu1.1] (ubuntu-server)
[04:19] -queuebot:#ubuntu-release- Unapproved: maxima (yakkety-proposed/universe) [5.37.2-8 => 5.37.2-8ubuntu<IP_ADDRESS>] (no packageset)
[11:17] -queuebot:#ubuntu-release- New binary: flask-login [amd64] (zesty-proposed/universe) [0.4.0-1] (no packageset)
[11:21] -queuebot:#ubuntu-release- New binary: limesuite [amd64] (zesty-proposed/universe) [16.12.0+dfsg-1] (no packageset)
[11:21] -queuebot:#ubuntu-release- New binary: limesuite [ppc64el] (zesty-proposed/universe) [16.12.0+dfsg-1] (no packageset)
[11:21] -queuebot:#ubuntu-release- New binary: limesuite [i386] (zesty-proposed/universe) [16.12.0+dfsg-1] (no packageset)
[11:26] -queuebot:#ubuntu-release- New binary: limesuite [arm64] (zesty-proposed/universe) [16.12.0+dfsg-1] (no packageset)
[11:26] -queuebot:#ubuntu-release- New binary: limesuite [s390x] (zesty-proposed/universe) [16.12.0+dfsg-1] (no packageset)
[11:27] -queuebot:#ubuntu-release- New binary: limesuite [powerpc] (zesty-proposed/universe) [16.12.0+dfsg-1] (no packageset)
[11:29] -queuebot:#ubuntu-release- New binary: limesuite [armhf] (zesty-proposed/universe) [16.12.0+dfsg-1] (no packageset)
[11:39] -queuebot:#ubuntu-release- New binary: boost1.63 [ppc64el] (zesty-proposed/universe) [1.63.0+dfsg-1] (no packageset)
[11:43] -queuebot:#ubuntu-release- Unapproved: sudo (xenial-proposed/main) [1.8.16-0ubuntu1.2 => 1.8.16-0ubuntu1.3] (core)
[11:48] -queuebot:#ubuntu-release- New binary: boost1.63 [s390x] (zesty-proposed/universe) [1.63.0+dfsg-1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: boost1.63 [i386] (zesty-proposed/universe) [1.63.0+dfsg-1] (no packageset)
[11:57] -queuebot:#ubuntu-release- New binary: boost1.63 [amd64] (zesty-proposed/universe) [1.63.0+dfsg-1] (no packageset)
[12:03] -queuebot:#ubuntu-release- New binary: boost1.63 [powerpc] (zesty-proposed/universe) [1.63.0+dfsg-1] (no packageset)
[12:15] -queuebot:#ubuntu-release- New binary: boost1.63 [arm64] (zesty-proposed/universe) [1.63.0+dfsg-1] (no packageset)
[12:17] -queuebot:#ubuntu-release- New: accepted boost1.63 [amd64] (zesty-proposed) [1.63.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New: accepted boost1.63 [i386] (zesty-proposed) [1.63.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New: accepted boost1.63 [ppc64el] (zesty-proposed) [1.63.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New: accepted flask-login [amd64] (zesty-proposed) [0.4.0-1]
[12:17] -queuebot:#ubuntu-release- New: accepted limesuite [amd64] (zesty-proposed) [16.12.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New: accepted limesuite [armhf] (zesty-proposed) [16.12.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New: accepted limesuite [powerpc] (zesty-proposed) [16.12.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New: accepted limesuite [s390x] (zesty-proposed) [16.12.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New: accepted redis-py-cluster [amd64] (zesty-proposed) [1.3.3-1]
[12:17] -queuebot:#ubuntu-release- New: accepted boost1.63 [arm64] (zesty-proposed) [1.63.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New: accepted boost1.63 [s390x] (zesty-proposed) [1.63.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New: accepted limesuite [arm64] (zesty-proposed) [16.12.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New: accepted limesuite [ppc64el] (zesty-proposed) [16.12.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New binary: boost1.63 [armhf] (zesty-proposed/universe) [1.63.0+dfsg-1] (no packageset)
[12:17] -queuebot:#ubuntu-release- New: accepted boost1.63 [powerpc] (zesty-proposed) [1.63.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New: accepted limesuite [i386] (zesty-proposed) [16.12.0+dfsg-1]
[12:17] -queuebot:#ubuntu-release- New: accepted hiro [amd64] (zesty-proposed) [0.2-1]
[12:17] -queuebot:#ubuntu-release- New: accepted puppet [amd64] (zesty-proposed) [4.8.1-2]
[14:09] -queuebot:#ubuntu-release- New: accepted boost1.63 [armhf] (zesty-proposed) [1.63.0+dfsg-1]
[14:09] -queuebot:#ubuntu-release- New: accepted lighttpd [arm64] (zesty-proposed) [1.4.44-1ubuntu1]
[14:09] -queuebot:#ubuntu-release- New: accepted lighttpd [i386] (zesty-proposed) [1.4.44-1ubuntu1]
[14:09] -queuebot:#ubuntu-release- New: accepted lighttpd [ppc64el] (zesty-proposed) [1.4.44-1ubuntu1]
[14:09] -queuebot:#ubuntu-release- New: accepted pluma [amd64] (zesty-proposed) [1.17.3-0ubuntu1]
[14:09] -queuebot:#ubuntu-release- New: accepted pluma [armhf] (zesty-proposed) [1.17.3-0ubuntu1]
[14:09] -queuebot:#ubuntu-release- New: accepted pluma [powerpc] (zesty-proposed) [1.17.3-0ubuntu1]
[14:09] -queuebot:#ubuntu-release- New: accepted pluma [s390x] (zesty-proposed) [1.17.3-0ubuntu1]
[14:09] -queuebot:#ubuntu-release- New: accepted lighttpd [amd64] (zesty-proposed) [1.4.44-1ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted lighttpd [powerpc] (zesty-proposed) [1.4.44-1ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted pluma [arm64] (zesty-proposed) [1.17.3-0ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted pluma [ppc64el] (zesty-proposed) [1.17.3-0ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted lighttpd [armhf] (zesty-proposed) [1.4.44-1ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted pluma [i386] (zesty-proposed) [1.17.3-0ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted lighttpd [s390x] (zesty-proposed) [1.4.44-1ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted python-parse [amd64] (zesty-proposed) [1.6.6-0.1~build1]
[14:10] -queuebot:#ubuntu-release- New: accepted cloud-initramfs-tools [amd64] (zesty-proposed) [0.35ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted imagemagick [arm64] (zesty-proposed) [8:<IP_ADDRESS>+dfsg-2ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted imagemagick [i386] (zesty-proposed) [8:<IP_ADDRESS>+dfsg-2ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted imagemagick [ppc64el] (zesty-proposed) [8:<IP_ADDRESS>+dfsg-2ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted panko [source] (zesty-proposed) [1.0.0-0ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted slurm-llnl [arm64] (zesty-proposed) [16.05.8-1ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted slurm-llnl [i386] (zesty-proposed) [16.05.8-1ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted slurm-llnl [ppc64el] (zesty-proposed) [16.05.8-1ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted imagemagick [amd64] (zesty-proposed) [8:<IP_ADDRESS>+dfsg-2ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted imagemagick [powerpc] (zesty-proposed) [8:<IP_ADDRESS>+dfsg-2ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted slurm-llnl [amd64] (zesty-proposed) [16.05.8-1ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted slurm-llnl [powerpc] (zesty-proposed) [16.05.8-1ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted imagemagick [armhf] (zesty-proposed) [8:<IP_ADDRESS>+dfsg-2ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted slurm-llnl [armhf] (zesty-proposed) [16.05.8-1ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted imagemagick [s390x] (zesty-proposed) [8:<IP_ADDRESS>+dfsg-2ubuntu1]
[14:10] -queuebot:#ubuntu-release- New: accepted slurm-llnl [s390x] (zesty-proposed) [16.05.8-1ubuntu1]
[14:13] -queuebot:#ubuntu-release- New binary: panko [amd64] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
[14:58] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.21+16.10]
[15:02] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.21]
[15:11] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.21~14.04]
[18:42] <slangasek> Laney: hmm, do you have any idea why the systemd autopkgtests have been failing since 17Dec with a timeout?
[21:41] <acheronuk> Hi. according update_output_notest.txt Qt stack would migrate to -release if it were not for some test http://paste.ubuntu.com/23800541/plain/
[21:41] <acheronuk> can anyone work out what?
[21:51] <valorie> my copy of that says SUCCESS at the end?
[21:51] <valorie> 157/0
[21:56] <acheronuk> valorie: yes, update_output_notest.txt which I pasted from shows what would migrate if all tests were ignored
[21:56] <valorie> oh
[22:01] <acheronuk> valorie: so I'm trying to work out what the failing tests hold it back are.
[22:05] <valorie> perhaps drop a note to Santa_? we're sort of missing him
[22:07] <acheronuk> urgh: pyqt5 at the very least. I thought that was sorted
[22:07] <acheronuk> valorie: I messaged him on and off on Telegram. he has been on there and read them I think, but is just ignoring me
[22:08] <acheronuk> or is not able to reply or something.
[22:08] <acheronuk> I don't know what is going on. maybe family stuff
[22:12] <valorie> could be
[22:28] <acheronuk> autopkgtest for yade/2016.06a-7 is blocking pyqt5
[22:29] <acheronuk> autopkgtest for unity8/8.15+17.04.20170110.4-0ubuntu1: amd64: is blocking ubuntu-system-settings
[22:30] <acheronuk> which is the only other thing on that "success" list which is not a valid candidate
[22:31] <acheronuk> so they need force-bad/skip/test'ing  if that is acceptable, or otherwise sorted. to remove direct blockers anyway
[22:48] <acheronuk> arse
[22:49] <acheronuk> oops. sorry
[23:46] -queuebot:#ubuntu-release- New binary: qgis [ppc64el] (zesty-proposed/universe) [2.14.11+dfsg-1] (no packageset)
[23:52] -queuebot:#ubuntu-release- New binary: qgis [s390x] (zesty-proposed/universe) [2.14.11+dfsg-1] (no packageset)


[00:53] <josharenson> Any reason I can't x-compile unity8 in a wily chroot? libconnectivity-qt1-dev:armhf giving me grief
[02:18] <Gest46573> hello, does anyone know how to edit GTK3 themes? or a tutorial? to make the highligh-selection look flat
[02:22] <Gest46573> like this, but for GTK3:  http://xfce-look.org/content/show.php/BtB?content=109494
[03:45]  * ljp now using a touchscreen workstation
[09:03] <dandrader> cimi, hey. I've two MPs I would like you to review:
[09:03] <dandrader> cimi, https://code.launchpad.net/~dandrader/ubuntu-settings-components/deprecation-warnings/+merge/262267
[09:03] <dandrader> cimi, and https://code.launchpad.net/~dandrader/unity8/deprecatedTheme/+merge/262216
[09:04] <cimi> dandrader, ok
[09:05] <cimi> dandrader, what time is in brazil?
[09:06] <dandrader> cimi, 6 am :)
[09:08] <dandrader> got at doctor appointment at 13. wanted to have most of my work done till then
[09:20] <cimi> dandrader, the trailing whitespaces in those cardcreator tests are there for a reson
[09:20] <cimi> reason
[09:25] <dandrader> cimi, ok. my editor does this clean up automatically and I was too lazy to do put them back (using another editor) :)
[09:25] <dandrader> cimi, but the card tests still pass though
[09:28] <cimi> dandrader, yeah
[09:28] <cimi> dandrader, can you revert that?
[09:29] <dandrader> cimi, almost done
[09:31] <dandrader> cimi, done. had to overwrite the branch though
[09:31] <dandrader> (was the easiest way)
[09:31] <cimi> dandrader, we need do ask albert why he wants trailing spaces
[09:49] <cimi> dandrader, both my reviews are like... if we need to update to 1.3, we need to do it for every file
[09:51] <dandrader> cimi, ok, doing so
[10:21] <dandrader> cimi, done
[10:51] <greyback_> mzanetti: can I get an ack here plz: https://code.launchpad.net/~mir-team/qtmir/gles-sync/+merge/262252
[10:51] <greyback_> and here https://code.launchpad.net/~mir-team/qtubuntu/gles-sync/+merge/262253
[10:51] <mzanetti> looking
[11:13] <ltinkl> larsu: ping
[11:32] <cimi> dandrader, we need to test it and see if it spots regressions
[11:32] <cimi> mzanetti, daniel went through replacing all 1.1 uitk imports to 1.3, can we silo it?
[11:32] <mzanetti> yes
[11:33] <cimi> dandrader, we also need to test the APIs, I am sure the ubuntushape needs changes
[11:34] <dandrader> cimi, that's why I asked you to review it :)   you know ubuntu shape and ubuntu-settings-components
[11:34] <cimi> dandrader, ok, it's a lot bigger then :)
[11:35] <dandrader> cimi, I tried it on the device and all seemed fine. But wasn't thorough as I don't know all the places that have to be checked
[11:35] <cimi> dandrader, at least all ubuntushape we use need to rename few APIs
[11:44] <dpm> hi seb128, do you happen to know if there is a wiki page with instructions to use xmir to start x apps on a unity 8 session?
[11:45] <dandrader> mzanetti, https://code.launchpad.net/~dandrader/unity8/fixShellTests/+merge/262323
[11:45] <mzanetti> thanks dandrader
[11:46] <cimi> dandrader, so, first advice is finding all ubuntushapes and update them to the new APIs
[11:46] <cimi> and simple Shape
[11:46] <cimi> and where we have UbuntuShapeForItem we can use a normal new UbuntuShape iirc
[11:47] <larsu> ltinkl: hey
[11:48] <ltinkl> larsu, can you please merge https://code.launchpad.net/~lukas-kde/gsettings-qt/queued-processing/+merge/259883
[11:48] <ltinkl> larsu, or is there any problem with it? :)
[11:49] <larsu> ltinkl: oh no automerging for this?
[11:49] <larsu> seb128: do we need to do anything special with that branch? ^
[11:49] <larsu> or can I just push to trunk?
[11:49] <ltinkl> larsu: no idea, you'd have to ask mzanetti
[11:49] <mzanetti> well, it needs to be siloed
[11:50] <mzanetti> automerging doesn't happen any more in quite a while now
[11:50] <larsu> ya, seb128 said something like that
[11:50] <larsu> which is why I'm asking
[11:50] <larsu> mzanetti: it was a better time...
[11:50] <mzanetti> heh...
[11:51] <mzanetti> not really sure. it was easier in some places, harder in others
[11:51] <mzanetti> i.e. once you have a trunk full of automerged bugs, it wasn't fun to release that any more
[11:51] <larsu> why not? Don't merge if it's not ready to go in
[11:51] <larsu> now someone needs to deal with it after approving
[11:52] <mzanetti> because automerging didn't pull QA in. so it's easier to merge bugs to the code base
[11:52] <mzanetti> now landing things can be a pain, but trunk is generally higher quality
[11:53] <dandrader> cimi, please write that stuff down on the MP
[11:53] <seb128> larsu, it needs to go through the ci landing
[11:54] <dandrader> cimi, if you have the time, I would appreciate help on it as well. we could move that branch to ~unity-team so you could push as well
[11:54] <dandrader> cimi, also, you sure these updates are necessary? I didn't spot anything broken...
[11:54] <mzanetti> dandrader, cimi. do you want a silo for that uitk branch then? Or should I wait a little more?
[11:54] <larsu> mzanetti: good point. Couldn't we have added that to the MR process thoguh? I guess I shouldn't start this conversation in case didrocks is looking
[11:54] <mzanetti> hehe
[11:54] <mzanetti> indeed. nothing we can change right now
[11:55] <mzanetti> I'm actually quite happy with how it works right now, for the biggest parts
[11:56] <seb128> +1
[11:56] <mzanetti> larsu, still that gets us back to the original question, please sync with seb if you will land that branch. If you can't for some reason I guess I can squeeze it into some unity8 silo
[11:56] <seb128> larsu, also we do testing on device nowadays, with the current system you can batch 6 changes and test together, with individual commits you had to test every changesets
[11:58] <larsu> seb128: let's sync!
[11:58] <seb128> larsu, "sync"? you mean land the change?
[11:58] <seb128> sure, can put a landing for that one
[11:59] <larsu> seb128: yes :) was using mzanetti terminology
[11:59]  * larsu liked that
[11:59] <mzanetti> I did say sync?
[11:59]  * mzanetti reads scrollback :D
[12:00] <larsu> "please sync with seb"
[12:05] <mzanetti> ah :) yes
[13:28] <dandrader> cimi, replied to your comment in https://code.launchpad.net/~dandrader/unity8/deprecatedTheme/+merge/262216
[13:29] <dandrader> cimi, I think it's good as it is. This MP isn't meant, and doesn't have, to solve everything. just what's needed to get rid of these warnings.
[13:29] <cimi> dandrader, the new ubuntushape is deprecating things though
[13:29] <cimi> dandrader, for warning fine then
[13:29] <cimi> dandrader, we should however fix splash.qml
[13:29] <cimi> dandrader, we shouldn't have a visual regression because we are fixing a warning
[13:30] <dandrader> cimi, there should be no visual regression
[13:30] <dandrader> cimi, have you tried it?
[13:32] <cimi> dandrader, not yet, I will make sure to test it deeply
[13:34] <dandrader> cimi, changing all imports to 1.3 was already beyond the scope of this MP....
[13:40] <cimi> dandrader, well, sdk team said we need to either change them all or not
[13:41] <dandrader> for what's it's worth, trunk is already a mix of 0.1 and 1.1
[14:03] <cimi> dandrader, yeah, there are also other import 0.1 that need to be 1.3
[14:04] <dandrader> cimi, I also moved thos 0.1 to 1.3 in this branch
[14:05] <cimi> dandrader, grep -rn "Components 0\.1" .
[14:05] <cimi> #fail
[14:05] <cimi> that was settings components
[17:38] <ahoneybun> hello all I am having a issue with unity8 in a container
[21:32] <ahoneybun> any idea why my LXC container is blinking on and off and does not take input?


[09:21] <thorwil> http://thorwil.wordpress.com/2010/07/15/ubuntu-remix-italiano-customization-kit-mini-remix/
[11:14] <vish> pfff, thorwil and his world of remixes!
[11:14] <vish> ;p
[11:14] <vish> thorwil: now you made it difficult for the Italian loco to choose a logo  ;)
[11:23] <thorwil> heh
[11:26] <thorwil> working with the italian colors was surprisingly difficult. white stands out, doesn't really pair with the others, red and green should be kept separated to avoid the harsh contrast


[00:11] <lfaraone> ScottK: just synced it, and uploaded the new package.
[00:11] <lfaraone> (to -proposed)
[00:11] <ScottK> K.
[01:13] <psusi> how do you invert true/false in shell?  like if !false ; then echo true ; fi?
[01:15] <broder> add a space after the bang
[01:16]  * psusi facepalms
[01:18] <EvilResistance> broder:  can you do a check on whether i included all the info needed for a backport request?  Bug #914996 if you could take a gander
[01:18]  * EvilResistance wants to make sure everything is in order
[01:18] <broder> EvilResistance: sorry, can't today - i'm tied up with other stuff until the beginning of next week
[01:18] <EvilResistance> ok
[01:18] <broder> i'll just be around to make random snarky comments :)
[01:18] <EvilResistance> anyone else who's a MOTU able to?
[01:19] <broder> s/MOTU/ubuntu-backporters/
[01:19]  * EvilResistance doesnt need it processed, just needs to know everything's there
[01:19] <EvilResistance> right.
[01:19] <EvilResistance> :P
[01:55] <jmccrohan> Debian maintainer here. A new version of my package entered Testing today, but I belive the Precise sync happened on Monday. Would someone be so kind as to manually upload my package?
[01:55] <jmccrohan> Or is that possible?
[01:55] <EvilResistance> jmccrohan:  what package?
[01:55] <jmccrohan> lcd4linux
[01:55] <EvilResistance> jmccrohan:  link to the packages.debian.org page for me please
[01:55] <EvilResistance> whilst i fiddle with my DNS resolver
[01:56] <jmccrohan> http://packages.qa.debian.org/l/lcd4linux.html
[01:56] <EvilResistance> you can request a sync, too, if you want :P
[01:56] <EvilResistance> that'd be what you'd ideally need to do
[01:56] <EvilResistance> or have someone do for you
[01:57] <jmccrohan> EvilResistance: Ok. How do I do that? (Totally unfamiliar with process)
[01:57] <EvilResistance> um... lemme dig in my logs
[01:57] <jmccrohan> File a sync request that is. Just a bug report against the package?
[01:57] <EvilResistance> someone referenced a script to help
[01:58] <EvilResistance> unstable is sid, right?
[01:59] <EvilResistance> (in debianworld)
[01:59] <EvilResistance> jmccrohan:  i'm assuming you'd know the answer to that :P
[01:59] <EvilResistance> jmccrohan:  also, there's a script in ubuntu-dev-tools called requestsync
[01:59] <EvilResistance> that can be used to streamline the request for sync process
[01:59] <jmccrohan> EvilResistance: Yup. unstable is perpetually Sid.
[02:00] <EvilResistance> jmccrohan:  you okay if I send you a privmsg?
[02:01] <jmccrohan> EvilResistance: Sure.
[06:22] <EvilResistance> ScottK:  around?  i assume not, but it never hurts to ask :P
[06:22] <ScottK> Why would you assume that?
[06:22] <EvilResistance> the hour :P
[06:22] <ScottK> Meh.  Sleep is for the weak.
[06:22] <EvilResistance> i assume you're getting the updates for bug 914996?
[06:23] <ScottK> Probably not, I think I forgot to subscribe to it.
[06:23]  * ScottK looks
[06:23] <EvilResistance> well there's new references to the prior backport request
[06:23] <EvilResistance> for ZNC 0.202-1 (from Precise, back when it was fresh out of Debian Unstable to the precise repos)
[06:24] <ScottK> I see now.
[06:24] <EvilResistance> ScottK:  the build-deps of `swig` and `swig2.0` conflict in Ubuntu, cause dpkg failures, which in turn lead to build failures
[06:24] <ScottK> Got it.
[06:24] <ScottK> I'll try and take a look at it tomorrow if broder doesn't get to it first.
[06:25] <ScottK> Generally we want debdiffs, but I understand you're in a bad spot and it's a security issue ...
[06:25] <EvilResistance> mmm
[06:25] <EvilResistance> indeed
[06:25] <EvilResistance> although i had indications this system was on the road to death...
[06:25] <EvilResistance> bad blocks, bad sectors, etc.
[06:25] <EvilResistance> they keep popping up too
[06:27] <EvilResistance> ScottK:  you'd also have to guide me through the process of generating a debdiff, if my system were usable.  i'm familiar with git diffs, but not deb diffs
[06:27]  * EvilResistance curses his computer, digs around for his LiveUSB
[06:27] <ScottK> It's not that hard.
[06:28] <micahg> if you can generate a source package, you can generate a debdiff
[06:28] <EvilResistance> micahg:  if my system hadnt explodified itself, i'd be able to do both
[06:28] <EvilResistance> hence why i need to find my liveusb
[06:34] <EvilResistance> okay, now that i'm in the linux environment, and i installed the tools, someone want to explain how i'd generate the debdiff?
[06:35] <ScottK> EvilResistance: You've got devscripts installed?
[06:36] <EvilResistance> ScottK:  mhm
[06:37] <ScottK> Did you grab the old version of the package and then make a new version of your package?
[06:37] <ScottK> EvilResistance: ^^^
[06:38] <EvilResistance> not yet, considering i'd theoretically have to merge ZNC 0.202-2 with ZNC 0.202-1 in order to get the diffs...
[06:38] <EvilResistance> s/diffs/changes/
[06:38] <EvilResistance> oh crap i just realized what the hour is...
[06:38] <EvilResistance> i should sleep, i have to be up at 06:45 (its 01:38 atm)
[06:39] <EvilResistance> i'll make the debdiff later
[06:39]  * EvilResistance needs sleep right now
[06:39] <ScottK> EvilResistance: OK. It's just debdiff old.dsc new.dsc > somename.debdiff
[11:28] <dholbach> could anyone imagine giving a session at UDW about working with Debian? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable
[11:29] <dholbach> we still a bunch of slots open and this time we also have the possibility to have 30m sessions
[11:32] <Laney> I see opportunities for two 30m sessions there: working /with/ Debian and working /in/ Debian
[11:32] <Laney> one is like how to set up reportbug and stuff and the other is how to maintain your stuff in Debian and find sponsors and so on
[11:32] <Laney> dholbach: #debian-ubuntu ?
[11:32] <dholbach> Laney, that sounds like a great idea
[11:33] <dholbach> sure, I can ask there as well
[11:33] <Laney> I could possibly do one of them
[11:33]  * tumbleweed could too
[11:33] <Laney> but a more 'pure Debian' person might have a differently interesting perspective
[11:34] <tumbleweed> hard to find "pure Debian" people in Ubuntu :)
[11:34]  * Laney looks at Rhonda :P
[11:35] <dholbach> Laney, tumbleweed: which slot would suit you for a "working with debian" session? you'd be quite the double act :)
[11:37] <Laney> 1830 or 2000 on wednesday could work
[11:40] <tumbleweed> both work for me too
[11:40] <tumbleweed> I see we have a shorter "week" this time
[11:40] <Laney> UDHW
[11:40] <Laney> claiming 1830
[11:41] <dholbach> tumbleweed, yes, the days are longer and with shorter sessions we offer more topics
[11:41] <dholbach> but yeah it's shorter
[11:41]  * dholbach hugs Laney and tumbleweed
[11:41] <dholbach> you rock
[11:41] <tumbleweed> Laney: which half do you want?
[11:42]  * Laney proposes Ubuntu Backports: ARB isn't the only way ;-)
[11:42] <tumbleweed> broder: ^
[11:42] <Laney> I'll see if anyone from the other channel steps up
[11:43] <Laney> but I just put us both to share working with debian for now, as dholbach just said
[11:43] <tumbleweed> worksforme
[11:43] <dholbach> <3
[11:44]  * Laney thinks ajmitch ought to be roped into doing something
[11:50]  * nigelb seconds that motion
[11:50] <nigelb> Laney: did you get your lp patch in?
[11:50] <Laney> nobody reviewed it yet
[11:50] <Laney> the db change needs to land
[11:50] <nigelb> Ah, epic week. Right.
[11:59]  * Rhonda peeks at Laney
[12:00] <Rhonda> Laney: You are a DD, so you know how it works.  Done.
[12:01] <nigelb> haha
[12:02] <Rhonda> If you want to know what it is like to work in Debian, look at the bugreports opened by Jari Aalto against gitolite …  I have no nerves for much these days unfortunately.
[12:03] <tumbleweed> against .*
[12:05]  * nigelb looks
[12:05] <Rhonda> tumbleweed: Right, but gitolite is a current good example of reopening bugs which both upstream an the maintainer agrees that they aren't (multiple times, I am at four closes to the same bug right now), removing wontfix tags, and the likes.
[12:05] <Rhonda> !fun
[12:06] <Rhonda> ubottu: I wasn't talking to you :)
[12:06] <Rhonda> ! is a bad choice for a prefix character for a bot in a technical channel, me thinks.
[12:07]  * tumbleweed prefers addressing bots by nick. After all, we all have tab completion
[12:07] <Rhonda> 'sactly
[12:07] <ts2> Rhonda: starting a sentence with punctuation is the bad choice ;)
[12:08] <tumbleweed> it's IRC, we don't use full sentences
[12:09] <nigelb> wow
[12:09] <Rhonda> ts2: Since when is !fun a sentence?  :)
[12:09] <nigelb> heh
[12:09] <nigelb> Rhonda: that is one epic bug.
[12:10] <nigelb> Also, I see you are maintainer for gitolite \o/
[12:10]  * nigelb is a happy downstream user.
[12:10] <ts2> Rhonda: since... always
[12:11] <Rhonda> A sentence contains at least of subject and verb?
[12:11] <Rhonda> Do I have to fire up wikipedia for the definiton?  ;)
[12:12] <Rhonda> "A sentence can also be defined in orthographic terms alone, i.e. as simply that which is contained between a capital letter and a full stop."
[12:12] <Rhonda> There was no full stop involved. And no capital letter. There you go.
[12:12] <tumbleweed> Rhonda: jaalto isn't a problem unique to debian, though
[12:13] <Rhonda> tumbleweed: I know, likewise with … kmos? What was his nick? He was send over from "you" to "us". :)
[12:14] <tumbleweed> that predates me (or at least my awareness of it)
[12:14] <tumbleweed> but, yes, I don't think we've worked out how to ban people successfully (and I don't think we want to)
[12:15] <Rhonda> I remember that one person who was banned from ubuntu irc channels and then ranted to me in a query asking me whether I am pleased.  I wasn't even aware of the ban at that time
[12:21] <Rhonda> Sorry for not replying by mail, this is easier for me right now.
[12:21] <Rhonda> my son sent a wrong message now using irssi history, don't be confused
[12:22] <Rhonda> Btw., 30m sessions, last time it was hard for me to keep it under an hour when speaking about the BTS (which is a huge topic, I am aware of that)
[12:22] <Rhonda> the week is only three days this time?
[12:23] <Rhonda> short week :)
[12:54] <Laney> I am a DD, but I have an Ubuntu background. Thought it might be interesting to have someone without (so much of) one speak about Debian…
[14:22] <ScottK> dholbach: You might ask zack if he wants a slot to recruit people interested in Ubuntu development to work in Debian in addition.
[14:23] <dholbach> ScottK, thanks for the suggestion - I think I pinged him the last time and he said something along the lines of: try a mailing list and you might reach more folks than just me :)
[14:23] <ScottK> OK.
[14:56] <blueyed> Is there a tool for easily backporting/uploading a package to a PPA (debian/changelog entry, debuild -S -sa and maybe dput)?
[14:58] <blueyed> backportpackage probably..
[14:59] <micahg> blueyed: yes, backportpackage is it
[15:35] <EvilResistance> ScottK:  for Bug 914996, the debdiffs need to be made for... what, the difference between ZNC 0.202-1 in backports and ZNC 0.202-2 in Debian?
[15:45] <ScottK> EvilResistance: No.  Debdiff required to go from Precise to Oneriric/Natty for 0.202.
[15:46] <EvilResistance> ScottK:  the package needs changing in Precise too, per the specified changes I stated in the sync request before I can effectively do that
[15:46] <ScottK> I see.  Then it needs a merge, not a sync.
[15:46] <ScottK> Once those changes are done it needs no additional changes to be backported to the earlier releases?
[15:46] <EvilResistance> correction
[15:47] <EvilResistance> it needed syncing first because 0.202-2 did not exist
[15:47] <EvilResistance> everyone here said it required a sync first
[15:47] <EvilResistance> if you dig around in the logs, the diffs between -1 and -1build1 remove the conflicts
[15:47] <EvilResistance> within the main archive
[15:48] <EvilResistance> short of me uploading -2build1 to REVU with the statement "Fixes build errors in 0.202-2 from Debian"
[15:48] <EvilResistance> the archive admins would have to do that
[15:48] <EvilResistance> or a MOTU
[15:49] <micahg> EvilResistance: are you saying the precise upload is broke?
[15:49] <EvilResistance> micahg: the precise upload has been broken since the import of 0.202-1
[15:49] <EvilResistance> i caught that error when backporting in PPAs, and removed the 'swig' build-dep
[15:50] <EvilResistance> in Debian, 'swig' and 'swig2.0' don't conflict
[15:50] <EvilResistance> in Ubuntu, they do
[15:50] <micahg> no, they don't in precise
[15:50] <EvilResistance> micahg:  are you *absolutely certain* about that?
[15:50] <micahg> yes
[15:50] <EvilResistance> then the backported versions need the change
[15:50] <micahg> yes
[15:50] <EvilResistance> in Ubuntu Oneiric/Natty, 'swig' and 'swig2.0' conflict
[15:50] <EvilResistance> i mention that in the backport request
[15:50] <micahg> default swig is 1.3 in <precise and 2.0 in precise
[15:51] <EvilResistance> micahg:  Bug 914996
[15:51] <EvilResistance> and I quote from the thing:
[15:51] <EvilResistance> hanges Required for Ubuntu:
[15:51] <EvilResistance> debian/control: Remove conflicting `swig` build-dep, which conflicts with `swig2.0` build dep. Removal will allow packages to build, except on natty (due to backported build deps not being able to be used for backports). (refer to previous backport of ZNC 0.202-1, Bug #887758)
[15:52] <EvilResistance> the issue with the natty build is outlined in bug...
[15:52] <EvilResistance> um...
[15:52] <EvilResistance> Bug 888665
[15:52] <micahg> EvilResistance: I saw, I don't have time to deal with it at the moment, maybe someone else can (if you provide a proper diff on top of the new version in precise, that could speed things up)
[15:53] <EvilResistance> so basically i'd need to modify the package in order to provide the diff :P
[15:53] <micahg> EvilResistance: you can take the diff from the last upload and try to apply it
[15:54] <EvilResistance> micahg:  that's actually easy, assuming i modify debian/control
[15:59] <EvilResistance> micahg:  they did add two .py files for the znc-python binary
[15:59] <EvilResistance> the diffs wont apply unless i pull in that code
[16:00] <EvilResistance> (unless i generate the debdiffs myself)
[16:00] <EvilResistance> (which i can do)
[16:07] <EvilResistance> might be easier for someone else to do this, because of the two files that do not exist in the backport
[16:08]  * EvilResistance is running into numerous issues
[17:28] <blueyed> Precise's pbuilder should know about precise, shouldn't it?
[17:30] <blueyed> Oh, it's my ~/.pbuilderrc going wrong.


[08:34] <GunbladeIV> [1;3D
[11:46] <rayChang> /clear
[11:47] <rayChang>  (행동)
[15:58]  * mvo looks around
[15:58]  * liw looks around
[15:58]  * robbiew waves
[15:59] <robbiew> I got 1 minute!
[15:59] <slangasek> morning
[15:59] <cjwatson> hi
[16:00] <robbiew> #startmeeting
[16:00] <MootBot> Meeting started at 10:00. The chair is robbiew.
[16:00] <robbiew> hi liw: mvo: slangasek: cjwatson:
[16:00] <mvo> hi
[16:00] <robbiew> Keybuk: around? done crying about your iPhone :P
[16:01] <Keybuk> ;)
[16:01] <mvo> what happend to it?
[16:01] <robbiew> Agenda: http://wiki.ubuntu.com/FoundationsTeam/Meetings/2009/0610#Agenda
[16:01] <robbiew> james_w: awake?
[16:02] <james_w> aye aye
[16:02] <mterry> hi
[16:02] <robbiew> mterry: howdy
[16:03] <robbiew> last one in takes dmraid
[16:03] <robbiew> lol
[16:03] <Keybuk> mvo: nothing interesting, just told me it had core dumped
[16:03] <james_w> heh
[16:03] <robbiew> doko: you joining..or just listening :)
[16:03]  * evand1 knocks over everyone in his path to the entrance
[16:04] <al-maisan> robbiew: interesting management technique ;)
[16:04] <robbiew> thanks for taking dmraid evand1 :P
[16:04] <doko> robbiew: joining
[16:04] <robbiew> okay...let's go!
[16:04] <robbiew> [TOPIC] DMRaid
[16:04] <MootBot> New Topic:  DMRaid
[16:05] <robbiew> TheMuso can't take it to Desktop...so I need someone to take it
[16:05] <mterry> Why is it so scary?  Just needs special hardware?
[16:05] <cjwatson> ok, so
[16:05] <robbiew> yeah
[16:05] <liw> as I understand it the hardware is pretty common (part of the usual intel motherboard chipsets that lots of people have)
[16:06] <cjwatson> dmraid is a system for dealing with low-end hardware raid - but it's not using a proper raid controller, it's basically done in the bios
[16:06] <robbiew> well..it's software raid, so I don't think it's that special
[16:06] <cjwatson> the reason it's a bit scary is that (a) the hardware is nasty (b) the software is nasty
[16:06] <robbiew> heh
[16:06] <robbiew> TheMuso is willing to help whomever takes it over get up to speed
[16:06] <doko> nasty + nasty = scary ?
[16:06]  * slangasek doesn't have the hardware here
[16:06] <liw> I have the chipset on my desktop machine, but I want to use that machine, and I am not sacrificing its hard disks to dmraid :P
[16:07] <Keybuk> and (c) scott keeps changing things underneath you
[16:07] <mterry> How do i know if I have the right hardware?
[16:07] <cjwatson> it basically occupies an uncomfortable halfway house between proper hardware raid and mdadm
[16:07] <liw> Keybuk, which Scott? :)
[16:07] <cjwatson> however, dmraid *mostly* works now; the main thing that's missing is that IIRC the desktop installer doesn't yet deal with it
[16:07] <mterry> I'm sure I could appropriate some of the OEM hardware, if we have matching stuff
[16:07] <cjwatson> but of course it needs maintenance, and I understand that the userspace side is being integrated into mdadm at some point
[16:07] <liw> mterry, TheMuso gave the specs in a previous meeting, but I can't find it now
[16:08] <cjwatson> every bios vendor has their own flavour of it so there's a certain amount of whack-a-mole involved
[16:08] <robbiew> mterry: the only issue with you taking it...is when you go back to OEM next cycle
[16:08] <robbiew> unless you want to keep it :)
[16:08] <cjwatson> take it, fix it, document it, leave it? :)
[16:08] <mterry> robbiew: But then doko comes back for it, right?  I thought it was doko's baby.  Maybe I'm misremembering
[16:08] <liw> robbiew, that's not an issue, that's "distributing knowledge around the company"
[16:08] <robbiew> mterry: no..TheMuso's
[16:08] <mterry> Ah
[16:08] <cjwatson> certainly anyone taking it ought to have the relevant hardware, if only because that provides an incentive to make it work well
[16:09] <robbiew> right
[16:09]  * doko is handling over glibc to mterry
[16:09] <cjwatson> but I imagine there's some company hardware somewhere with it, as you say
[16:09] <robbiew> I also imagine that I could find some from the server team...since we are doing it for them in many ways
[16:09] <cjwatson> IIRC there hasn't been a lot of Ubuntu community interest in it unfortunately
[16:10] <cjwatson> (if I'm wrong, sorry, no slight intended)
[16:10] <robbiew> maybe we try giving it back to the server team....though I don't have much hope in them taking it
[16:11] <Keybuk> raid sounds very servery ;)
[16:11] <mterry> Well, if I'm not suitable, maybe OEM could give up some hardware to someone else, if people are worried about frying their stuff
[16:11] <liw> dmraid does not sound very servery to me ;-)
[16:11]  * soren concurs with liw :)
[16:11] <cjwatson> server people hate dmraid because it's cheap
[16:12] <evand1> I'm slightly confused by this being driven by the server team but the last missing piece being integration in ubiquity.
[16:12] <mterry> Everything we have is Intel, and we've got old netbooks
[16:12] <cjwatson> it's something hot-rod machines sold to gamers use
[16:12] <cjwatson> anyway, I think it'd be cool for mterry to do it personally
[16:12] <robbiew> cjwatson: okay
[16:12]  * liw votes for mterry
[16:12] <mterry> Again, it's not clear I have the hardware.  Will have to talk to TheMuso
[16:12] <robbiew> but we'll need to figure out a plan for post-mterry :)
[16:13] <robbiew> ok
[16:13] <robbiew> [ACTION] mterry to talk to TheMuso about dmraid
[16:13] <MootBot> ACTION received:  mterry to talk to TheMuso about dmraid
[16:13] <mterry> I assume we're obligated to love it?
[16:13] <mterry> Like, we can't just kick it to universe and wipe our hands?
[16:13] <robbiew> yes...but I can't remember why....cjwatson?
[16:13] <slangasek> I'd be willing to take it, but the company would need to get me a gaming rig^W^W test machine
[16:14] <robbiew> heh
[16:14] <evand1> heh
[16:14] <cjwatson> largely because lots of real hardware uses it and people get upset when Ubuntu doesn't work right on it
[16:14]  * ogra puts a "i love hot rods" sticker on mterry's back
[16:14] <cjwatson> if we aren't dmraid-aware, then if you try to install Ubuntu alongside e.g. an existing Windows installation, then it trashes your Windows installation for you
[16:14] <ogra> (with lots of flames)
[16:14] <robbiew> ah...right
[16:14] <cjwatson> since it desyncs the multiple disks
[16:14] <robbiew> I recall TheMuso mentioning tht
[16:14] <robbiew> that
[16:14] <mterry> cjwatson: Ah.  That just needs marketing as a feature, not a bug.  But good point
[16:14]  * Keybuk hides the Alienware logo on his desktop
[16:15] <slangasek> "just" :)
[16:15] <robbiew> mterry: I guess just chat with TheMuso later today and let me know if you can do it...thnks
[16:16] <mterry> robbiew: OK
[16:16] <robbiew> [TOPIC] Karmic Roadmap
[16:16] <MootBot> New Topic:  Karmic Roadmap
[16:16] <robbiew> http://wiki.canonical.com/UbuntuPlatform/Foundations/9.10
[16:16] <MootBot> LINK received:  http://wiki.canonical.com/UbuntuPlatform/Foundations/9.10
[16:16] <plars> https://mail.google.com/mail/?ui=2&zx=1bwv90j2o1its&shva=1#inbox
[16:16] <robbiew> I still need to put in the Medium and Lows...and move over to ubuntu.com
[16:16] <robbiew> plars: ????
[16:17] <robbiew> It's becoming clear as I populate the list...that there's NO way we can deliver all this
[16:17] <robbiew> at least, in my opinion
[16:17] <james_w> put in the medium and lows?!
[16:17] <mterry> Heh
[16:17] <doko> can we add e?glibc-2.10 to the roadmap?
[16:17] <robbiew> no
[16:18] <robbiew> heh
[16:18] <plars> robbiew: sorry, misfire
[16:18] <doko> robbiew: do you want to stick with 2.9 for karmic?
[16:19] <robbiew> doko: are you saying glibc or eglibc?
[16:19] <slangasek> robbiew: do you want multiarch on there as a 'low'? :)
[16:19] <Keybuk> robbiew: the swap file stuff has two parts
[16:19] <Keybuk> a boot part and an installer part
[16:19] <doko> robbiew: parse it as an extended regexp ;)
[16:20] <robbiew> slangasek: whatever the blueprint says
[16:20]  * robbiew forgot to put that in...like i said, it's not done
[16:20] <robbiew> Keybuk: right...okay
[16:20] <cjwatson> the installer part's pretty trivial - I'd be happy for us to do that bit without splitting up the blueprint
[16:20] <mterry> I don't see copyright stuff on that list.  Was that not us?
[16:20] <doko> slangasek: maybe delay that after debconf?
[16:21] <robbiew> [ACTION] robbiew to break apart the swapfile into boot and installer
[16:21] <MootBot> ACTION received:  robbiew to break apart the swapfile into boot and installer
[16:21] <Keybuk> cjwatson: the boot part is pretty trivial too ;)
[16:21] <robbiew> cjwatson: okay
[16:21] <slangasek> doko: delay what?  after debconf would be too late to start on a spec for karmic...
[16:21] <robbiew> that works too
[16:21] <robbiew> mterry: it is...just not gotten to it yet
[16:21] <slangasek> doko: and I'm trying to get the spec finalized so that Guillem has something to work to
[16:21]  * mterry is excited about the dep5 future
[16:22] <slangasek> you're excited about 4 more months of bikeshedding? :)
[16:22]  * mterry will be excited to have a bikeshed anyway
[16:22] <liw> slangasek, I'm excited about four months of bikeshedding that you drive :)
[16:23] <robbiew> so, I obviously need to finish this roadmap today/tomorrow, but wanted to let everyone see it now...to start the panic early ;)
[16:23] <doko> slangasek: wasn't aware that you do want to finish the spec before
[16:23] <cjwatson> in case people haven't noticed, BTW, this week is listed on the release schedule as the deadline for getting specs written
[16:24] <evand1> robbiew: should we contact you about items that are not on that list yet, or are you aware of the missing specs?
[16:24] <robbiew> I would like us to think about putting delivery milestones for our work...using the section in the blueprints
[16:24] <robbiew> evand1: no...I'm still building the list
[16:24] <liw> cjwatson, FeatureDefinitionFreeze? it's not june 18?
[16:24] <evand1> okay
[16:24] <cjwatson> liw: see the note against the previous week in https://wiki.ubuntu.com/KarmicReleaseSchedule
[16:25] <cjwatson> IOW the specs need to be written up so that we have time to sift through them and agree what we're actually doing
[16:25] <liw> cjwatson, bah, that should be in the .ics file too, too many places to poll :(
[16:25] <robbiew> cjwatson: +1
[16:25] <mvo> *ick*
[16:25]  * mvo will have to focus on spec writing today then
[16:25] <robbiew> if you already know of work that you simply cannot do...let me know
[16:26] <robbiew> I can defer it, until next cycle...or help resolve the conflict of priorities
[16:26]  * Keybuk hasn't even started writing specs yet
[16:27]  * liw is still recovering from three weeks of travel
[16:27] <robbiew> cry me a river
[16:27] <robbiew> lol
[16:28] <liw> but yeah, finishing the specs I have this week should be reasonably possible, if I stop reading e-mail
[16:28]  * james_w can finish the specs this week. The work on the other hand... :-)
[16:29] <robbiew> okay...moving on
[16:29] <robbiew> [TOPIC] Bugs
[16:29] <MootBot> New Topic:  Bugs
[16:29] <cjwatson> robbiew: there was precious little agreement on foundations-karmic-ubuntu-one-in-installer, IIRC; the gobby document ends with "we won't change the installer"
[16:29] <cjwatson> so I think you can safely take that off our list
[16:29] <robbiew> cjwatson: yep...good point
[16:29] <robbiew> will do
[16:29]  * Keybuk writes the words "See implementation" in all his specs
[16:29] <Keybuk> done!
[16:30] <robbiew> [ACTION] robbiew to take off ubuntu-one-in-installer
[16:30] <MootBot> ACTION received:  robbiew to take off ubuntu-one-in-installer
[16:30] <robbiew> Alpha 2 is tomorrow
[16:30]  * slangasek chooses Keybuk as approver for all his specs
[16:30] <robbiew> heh
[16:31] <slangasek> he's the OTS of spec regulation
[16:31] <Keybuk> OTS?
[16:31] <slangasek> Office of Thrift Supervision :)
[16:31] <robbiew> heh
[16:31] <robbiew> not much to say about bugs for alpha2...since it's tomorrow
[16:31] <robbiew> so moving on to our favorite topic:
[16:32] <robbiew> [TOPIC] Sponsorship Queue
[16:32] <MootBot> New Topic:  Sponsorship Queue
[16:32] <cjwatson> I sucked during my scheduled timeslot yesterday, but rocked this morning to make up for it
[16:32] <cjwatson> (until I remembered that we were in soft freeze and rapidly switched to universe stuff, whoops)
[16:33] <robbiew> FWIW, dholbach has a little website that tries to gather sponsorship stats on each developer
[16:33] <robbiew> lol
[16:33]  * slangasek blames all CD problems today on cjwatson
[16:33] <robbiew> slangasek: isn't that the norm? :P
[16:33] <slangasek> no, I usually blame them on Keybuk
[16:34] <robbiew> somehow that doesn't surprise me
[16:34]  * james_w sponsored two things this morning, with an hour scheduled on Friday for some more
[16:34] <robbiew> anyway, I know you all have tons to do...but please make sure to check the queue when you can
[16:35] <robbiew> [TOPIC] Activity report news
[16:35] <MootBot> New Topic:  Activity report news
[16:35] <robbiew> I haven't read them all...but does anyone have something they want to bring up?
[16:36] <robbiew> taking the silence as a "No!"
[16:36] <mvo> tomorrow is a public holiday in (my part of) germany
[16:36] <robbiew> [TOPIC] Good News
[16:36] <MootBot> New Topic:  Good News
[16:36] <robbiew> mvo: well, that's good news :)
[16:36] <robbiew> for you
[16:36] <robbiew> heh
[16:36] <slangasek> still more merges to be done :)
[16:36] <mvo> :)
[16:37] <robbiew> I got a 73" HDTV coming today :D
[16:37] <slangasek> only 15 merges left under doko's name
[16:37] <Keybuk> robbiew: your performance review went well, then!
[16:37] <cjwatson> lots of my specs appear to be pleasingly small
[16:37] <robbiew> Keybuk: lol...no, my realtor gave me back 2% of her 3% commission ;)
[16:38] <cjwatson> (couple of meaty ones, there's plenty left to do on grub2)
[16:38] <robbiew> cjwatson: yeah...I was worried at first
[16:38] <doko> slangasek: are there some where I should help?
[16:38] <mvo> slangasek: I can help with those as well
[16:38] <evand1> 73"?  I have TV envy.
[16:38] <slangasek> doko, mvo: don't bother with gawk, I'm going to assert my maintainership of the package in Debian and try to get that into a sync
[16:39] <mterry> 'assert my maintainership' sounds so forceful
[16:39] <ogra> evand1, above 50" are only for managers :P
[16:40] <evand1> apparently!
[16:40] <cjwatson> mterry: this is slangasek's manly side
[16:40] <robbiew> #endmeeting
[16:40] <MootBot> Meeting finished at 10:40.
[16:40] <cjwatson> whoa, I had one AOB
[16:40]  * mvo is pretty impressed after he calculated what 73" means in centimeter
[16:40] <robbiew> heh...i see we've digressed
[16:40] <robbiew> oh
[16:40] <robbiew> sorry
[16:40] <cjwatson> anyway, it's quick
[16:40] <cjwatson> 8.04.3
[16:40] <mterry> cjwatson: Just like yours is going into the woods without a patch system
[16:40] <robbiew> fire away
[16:40] <cjwatson> mterry: hah
[16:40] <robbiew> heh...that's a significant AOB
[16:40] <cjwatson> there are a few things that I think still ought to be cleared up for .3 if possible
[16:41] <cjwatson> evand1: bug 219192
[16:41] <cjwatson> doko (or somebody who can play him on TV): bug 288279
[16:41] <evand1> sure thing
[16:42] <slangasek> mterry: Debian politics... the package was put up for adoption, I adopted it in agreement with the maintainer, someone else is uploading it using maintainer version numbers :)
[16:42] <cjwatson> and it'd be nice if somebody could look at bug 347303 and bug 246625
[16:42] <cjwatson> (maybe not for .3 in the latter two cases)
[16:43] <doko> cjwatson: openjdk-6: I'm tempted to prepare an update for hardy based on the jaunty package
[16:44] <cjwatson> I have one more of my own to take care of, namely bug 250400
[16:45] <robbiew> cjwatson: slangasek: anything else related to 8.04.3?
[16:45] <slangasek> doko: I don't think a wholesale packaging update is appropriate, or likely to clear regression verification in time for .3
[16:45] <cjwatson> that's all from me, dunno about Steve
[16:46] <slangasek> nothing else from me; I'll poke people individually for anything critical
[16:46] <robbiew> okay
[16:46] <robbiew> #reallyendmeeting
[16:46] <robbiew> :)
[16:46] <robbiew> thanks all
[16:46] <mvo> thanks!
[16:46] <slangasek> thanks
[16:46] <liw> gracias
[16:46] <al-maisan> thanks!
[17:58] <ara> hola!
[17:59] <fader> Howdy.
[17:59] <bdmurray> Hi
[17:59] <pedro_> hello folks!
[17:59]  * ogasawara waves
[18:00] <cr3> yo homies
[18:00] <heno> hey everyone!
[18:00] <sbeattie> hey
[18:00] <schwuk> hi
[18:00] <eeejay> yo
[18:01] <heno> #startmeeting
[18:01] <MootBot> Meeting started at 12:01. The chair is heno.
[18:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:02] <heno> We have a long agenda: UbuntuBugDay highlights -- pedro
[18:02] <pedro_> well there's was no hug day the last week
[18:02] <pedro_> but we are having one tomorrow cof cof
[18:02] <pedro_> based on update-manager and update-notifier
[18:02] <heno> [TOPIC] UbuntuBugDay highlights -- pedro
[18:02] <MootBot> New Topic:  UbuntuBugDay highlights -- pedro
[18:02] <pedro_> https://wiki.ubuntu.com/UbuntuBugDay/20090611
[18:02] <pedro_> as always everybody is welcome to join us and clean up those products
[18:03] <heno> thanks pedro_
[18:04] <heno> [TOPIC] New bug control members! -- bdmurray
[18:04] <MootBot> New Topic:  New bug control members! -- bdmurray
[18:04] <pedro_> my pleasure
[18:04] <bdmurray> Paul Larson was added as a regular bug control member this past week
[18:04] <mvo> update-manager!
[18:05]  * heno hugs mvo
[18:05]  * mvo hugs heno and pedro_
[18:05] <cr3> ara: regarding those bugs found for the update-manager, these might be good leads when writing desktop tests
[18:05]  * pedro_ hugs mvo back
[18:05] <ara> cr3: indeed
[18:06] <heno> how many update-manager bugs are really u-m bugs and how many belong to other packages (typically)
[18:06] <heno> I'm guessing the u-m GUI itself doesn't have that many real bugs
[18:06] <mvo> heno: hard to say (and I'm biased of course), but I would say > 50% are not really u-m bugs. some are really hard to diagnose though
[18:07] <mvo> I think one problem is that u-m excercises the system a lot during a disk-upgrade so that HW problems show up more likely
[18:07] <mvo> it stresses network, mem and disk-io quite a bit
[18:08] <mvo> at some point I did some statistics, might be worthwhile to redo them
[18:09] <heno> We should look at doing GUI-driven upgrade testing as part of the dist upgrade spec
[18:09] <cr3> mvo: would it be worthwhile to run a sanity check on hardware before running tests in order to detect those kinds of failures beforehand?
[18:09] <heno> if that would help flush out such issues
[18:09] <mvo> cr3: a interessting idea
[18:09] <cr3> mvo: luckily, there are plenty of stress test suites out there already for hardware which could be integrated into checkbox
[18:09] <mvo> heno: absolutely, I hope with "update-manager --sandbox" this is easy(ier) now
[18:10] <cr3> mvo: I'm not completely convinced this would be useful so I'm just throwing the idea on the table
[18:10]  * mvo nods
[18:11] <heno> fortunately the dist upgrade spec is not complete yet ;) so we can consider this
[18:11] <heno> we'll look at that in the last agenda item
[18:11] <heno> moving on ...
[18:11] <heno> [TOPIC] Fridge Calendar Entry - wrong time -- schwuk
[18:11] <MootBot> New Topic:  Fridge Calendar Entry - wrong time -- schwuk
[18:12] <schwuk> heno: in progress
[18:12] <heno> ok
[18:12] <heno> [TOPIC] Official Bug Tags - should apport- stuff be listed? -- bdmurray
[18:12] <MootBot> New Topic:  Official Bug Tags - should apport- stuff be listed? -- bdmurray
[18:13] <bdmurray> Launchpad now suggests the official bug tags when one is adding tags to a bug report and this is something that didn't exist when started the official tags list
[18:14] <bdmurray> I don't believe it useful for tags like apport-crash and apport-bug to be suggested since they should be added automatically
[18:14] <bdmurray> So I'd like to remove them from the "official" tag list
[18:15] <bdmurray> And only keep ones that should be added by people
[18:15] <sbeattie> does "official" status confer anything else to the tag?
[18:15] <heno> does https://wiki.ubuntu.com/Bugs/Tags otherwise map to the LP official list?
[18:15] <bdmurray> sbeattie: well, they show up in the official portlet vs the "other tags" portlet
[18:16] <bdmurray> but that's the only other advantage I know of
[18:16] <heno> bdmurray: you want to remove them from the LP list (are they there?) or just the wiki page?
[18:16] <bdmurray> heno: some of the ones on the wiki page are experiments (ways to test new tags)
[18:17] <bdmurray> heno: from the lp list so they aren't recommended when someone is adding tags to a bug report
[18:17] <heno> bdmurray: makes sense
[18:17] <bdmurray> heno: they'd stay on the wiki page as they are useful for triagers to understand when or why a tag was added
[18:17] <heno> we could move them to an automatic section on the wiki page too
[18:18] <heno> should we also move the experimental ones or highlight them in grey so we get a clear mapping between the two places?
[18:19] <bdmurray> maybe adding a column for the "official" ones?
[18:19] <heno> anyway +1 for your original suggestion, bdmurray
[18:19] <heno> right, or just mark the others with a '*'
[18:20] <heno> but we're bikesheding ...
[18:20] <schwuk> heno: Fridge entry fixed.
[18:20] <heno> [TOPIC] qa.u.c landing page. Any news? -- ara
[18:20] <MootBot> New Topic:  qa.u.c landing page. Any news? -- ara
[18:20] <ara> I just wanted to ask about how this is going
[18:20] <heno> ok, how about this one :) schwuk ^
[18:21] <schwuk> IS are finally moving on this (after I poked them) but now there's a permissions problem.
[18:21] <cr3> how come the landing page says "ubuntu brainstorm"?
[18:21] <schwuk> cr3: It won't soon :)
[18:21] <cr3> schwuk: how come it did in the first place?
[18:21] <schwuk> cr3: because it's currently served by brainstorm - we're switching it to static content.
[18:22] <cr3> interesting... thanks for the background info
[18:22] <schwuk> heno: I expect this to be complete by next weeks meeting. Hopefully by the end of this week.
[18:22] <heno> the ISO tracker share code and used to share an instance, cr3
[18:22] <heno> schwuk: ok, thanks
[18:23] <heno> schwuk: can you blog about it when it does?
[18:23] <ara> schwuk: thanks
[18:23] <heno> [TOPIC] Testing Days in Karmic -- ara
[18:23] <MootBot> New Topic:  Testing Days in Karmic -- ara
[18:24] <ara> I am wondering when should we start again with the testing days
[18:24] <schwuk> heno: of course
[18:24] <ara> do you think we are late enough in the cycle to start with them?
[18:25] <heno> Might be good time for a Hardy.3 SRU testing day
[18:25] <heno> or possibly Jaunty SRUs?
[18:25] <sbeattie> heno: hrm, yeah, makes sense
[18:25] <heno> sbeattie: which one? :)
[18:25] <sbeattie> both, honestly.
[18:26] <ara> :)
[18:26] <heno> ara: things like grub2 and ext4 default are landing
[18:26] <sbeattie> though hardy.3 should come soon, given upcoming deadline.
[18:26] <heno> it's early for Gnome stuff though
[18:26] <sbeattie> yes, I think there's enough stuff landing already that karmic testing days make sense.
[18:26] <heno> pedro_: when should we expect the first Gnome drops?
[18:27] <heno> ara: reminds us of the topic suggestion URL?
[18:28] <ara> heno: https://wiki.ubuntu.com/Testing/UbuntuTestingDay/Features
[18:28] <heno> ok, let's add our ideas there
[18:29] <pedro_> heno: IIRC next week we might have some new packages with Gnome 2.27 on karmic
[18:29] <heno> should we aim for an SRU testing day next Monday?
[18:29] <sbeattie> heno: that's reasonable.
[18:29] <heno> sbeattie: which ever release is most pressing, or both
[18:30] <heno> pedro_: does it make sense to get formal testing of that or is it too raw?
[18:32] <pedro_> it's a bit raw now, I'd wait for 2.27.4 or .5 which is due to July for doing a more formal testing
[18:32] <heno> ok
[18:33] <pedro_> Jul 15 2.27.4 and Jul 29  2.27.5 for being more specific
[18:33] <heno> ara: is that enough to get us started?
[18:33] <ara> heno: sure, we can start with srus, then ext4 and/or grub2 and then move to gnome stuff
[18:34] <heno> ok, great
[18:34] <ara> sbeattie: for next monday hardy or jaunty?
[18:34] <heno> there are also some new Karmic features listed here https://wiki.ubuntu.com/QATeam/Specs/RegressionImmunisation
[18:34] <sbeattie> Right now, hardy, but I may expand it to cover jaunty as well.
[18:34] <sbeattie> ara ^
[18:35] <heno> speaking of which ...
[18:35] <heno> [TOPIC] SRU Verifications -- sbeattie
[18:35] <MootBot> New Topic:  SRU Verifications -- sbeattie
[18:35] <sbeattie> First, thanks to Alexei Mokeev, ZelinskiyIS, gidantribal, medisoft, ded, and Patryk Bajer for testing SRUs and helping to get them out.
[18:36] <sbeattie> And second, as mentioned above, 8.04.3 is coming (july 9th I believe).
[18:36] <heno> sbeattie: do we know when the verification deadline is?
[18:36] <sbeattie> Hrm, no, I'll ask slangasek.
[18:37] <sbeattie> But I would expect a week or two before.
[18:37] <heno> ok
[18:37] <sbeattie> Sine there'll be a run up time of image testing.
[18:37] <heno> right
[18:38] <heno> how many images are we doing now, just Ubuntu server?
[18:38] <sbeattie> hrm, once again, I don't recall if we're spinning desktop images as well.
[18:39] <sbeattie> The calendar at https://wiki.ubuntu.com/HardyReleaseSchedule doesn't say
[18:39] <heno> ok
[18:39] <heno> next
[18:39] <heno> [TOPIC] Spec Roadmap review -- heno
[18:39] <MootBot> New Topic:  Spec Roadmap review -- heno
[18:39] <heno> see https://wiki.ubuntu.com/QATeam/RoadMap
[18:40] <heno> it's looking better, but there are still gaps
[18:40] <heno> let's go down the list of non-Approved specs and get some drafting ETAs
[18:41] <heno> Specialization Within bug-control
[18:41] <heno> pedro_: ^?
[18:41] <pedro_> I'm a bit behind with my spec, since i wasn't around the last week but i hope to have that drafted by the end of the week
[18:42] <bdmurray> What's the (i) for on that page?
[18:42] <heno> pedro_: right, do you need some help drafting?
[18:42] <pedro_> for hopefully having more opinions on the subject from the community team
[18:42] <heno> bdmurray: informational
[18:42] <heno> I should add it to the key :)
[18:42] <pedro_> heno: that'd be nice :-)
[18:43] <heno> ogasawara: Package Greasemonkey Scripts ?
[18:43] <ogasawara> heno: hoping to get it done by end of the week since I just became the drafter yesterday
[18:43] <heno> understood
[18:44] <heno> ogasawara: could you also add the two kernel bug specs to that page?
[18:44] <bdmurray> I'll be helping out with that one
[18:44] <ogasawara> heno: will do
[18:44] <heno> bdmurray: great, thanks
[18:44] <heno> fader: Extended Audio Testing ?
[18:45] <fader> Hoping to get it done today, but I'll promise no later than EOD tomorrow.
[18:45] <fader> (i.e. you can hold me to that :) )
[18:46] <heno> ok. we talked about what needs doing to it
[18:46] <heno> sounds good
[18:46] <heno> ogasawara: Suspend Resume Testing - same situation on that one I guess
[18:46] <ogasawara> heno: yup
[18:47] <heno> to be fair I made up that spec yesterday ...
[18:47] <ogasawara> :)
[18:47] <heno> sbeattie: Distribution Upgrade Testing ?
[18:48] <heno> I think you said we should ask mvo to look at that one too https://wiki.ubuntu.com/QATeam/Specs/DistributionUpgradeTesting
[18:48] <sbeattie> Yep, if mvo could help flash that out, it'd be great.
[18:48] <heno> same goes for james_w with the package testing spec
[18:48] <cr3> sbeattie: yeah, I'd like to see mvo "flash" too!
[18:49] <heno> sbeattie: can we set an ETA though?
[18:49] <sbeattie> heno: otherwise, by end of the week.
[18:49] <cr3> james_w: if you need help with that spec, I'm your man
[18:49] <heno> ok, thanks
[18:49] <maco> what a line to enter the buffer on
[18:50] <schwuk> maco: you should be used to cr3 by now
[18:50] <heno> I guess mgunes isn't here
[18:51] <heno> Testing Weather Report still needs some drafting
[18:52] <heno> like answering the python vs. ruby question :)
[18:52] <heno> I can poke some more at that too
[18:52] <heno> schwuk: the 2 checkbox specs?
[18:53] <schwuk> heno: enhancements tomorrow, wishlist friday
[18:53] <heno> again to be fair, we've regrouped those a great deal
[18:53] <heno> schwuk: ok, thanks
[18:53] <schwuk> yeah - there's a lot folded into those
[18:54] <heno> cr3: the checkbox filters spec - draft or punt to Karmic+1?
[18:54] <cr3> heno: draft, I totally forgot about that one
[18:55] <heno> ok, thanks
[18:55] <heno> now: who has started implementation work?
[18:55] <heno> o/ :)
[18:56]  * fader hides.
[18:56] <cr3> o/... I couldn't help myself :(
[18:56] <cr3> (note that the dots under my arm pit emoticon aren't stink waves)
[18:56] <heno> that's not really expected though :)
[18:57] <heno> we'll revisit the list in 3-4 weeks to look at implementation progress
[18:57] <heno> did I leave any key specs off that list?
[18:58] <cr3> karmic-qa-marc-needs-to-grow-up?
[18:58] <schwuk> lol
[18:58] <james_w> cr3: am I drafting the package testing one?
[18:58] <heno> eeejay: are you planning to write a separate Ubiquity automation spec?
[18:59] <heno> If so, let me know if you need a hand scoping it out
[18:59] <cr3> james_w: actually, I believe fader is, so you're probably off the hook... for now
[18:59] <fader> james_w: I'm drafting one but there's another as well
[18:59] <james_w> excellent :-)
[18:59] <eeejay> heno: sure, i could do that
[18:59] <fader> james_w: I'm not sure who is drafting it though -- I thought it was you :/
[18:59] <cr3> fader: could you let us know the url for the spec, I can't seem to find it
[18:59] <james_w> fader: let's chat after
[19:00] <heno> james_w: I understand you are involved with a related package spec on the foundation track?
[19:00] <fader> james_w, cr3: Sounds good, we can straighten this out after the meeting
[19:00] <cr3> james_w: heno is referring to the last session during uds
[19:00] <heno> eeejay: great, we can talk later
[19:00] <james_w> heno: yeah, myself and mvo are interested in much the same things as your team apparently, so we're going to combine efforts
[19:00] <heno> sounds good
[19:01] <heno> we are at time
[19:01] <james_w> we didn't have a clear picture of what would happen this cycle and who would do what after the session though, so we agreed to discuss it after UDS
[19:01] <heno> any other urgent business?
[19:01] <heno> james_w: makes sense
[19:01] <heno> we are just emerging from that phase ourselves ;)
[19:02] <heno> #endmeeting
[19:02] <MootBot> Meeting finished at 13:02.
[19:02] <heno> thanks everyone!
[19:02] <james_w> thanks all
[19:02] <pedro_> thanks you!
[19:03] <ara> cheers
[19:03] <sbeattie> thanks!
[19:03]  * fader waves.


[00:46] <dragonlord_>  hi ! i need help with kde plasma system  settings,  it keeps  crashing,  any help plz ?
[00:48] <dragonlord_> anyone ?
[00:51] <dragonlord_> plz help, :(((
[00:57] <kryten> dragonlord_: Just curious.. since you are crossposting.. are you actually using Kubuntu or Ubuntu Studio?
[01:02] <dragonlord_> ubuntu-studio
[01:03] <dragonlord_> 20.10, i reinstalled but same :(
[01:04] <dragonlord_> need help, only system settings crashes when changing tabs,
[01:06] <dragonlord_> i can't sleep till it works :(((
[01:16] <dragonlord_> :(
[14:05] <dragonlord_> hi ! my system settings keeps crashing,  got 20.10.. any help plz ?
[14:27] <sirriffsalot> dragonlord_: need more details mate
[14:28] <sirriffsalot> dragonlord_: ah, I seem to remember you asking about changing tabs and then finding that your system crashes? If that's the case, try installing a different desktop environment and use that, see if the same problem occurs
[14:37] <dragonlord_> really, i like plasma  :(
[14:37] <dragonlord_> no other solution ?
[14:38] <OvenWerks> Maybe ask in #kubuntu
[14:38] <dragonlord_> no answer
[14:38] <dragonlord_> gonna try
[14:41] <sirriffsalot> dragonlord_: before you could hope to solve it you at least need to figure out what the problem is
[14:41] <sirriffsalot> dragonlord_: if my suggestion solves it, then you know to ask in #kde, because it's most likely a bug in your DE (desktop environment)
[14:42] <sirriffsalot> Sigh
[14:42] <sirriffsalot> Dragonlord still has some remaining beasts to slay
[15:04] <BrianHechinger[m> where do jack_midi_event_t and jack_midi_event_get() live? The docs aren't completely clear and I can't built this thing I'm writing. :(
[15:05] <OvenWerks> BrianHechinger[m: you are asking this here? not #LAD?
[15:05] <OvenWerks> sorry #lad
[15:06] <BrianHechinger[m> A) I didn't know about #lad
[15:06] <BrianHechinger[m> B) You're all like smart and stuff so I thought you might know. :-P
[15:07] <OvenWerks> Are you writing in c or c++
[15:09] <OvenWerks> in c++ generally client.midi_event_get() for example
[15:09] <OvenWerks> leave the client param out
[15:09] <BrianHechinger[m> I was just doing plain C
[15:10] <BrianHechinger[m> started with the simple_client.c
[15:10] <BrianHechinger[m> which builds and runs
[15:10] <BrianHechinger[m> but I don't want to touch audio, I want to capture midi events
[15:11] <OvenWerks> You can look at https://github.com/ovenwerks/studio-controls
[15:11] <BrianHechinger[m> go-jack has a bug that makes it useless. I was kinda looking at python which I didn't want to do but it's just a wrapper around the c libraries (as everything seems to be)
[15:11] <OvenWerks> sorry wrong link.
[15:11] <BrianHechinger[m> so I just went for C
[15:11] <OvenWerks> https://github.com/ovenwerks/midikb
[15:12] <OvenWerks> https://github.com/ovenwerks/midikb/blob/master/jack.c has the jack stuff
[15:12] <BrianHechinger[m> yeah, like the docs totally fail to mention midiport.h which I'm assuming is super important here. :-D
[15:13] <OvenWerks> yeah...
[15:13] <BrianHechinger[m> oh, and look at that, they all light up in the IDE all happy now
[15:15] <OvenWerks> BrianHechinger[m: in general the jack api is easier to use than ALSA
[15:15] <BrianHechinger[m> it seems simple enough, they just leave out some very important details in the docs
[15:16] <OvenWerks> some of us are not very good at writing docs :)
[15:16] <BrianHechinger[m> I'm one of us
[15:16] <BrianHechinger[m> :-D
[15:17] <BrianHechinger[m> but that seems like a pretty egregious oversight.
[15:19] <OvenWerks> The examples are supposed to help :)
[15:19] <OvenWerks> Thats where I started
[15:22] <OvenWerks> midikbd was my first jack program (forked from actkbd)
[16:23] <BrianHechinger[m> So i'm capturing the midi event: `printf("buf: %s\n", midi_event.buffer);`
[16:23] <BrianHechinger[m> But I get `SuspendRefNum error` as my string.
[16:25] <OvenWerks> why would you expect a string? I guess midi is char.
[16:29] <BrianHechinger[m> buffer is an unsigned char pointer, so %s is appropriate
[16:29] <OvenWerks> yes but may not be readable.
[16:30] <BrianHechinger[m> but it's literally this string: `SuspendRefNum error`
[16:31] <OvenWerks> Which seems wrong you should have a 3 byte string
[16:31] <OvenWerks>  (maybe two for a PC)
[16:32] <OvenWerks> Maybe not initialized?
[16:33] <BrianHechinger[m> ok, but what is `SuspendRefNum error` and where is it coming from?
[16:34] <OvenWerks> I don't know
[16:35] <OvenWerks> I just know I have to open a client, set the process call back (where I read MIDI), create a port in the right direction and then activate the client
[16:35] <BrianHechinger[m> I've done all that, now I'm trying to process the events
[16:36] <BrianHechinger[m> oh wait
[16:36] <BrianHechinger[m> I've forgotten to call jack_midi_event_get
[16:38] <BrianHechinger[m> THAT'S better. :)
[16:38] <BrianHechinger[m> ok, now how do I match those to what I see in Ardour's MIDI Tracer?
[16:38] <OvenWerks> Before actually using this, remove all printf statements as they are not rt safe
[16:39] <BrianHechinger[m> ok, good to know
[16:40] <OvenWerks> if you want to print out midi values, stuuf the events (raw) into a jack ring buffer and read out opf that buffer in another thread (like your main thread)
[16:40] <OvenWerks> other wise you risk xruns
[16:41] <BrianHechinger[m> what if I want to trigger other actions? same thing?
[16:41] <OvenWerks> as long as your ring buffer is big enough to keep up with traffic it will not cause xruns
[16:41] <OvenWerks> it depends on how much code goes into that
[16:42] <BrianHechinger[m> it's not going to be a ton
[16:42] <BrianHechinger[m> just find a process and send it a signal
[16:42] <OvenWerks> if you are taking midi in and coverting it and directly putting MIDI out from that it is ok.
[16:42] <OvenWerks> signals I don't know if they are blocking or not. anything blocking is not RT safe
[16:44] <BrianHechinger[m> they shouldn't be but I'd have to check to be sure
[16:44] <OvenWerks> The guys in #lad probably know better off the top of their head
[16:44] <OvenWerks> This is a _very_ quite channel
[16:53] <OvenWerks> Anyway, my policy for my own work, is to as little as possible in any jack call back. Drop values into a ring buffer or pick up processed from a ring buffer. Then I don't have to worry about any calls I make being non-rt
[16:55] <OvenWerks> Also note that most jack call backs can not make a jack call from within the call back. Set a flag or ring buffer and do it from another thread.
[16:56] <BrianHechinger[m> ok, all good things to know. Thanks!
[17:32] <BrianHechinger[m> Thanks for the #lad tip, got it all sorted!
[17:33]  * BrianHechinger[m  < https://matrix.org/_matrix/media/r0/download/matrix.org/MgPJvNRUmJxjcJnZHJapCTEN/message.txt >
[17:33] <BrianHechinger[m> those are the stop and play transport buttons on the nanokontrol. :)
[17:33] <BrianHechinger[m> now to draw the rest of the owl
[18:02] <BrianHechinger[m> IT WORKS MUAHAHAHAHAHAHA
[18:02] <OvenWerks> :)
[18:03] <BrianHechinger[m> I can now pause and unpause Valheim with the stop and play transport buttons. (valheim doesn't actually pause so I SIGSTOP/SIGCONT it)
[18:04] <OvenWerks> Life is a hack ...
[18:15] <BrianHechinger[m> and we're all hackers
[18:29] <BrianHechinger[m> @ove
[18:29] <BrianHechinger[m> klajsdhflkasjdf
[18:29] <BrianHechinger[m> OvenWerks: ok, I'm not fast enough, I'll need to do the buffer/ring thing
[18:30] <BrianHechinger[m> every press of the button causes an xrun
[18:30] <OvenWerks> :)
[18:30] <BrianHechinger[m> although to be fair I don't really care, but I'll probably fix it for the learning aspect.
[18:31] <OvenWerks> both midikbd and mcpdisp use ring buffers, but midikbd is in c while mcpdisp is in c++
[18:32] <OvenWerks> jack ring buffers do not require a jack client and can be set up before creating a client/port/etc.
[18:34] <OvenWerks> I try to set up a buffer about 3 or 4 times what I think. They need to be an even hex value (0x10, 0x100, etc.
[18:39] <OvenWerks> for midi there are a few ways of doing things. I think I pull three bytes per event (just add an extra for 0x0 for PC events), so check ring buffer size is > than 3, pull event, cycle. I do some preliminary filtering in the jack call back to eliminate events I am not interested in like running status
[18:46] <OvenWerks> Another way is to put event length as 1 byte, followed by that number of bytes. At the other end check length is more than 0, pull one byte, check length > length, pull those bytes. This will take care of all kinds of events. You do have to have a way of saving length if the evnt has not made it into the buffer (actually this should never happen I think)
[18:47] <OvenWerks> But if all you need is 3 byte events... it's easy. I guess you could pull one byte at a time and do all parsing after the ring buffer.
[22:26] <BrianHechinger[m> Yeah, I filter out the events I want (only two)
[22:26] <BrianHechinger[m> and from there i don't even need to send an event, it can be an arbitrary payload.
[22:27] <BrianHechinger[m> I just need to signal one of two things. I could do it with a single bit. :-D