[00:16] <DaskreecH> Hello
[00:16]  * DaskreecH waves at jrib
[00:16] <DaskreecH> Can someone look at a package issue?
[00:17] <jrib> ola
[00:18] <DaskreecH> in ibex there is a conflict with the xserver-xorg-video-unichrome driver and xserver-xorg-core
[00:21] <DaskreecH> The unichrome package depends on a -core package 1.1.1 or greater
[00:21] <DaskreecH> 1.5.1 is installed but the unichrome blanks out and refuses to install
[01:10] <DaskreecH> I be back
[03:21] <RAOF> james_w: You gnome-power-manager rock!
[04:44] <StevenK> ajmitch: It looks like pnetc should be killed since pnet-assemblies is gone
[04:46] <ajmitch> StevenK: yes, the whole set should have been removed
[04:47] <ajmitch> all a nice mess of interdependent packages which has a barely active upstream
[04:47] <StevenK> ajmitch: Could you be bugged to see what's left?
[04:47] <ajmitch> I could
[04:48]  * ajmitch suspects it'll just be pnetc left
[04:49] <StevenK> If it's just pnetc, I'll bin it nowish
[04:49] <ajmitch> yep, just that one
[04:53] <StevenK> ajmitch: Killed.
[04:53]  * ajmitch cheers
[06:00] <jml> is there a way I can list all packages I've installed from a particular archive?
[06:02] <Burgundavia> jml: possibly with a custom search in synaptic
[06:02] <lifeless> jml: no
[06:02] <lifeless> jml: because a package version may have multiple archives as sources
[06:03] <lifeless> jml: but you can figure out the packages which might be from there :P
[06:03] <jml> lifeless: yeah, well..
[06:03] <jml> lifeless: my real question is "why is doko's ppa in my sources.list?"
[06:11] <dholbach> good morning
[06:13] <ajmitch> hi
[06:15] <dholbach> hi ajmitch
[06:22] <Burgundavia> jml: one way to figure out is to look at the locally installed packages list in synaptic, then remove dokos ppa, then reload and look at that list
[06:22] <Burgundavia> anything new is from that ppa
[07:17] <viviersf> hi ajmitch :-) long time ...
[07:18] <didrocks> morning
[07:19] <ajmitch> hi viviersf
[07:22] <viviersf> how you doing ajmitch ?
[07:22] <ajmitch> good, busy, how are you?
[07:25] <viviersf> ajmitch, good, busy hehe, no longer working for impilinux
[07:26] <ajmitch> what are you doing now?
[07:27] <viviersf> ajmitch, same old, but working for siemens now
[07:27] <ajmitch> ah nice
[07:27] <viviersf> jip
[07:27] <viviersf> you still at same place ?
[07:28] <ajmitch> yeah
[07:29] <viviersf> ah okies
[07:29] <ajmitch> still planning to do MOTU stuff? :)
[07:39] <viviersf> ajmitch, yeah, im just trying to get my life in order, as soon as i get rid of one fire, another one starts elsewhere
[07:40] <ajmitch> that's no fun
[07:42] <viviersf> ajmitch, yeah i know, as soon as i can get internet at home again, ill start doing some stuff for motu
[08:28] <persia> Anyone familiar with mongrel about?
[08:43] <stefanlsd> Does anyone have an idea why i get this - http://pastebin.ubuntu.com/57333/.  Essentially with debuild -S -sa - configure: error: Cannot find Ncurses (-ncurses). please check out your system setup.
[08:44] <persia> stefanlsd, Could you paste the offending debian/rules?
[08:45] <stefanlsd> persia: http://pastebin.ubuntu.com/57335/ (thats the whole rules file) - this package is a direct sync from debian, and I havent changed anything yet.
[08:49] <persia> stefanlsd, You've run into a package that is annoying.  apt-get build-dep sabre before building source.  It's not too hard to fix it, but I'm not going to fix it before Lenny releases.
[08:50] <persia> (and I don't suspect anyone else on the Games team will either)
[08:51] <stefanlsd> persia: kk. so essentially i'm missing some build dep on my system that it requires
[08:52] <persia> stefanlsd, Right.  If you look at the rules file, you'll notice that clean depends on stamp-configure, so it's running the ./configure during clean, and then deleting the results.
[08:53] <persia> Exactly why is does this would require someone to dig through SVN history and see who made it do that, and which bug they were fixing.
[08:54] <persia> Personally, I don't think it's worth doing that until Lenny is released, because of the chance that some RC bug might appear.
[08:55] <persia> And I don't think it's worth Ubuntu delta (especially for a package maintained by a team comprised of people from both Debian and Ubuntu) to fix it locally, as it's easy enough to work around.
[09:06] <stefanlsd> persia: and just to make sure i get it - normally a debuild doesnt (or shouldnt) call a configure, that should happen when i use pbuilder and it will download build deps
[09:07] <persia> stefanlsd, In my opinion, a clean rule should limit itself, as much as possible, to build-essential.  Mind you, that's not always sufficient.
[09:08] <persia> Calling ./configure just seems plain wrong, as it forces that the ./configure happens to the current system, which is unlikely to be pristine.  Mind you, in this case, it cleans up after itself : I suspect it's part of making the patches work cleanly.
[09:08] <stefanlsd> (or have the build deps installed)
[09:09] <stefanlsd> ok. will just install the build deps for it, thanks for the info. im attempting to backport a security fix into the earlier version. (hence playing with silly games)   :)
[09:10] <persia> Policy doesn't provide any guidelines, and expects all the build-dependencies to be installed on the developer machine, as a side effect of standard Debian practice, so it's a minor point.
[09:11] <persia> Oh, yeah, backporting a security fix means that even if this was fixed, you couldn't take advantage of the fix :)
[09:30] <persia> stefanlsd, Hrm.  Seems there's a sabre upload pending in Debian : anything that ought get there now?
[09:32] <stefanlsd> persia: mm. its already fixed in the latest version 0.2.4-25.  i was just fixing the other releases.
[09:32] <persia> stefanlsd, OK.  I just saw a sponsorship request, and wanted to reduce your merge later if that would help.  Thanks for the confirmation that there's nothing to do there.
[09:33] <huats> hello everyone !
[10:52] <Koon> dholbach: are there any tentative dates for the next OpenWeek ?
[10:53] <dholbach> Koon: I'll ask jono about it
[10:53] <Koon> dholbach: thx
[10:53] <dholbach> Koon: nothing announced yet
[11:05] <james_w> ogra: Neil has netbook-launcher, window-picker-applet, maximus and go-home-applet for Intrepid, do I have your permission to push them tonight?
[11:06] <james_w> ogra: I haven't reviewed them yet
[11:06] <ogra> yep, saw the conversation :)
[11:06] <ogra> feel free to upload at will, i might need FFe bugs if you have new upstreams though
[11:06] <james_w> ok, I'll document what I do
[11:08] <james_w> he's working on a fix for the fact that you can't shutdown UNR, it will be quite a big change, it will hopefully be ready this week, how do you feel about that?
[11:10] <ogra> as long as it doesnt introduce regressions i'm fine
[11:11] <ogra> james_w, we all suffer from that late fusa change it seems, i feel the pain as i have the same probs with ltsp
[11:12] <james_w> oh, this isn't a fusa change, it's a long-standing gnome-session change
[11:12] <james_w> at least it's possible to shut it down now via log out + gdm, for a while you couldn't even do that
[11:41] <james_w> lfaraone: hey, did you file that bug report?
[12:43] <AnAnt> superm1: Hello
[12:43] <AnAnt> superm1: I added dkms support to sl-modem, but it only builds one module, but not the other, and make.log has no useful info
[12:44] <AnAnt> superm1: no CC lines in it
[13:15] <lfaraone> james_w: er, sorry, I didn't have any time last night.
[13:15] <james_w> that's ok
[13:29] <lfaraone> james_w: morgs reported bug 283194, I'll mark it as also affecting the other packages.
[13:29] <james_w> lfaraone: and subscribe me please
[13:30] <lfaraone> james_w: subscribed
[13:30] <james_w> thanks
[13:33] <lfaraone> james_w: btw, it looks like /usr/share/activities was the directory that we used in hardy.
[13:33] <lfaraone> james_w: (which was incorrect)
[13:34] <lfaraone> james_w: so I think this affects all the sugar activity packages, since not even the locally-packaged-activities show up. will test, however (later today)
[13:34] <james_w> thanks
[13:35] <james_w> lfaraone: if you could drop a note in the bug explaining what to change in the source package to fix this that would speed things up for me as well
[13:37] <james_w> lfaraone: if I run sugar emulator and choose shutdown from within will that just close Xephyr, or shutdown my machine?
[13:37] <lfaraone> james_w: it will just close xephyr.
[13:37] <james_w> cool
[13:37] <lfaraone> james_w: (iirc)
[13:37] <lfaraone> james_w: a bug has been filed upstream to add a "log out" option. http://dev.laptop.org/ticket/8815
[13:38] <james_w> it apparently does neither
[13:39] <morgs> james_w: lfaraone: patch attached to bug 283194 - I'm not sure how best to apply it - in debian/patches ?
[13:40] <james_w> ah, it already has a list of places to look for activities?
[13:40] <james_w> that's probably even better
[13:40] <james_w> oh, and hey morgs
[13:40] <morgs> hey james_w
[13:40] <morgs> yes, it already has a few alternatives
[13:40] <james_w> yeah, I think doing that would be more appropriate
[13:41] <james_w> that searches /usr/share/sugar/activities/ first I guess?
[13:42] <lfaraone> morgs: that's actually really good.
[13:42] <morgs> james_w: yeah
[13:42] <lfaraone> morgs: so next cycle we can actually fix them to go in the "proper" dir, right?
[13:42] <morgs> yes :)
[13:42] <lfaraone> morgs: (cause I _just_ found the part of the package that we'd need to fix in sugar-*-activities
[13:42] <james_w> heh :-)
[13:42] <morgs> if only we had more time :)
[13:43] <lfaraone> (line 64 in debian/cdbs/1/class/python-sugar.mk on the imported debian packages)
[13:43] <james_w> the Debian maintainer already plans to fix the Debian packages at some point?
[13:43] <lfaraone> james_w: idk if he even knows the problem.
[13:43] <morgs> Yes, although he's not facing imminent release...
[13:43] <james_w> I thought he was the one that told you about it
[13:44] <james_w> yeah, not bothered about pulling the fixed packages at this point, we can just get it fixed there now, and know it will work for Jaunty
[13:45] <morgs> debian maintainer said to me "For quite some time I could only make my own test setup work by adding a symlink from ~/.Activities to /usr/share/activities. Just tested with a symlink from /usr/share/sugar/activities and indeed it works. Super. Thanks a lot for this hint!!"
[13:45] <james_w> morgs: works for me :-)
[13:45] <james_w> I'll upload a fixed sugar package in a moment
[13:45] <morgs> james_w: thanks!
[13:46] <lfaraone> james_w: wonderful. I'll mark all the packages I filed it against as invalid (since I just attached all the other activities to that bug)
[13:46] <lfaraone> s/invalid/wontfix/
[13:47] <james_w> lfaraone: just mark them Invalid I think, it will be fixed next cycle, but keeping them open just creates more work then
[13:47] <james_w> I can do it if you like
[13:48] <lfaraone> james_w: wont-fix has the same meaning as invalid for the most part, exept it awknoledges that there was a problem there.
[13:48] <lfaraone> (if I'm correct)
[13:48] <james_w> yeah
[13:49] <james_w> though we do plan to fix it
[13:49] <james_w> doesn't really matter though
[13:51] <persia> morgs, james_w: be careful about just adding a symlink to the package : consider the upgrade case, and users who may have activities in the wrong location.
[13:52] <james_w> yeah, we're not symlinking
[13:52] <persia> Ah.  I wasn't sure from backscroll.  Extending the search list sounds excellent :)
[13:52] <james_w> we're extending the search path to look in the location where they currently live. Once they are fixed we will drop the patch
[13:53] <james_w> yeah, symlink was ruled out the other day, I didn't realise there was a search path we could extend.
[13:58]  * lfaraone gives morgs a cookie.
[13:58]  * morgs nom nom nom
[13:58]  * directhex pokes RAOF viciously for passing bug onto him
[13:59] <lfaraone> morgs: botsnack.
[13:59] <morgs> heh
[14:01] <james_w> nice, journal shows up as well now
[14:02] <sistpoty|work> hi folks
[14:02] <james_w> hey sistpoty|work
[14:02] <sistpoty|work> hi james_w
[14:06] <lfaraone> james_w: wonderfuk.
[14:06] <lfaraone> *wonderufl
[14:17] <sebner> hihu sistpoty|work :)
[14:17] <sistpoty|work> hi sebner
[14:20] <Riddell> didrocks: ping
[14:20] <Riddell> swfdec0.8?  does that mean gstreamer and whatever need to have a last minute transition?
[14:21] <Riddell> hmm, gstreamer doesn't seem to be in the rdepends of current swfdec
[14:27] <didrocks> Riddell: pong
[14:27] <didrocks> Riddell: swfdec-gnome and swfdec-mozilla are on the road
[14:27] <Riddell> didrocks: on the road to arrive before freeze in two days?
[14:28] <Riddell> didrocks: do you know if .swf files are preferred modifiable form?
[14:28] <didrocks> Riddell: swfdec-gnome is already done and wait for sponsoring
[14:28] <didrocks> swfdec-mozilla need just some checking
[14:28] <didrocks> and will be ok for tomorrow
[14:28] <didrocks> Riddell: no, I do not know for .swf files about modifiable form
[14:29] <Riddell> they're in swfdec0.7 too so I guess someone has checked they are
[14:29] <Riddell> didrocks: accepted
[14:47] <sistpoty|work> Riddell: I doubt that .swf is the preferred form, but rather the actionscript source
[14:48] <sebner> sistpoty|work: .fla?
[14:48] <sistpoty|work> sebner: no idea what the file ending is, but you can read it with an editor ;)
[14:48] <sebner> sistpoty|work: ah not fla then
[14:49] <directhex> yay, sebner is here
[14:49] <sebner> directhex: \o/
[14:49] <Riddell> sistpoty|work: so you can't modify .swf files?
[14:50] <directhex> sebner, so, who do you reckon i should beat up to sponsor one last mono merge for intrepid, to fix ickle issues like security holes?
[14:50] <sistpoty|work> Riddell: I'm not 100% sure about the whole flash thingy, but I know that you can create .swf from actionscript files
[14:50] <sistpoty|work> Riddell: by compiling them
[14:50] <sebner> directhex: make a dice (paper), write names on it and ROLL it :P
[14:51] <sebner> yep. swf are the binaries
[14:52] <directhex> sebner, let's see, who to put on the dice...
[14:52] <sebner> directhex: hehe, but you don't have that many names though ^^
[14:53] <directhex> sebner, slomo would do it if he wasn't already working a 86 hour day. pitti i could probably bribe, but his TODO is about 41GiB big...
[14:53] <sebner> directhex: so.. who remains :)
[14:53] <sistpoty|work> sebner: as far as I've read it right now, .fla seems to be a project file (which I assume to contain the individual action script files then?)
[14:54] <directhex> sebner, dunno. reckon Hobbsee is bribeable?
[14:54] <directhex> sistpoty|work, .ACTIONSCRIPT, would you believe?
[14:54] <sebner> sistpoty|work: yep, /me had to work with that in school
[14:55] <sebner> directhex: try it ^^
[14:55] <directhex> wait, wikipaedo says ".as"
[14:56] <sistpoty|work> ah, right
[14:58] <sebner> sistpoty|work: but you can also produce swf files without any actionscript. you can make animations with klicki klicki ^^
[14:58] <directhex> sebner, isn't there some list of who's meant to sponsor things on a given day of the week? i can't find it
[14:59] <sistpoty|work> sebner: but can you also open a .swf file and change the animation with klick klick again? Or do you need the project file then?
[14:59] <sebner> directhex: never heard of it
[14:59] <sistpoty|work> s/klick klick/klicki klicki/ :P
[14:59] <sebner> sistpoty|work: hrhr, dunno but afaik the swf is the binary so unchangeable and you need the project file
[15:00] <directhex> plenty of people modify SWF files
[15:00] <directhex> just think of all those modified versions of flash games out there
[15:00] <sistpoty|work> sebner: ah, that's what I assumed then
[15:13] <persia> directhex, There's a list of who is archive admin per day of week, but not who is sponsor (most days there are many sponsors)
[15:14] <directhex> persia, ah, hence my confusion.
[15:26] <lfaraone> If a package uses Gconf and keys need to be changed from upstream default to work with ubuntu (like settinga  key from true to false), how would I go about that in a postinstall script?
[15:37] <lfaraone> How hard is it to get a SRU for packages that are unusable durning a releasae?
[15:38] <persia> lfaraone, Not hard.  Falls under the "Doesn't even work" rule.
[15:38] <lfaraone> (like, if there's a critical bug in foopackage (in univ.) and it isn't fixed by releaaseday)
[15:38] <lfaraone> persia: kk.
[15:38] <lfaraone> persia: what if the fix requires a new upstream version? (that adds new features etc)
[15:38] <persia> lfaraone, Try not to let that happen :)
[15:38] <persia> That's highly discouraged.
[15:39] <persia> post-release is the strictest freeze we have, and there's a compeltely different (stricter) team that reviews the patches.
[15:46] <persia> lfaraone, Also, for changing gconf schemas, I suspect you might want to start with the dh_gconf manpage (although I may be wrong).
[15:46] <jdong> lfaraone: in the entire history of Ubuntu there have been about two cases of new-upstream-version accepted. I was driving one of them and it took almost a release cycle for me to get that through
[15:47] <jdong> so I agree with the "try not to do that" strategy :)
[15:47] <persia> Anyone from MOTU Release have a bit to look at bug #280829?  Needs a second ACK : it's an update to the KDE 2ch client, without which users cannot post to 2ch.
[15:47] <Riddell> cody-somerville, jdong, TheMuso, \sh: motu-sru love needed on bug 268260
[15:48] <sistpoty|work> persia: confirmed
[15:49] <persia> sistpoty|work, Thanks.
[15:50] <sistpoty|work> jdong: do you happen to be familiar with ogmrip (FFe bug #268063) and have an opinion?
[15:52] <jdong> sistpoty|work: yeah let me take a look
[15:52] <sistpoty|work> thanks jdong
[15:55] <jdong> sistpoty|work: I think it's a good idea; upstream has abandoned the 0.11.x branch and it's basically one of the only ogg theora GUI-friendly encoders we've got
[15:56] <sistpoty|work> jdong: ok, thanks
[15:56] <jdong> sure thing
[15:57] <directhex> so who's a core dev, and in the mood for a nice friendly merge full of security bug closing?
[15:59] <morgs> james_w: bug 283279 has a debdiff for you.
[15:59] <morgs> james_w: fixes bug 283254 and bug 283269
[16:01] <zul> sistpoty|work: ping
[16:01] <sistpoty|work> zul: pong
[16:01] <zul> sistpoty|work: so ec2
[16:02] <zul> sistpoty|work: basically we didnt have these tools before
[16:02] <zul> sistpoty|work: and its actually soren's package as well ;)
[16:03] <james_w> morgs: no need to open a separate bug report for a patch, you can just attach it to one of the bugs :-)
[16:03] <sistpoty|work> zul: ah, heh... but I recall a FFe that had something to do with e2c, right? maybe for vmbuilder? or s.th. different?
[16:03] <morgs> james_w: OK cool :)
[16:03] <james_w> morgs: I'll take a look a little later if that's ok
[16:03] <morgs> james_w: np
[16:04] <zul> sistpoty|work: not that I know of
[16:05] <sistpoty|work> zul: hm... I guess I need to buy a better brain *g*
[16:05] <zul> sistpoty|work: lol
[16:09] <sistpoty|work> grml... lp times out when trying to find the information about the past FFe :(
[16:11] <lfaraone> jdong: what were the cases?
[16:12] <jdong> lfaraone: compiled with the wrong compiler, against libraries with unsupported stubs for critical network calls, heavily patched and repacked sources upstream doesn't support, segfaults with most runtimes, otherwise it starts but is 100x slower and uses 10x more RAM than it should.
[16:12] <jdong> (azureus 2.4.x.x < gutsy)
[16:13] <sistpoty|work> zul: ah, it was ec2-init (bug #269434)
[16:13] <zul> sistpoty|work: ah yeah....I forgot about ec2-init
[16:15] <lfaraone> jdong: wah.
[16:15] <lfaraone> *woah
[16:15] <sistpoty|work> zul: I assume that ec2-ami-tools make that amazon ec2 thingy more complete then?
[16:15] <zul> sistpoty|work: yep
[16:15] <sistpoty|work> zul: +1 from me then
[16:15] <jdong> lfaraone: yeah along the whole way my argument was (1) it's an extremely popular app (2) it can't possibly get any worse than this
[16:16] <jdong> and even then it was difficult to convince. so don't take this route. try to resolve before release if it requires a new version
[16:16] <zul> sistpoty|work: thanks
[16:16] <sistpoty|work> np
[16:17] <lfaraone> jdong: kk. I take it I have until the RC comes out on the 23rd, right?
[16:17] <lfaraone> jdong: (we already have  FFE for new versions)
[16:17] <lfaraone> (on this group of pgks)
[16:17] <lfaraone> pkgs*
[16:18] <jdong> lfaraone: correct
[16:18] <james_w> lfaraone: what's the bug?
[16:21] <lfaraone> james_w: hrm?
[16:21] <lfaraone> james_w: morgs ' bug, or the one I'm talking aobut?
[16:22] <lfaraone> james_w: the latter is jsut the other packages in sugar that havn't been updated
[16:36] <james_w> lfaraone: ah, ok. Why weren't the synced with the rest?
[16:37] <lfaraone> james_w: debian doesn't have them.
[16:37] <lfaraone> james_w: we have more packages than debian.
[16:37] <james_w> lfaraone: ah, ok. Do they not work with the new sugar?
[16:37] <lfaraone> james_w: most don't.
[16:38] <james_w> how many packages are we talking about?
[16:38] <bddebian> Heya gang
[16:41] <lfaraone> james_w: 3 or 4, I think.
[16:41] <lfaraone> james_w: I'll have to do more testing.
[16:42] <james_w> ok, will it just be uploading new versions?
[16:52] <sistpoty|work> hi bddebian
[16:57] <persia> I've an uncertainty about an initscript, and would like some advice.  Specifically, timidity attempts to start/restart a daemon when installed/upgraded.  In some cases, pulseaudio doesn't permit a connection to the soundcard.  This breaks the installation.  It works OK on boot.
[16:58] <persia> The postinst calls invoke-rc.d timidity start || exit $? which means that when it fails, it breaks the package installation.
[16:58] <persia> I am tempted to change this to  invoke-rc.d timidity start || true, but wanted to get another opinion.
[16:58] <bddebian> Hi sys
[16:58] <bddebian> Err sistpoty|work
[16:59] <james_w> persia: I assume there is no way to detect the condition, either before, or when the error happens?
[16:59] <persia> Well, I can tell that timidity couldn't connect.  I suppose I could check for a running pulseaudio, but it's not meaningfully distinct from being blocked by anything else.
[17:00] <persia> On the other hand, most other things don't block the kind of connect timidity makes.  I don't think this would fix the bug, but rather that it might be a good workaround until someone can spend some time with pulse and timidity for jaunty, and make them do the right thng.
[17:02] <james_w> I think it sounds reasonable, but it is out of the ordinary
[17:02] <sistpoty|work> persia: changing the postinst seems correct to me, the only counter-reason I can think of, would be if dependant packages would need a running timidity in their maintainer scripts as well (but then these should get fixed as well imho)
[17:03] <persia> sistpoty|work, None of the dependencies need a running timidity daemon to run, although they may not generate sound if timidity is not running (in which case the user can start timidity).
[17:03] <sistpoty|work> persia: but I guess the init script displays s.th. to let users now that it couldn't be started, right?
[17:03] <persia> The exception is wildmidi, which depends on the timidity configuration, rather than timidity itself, and so should be able to generate sound directly.  As this is the selected MIDI backend for gstreamer, I suspect those using timidity directly are not the common case.
[17:05] <persia> The initscript currently uses log_end_msg 1 to report the issue.  I suppose I could detect the failure, and add a textual note to the postinst, which would be helpful, but still not break installs.
[17:06] <persia> (so invoke-rc.d timidity start || echo timidity failed to start with error $? : please restart timidity or reboot to start the sequencer
[17:12] <persia> sistpoty|work, Does that workaround seem complete to you, or am I missing something more?
[17:14] <sistpoty|work> persia: looks good to me
[17:14] <persia> sistpoty|work, Thanks for the confirmation.  I'll do it that way.
[17:14] <sistpoty|work> np
[17:25] <emh> persia: Magnus (author of xprintidle) has published a new version of xprintidle with my changes at http://www.dtek.chalmers.se/~henoch/text/xprintidle.html. He relicensed it under GPL.
[17:26] <persia> emh, Cool.  Saves the trick of dealing with the licenses.  Next step is to get Milan to confirm it's Lenny-critical, and get it into Debian.
[17:30] <james_w> morgs: hey, you disable the import of abiword.Canvas, but still call it in the code?
[17:30] <james_w> morgs: is that a codepath that can't be reached?
[17:45] <james_w> I've got an issue that should be decided now, I've been putting it off in the hope that we would get a release
[17:46] <james_w> clutter is at 0.8 in the archive, except for pyclutter
[17:46] <persia> james_w, What depends on pyclutter?
[17:46] <james_w> that's not had a release for 0.8, but SVN has been ported
[17:46] <james_w> no rdepends
[17:47] <persia> OK.  Why is it preferable to package it?
[17:47] <james_w> After having a few people test SVN it works for some, and not for others
[17:47] <james_w> so we have a choice of no package or one that only works for some
[17:47] <persia> Personally, I think no package is better, especially at this point in the cycle.
[17:48] <persia> Those very interested can grab SVN, or use the release once it happens.
[17:48] <persia> I've heard a few people talking about using clutter more heavily for Jaunty, so I suspect it would be an early candidate for Jaunty inclusion, and that gives us time to debug it.
[17:48] <james_w> yeah, the arguments would be having good clutter support, but it's not if it's partially broken, and being able to fix it for those it would be broken for
[17:48] <persia> Mind you, I'm not on the release team, so it's just my opinion :)
[17:49] <james_w> I'm leaning towards kicking it, but I've been trying to get us a package for a while
[17:49] <james_w> unfortunately it doesn't get on at all well with my machine, otherwise I would have probably uploaded by now.
[17:49] <persia> Can you wait three more weeks?
[17:50] <james_w> oh, I'm not even going to use it :-)
[17:51] <persia> OK.  Then I *really* don't see the point :)
[17:51] <james_w> I just got involved in the bug and there have been a couple of people trying to make it happen, and I want to lend them a hand if I can
[17:52] <persia> If there aren't any rdepends, and it doesn't work for some people, I just don't see any strong argument in favour.  What's the benefit?
[17:57]  * sistpoty|work heads home... cya
[17:58] <emh> persia: I reported it to Debian using reportbug and deleted the ubuntu stuff that the ubuntu version of reportbug put into the report.
[17:59] <persia> emh, Cool.  That there was a new version, and the problems it solved?
[18:00] <emh> persia: http://lart.no/lpaste/gcady/raw
[18:00] <emh> and yes
[18:01] <persia> emh, Is this the bug that makes the screen keep waking up every time it thinks it's about to fall asleep?
[18:02] <emh> No, I don't think so. The screen goes to sleep, it just resets the screen saver idle time while it's at it.
[18:04] <persia> emh, Ah.  OK.  I heard a couple users complain about a bug that woke up the screen when it was supposed to DPMS off, but I guess that's different then.
[18:08] <james_w> Riddell: decision made on bug 267478, thanks
[18:14] <iulian> Hi
[18:44] <fabrice_sp> Hi. Any motu-release member for a second ack on Bug #242572?
[18:56] <james_w> fabrice_sp: hey, did you get a second ACK?
[18:58] <fabrice_sp> Hey james_w: Not yet. I got one from dktrkranz, but I still miss one.
[18:58] <fabrice_sp> That's why I'm asking for one here :-)
[18:58] <james_w> fabrice_sp: please don't set the bug to "Confirmed" until you do, that's how the release team determine whether it has the exception
[18:59] <james_w> doing so would probably mean you would never get the second ACK
[18:59] <james_w> hey tdomhan
[19:00] <fabrice_sp> james_w: ok. I thought it has to be confirmed to get attention
[19:00] <fabrice_sp> will put back new
[19:18] <rainct> heya
[19:35] <james_w> ogra: bug 283355
[19:36] <james_w> ogra: I've got them all ready, just double checking I'm correct I've got your ACK as -mobile delegate
[19:37] <persia> ogra, And to prove people use them with ubuntu-mobile: http://gihyo.jp/admin/serial/01/ubuntu-recipe/0037?page=2
[19:37] <ogra> james_w, acked :)
[19:38] <james_w> ogra: thanks
[19:38] <ogra> persia, sweet
[19:38] <ogra> though i directly see the bug :)
[19:38] <james_w> I'll build an image once they are all in the archive to test them, I've reported the one remaining bug that I know about.
[19:39] <slytherin> superm1: any idea where does bluez-gnome store preferences?
[19:39] <superm1> slytherin, /var/lib/bluetooth i want to say
[19:39] <superm1> well
[19:39] <slytherin> superm1: even the use specific preferences?
[19:39] <superm1> slytherin, ah those, i'm not too sure
[19:39] <superm1> slytherin, poke around the code and see if it's using gconf / what not
[19:41] <rainct> Nobody says hello? I'm not going to complain about Intrepid today ;P
[19:41] <slytherin> superm1: The issue I just discovered when I tried testing with another dongle is that the applet icon is not present when I switched the dongle. The default value to for the display preference is 'never display'
[19:42] <superm1> slytherin, that's really bzr
[19:42] <slytherin> superm1: checking code.
[19:48] <slytherin> superm1: the gconf schema says icon policy is 'present'. I suspect the value is not getting read when the applet is started first time for a particular dongle.
[19:49] <en1gma> does 'auto-apt run ./configure' use the configure file in my sources or the configure file online in a repo?
[19:51] <slytherin> en1gma: what is auto-apt?
[19:52] <en1gma> i was reading it when i was finding info about checkinstall
[19:52] <en1gma> https://help.ubuntu.com/community/CheckInstall
[19:52] <slytherin> en1gma: By the way I don't understand what you mean by configure file in online repo.
[19:53] <en1gma> the source repos have all the original files?
[19:53] <slytherin> superm1: I will do more investigation in this regard later.
[19:53] <en1gma> by issuing the "auto-apt run ./configure"
[19:54] <en1gma> does it use the local ./configure file or the one on the repos
[19:54] <superm1> slytherin, that's a weird problem though indeed
[19:54] <slytherin> en1gma: I don't think auto-apt deals with sources anywhere.
[19:55] <en1gma> idk ....it deals with a ./configure file and that file is located in sources
[19:55] <en1gma> but is it local source or online ubuntu repor source
[19:55] <slytherin> superm1: Yes. It is. And the bluetooth problems I was facing are hardware specific. Almost everything from pairing to file transfer is working with the current dongle.
[19:56] <superm1> very good to hear
[19:56] <DktrKranz> NCommander, GNAT transition started, now waiting for archive-admins to accept packages in -proposed.
[19:56]  * NCommander didn't know -proposed needed approval
[19:56] <NCommander> You learn something new every day :-)
[19:56]  * NCommander hugs DktrKranz
[19:56] <slytherin> en1gma: the ubuntu source does not have configure hanging around. It is inside a archive. So no, I don't think auto-apt deals with it.
[19:57] <NCommander> DktrKranz, anyway, gnatgps. Thats an interesting issue. It doesn't compile because python2.3 isn't in hardy
[19:57] <en1gma> ahh thats a good point
[19:57] <NCommander> DktrKranz, it violates the python packaging policy extremely badly
[19:57] <en1gma> you prob right
[19:57] <NCommander> DktrKranz, it could be fixed with a massive search and replace python2.3 -> python2.4, but that woudl still be violating policy ...
[19:58] <slytherin> superm1: By the way I didn't know that when initiating pairing form PC it autogenerates a pin. I as usual tried entering pin 1234 form the phone and pairing failed. Then I checked the dialog in detail and that it asked me for a different pin. :-)
[19:58] <superm1> slytherin, :)
[19:58] <DktrKranz> NCommander, my guess is it isn't used largerly, and it's a leaf in GNAT transition, so I'll leave it alone unless someone *really* needs it
[19:58] <laga_> gah, merging libfile-temp-perl into perl-modules was a great idea so late in the cycle. it breaks versioned depends on libfile-temp-perl :(
[19:59] <NCommander> DktrKranz, doing a transition via SRU must be a first ;-)
[19:59] <DktrKranz> NCommander, and yes, packages in -proposed needs manual approval from archive-admins (at least for now)
[20:00] <NCommander> james_w, ping
[20:00] <james_w> heh :-)
[20:02] <james_w> asac: I'd appreciate your input on bug 262191 when you get a moment
[20:03] <DktrKranz> NCommander, when first packages will be available (see https://bugs.edge.launchpad.net/ubuntu/hardy/+queue?queue_state=1&queue_text=), I'll take care of the remaining ones (they need some extra-care, I noticed a couple of issues).
[20:04] <NCommander> DktrKranz, its ADA, you really think it would have not exploded on the first try ;-)?
[20:04] <DktrKranz> NCommander, I'm a silly optimist ;)
[20:05] <superm1> james_w, http://github.com/pieter/git-bzr/tree/master seems to be a method of adding a bzr repo as a git remote, is there any way (or plans of a method) for the other way around, to be able to push directly to a git repo from bzr?
[20:05] <NCommander> DktrKranz, the archive admins are going to be wondering why there is so many ada packages pending ;-)
[20:05]  * DktrKranz is more and more sure we will find lots of people to test packages affected
[20:05] <james_w> superm1: yeah, git-bzr. It's not fully functional yet though
[20:06] <DktrKranz> NCommander, they didn't see the others ;)
[20:06] <NCommander> "the others"?
[20:06] <DktrKranz> the remaining ones
[20:07] <NCommander> Its a pity I'm not a MOTU, I could have uploaded for you ;-)
[20:07] <superm1> james_w, ah, I just came across it because of an interesting situation that we have with the packaging for -fglrx.  the packaging is kept in git, but i'm the only one in the community right now with rights to touch it, so ideally i'd like to be able to create a bzr branch to keep it and then whenever things get changed in the bzr branch I can get a notification that it needs to get merged there too
[20:07] <DktrKranz> I could upload them with strict bdepends (I'll do), but I'd like to see if they're OK before proceeding
[20:07] <superm1> was hoping to keep the process fairly low touch if possible
[20:07] <NCommander> DktrKranz, yeah, building them in a PPA is *****
[20:08] <NCommander> DktrKranz, I got a load of build failure notices from your PPA ;-)
[20:08] <DktrKranz> NCommander, it's just a matter of launching my massupload.sh script, not a pain ;)
[20:08] <NCommander> Well, you had to assemble the debdiff first
[20:08] <DktrKranz> huh? is it still linked?
[20:08] <NCommander> ?
[20:08]  * NCommander would have just did dupload ubuntu *.changes
[20:08] <james_w> superm1: yeah, sorry, there's nothing that won't be a bit of a pain at the moment. Hopefully git-bzr will mature over the next few months.
[20:09] <DktrKranz> NCommander, it's a wrapper I use when uploading multiple packages at the same time
[20:09] <NCommander> Is that so git can access bzr repos, or the other way around O_O;
[20:09] <NCommander> DktrKranz, and why doesn't dput *.changes work?
[20:09] <superm1> james_w, great.  well i'll take another look around UDS time, and if not find a way to pick your brain for more ideas
[20:09] <slytherin> persia: need some advice. packages related to grinvin were removed form Debian some time back because they were supposedly too broken. I wasn't sure if we also want to remove the packages hence didn't log a bug. Now they have been released with recent upstream version.
[20:09] <DktrKranz> because I keep packages in subdirectories, I like order ;)
[20:10] <james_w> superm1: yeah, it's something that I want to work well, so I'd be happy to start by talking through what you would like
[20:12] <NCommander> james_w, anyway, the reason it didn't work is because you used asm/types.h
[20:13] <sebner> james_w: arrrgh, I got caught by a flu. If I'm not dead tomorrow I'll really really really deal with the ssmtp stuff :\
[20:13] <james_w> sebner: cool, thanks
[20:13] <james_w> NCommander: at least on i386 that leads to the appropriate typedef
[20:13] <james_w> NCommander: what should I have used?
[20:13] <NCommander> james_w, linux/types.h
[20:14] <NCommander> But you also put it in the wrong place
[20:14] <NCommander> (netfilter.h was pulled in via a different .h file)
[20:14] <sebner> DktrKranz: unlike Achmed I didn't have my flu shot :P
[20:14] <NCommander> Actually
[20:14] <NCommander> Forget what I said on asm/types
[20:14] <NCommander> That would have worked, I'm just an idiot ;-)
[20:14] <NCommander> ok
[20:14] <NCommander> It builds now from source
[20:14] <NCommander> ;-)
[20:14] <DktrKranz> sebner, did flu killed you?
[20:14] <james_w> yeah, I see that linux/types.h might have been better now
[20:15] <sebner> DktrKranz: not yet
[20:15] <DktrKranz> sebner, AAAAAAAAAH!
[20:15] <DktrKranz> sebner, and now?
[20:15] <sebner> DktrKranz: now what?
[20:15] <james_w> NCommander: if you have a fix would you send it to Debian as a heads up please? I wanted to wait until there was a confirmed fix, so I didn't do it when I uploaded
[20:15] <NCommander> This package FTBFS on Debian?
[20:16] <NCommander> link to Debian bug please
[20:16] <james_w> no, but I imagine it's a .27 issue
[20:16] <james_w> that's why I said as a heads up
[20:17] <slangasek> ScottK, DktrKranz, TheMuso : ping, does https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html still apply for this release?
[20:17] <james_w> NCommander: ah, or https://edge.launchpad.net/nufw/+bugs
[20:17] <NCommander> james_w, care to upload the fix to Ubuntu?
[20:17] <james_w> ah, what?
[20:17] <james_w> NCommander: sure, debdiff me
[20:18] <james_w> it points to that on it's homepage, but won't let you actually report bugs
[20:18] <james_w> I guess opening an upstream task is sufficient
[20:18] <NCommander> er, wait, what?
[20:19] <NCommander> james_w, wait, your Debian upstream?
[20:19] <james_w> nah
[20:20] <james_w> I went to see where nufw's bug tracker is, and it points to launchpad, but doesn't actually let you report any bugs there
[20:20] <james_w> but as we have one open in launchpad we can just do "Also affects" and add a task for nufw, and explain what the problem is
[20:20] <DktrKranz> slangasek, I guess it's not changed since Hardy
[20:20] <NCommander> james_w, http://pastebin.ca/1227122
[20:21] <NCommander> james_w, Can you test build on i386 for me?
[20:21] <james_w> sure, if you put it somewhere other than pastebin.ca
[20:22] <NCommander> what's wrong with pastebin.ca?
[20:22] <NCommander> just click the "Get Raw" link
[20:22] <james_w> I have a philisophical differences with Canada
[20:22] <NCommander> james_w, http://paste.ubuntu.com/57556/
[20:22] <james_w> that, or there's a buggy router between me and pastebin.ca which means I can never access it
[20:22] <slangasek> DktrKranz: ok, thanks
[20:23] <NCommander> james_w, hows that?
[20:25] <james_w> NCommander: http://paste.ubuntu.com/57557/
[20:25] <NCommander> james_w, didn't you see my paste to paste.ubuntu.com?
[20:26] <james_w> NCommander: ah, sorry, I thought you were asking how I couldn't get to pastebin.ca
[20:26] <james_w> just wanted to prove I had nothing against Canadians as well :-)
[20:28] <NCommander> james_w, yeah.
[20:28] <NCommander> WOOO, I'm only a single upload away from 50 after this one
[20:28] <james_w> fix a bug
[20:29]  * NCommander looks for abug ;-)
[20:30] <DktrKranz> NCommander, break something and then repair it, two uploads in a row ;)
[20:30]  * NCommander should just wait for the GNAT SRU to finish
[20:30] <NCommander> That's five or six uploads en-mass
[20:32] <RAOF> directhex: Hey!  That _is_ a mono bug, and it's really just a reminder for when the upstream task is fixed :P
[20:33] <james_w> NCommander: uploaded, thanks for your contribution.
[20:33] <NCommander> \o\ /o/ |o| !<o>!
[20:33] <NCommander> hrm, that last one is a TIE fighter
[20:33] <ajmitch> disturbing
[20:38] <RAOF> NCommander: And the middle ones are TIE fighters, too.  They're just banking!
[20:38]  * NCommander does a barallel roll
[20:39] <NCommander> ._. :| .-. |: ._.
[22:27] <crimsun> Laney: bug 274124 is still reproducible for you on current 8.10, correct?
[22:27] <crimsun> gah, awful summary
[22:40] <LaserJock> any quilt people around?
[22:40] <LaserJock> I can't figure out how to get quilt to add a new file
[22:41] <RAOF> LaserJock: By "add a new file", what do you mean?  Quilt is wierd :)
[22:41] <james_w> LaserJock: "quilt edit file"?
[22:41] <LaserJock> sorry
[22:41]  * RAOF thought it was "quilt add file"
[22:42] <LaserJock> I mean I'm adding a new file
[22:42] <LaserJock> it doesn't seem to like it
[22:42] <LaserJock> I can create a patch, but it assumes I have an empty file
[22:42] <RAOF> Oh.  Adding a file which previously didn't exist in a patch.
[22:42] <LaserJock> yes, exactly
[22:42] <LaserJock> so when I quilt pop -a I'm left with an empty file
[22:43] <RAOF> Maybe you need to "quilt add file_i'm_about_to_create" first?
[22:43]  * RAOF is hardly a quilt expert.
[22:44] <RAOF> Heh.  Alternatively, you could just make a patch, and then "quilt import"
[22:44] <LaserJock> I did do the quilt add first
[22:44] <RAOF> :(
[22:44] <LaserJock> and that did give me a good looking patch
[22:44] <LaserJock> but when I build the package it says that it didn't cleanly unpatch
[22:45] <RAOF> Ah.  Because you can't delete a file in a patch.
[22:45] <RAOF> Oh.  That's somewhat awkward.
[22:47] <james_w> http://paste.ubuntu.com/57615/ <- thoughts on whether that is bugfix only?
[22:48] <LaserJock> oh wait, I got it
[22:49] <crimsun> james_w: no, it's not, but the addition of new features don't seem to break anything existing.
[22:49] <crimsun> doesn't seem, rather
[22:49] <crimsun> at least it doesn't seem to explode locally
[22:50] <james_w> ok, thanks
[22:59] <Riddell> cody-somerville, jdong, TheMuso, \sh: motu-sru love still needed on bug 268260
[23:01] <jdong> Riddell: ack sorry, preparing for midterms today; I took a quick look in the morning; what exactly needs to be done?
[23:01] <Riddell> jdong: someone from motu-sru needs to say it's ok to accept those patches
[23:03] <james_w> how bad would it be to upload a version as -1ubuntu1 when the package isn't in Debian (the whole package isn't, not just the upstream version).
[23:03] <james_w> It's just to provide an upgrade path from a PPA, so it's not crucial
[23:03] <TheMuso> Riddell: I am no longer in MOTU SRU.
[23:04] <jdong> Riddell: oh ok. I thought Luca was SRU so I was confused. let me take a look
[23:05] <ajmitch> james_w: get the package into debian ASAP? :)
[23:05] <Riddell> TheMuso: launchpad says you are https://edge.launchpad.net/~motu-sru/+members
[23:05] <james_w> ajmitch: or that, yes :-)
[23:05] <TheMuso> Riddell: heh woops I forgot to remove myself.
[23:06] <Riddell> jdong: I still need someone acting in motu-sru capacity to say it's approved
[23:08] <jdong> Riddell: ok, they all look good to me. comment added.


[00:21] <amurray> mdeslaur: heh even though I wrote that blog post I had forgotten about unprivileged bpf for impish - in my head I was thinking it was only in jammy :)
[00:33] <sdeziel> amurray: I've been setting that sysctl key since 2019 and https://lwn.net/Articles/660331/ says it went in kernel 4.4 apparently
[00:34] <amurray> sdeziel: I meant I had forgotten we changed the default to disallow unpriv bpf in impish
[00:35] <sdeziel> amurray: ah, OK sorry for the confusion and good to know!
[15:19] <mpiano> Hi again ebarretto, sorry for bothering again. Regarding what was said yesterday about cvescan, I tried to do a bit of a comparative analysis between that database and OVAL, so here's a couple thoughts: https://pastebin.com/bzJhErQt
[15:19] <mpiano> Given these, I wanted to know whether there are some planned improvements for the data provided via OVAL before the cvescan databases are deprecated completely, as, for how things are right now, seems to be like a bit of a step backwards in terms of support for vulnerability management.
[15:25] <ebarretto> mpiano, you will probably want to check the CVE OVAL instead, same URL, just switch the usn in the bz2 filename to cve. This was what we previously put on the website, but with time customers were complaining by the amount of vulnerabilities shown and instead wanted to know what vulnerabilities that we have patched they still didn't install. So we advocate for the USN OVAL on most cases.
[15:27] <ebarretto> mpiano, regarding improvements in OVAL, yes we have quite a list on things wanted there and I've been working working on it. I will take your feedback in consideration for sure and I appreciate it
[15:29] <ebarretto> mpiano, btw, which ubuntu releases are you using?
[15:31] <mpiano> Wow, that's very interesting (I should have probably scavenged https://security-metadata.canonical.com/oval/ where that naming convention is actually explained). Thanks for letting me know I'll check that out asap.
[15:34] <mpiano> > which ubuntu releases are you using?
[15:34] <mpiano> basically all LTSes currently in standard support (plus a bit of Xenial which got late at being migrated)
[15:35] <ebarretto> mpiano, and you are in need of the json xenial data for cvescan right?
[15:40] <mpiano> ebarretto, indeed, it greatly helps us draw a risk picture. But of course, if it is set for deprecation, we will do work to adapt to a different system. Being a free utility I don't feel in any position to enforce SLAs.
[16:49] <sarnold> mpiano: re severity vs priority -- we prioritise which issues our team should work on, but that's a different thing than the severity of a given issue at a given site. Without knowing the full details of the context of how any given software is used, it's very difficult to come up with a "severity"
[16:50] <sarnold> mpiano: attempts to do so often lead to ridiculous results like binutils issues being marked "high severity" via cvss scores; but those tools were never designed to do malware analysis, they're for building software from source code you trust. simplistic attempts to assign "severity" ratings without awareness of how the software is used isn't always helpful..
[16:57] <mpiano> sarnold: that's very true, it's something that I usually treat as an indication more than an absolute truth. My point was more on the fact that in the USN-indexed OVAL the severity of multiple CVEs was grouped into a single value, but this is totally solved with the other OVAL format ebarretto pointed me to.
[17:03] <sarnold> mpiano: aha, cool cool; definitely, different people want different things from the oval. some wanted re-assurances that they ran apt-get update && apt-get upgrade correctly ;) and others want to know what issues are known but not yet fixed..
 "Thomas Sjögren: heh, that "..." <- https://ubuntu.com/engage/FIPS-on-Ubuntu-in-air-gapped-environments - have there been an update to that info?
[17:09] <konstruktoid[m]> s/info/article/
[17:10] <sarnold> konstruktoid[m]: good question :)
[17:13] <konstruktoid[m]> just don’t want anyone to lose face discussing air-gaps instead of having a presentation about an interesting topic


[06:06] <flocculant> if anyone happens to notice that the try/install dialogue fails to wait and they land straight at desktop - it's reported and fix was on the way before that.
[08:56] <ochosi> bluesabre: and i presume we include both in 18.04..?
[10:05] <bluesabre> ochosi: yes
[10:40] -SwissBot:#xubuntu-devel- ::xubuntu-artwork:: [bionic] r338 Update elementary-xfce to 3ab8783... (by Sean Davis)
[10:40] -SwissBot:#xubuntu-devel- ::xubuntu-artwork:: [bionic] r339 Release 18.04.5 (by Sean Davis)
[16:38] <ochosi> bluesabre: thanks for taking care of the artwork upload!
[19:12] <albinard> hello


[13:39] <psc> hi everybody, long time user of u-studio, dist-upgraded it from 12.04 to 16.04 = pulseaudio is choppy
[13:40] <psc> anyone experienced this? when opening pa-vu-control is kind of works but loop from gui to a message telling my Connection to pulseaudio...
[13:41] <OvenWerks> psc: no I have not experienced that unless I have latency set very low.
[13:42] <OvenWerks> psc: also there are some laptops where the internal mic is 48000 only and that causes problems
[13:44] <psc> OvenWerks, latency of my real soundcard (firewire presonus jack is very low), but I also have the internal soundcard of the motherboard (which I don't care much)
[13:44] <OvenWerks> psc are you bridging jack and pulse then?
[13:44] <psc> OvenWerks, yes
[13:45] <psc> will try to disable the motherboard's soundcard from the bios...
[13:45] <OvenWerks> I find that in pavucontrol I have to turn all the alsa cards off
[13:46] <OvenWerks> pulse has trouble with getting sync from jack plus any other cards
[13:46] <psc> I wish I could, but the pavucontrol show only the gui for a short period of time and loops
[13:46] <OvenWerks> skype will not work with jack set lower than 128/2
[13:47] <psc> (Establishing connection to PulseAudio... please wait)
[13:51] <psc> ok on u-studio 12.04 my presonus firewire was not connected by pulseaudio automagically, but now it looks like PA knows how to start my presonus...
[13:53] <psc> perfect disabling my onboard soundcard fixed the problem
[13:55] <psc> BUT (of course more problems): how can I start jack if PA is using my soundcard?
[13:55] <psc> Would be happy to only use jack (with pulseaudio bridge for chrome etc)
[14:12] <OvenWerks> jack asks pulse to release the card.
[14:12] <OvenWerks> what I do ... is tell pulse to not look for alsa cards...
[14:13] <OvenWerks> pactl unload-module module-udev-detect
[14:13] <OvenWerks> pactl unload-module module-alsa-card
[14:13] <OvenWerks> then I use jack_control to setup and run jack
[14:13] <OvenWerks> I have this set to run at session start
[14:15] <OvenWerks> psc: I also do some other things, but that is besides the point.
[14:15] <psc> OvenWerks, qjackctl crash on first load... maybe because it's not able to release the soundcard from pulseaudio...
[14:15] <OvenWerks> psc: I have heard that if you are using the old firewire drivers you have to blacklist the alsa firewire drivers
[14:16] <psc> OvenWerks, trying to find the right combo, right now I am able to use jack with my soundcard
[14:16] <OvenWerks> psc: you can only use FW via alsa or via the the old drivers.
[14:17] <psc> OvenWerks, if I disable pulseaudio configuration presonus OFF, start jack with cadence = OK but no PA bridge
[14:17] <OvenWerks> psc: if you run jackd instead of jackdbus, the pa-jack bridge will not auto connect
[14:18] <OvenWerks> if jackd is running, jackdbus will fail.
[14:18] <psc> Oh good know!
[14:18] <OvenWerks> (also if jackdbus is running jackd will fail)
[14:19] <OvenWerks> qjackctl and jack_control both run jackdbus by default.
[14:19] <OvenWerks> jackdbus does allow making changes in settings without stopping jack.
[14:20] <psc> well I fear that my setup is a bit odd (12.04 -> 16.04)...
[14:21] <OvenWerks> I do not use a fw interface (old ice1712 device in PCI) but my startup file is at http://www.ovenwerks.net/paste/autojack if it is any help
[14:22] <psc> thanks! saved
[14:22] <OvenWerks> psc: the only "non-odd" setup I know of is to use the internal audio junk...
[14:25] <OvenWerks> psc: be warned to turn cadence auto start off to use something like what I have.
[14:25] <psc> i don't want to reinstall from scratch but i have a feeling that this is what I will end up doing...
[14:26] <psc> i will be painful
[14:26] <psc> it
[14:27] <OvenWerks> I haven't tried upgrading so I don't know. I just save my home directory and start over.
[14:29] <psc> Yes, but then I will need to redo USB policy (I have custom USB hardware in my box), disable CPU governor, memory limits etc)...
[14:30] <OvenWerks> psc: make a package :)
[14:31] <psc> you mean .iso / .img of my whole drive and reinstall that?
[14:31] <OvenWerks> seriously, memory limits should be set right from ubuntustudio install.... cpu governor is coming...
[14:31] <OvenWerks> I am told that performance mode uses less power than ondemand...
[14:34] <psc> thanks for all the help OvenWerks!
[14:34] <OvenWerks> no problem.
[14:34] <psc> I have now a setup that works: no pavucontrol, but bridge is working and I can make music
[14:35] <psc> Will stick around in this channel for a few days. Thanks again!
[14:35] <OvenWerks> cool, making music is the most important part
[16:50] <studio-user416> Hello, anybody there?