[10:48] <zequence> -controls upload will have to wait until after Beta1. Too much not finished yet
[11:25] <zequence> I haven't checked what changes Xubuntu has done in the last couple of months, so our seeds probably need to be updated
[11:27] <zequence> Just did, and seems fine. No changes this year at all
[11:28] <zequence> No changes to our seeds either, as it seems
[13:07] <flocculant> zequence: your mail says "I requested a rebuild of the ISO,..." queuebot says "Ubuntu Studio DVD amd64 [Xenial Beta 1] has been disabled" and the tracker agrees - no studio on beta testing tracker
[13:15] <zequence> flocculant: I tried reversing that to no effect
[13:15] <zequence> A little weird with two options, and two buttons for making them
[13:16] <zequence> YOu saying a build request was never made?
[13:16] <zequence> No, wait
[13:17] <zequence> Ok, I forgot to select them again
[13:18] <zequence> Well, they are enabled for testing again, so I hope the build request got through this time
[13:18] <zequence> Ah, yes, seems good
[13:18] <zequence> flocculant: Thanks
[14:44] <zequence> OvenWerks: Did you find anything new with qjackctl?
[16:14] <OvenWerks> zequence: still bad? no nothing new.
[16:18] <flocculant> zequence: just to keep you updated - you'll be wanting a rebuild again later :p
[16:36] <OvenWerks> qt4-doc is rather large...
[16:43] <OvenWerks> zequence: qjackctl built with qt4 works on 1604
[16:44] <OvenWerks> That is version 0.4.1 dl from Sourcefarge
[16:45] <OvenWerks> zequence: I will try building for qt5 to see if that is _the_difference between working/not
[16:56] <OvenWerks> apparently qjackctl's config doesn't check for everything.
[16:58] <OvenWerks> zequence: building qjackctl in QT5 from devs source also fails.
[17:00] <sakrecoer_> i thought i had a grip of jack, but the recent talk about it i can only assume i'm slightly grasping some fluffy ideas of what is going on..
[17:03] <OvenWerks> sakrecoer_: what is confusing you? The internals do not need to be understood to use jack
[17:04] <sakrecoer_> this jack and jack2 vs ardour thing..
[17:05] <sakrecoer_> jack is basicaly the term used to say "jackd" or "jackd2" ?
[17:05] <OvenWerks> jack1 vs jack2 is the thing really. There was a bad version of jack2 that was making "freerun" not work right.
[17:06] <sakrecoer_> and we ship the bad version of jack2?
[17:07] <sakrecoer_> which ironicaly seem to be version 1.9.10 :D
[17:07] <OvenWerks> jack or jackd does not mean anything but what is currently installed. to be specific one must use jack1 or jack2 ... to confuse things jack1 actually has a version number below 1 and jack2 is currently version 1.9.10  :)
[17:07] <OvenWerks> From Ralphs last comment that is fixed.
[17:08] <OvenWerks> debian by default ships the highest version of a program... so jack2. But really jack1 and jack2 are parallel. they should be jackd and jackdmp
[17:09] <OvenWerks> jackd1 is single thread, single core. Jackd2 can use more than one core unless in syncronus mode.
[17:11] <sakrecoer_> jack1 is jackd, and jack2 is jackdmp?
[17:12] <sakrecoer_> so 14.04 comes with jack1? i can't find any jackdmp, but maybe i'm looking in the wrong places..
[17:14] <OvenWerks> 14.04 comes with jackd2 which is jackdmp
[17:14] <OvenWerks> What I am saying is that the use of 1 and 2 has led to much confusion :)
[17:14] <sakrecoer_> OvenWerks: ok... but the command is still named jackd?
[17:15] <sakrecoer_> i find no jackdmp command..
[17:15] <OvenWerks> yes.
[17:16] <sakrecoer_> haha :) that is the most confusing name and versioning story i've ever heard.
[17:17] <sakrecoer_> now i see, jackd -V gives me "jackdmp 1.9.10" :D
[17:17] <OvenWerks> for our purposes jack2 is nice because it comes with jackdbus (yes you will find that one) which allows easy use of pulseaudio and jack together.
[17:18] <sakrecoer_> but is jack1 still being developped?
[17:18] <OvenWerks> there is a patch for jack1 that makes it work with dbus, but it is not in the repo
[17:18] <OvenWerks> jack1 is still being developed and in some ways is ahead of jack2
[17:19] <sakrecoer_> hahahaha?!?!?! i'm dying a little bit from laughing :D
[17:19] <OvenWerks> https://github.com/jackaudio/jackaudio.github.com/wiki/Q_difference_jack1_jack2
[17:20] <sakrecoer_> reminds me of photography, where large shutter is small number, large exposure number is short exposure etc etc...
[17:20] <OvenWerks> sakrecoer_: it is possible to install jack1 on ubuntu, but it would try to remove much sw that (mistakenly) depends on jack2
[17:20] <sakrecoer_> but we are better off with jack2 anyways aren't we?
[17:21] <OvenWerks> sakrecoer_: same as wire size or sheet metal gauge
[17:21] <OvenWerks> sakrecoer_: I think so, but that is my opinion. There are a lot of people who use jack1.
[17:24] <OvenWerks> jack2 is also still being developed. If jack had been properly, fully developed from the start, it may have been what pulseaudio is today, but better :) but the developers were not that interested in desktop audio and so did not work at that.
[17:25] <OvenWerks> I have found that using jack as the "device" for pulse works very well and causes me less trouble than either jackd or pulse alone.
[17:26] <OvenWerks> The pa-jack mix is stable enough that I use it on my wife's computer as default.
[17:26] <sakrecoer_> well, so far i've always been happy with the jack installed in ubuntustudio, without having a truly conscient opinion, i must agree. it's super easy to connect the pulse stuff to jack stuff..
[17:35] <OvenWerks> zequence: there does not seem to be a launchpad code page for qjackctl for X. W is the last one and the depends are already qt4.
[17:38] <OvenWerks> zequence: http://stackoverflow.com/questions/25314391/system-tray-icon-doesnt-show-in-qt5-linux-lxde it seems the bug is well known with qt5
[17:44] <OvenWerks> It may be that the qt5 version ubuntu has needs upgrading too. but I am not familiar enough with qt to know. The qt4 libs are still available in 1604 so the best thing to do is build qjackctl that way.
[18:04] <OvenWerks> qt5.5 is supposed to fix things :P
[19:01] <zequence> OvenWerks: To get the source for any package in the development version, you can use the tool pull-lp-source
[19:01] <zequence> You get it with ubuntu-dev-tools, I believe
[19:02] <zequence> So, for qjackctl, it would be: pull-lp-source qjackctl
[19:02] <OvenWerks> *.deb src files make no sense to me. /debian/rules needs to be changed, but I am not sure from looking at that if I can just change the 2 qt5s to qt4 and change the depends to qt4 versions if that would work.
[19:02] <zequence> If not the latest development version: pull-lp-source qjackctl trusty
[19:02] <zequence> OvenWerks: Should be a config change
[19:02] <OvenWerks> zequence: I tried the latest version and it works with qt4
[19:03] <OvenWerks> zequence: There is no config option that makes sense to me.
[19:03] <OvenWerks> I do not see where ./configure might be run.
[19:03] <zequence> OvenWerks: best thing is probably to get the git branch from debian
[19:04] <zequence> ..and see what the diff is between the two revisions where that was changed
[19:04] <zequence> Let me find it..
[19:04] <OvenWerks> It appears that the ./configure step is skipped and the source is pre configured as shipped.
[19:05] <zequence> Maybe a config override in debian/rules was removed with the last update
[19:06] <OvenWerks> zequence: qjackctl 0.4.1 configured qt4 by default (though qt5 versions could be built) and 0.4.2 seems to default to qt5.
[19:06] <zequence> OvenWerks: git clone https://anonscm.debian.org/git/pkg-multimedia/qjackctl.git
[19:06] <zequence> One of the commits will be about the move to qt
[19:07] <zequence> I'm sure you know this, but I say it anyway. To check the diff, find the commit sum, and do: git show <sum>
[19:07] <zequence> Should show you only the changes done in that commit
[19:08] <OvenWerks> zequence: actually much easier than that, go to the above git page as a web page and just click on the commit.
[19:08] <zequence> Well, if you want to do it in the web, sure
[19:10] <zequence> Seems like the rules thing was one line changed and two added, and of course, build dependencies changed
[19:10] <OvenWerks> Sorry 0.4.0 to 0.4.1
[19:10] <zequence> If we want to fix the ubuntu package, by reverting to qt4, we should do the same thing, but make it a debian patch
[19:11] <zequence> Once the qt5 bug is fixed, we can just remove the debian patch
[19:11] <zequence> Is qt5 update in the works?
[19:11] <zequence> Seemed like the Kubuntu folks are going to do some uploads shortly
[19:11] <OvenWerks> zequence: I suspect a direct reversal of that patch may fail. But I can try.
[19:12] <zequence> OvenWerks: No, it needs to be done manually, and made into a patch
[19:12] <zequence> I need to find out what the best way is to create a patch today. I used a tool before, which is not working anymore
[19:12] <zequence> But, question is, how long will we need the fix, also
[19:13] <zequence> We could hang back for a little while, and fix it later, if needed
[19:13] <zequence> Or, do it now, and whoever does it gets to learn how to do Debian patches in the modern way
[19:13] <OvenWerks> zequence: the switch to qt4 could stay in 1604 with no problem as there are other programs that need qt4
[19:15] <OvenWerks> zequence: probably the easiest way is to branch the ubuntu version make changes upload to my branch... create a merge request.
[19:16] <zequence> OvenWerks: If you want, but it needs to be a debian patch. You can't just make changes to the code. That won't work
[19:16] <zequence> So, it can't just be a bzr commit. That's not enough
[19:16] <zequence> The patch needs to be documented according to debian patch format
[19:19] <zequence> OvenWerks: I did that for jackd and pulseaudio for 12.04, and things have changed a bit since
[19:19] <OvenWerks> hmm there doesn't seem to be a branch to play with anyway.
[19:19] <zequence> I would check Ubuntu Packaging docs, Ubuntu wiki, and most importantly, Debian wiki for information
[19:19] <zequence> Oh, there is
[19:20] <zequence> But, it's not a stable release. I don't remember the difference
[19:24] <zequence> Don't know if someone messed up the project of qjacktl somehow in LP
[19:24] <zequence> I can't find the bzr branch, no
[19:26] <zequence> Anyway, it needs to be a debian patch. One can get the current source with pull-lp-source
[19:27] <zequence> Then, make it a bzr branch, add the one commit with the debian patch, and push it to a branch
[19:27] <zequence> Then, poke someone to get it, check it, and upload it
[19:27] <zequence> A debdiff could probably work too.
[19:27] <zequence> But, that would be done without bzr
[19:28] <zequence> The bzr branch can be linked to the bug report
[19:29] <zequence> btw, might be a good idea to do the fix in Debian directly, come to think of it
[19:29] <zequence> Since I think it will continue to be a problem for them even after release
[19:29] <zequence> I could look into that
[19:29] <zequence> That way, all we need to do is a sync request
[19:32] <zequence> New ISOs just got built, but not published yet
[19:56] <OvenWerks> An upgrade shows no new qt stuff though.
[19:57] <OvenWerks> (new kernel though)
[20:06] <OvenWerks> zequence: we have both xchat and pidgin. Do we want that? Pidgin comes from xubuntu?
[20:26] <flocculant> OvenWerks: would you not be better with hexchat instead of xchat - one is maintained - afaik xchat is moribund
[20:27] <OvenWerks> but works. If we have pidgin do we need something else?
[20:27] <flocculant> we don't
[20:28] <flocculant> haven't for a couple of cycles iirc
[21:24] <zequence> New ISOs out
[21:25] <zequence> flocculant: Have you made changes to those yourselves?
[21:25] <flocculant> to the iso's?
[21:26] <zequence> No, pidgin and xchat
[21:26] <zequence> Maybe I have the wrong branch, but it seems like there have been no changes since November
[21:27] <zequence> Just confirmed on LP. Think I synced ours with yours after that
[21:28] <OvenWerks> zequence: my wife's version of xubuntu 16.04 has no xchat.
[21:28] <zequence> OvenWerks: Did you install your Studio recently?
[21:28] <zequence> My sync happened 2 days after the last change in xubuntu
[21:29] <OvenWerks> InstallationDate: Installed on 2015-11-19 (89 days ago)
[21:30] <zequence> The sync happened Nov 28th
[21:30] <OvenWerks> so it has been a while, I have kept it upgraded, but that doesn't remove cruft.
[21:30] <zequence> So, you probably have the olds stuff
[21:30] <zequence> YEah
[21:31] <OvenWerks> After I figure out this qjackctl stuff I will probably reinstall anyway.
[21:31] <OvenWerks> That way I can do an install test and live test.
[21:31] <flocculant> zequence: we seed pidgin - we stopped seeding xchat a couple of cycles ago
[21:32] <zequence> flocculant: Ok. Len probably has his from an older install, so we shouldn't have it anymore
[21:32] <OvenWerks> zequence: I do have a working (from ubuntu source) qjackctl. I had to patch the configure file as well.
[21:32] <zequence> OvenWerks: That btw might require another look at our irc shortcut. I haven't tested that for a couple of years at least
[21:33] <zequence> OvenWerks: The config file doesn't have a qt4 option anymore?
[21:34] <zequence> OvenWerks: the shortcut opens xchat, but we aren't shipping it anymore
[21:34] <OvenWerks> I don't know how to write that into the debian/rules file.
[21:34] <zequence> The git diff should give you a clue
[21:35] <OvenWerks> no, configure was changed from 0.4.0 to 0.4.1 to default to qt5
[21:35] <zequence> default to, yes, but there's still an option for qt4, right?
[21:35] <OvenWerks> So it defaults to qt5 now
[21:36] <zequence> And, in the Debian package, the config options was changed in the rules file, not anywhere else
[21:36] <OvenWerks> --enableqt4 I think
[21:36] <OvenWerks> no but it was changed in the source from sourceforge
[21:37] <zequence> Sure, but not in the Debian package. For us, the correct way to do things is through Debian packaging
[21:38] <OvenWerks> right, but not sure what rules uses for stuff to feed ./configure
[21:39] <zequence> It just supplies an env var for where the qt stuff is located
[21:39] <zequence> export QTDIR=/usr/share/qt4
[21:40] <zequence> Not your standard lib dir, but perhaps there's something more to it. I don't know qt
[21:41] <zequence> Could be that commit only made the packagin work after upstream changes. Going to check
[21:41] <OvenWerks> zequence: I changed those first, but when building it runs configure and configure says qt5 unless told other wise
[21:42] <zequence> Ok, so the packager only followed upstream in this case
[21:42] <zequence> http://anonscm.debian.org/cgit/pkg-multimedia/qjackctl.git/commit/?id=88e3ed9c8c59a072369938688bcdde2dd81aa9ed
[21:42] <zequence> That's the latest sync with upstream
[21:43] <zequence> Here is the diff to the config file http://anonscm.debian.org/cgit/pkg-multimedia/qjackctl.git/diff/configure?id=88e3ed9c8c59a072369938688bcdde2dd81aa9ed
[21:43] <zequence> And, that is where default was changed
[21:43] <zequence> A config override is possible from debian/rules
[21:44] <zequence> So, that is where it should be done
[21:44] <OvenWerks> zequence: yes you can see ac_qt4= has been change from yes to no. I just reverted those two lines back
[21:45] <zequence> Something like..
[21:45] <zequence> override_dh_auto_configure: dh_auto_configure -- --prefix=/opt/uruk
[21:45] <OvenWerks> but if I can get rules or whatever rules reads to give configure --enableqt4 that would work too.
[21:47] <zequence> Adding this could work http://paste.ubuntu.com/15191146/
[21:47] <zequence> I haven't muched messed with it, but there's the clue anyway. debhelper
[21:48] <zequence> Going to bed. Just getting the latest ISO, and will start testing early in the morning.
[21:48] <zequence> gn all
[21:48] <OvenWerks> gn
[23:37] <OvenWerks> zequence: I can't get override_dh_auto_configure: to work. It seems in order for that to work one has to first have dh $@ on a line above... but if I do that the whole build fails for lots of other missing stuff.
[23:39] <OvenWerks> quite honestly, this rules file is what has kept me from packaging some other packages. It expects all packages to be built in a certain way... if not the ways of getting around things are non-obvious/non-trivial
[23:41] <OvenWerks> none of the documentation seems to say that to use this you must have that... or this comes first, this comes last and this in the middle.