[17:04] <ScottL> stochastic:  you had offered to work on the seeds, if you would still like to do that i would appreciate it as i'm still behind on other stuff
[17:05] <ScottL> i think shnatsel had offered to help as well on the seeds
[17:05] <ScottL> lastly, i had expected some advice and information which has not come through at this time
[17:06] <shnatsel> ScottL: I wrote a doc with introduction, it's pretty complete
[17:06] <shnatsel> ScottL: I'm trying to figure out some pretty advanced parts right now
[17:07] <shnatsel> ScottL: I'm trying to transition elementary's plain old metapackages to seeds
[17:07] <ScottL> stochastic, https://mail.google.com/mail/?tab=Xm#inbox
[17:07] <ScottL> sorry, wrong link
[17:07] <ScottL> try this:  https://docs.google.com/document/d/1RPPF14h1Sw2gQjGTuZjUIlNHnGrafS8ekhFjJM9MT00/edit?hl=en_US&pli=1
[17:08] <shnatsel> oh yeah, my doc
[17:08] <ScottL> heh, but i think stochastic knows about seeds anyways, but i like to push information out there anyways :)
[17:09] <ScottL> but if we get things set, even if it's just simple stuff for now, then we are better off
[17:09] <ScottL> and if information comes for the graphics stuff in to me later, then we can always update the seeds with it
[18:59] <shnatsel> cjwatson has rescued me from my ignorance, as usual
[18:59] <shnatsel> so now I can add info about adding custom seeds and/or metapackages to the doc
[19:36] <len> Just an idea. Don't know if anyone has been following my conversation with David Henningsson. But it is becoming obvious to me that documentation would be a big help.
[19:37] <len> Even if it is not complete, something that gives as many ways around hardware quirks as possible would be nice.
[19:40] <len> I would think the best place to put this would be as part of the "about UbnutuStudio" button in the main menu.
[19:42] <len> Format should be very basic html so it self formats to whatever size window the browser happens to open with.
[19:43] <len> It would be fine to have a menu page where some of the options point to places on the web that already deal with certain things.
[19:45] <shnatsel> len: last time I checked Ubuntu Wiki described such things in detail
[19:45] <len> Ok, do we have anything that points there?
[19:46] <shnatsel> ubuntu didn't have anything pointing to help besides a firefox bookmark last time I checked
[19:46] <shnatsel> oh, and yelp
[19:46] <shnatsel> but it's useless
[19:47] <shnatsel> "about" is not a good place to place it - at least it would be the last thing I'd look if I had hardware issues
[19:47] <len> Yeah, that was what I found. How much of what they have relates to getting best quality?
[19:47] <len> On the main menu somewhere would be nice though
[19:48] <shnatsel> No idea. I could find info on setting higher sampling rate only in Arch wiki (pulseaudio) and in official ALSA docs (and those docs were not easy to find).
[19:49] <len> Those are the places I ended up at to find I had to pull one side of the capture down to get the internal mic to work.
[19:50] <len> It is also where  I found out about testing for system sample rate.
[19:51] <len> It is like there needs to be something about getting the best out of the standard internal audio setup.
[19:52] <len> Setting rate, setting levels etc. There is already something getting set up for setting kernel things and jack things up from what I have heard.
[19:56] <len> Being complete is not an issue (from where I stand) because it is impossible anyway no matter how much time is available. But some basic setup things would help. I get the idea that windows programs grab the sound card and set things up for the user... in the ubuntu world that would be pulse. The idea of jack is to allow a user preferred setup.
[19:58] <len> Anyway, I will try to come up with a basic set of HTML documents with whatever quirks I know about, either as text or pointers to pages that do a good job.
[19:58] <len> Probably a FAQ style of thing for now.
[20:00] <len> If there are any better ideas... I can work with them, but I am not CSS literate... just know basic html. I use bluefish for editing.
[20:01] <shnatsel> len: use google docs
[20:01] <shnatsel> len: you can always export that to HTML and gdocs are great for collaboration
[20:03] <len> Is that web based then? or something that I download?
[20:03] <shnatsel> web based
[20:10] <len> Ok, I will look it up. are there any ubuntustudio projects on there already? That I should work off of, or should I start something new?
[20:15] <shnatsel> none I know of
[20:16] <shnatsel> but I'm not the most informed person in here
[20:23] <len> I'll start something new, it can always be merged with whatever.
[20:32] <ScottL> shnatsel, stochastic:  i'm also wondering if we really need to make each items that might be selected with the ubiquity patch as it's own seed?
[20:33] <shnatsel> ScottL: yes
[20:33] <ScottL> oh :/
[20:33] <shnatsel> ScottL: and as its own metapackage, too
[20:33] <shnatsel> ScottL: it's not hard
[20:34] <ScottL> i know it's not hard, but i'm thinking about what will involved when we get information from graphic designers/artists and need to change/update
[20:34] <ScottL> it would have been nicer to have a generic pacakge name "ubuntustudio-graphics" which had severl binaries named in it
[20:34] <ScottL> each of these binaries depended on what ever we needed
[20:34] <ScottL> and if they could be selected during installation
[20:34] <ScottL> then we wouldn't need to udpate seeds and meta's just to update or change
[20:35] <ScottL> errr
[20:35] <ScottL> generic SEED name "ubuntustudio-graphics"
[20:35] <ScottL> that included a package named "ubuntustudio-graphics" which yadda, yadda, yadda...
[20:36] <ScottL> but it is what it is
[20:37] <ScottL> shnatsel, i'm going to read through pretty in depth later tonight
[20:38] <shnatsel> ScottL: seeds are better than packages like that, really
[20:38] <ScottL> why so?
[20:38] <shnatsel> ScottL: and they generate the same packages if you wish
[20:39] <shnatsel> ScottL: splitting package set into seeds is very similar to splitting program's main() into functions
[20:40] <shnatsel> ScottL: you can combine them, define inheritance, generate metapackages with atomatically generated detailed changelogs, you can look at the whole package set at once with all dependencies included, you can find out why a particular package is included, etc
[21:16] <ScottL> micahg, when you get back can you help me understand the "conflicts, provides, replaces" stuff for the -default-settings
[21:16] <ScottL> my main concern is that we have several packages that will be moving into the -default-settings package
[21:17] <ScottL> and i'm unsure how or if i can have the -default-settings package do "provides, conflicts, replaces" for multiple packages
[21:17] <ScottL> and if i will need to make a dummy or transitional package for these as well
[21:18] <ScottL>  
[21:18] <ScottL> and i should note that i did read the page you link previously several times and thought about it for several days and i am still unsure how this will work correctly