#ubuntu-meeting 2004-10-02 <jdub> so many channels... * ..[topic/#ubuntu-meeting:mdz_] : Ubuntu Technical Board Meeting -- 2004-09-21 1600UTC <mdz_> 5 minutes * ..[topic/#ubuntu-meeting:mdz_] : Ubuntu Technical Board Meeting -- 2004-09-21 1600UTC || Agenda at http://wiki.ubuntu.com/TechnicalBoard <mdz_> ok, time to begin <mdz_> the first item on the agenda is a discussion of the new software to be brought into universe <mdz_> my understanding is that this includes Debian contrib, Debian non-free and a subset of Christian Marillat's packages * ..[topic/#ubuntu-meeting:Kamion] : Ubuntu Technical Board Meeting -- 2004-09-21 1600UTC || Agenda at http://wiki.ubuntu.com/TechnicalBoardAgenda <Mithrandir> does this mean there will be no way for people to see whether they install free or non-free software from universe? <mdz_> that is correct <mdz_> universe would be a mixture <mdz_> or, we could use sections to delineate it <Kamion> there's a comment on the agenda from jdub suggesting we avoid non-free in universe <Keybuk> are we still going for a "you're installing software from universe, are you crazy?!" kinda warning? <mdz_> yes <mdz_> virtual jdub says, let's not do it <mdz_> Keybuk: yes <elmo> actually, it's everything in Marillat's - he doesn't have decss or anything flat out indistributable <mdz_> I have patches for synaptic waiting <Keybuk> what do we class as non-free? cf. mplayer <mdz_> elmo: he doesn't have java in there? <Mithrandir> I think we should have non-free universe or at least sections in it <elmo> mdz: no that I saw, no <mdz_> oh, ok. strike 'a subset of', then <elmo> Mithrandir: the current plan for that is to change the section to universe/non-free for non-free software <elmo> the alternate/backup plan is to create universe-non-free <Mithrandir> I would prefer the latter <elmo> (plan in the sense, of what I'd plan to do, if we go ahead, sort of thing) <mdz_> if the need is to let the user know whether they are installing free or non-free software, then a section is no good <Mithrandir> also think of derivatives, they might want to get something off universe, and if they have to go through a lot of licenses, that's kinda wasted work. <mdz_> if the goal is just to classify it so that people can look and find out at a glance <sabdfl> Mithrandir: universe is "you're on your own" <mdz_> then sections are useful <mdz_> I think it is preferable that universe live up to its name, and be inclusive by nature <mdz_> so if we want further classification, it should be in subdivisions of universe <mdz_> that could mean that universe becomes a separate archive, having components, or that we use sections * mdz_ hides from elmo <Mithrandir> I guess we can't have packages that exists in both universe and free-universe? <Mithrandir> or something along those lines? <sabdfl> Mithrandir: i'd prefer we do NO classification of universe software at all <Keybuk> what kind of non-free is likely to end up in universe? <elmo> mdz: dude, we can't have two archives - we have packages with source in main and binaries in universe <sabdfl> that way we don't have to argue semantics, it's either main, or it's not <mdz_> elmo: good point <mdz_> it would be useful to have a marker for derivative distributions <Mithrandir> Keybuk: no-commercial stuff, for instance? <mdz_> if they know that something came from Debian main, they don't need to be concerned about the license <elmo> sabdfl: yeah, but it's really harsh taking 9000 packages of free software and hiding 100 packages of very non-free software in there <elmo> sabdfl: debian doesn't do a good job of checking licenses - expecting users too, is just, well harsh <mdz_> we'd be mixing things in Debian main with non-free stuff, forcing them to review the licenses individually <Mithrandir> Keybuk: some commercial apps, like opera would be interesting (to me) <sabdfl> Mithrandir: i've asked elmo to look into opera in universe <sabdfl> elmo: 9x% of users, given the choice to add non-free during install, say yes <mdz_> limi will be pleased :-) <Mithrandir> sabdfl: it's non-redistributable atm, afaik. they promised to fix it a few years back, but I figure I need to kick some butt. <elmo> keybuk: mark's said we can ship anything that is distributable (even if it's "non-commercial only") and not likely to invoke DMCA type lawyer/police visits <sabdfl> not "ship" on the cd <elmo> err, sorry <elmo> s/ship/add to universe/ <sabdfl> but certainly make accessible via universe, for people who want it <mdz_> elmo: and also doesn't contaminate other software we distribute (i.e., java) <elmo> mdz: right, that too <sabdfl> the idea is simply to get rid of all the "go over there, add this line to that file, then compile that bit of code...." hoops <elmo> sabdfl: I don't think we should ignore the x% of users who _do_ actually care about freeness just because they're a minority tho <sabdfl> mdz_: my reading of the java licence is not that it contaminates other java implementations, but just that those have to be clearly labeled as replacing bits of java <Keybuk> is there going to be a contrib-alike "depends may not be complete" loop-hole, or do we want supported+universe to be depends-complete ? <sabdfl> there are a ton of warnings when you add universe to your sources list, for them specifically <sabdfl> Keybuk: depends-complete <elmo> ?? <sabdfl> erm, actually, i don't know what i'm talking about there <elmo> dude, you told me to import contrib, it can never be depends-complete if we do that <mdz_> contrib is permitted to depend on things that aren't packaged at all <Keybuk> sabdfl: packages in Debian contrib are allowed to depend on packages that don't exist <sabdfl> exactly. i don't know what i'm talking about there :-) <mdz_> or which are randomly downloaded from the Internet <sabdfl> we should include the "randomly downloaded" stuff in universe too, if we can <mdz_> elmo: did Debian ever get an official-ish opinion on the java license? <Mithrandir> sabdfl: I'm a bit wary of this -- it'll make universe include all kinds of _completely_ not-quality-controlled crap.. people treat it as "ok, not supported, but at least it's done by DDs so it might be decent" today. <elmo> sabdfl: I think you're conflating stuff.. the warnings are primarily there because the software is unsupported.. we're going to have to check the license on stuff we import that isn't from debian/main anyway, so we'll know which is free and which isn't. if we choose not to separate them out, it's not because it costs us anything to do so <elmo> mdz: official from who? AFAIC, the ftp-master position was that it was indistributable in non-free, and we invited -legal to tell us otherwise and they didn't <sabdfl> Mithrandir: most people will only install something from there that they are explicitly looking for. if they are explicitly looking for it, they will install it wherever they find it <mdz_> Mithrandir: true, currently people moving from Debian see it that way, as a sort of compatibility layer <elmo> there's also the issue of derivtatives, it's not just users <mdz_> elmo: official-ish as in consensus from people who enjoy arguing about licenses (i.e., debian-legal) <Kamion> yeah, if we want to do something like gnubuntu, it'll be a real issue <sabdfl> i'm committed to making it obvious that installing software from universe is well labelled as "scary" <sabdfl> but then making it easy for people to do that if they want <Kamion> although they may want to audit licences themselves anyway <Kamion> if we could avoid throwing away the information about the origin component in Debian, that might help <elmo> mdz: I REJECTed it, asked for follow ups to legal - no clear consensus emerged to dispute the contamination issues, AFIACR <Mithrandir> we have a few issues here -- we have the free-vs-non-free argument, and we have the "put random stuff downloaded off the net" discussion <Mithrandir> should we do one at a time? <mdz_> I don't think the latter is much of an issue at this point <Kamion> elmo: is there any way we can have Debian-Section: or something in the Packages files? <Kamion> elmo: that way, we can rearrange ourselves as we see fit without throwing away the information <Mithrandir> most users don't give a shit about licenses -- derivatives will, to a lesser or bigger degree. <mdz_> right <Keybuk> Kamion: or some kind of origin field in general? <mdz_> free-vs-non-free is an issue for philosophers and derivatives <Kamion> and derivatives will be quite happy wandering about through the Packages files <mdz_> the question is, how much work are we willing to do in order to make life easier for those two groups? <mdz_> I think that a marker to say where the package came from, as Kamion is suggesting, is about the right amount <Kamion> mdz_: we==Canonical are doing a hell of a lot of work to make life easier for derivatives :-) <mdz_> Kamion: on the specific issue of licensing :-) <Mithrandir> throwing away information is silly, but if we can preserve it like Kamion suggests, it sounds good to me <sabdfl> we can stick some of that stuff in the launchpad database, which would make it possible for the derivatives to use it in the same interface where they are selecting packages anyway <mdz_> don't we already preserve the Section: from Debian? <sabdfl> all of that stuff, actually :-) <Keybuk> I guess we need to keep track of where we get $random debs from anyway, to get the newer versions <elmo> mdz: usually but not always - I override them sometimes, e.g. nothing in universe is >> optional <Mithrandir> elmo: er, section != priority? <sabdfl> i don't want to add any work to the archive structure and files, that's a next-gen archive problem <elmo> that's priority, actually, but you get the idea, i.e. that we have our own overrides which are seeded from debian's <Kamion> mdz_: I think the part before the / needs to be squashed ...? <mdz_> Kamion: doesn't it stick around in the .deb? <mdz_> and the .dsc <sabdfl> i'll agree that we'll capture this stuff in launchpad, where it can be part of the automatic filtering of packages <Mithrandir> mdz_: it is in the debian/control zstrickland@example.net. <Kamion> mdz_: hm, true, assuming that the original .deb's section was right <Kamion> although you have to get at least contrib/non-free right, I guess <sabdfl> "don't show me packages that have licence XYZ" <elmo> kamion: for Debian it has to be - debian doesn't have component overriding <mdz_> Kamion: I would at least hope that the original .dsc section is correct with respect to main/non-free/contrib <Kamion> elmo,mdz: yeah, brain just catching up with fingers <elmo> sabdfl: or more likely "don't show me non-free software" :-P [hell, that should be the default IMO] <Keybuk> elmo: do you get to save your particular non-free religion in a cookie to do that? {ducks} <mdz_> ok, so if we're doing it fancy for the next-gen stuff, the question would seem to be, what can we do today in order to make it easy to seed that data when it's ready? <sabdfl> mdz, we'll capture it in launchpad, then discuss for next-gen-archive <elmo> at the very _least_ we should override the section to be universe/non-free <Keybuk> mdz_: stick a field in the database and record where we get things from? "origin = debian non-free" or something <mdz_> Keybuk: the existing database? <Keybuk> elmo: that makes some sense too <elmo> sabdfl: we really shouldn't just put this all off till next-gen - we have to redo our archive anyway for universe, things like adding another section is mickey mouse <mdz_> sabdfl: is launchpad ready to receive it? <Keybuk> mdz_: if it's no real work to capture it in both launchpad and katie, let's do that? <sabdfl> no, i really DON'T want us to be clasifying this stuff. if we do it, we have to do it totally for everything, and that's going to require non-scalable review processes <sabdfl> mdz_: no <mdz_> sabdfl: the sort of classification being diiscussed was a "where this came from", which is no work for us because we already know <mdz_> i.e., Debian main, Debian contrib, Debian non-free, and "other" <elmo> sabdfl: dude, I can not sanely import non-free/*, there _is_ going to be software in there that says "only Debian may redistribute" this <elmo> sorry, "Debian and it's mirrors" <mdz_> aren't we a de facto Debian mirror? :-) <elmo> not when we do 1.0-2ubuntu1 uploads :-P <sabdfl> we have to store that somewhere on our side for ongoing syncing purposes anyway, there is no need to stick it in the archive <Keybuk> mdz_: dodgy, decididly <mdz_> so, the needs of derivatives are expected to be met by the launchpad db <mdz_> what about the philosophers? <mdz_> they want that information now, while derivatives can wait <elmo> "philosophers" pfft <elmo> guys, it's not being a philosophers to not want to unwittingly install some "no commercial" use software at work <sabdfl> the philosophers have the following information: YOU ARE ON YOUR OWN. now philosophize. <elmo> sabdfl: due respect, that's crap <mdz_> that's a big step down from Debian <mdz_> especially for the server market <elmo> exactly <sabdfl> mdz_: it's a different approach. why is the server market different? <elmo> because home users aren't affected by "no commercial use" clauses <elmo> (usually) <mdz_> sabdfl: today, I can put Debian on a corporate box, and know that anything I can intsall I am legally allowed to use <sabdfl> same with ubuntu. if you dip into universe, you need to check the licence of anything you install. <Kamion> this would basically make universe totally useless for anyone except home users <Kamion> other people aren't likely to have time to check the licences <mdz_> sabdfl: the difference is that Debian has everything you could possibly want on a server <mdz_> sabdfl: while ubuntu doesn't, not by a long shot <mdz_> you don't need to dip outside Debian <elmo> sabdfl: dude, no one (not even us) is going to run just 'main' on their servers <mdz_> every server has its dirty laundry :-) <elmo> why on earth should we actively make things hard for people, when we already know whether a piece of software is free or not? <sabdfl> because if we say some things are non-free, and some aren't, we expose ourselves to risks in other regards <Keybuk> sabdfl: in what way? <mdz_> which is why I couched it in terms of origin, rather than licensing <sabdfl> what about universe/known-free and universe/black-hole <mdz_> if we record where it came from, we're providing almost all the information the user needs, without making a licensing decision <elmo> what about universe/debian-main, universe-REALLY-fucking-scary ? :P <Kamion> and we can do 'Origin => Marillat', which is the sort of thing some people may be interested in anyway <sabdfl> Keybuk: someone might argue that we are recommending things to people based on that classification <mdz_> universe-you-must-be-this-tall-to-ride-this-ride <sabdfl> which is why i prefer NO classification <Kamion> sabdfl: it's not a classification, it's informational <sabdfl> mdz_: so LA <sabdfl> Kamion: so is the label on herbal tea, and that can get you sued <Kamion> the reason it isn't a classification is because the packages aren't segregated on that basis <Keybuk> sabdfl: is that inherently much different to the nv driver being in main and the nvidia being in restricted? <mdz_> sabdfl: how about we mark things which came from Debian main with an Origin: tag <sabdfl> but there we have done a really thorough job of the analysis. <mdz_> sabdfl: and simply omit that tag from everything else <Kamion> sabdfl: if something's going to be getting us sued based on what random fields we put next to it in a Packages file, we should be running away from it, not distributing it <sabdfl> and I don't WANT to do a really thorough job on some of the stuff that I want in universe <Keybuk> sabdfl: yeah, I guess ... simply saying where it came from doesn't have that problem though? "Origin: debian contrib" for example? <Kamion> that's a quotation more than a classification <mdz_> it wouldn't be necessary, except that it's not particularly easy to determine from the package itself whether or not it came from Debian <mdz_> or even possible <mdz_> sabdfl: does a Debian/non-Debian distinction give you any bad feelings? <sabdfl> mdz_: yes, i'd prefer "known-free" and "something else" <elmo> known-free is just as dangerous liability-wise <mdz_> sabdfl: how about if known-free happens to contain only stuff from Debian main? <elmo> if Debian screws up (and it does - a lot) we're in the same boat <elmo> if you're worried about liability, Debian-main/everything-else are better IMHO <sabdfl> mdz_: it will end up carrying more than that, inevitably <sabdfl> we will end up with potentially a lot more software in universe than in all of debian <mdz_> sabdfl: it will only carry more than that if we are reviewing licenses of things going into universe <mdz_> sabdfl: which we won't(?) <elmo> err, we so will <elmo> guys, there's 178 packages in non-free <elmo> it'll take me like an hour or two at most to check those licenses, and I think it'd be unutterably insane to not do so <elmo> there's avoiding liability and then there's gross negligence <Kamion> a lot more in universe than in all of debian? it'll take even a crack team of packagers performing no QA at all quite a while to get that far <Kamion> I can see a few special cases, but it seems we should be encouraging free software wherever possible, so there's no reason why the bulk of things shouldn't be in Debian too <mdz_> what if we lump everything together <mdz_> and some random schmo on the Internet publishes a web page with a list of what he thinks is free and what isn't <sabdfl> mdz_: we'll do some internal review, but the less we advertise and make claims about what's there, the better <sabdfl> elmo: of course i am happy for that review to happen, so we can find any real problems and weed them out <mdz_> sabdfl: agreed <mdz_> sabdfl: someone from the free software community could do such a classification, independently, though <sabdfl> yes <sabdfl> and we can put a very rich classification into launchpad, to make it easy for derivatives <mdz_> which I think would meet the needs of the zeal^Wphilos^Wfreedom fighters <mdz_> sabdfl: won't the rich classification in launchpad have the same issues? <sabdfl> i'd prefer "known-free" and "unknown", where in launchpad, unknown trivially lets you read the licence and decide for yourself whether to include that package in your derivative <sabdfl> i do see the point in "known-free" for 90% of the no-brainer cases out there <sabdfl> is the text in sources.list suitably scary? <mdz_> no <elmo> it needs to be FIGLET scary <mdz_> ## Uncomment the following two lines to fetch updated software from the network <mdz_> ## and be able to use more than 12000 unsupported packages from the universe archive. <sabdfl> my install must be old, there's nothing there at all <mdz_> it sounds almost tempting <sabdfl> eek, that sounds ENCOURAGED <sabdfl> it should be something like: <mdz_> sabdfl: I have patches from mvo to add scary warnings to synaptic <elmo> what about dselect/aptitude? <elmo> or even apt it self? <mdz_> elmo: comments in sources.list <elmo> let's offer a bounty to the maintainer of apt! <sabdfl> # uncomment the following line to add software from the "universe" repository. <elmo> mdz: that's it ??? <mdz_> elmo: oh, you mean when installing stuff <mdz_> that's so Hoary <sabdfl> # NB software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu team <elmo> I'm going to populate hoary soon, and you guys will have to starty saying "that's so Perky" :-P <Keybuk> For following NEWS universe packages WHICH ARE ENTIRELY UNSUPPORTED YOU FOOL will be installed: <mdz_> elmo: you're bluffing <Keybuk> elmo: grumpy <Keybuk> hmm @ auto-typing <Mithrandir> sabdfl: "they are not supported in any way, including security updates" <sabdfl> # and may also not be under a free licence. Please satisfy yourself as to <Kamion> sabdfl: if you could file a base-config bug with the text you want, that'd be good ... <Mithrandir> but scarier. <sladen> http:/.../ universe non-free non-commerical java distributable ? <sabdfl> # to your rights to use the software. Also, please note that software in universe <mdz_> (transcribing this into a bug report btw) <sabdfl> # WILL NOT receive any review and updates from the Ubuntu security team. <sabdfl> how's that sound? <mdz_> s/and/or/ <mdz_> and I'm happy <Mithrandir> sabdfl: I would have it even scarier, if possible. <sabdfl> Kamion: i'll file a bug on base-config <mdz_> is "under a free licence" sufficiently descriptive? <Kamion> sabdfl: thanks <mdz_> sabdfl: I already filed one <Mithrandir> and synaptic needs to pop that up before letting you enable the component <mdz_> https://bugzilla.ubuntu.com/show_bug.cgi?id=1564 <sabdfl> Mithrandir: agreed <elmo> is synaptic what you get when you use the menus in gnome? <sabdfl> really, we are saying "adults only" <sabdfl> elmo: yes <mdz_> Keybuk: we'll have the infrastructure for that stuff in apt/aptitude/etc. in Hoary <sabdfl> new school, kinda <Kamion> note that we aren't localizing that text in any way <sabdfl> synaptic will also show ALL universe packages with a clear label (skull and crossbones, i think, was mvo's choice) <Kamion> that's so NOTWARTY it's untrue, though <elmo> ?? "get your warez" here? that's not very _discouraging_ to most people :p <sabdfl> we didn't manage to get the aptitude guy interested in being able to set a colour based on component though <sabdfl> now let's be bold about what goes into universe <mdz_> ok, so the resolution on classification was known-free and "other"? <mdz_> and we'll update the comments in the default sources.list <mdz_> and bring in the patches to synaptic with the same text <mdz_> and also (in synaptic) the supported/unsupported classification in the UI <Keybuk> sounds reasonable to me <mdz_> one hour, one agenda item down :-) <elmo> so, hang on, sorry, am I not even mutilating the section now? <mdz_> elmo: implementation details :-P <mdz_> section? origin? <mdz_> section seems appropriate <mdz_> since it's _completely useless_ for anything else <sabdfl> so universe/free and universe/other? <sabdfl> or universe/free and universe/unknown? <sabdfl> grrrr... <mdz_> unknown > other <Kamion> that's gonna make everything show up in one humungous list in synaptic <mdz_> Debian sections are not useful for finding software <Kamion> it won't even be categorized to the fairly minimal extent it is in Debian, and we don't have debtags yet <sabdfl> please can the standard line just be "universe" and let the philosophers use the free/unknown filter <mdz_> sabdfl: yes, I don't think the line in sources.list needs to change at all <sabdfl> Kamion: universe isn't designed to be useful for substantial package selection <Kamion> the section pretty much has to be universe/something I think <sabdfl> something? <mdz_> "something' being the original Debian section <Kamion> mdz_: that's the current state <sabdfl> so where's the "free" indicator go, for those that want it? <mdz_> admin base comm devel doc editors electronics embedded games gnome graphics hamradio interpreters kde libdevel libs mail math misc net news oldlibs otherosfs perl python science shells sound tex text utils web x11 <mdz_> USELESS <Kamion> mdz_: more useful than one huge list <Kamion> it's certainly not very good, but it's better than the absence <mdz_> is there any point in having the freeness indicator in the archive? <mdz_> I don't think we have any package management UI in Ubuntu which lets you wear freeness blinders based on anything but sources.list <mdz_> so it'd be purely informational anyway <mdz_> X-Ubuntu-Known-Free: yes <Keybuk> mdz_: the only thing would be the Section ... at least that shows up in the UI <elmo> yes, AFAICS, we have 3 choices: (a) split universe into universe-known-free and universe-universe, (b) abuse Section, (c) add some random meta-data tag <mdz_> so is the freeness classification worth giving up the benefits of sections, however marginal? <elmo> mark hates (a), (b) and (c) are kind of useless, (b) being marginally less so <mdz_> "what's the use case?" <elmo> only (a) would come close to actually helping any poor sod who wants to use ubuntu in a commercial environment <mdz_> if it's "I only want free software on my computer" <mdz_> then none of those except (a) actually do anything <elmo> that's not true <elmo> (b) helps if you don't use apt-get directly <sabdfl> elmo: how would they enforce that, would they use archive.ubuntu.com/ubuntu warty universe/free ? <mdz_> (b) helps if you never ever use the command line <elmo> sabdfl: no, unfortunately, the only way to make it sources.list based is option (a) <elmo> sources.list/apt-get has no concept of sections, only components <Kamion> elmo: components can't be multi-level? <Keybuk> Kamion: not in sources.list ... apt doesn't filter <elmo> err.. well, I dunno, to be honest.. I suppose katie could - would they work with apt <elmo> +? <mdz_> universe/free, you mean? <Kamion> it'd have to be hyphen rather than slash if you wanted it to be sources.list based then <mdz_> stable/non-US works fine <Keybuk> mdz_: but if you put just "stable", you don't get "stable/non-US" <mdz_> Keybuk: right <mdz_> if we switch to that, we need to convert everyone's sources.list <mdz_> which is not out of the question, if it's the right solution otherwise <Keybuk> so the question really does come, do we want users to be able to select in their sources.list to only get known-free universe packages? yes/no? <sabdfl> yes, that's the only point i can see to making the distinction in the archive not in launchpad <mdz_> agreed <Keybuk> elmo: is it possible for a package to be simultaneously in two or more sections? <Keybuk> components, sorry <sabdfl> is there another place we can put a flag that will be displayed in aptitude and synaptic? <sabdfl> no <elmo> keybuk: package/version/arch tuple? no <elmo> keybuk: package, yes <elmo> across releases, for example <mdz_> there's currently noplace we can put a flag which will be visible across all apt frontends <Keybuk> ok, so if we do it in sources.list we're looking at splitting universe into universe and universe-maybe-not-free/multiverse/whatever? there's no other way to do that? <mdz_> if we want to support a useful freeness distinction for the user in universe, it needs to be at the sources.list level <sabdfl> universe and blackhole <sabdfl> forget it, this is the mess i was trying to avoid :-) <sabdfl> (and yes, i know it means there's a whole other kind of mess :-) <Keybuk> elmo: any suggestions? <mdz_> we provide a freeness distinction within our supported set <mdz_> (only) <sabdfl> how much work would it be to add a header item to the packages file which is displayed in both aptitude and synaptic when you view the package detail? <elmo> Keybuk: not really? there is only really creating a separate component available to us as an option at this point in time.. and if sabdfl doesn't want to do to that <sabdfl> Free-Software: Confirmed <Keybuk> elmo: having a magic universe-known-free subset component isn't possible? <sladen> If a package is non-free/non-commerical, I'd prefer if dpkg/apt didn't even know about it; ...rather than having to get them to filter it out. <mdz_> sladen: the answer would be, "then don't use universe" <sabdfl> hmm... <elmo> keybuk: how is a "magic subset" component different from a simply separate component <elmo> +? <mdz_> Debian is in the business of collecting gobs of software and dividing it into free and not free <mdz_> Ubuntu is in the business of collecting gobs of software and dividing it into supported-free, supported-non-free, and unsupported <mdz_> that's how it stands today <mdz_> if our supported set expands to contain a reasonably complete subset of useful software, the distinction becomes less important <mdz_> but as it stands, Ubuntu supported << Debian main <Keybuk> yeah, we could possibly add a universe note that if people are continually installing things from universe to discuss with us about making them supported. <Keybuk> we may have missed something glaringly obvious <mdz_> Keybuk: making popularity-contest work would be a good start <mdz_> been meaning to file a bug about that <sabdfl> my hope is that derivatives will commit to getting stuff that is in universe, that is important to them, supported to the level we require for inclusion in main <mdz_> Keybuk: it's certain that we've missed some glaringly obvious things; a few have come up already <sabdfl> then, as mdz points out, main expands to be more useful <mdz_> if we get to a point where most people can use only supported software, then that will satisfy those who want the distinction as well <mdz_> they could remove 'restricted' <mdz_> RMS will never be happy with it <mdz_> but that's almost a given <Keybuk> did you read his correspondance with Jeff? He was actually quite civil <Keybuk> http://lists.gnome.org/archives/foundation-list/2004-September/msg00067.html <mdz_> I blacked out at "GNU slash Linux..." <mdz_> anyway, there is a decision on the table about whether to subdivide universe <mdz_> at least, whether to subdivide universe today <sabdfl> just to clarify, the old division that makes sense, if we do it, is two components <Keybuk> I don't think we can do it in a useful way today, by the sounds of it <sabdfl> "universe" and "multiverse" <sabdfl> s/old/only/ <Keybuk> not without two components anyway <elmo> what the heck's multiverse? <sabdfl> elmo: non-free universe <mdz_> given the lack of a straightforward solution, and hazy user need, I think we can safely defer the decision until post-Warty <elmo> meh <mdz_> if we want, we can set up the Hoary archive differently <mdz_> can we not? <elmo> what's not straightforward about two components? <sabdfl> then the apt/sources.list can at least contain meaningful options w.r.t. known-free stuff <elmo> if we don't want to do it, fine, but let's at least just say that <sabdfl> elmo: is two components going to take more than an extra day to arrange? <mdz_> what would we call the components? <sabdfl> universe and multiverse <mdz_> by definition there can only be one universe <elmo> sabdfl: no, not at all, it's just a change in the planto import non-free <mdz_> multiverse doesn't tell the user anything about what they're asking for <mdz_> universe-known-free and universe-somethingelse would be my preference <sabdfl> mdz_: i'm expressly trying to avoid warranties in this regard <mdz_> sabdfl: known-free was what you said you preferred <sabdfl> i really think that text should still say "be an adult and check this stuff for yourself" <sabdfl> i prefer known-free to non-free, since known-free is easier to assure <mdz_> what I suggested was Debian/non-Debian, which at the same time says nothing explicitly about freeness whatsoever, and provides the same utility for people who expect it from Debian <mdz_> which is trivial to assure <mdz_> but, I suppose, that's not useful in a sources.list context because it's tied to Debian <elmo> universe, universe-non-debian ? <sabdfl> no, i don't want to have a component based on source <sabdfl> origin, sorry <Keybuk> universe-unchecked ? <elmo> universe-fuckitall <sabdfl> universe and multiverse. the sources.list text can do the explaining <sabdfl> i *really* prefer just universe, but let's get a sense of opinions <elmo> from where/how? <sabdfl> technically, this is just about mdz, keybuk and me, buti'd like to hear from others <sabdfl> (a) just universe <sabdfl> (b) universe and multiverse <Mithrandir> multiverse is "possibly and surely non-free"? <sabdfl> what else? <mdz_> (c) sections <sabdfl> Mithrandir: yes <Mithrandir> I'd like b) to happen <sabdfl> Keybuk: <sabdfl> ? <elmo> I [obviously] vote (b), for whatever that's worth <Keybuk> b, I think <mdz_> (b) is OK with me, except for the multiverse name <elmo> mdz: is it really any worse than "universe"? <mdz_> elmo: universe and multiverse side-by-side? yes, absolutely worse <npmccallum> the two do seem entirely ambiguous <mdz_> I think that universe-foo and universe-bar would be clearer <mdz_> but once a universe is subdivided, it's not a universe anymore :-) <elmo> that's why multiverse is so cute <mdz_> anyway, my argument is semantic; I don't have any problems with the component implementation of the distinction <sabdfl> i think the answer is that universe is "unsupported", period <sabdfl> launchpad can have exact licence terms <Mithrandir> mdz_: agree, we can use pwgen-based names for all I care. ;) <mdz_> as I mentioned before, launchpad answers the needs of derivative distributions, but not of users, at least not directly <mdz_> but I suppose someone could then create a "frubuntu" <mdz_> and go about classifying all the software there <elmo> [are planning on supporting dervitatives who want to dervive "all of universe"? ] <mdz_> and they could call it "Frubuntu GNU/Linux", and maybe it really _would_ be possible to please everyone <mdz_> elmo: derivatives should be able to select any packages they want from universe, up to and including all of it, no? <elmo> mmk <sabdfl> elmo: sure <mdz> that lets us leave universe alone for Warty, and also lets someone else do the work of classifying licenses <mdz> and leaves room for more than one group of users to make their own classifications <elmo> they can do that regardless of what we do <mdz> (d) consider this a use case for a derived distribution <mdz> (and not for Ubuntu itself) <sabdfl> i can live with (b) <sabdfl> i think it's simpler to go with (a) for warty and review for hoary <Keybuk> yeah, I'm happy with that <sabdfl> Keybuk: which? <mdz> it all depends on what fraction of the Debian community considers the freeness bit important to them <mdz> that subset won't look twice at Ubuntu if it doesn't have a distinction <Keybuk> sabdfl: I prefer b, but would be happy with a <mdz> but, I suppose we have a partial answer in main/restricted <mdz> so a secondary decision is whether or not to do anything about the issue _for Warty_ <sabdfl> mdz: i think everyone considers it important <elmo> I do think there's community backlack potential when we ship the 178 non-free packages from Debian in 'universe'.. mitigated maybe by a promise to review it for hoary.. *shrug* <sabdfl> mdz: let's go with b, and just do the work to get the apt sources.list text right <mdz> ok <Mithrandir> sabdfl: as well as fixing synaptic. :) * Mithrandir nags a bit <sabdfl> i think it's an unnecessary risk <mdz> elmo says it's no more work, but if the list of elmo's tasks in my head is half as long as the complete one... <mdz> elmo: speaking of which, remind me later to nag you about access to buildd logs <elmo> remind you to nag me to do stuff I haven't done yet? yeah, 'cos _that's_ going to happen :-P <elmo> (but yes, I know) <sabdfl> so let's move on guys, time is limited <mdz> so the consensus is that elmo should carry out (b) <sabdfl> yes please <mdz> ok, moving on then <sabdfl> question: what are the criteria for "universe"? everything else is in "multiverse"? <mdz> should be the same criteria as for main vs. restricted <mdz> or, main and not-main <Keybuk> sabdfl: universe is known to be free, I guess <elmo> what about contrib? <sabdfl> yes but how do you define free? dfsg? rms? <elmo> sabdfl: ours <sabdfl> ok <elmo> it's our universe, damn it ;-) <Keybuk> didn't we have our own guidelines for that? <Keybuk> same as supported, I'd say <sabdfl> ok, moving along <Keybuk> universe is free enough for us, just as supported is ... people with stricter requirements make a perfect derivative distro <mdz> the ESD issue, I think, was _mostly_ resolved in bugzilla overnight <Keybuk> mdz: bug#? <mdz> we should move everything to ESD, except for things which don't support it, and those things just suffer <Keybuk> the totem/gstreamer thing? <mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=1481 <mdz> gnomemeeting was pointed out as an app which doesn't support esd <elmo> sorry, -ECONTEXT, why do we want to use ESD? <sladen> esddsp <mdz> elmo: #1481 <Keybuk> elmo: most alsa drivers don't allow concurrent access to /dev/dsp <mdz> as a means to share the audio device <Keybuk> if you have sound events on, esd hogs /dev/dsp <sabdfl> is there a sense of momentum in the sound community on this issue? <sabdfl> if the world+dog are moving to ALSA-native, we should not go in the other direction <mdz> I think the momentum is in favour of sound hardware which can do mixing on its own, but it's not widespread yet <mdz> it's a hardware issue that needs a software solution <sabdfl> hardly seems fair to require hardware changes <mdz> I don't think that ALSA-native buys us anything over OSS-ALSA in this case <Mithrandir> oss-alsa is actually a fairly nice solution, IME. <Keybuk> sabdfl: I think you get the same problem alsa-native anyway <Mithrandir> Keybuk: that depends on your hardware. <Keybuk> esd sounds like a reasonably warty solution to me; it may be worth getting someone to talk to (e.g.) the Fluendo guys on the hoary timeframe to see if there's a "better way" ? <mdz> there are some vague rumblings about libasound doing software mixing, but I can't see how it could be implemente dalready <Mithrandir> mdz: it's also rumored to suck badly <sladen> mdz: (Its ugly), but have gnomemeeting depend on esound-clients and wrap gnomemeeting with esddsp gnomemeeting <Keybuk> Mithrandir: certainly I get the same problem with alsa-native on my desktop ... but don't get either problem on my laptop :( <seb128> GNOME guys would like to kill esd I think <mdz> it would require some IPC facility which doesn't exist <mdz> esd can't die until something replaces it, though <Mithrandir> Keybuk: my desktop has a decent sound card; I have hardware mixing on all my desktops, but not my laptop, I think. <mdz> software mixing in kernelspace sounds unlikely to happen <mdz> so when it is re-solved in userspace, it will probably be via the alsa API <mdz> people who have hardware mixing aren't hurt by ESD <mdz> and it helps people who don't <mdz> my laptop seems to have hardware mixing <mdz> at least, it allows multiple opens of /dev/dsp <elmo> mdz: that's not true, esd does interesting things to my desktop machine * sladen also has to run ESD on his laptop since the audio hardware can /only/ do 44100Hz, so have to use esd to do resampling <mdz> elmo: such as what? <seb128> the problem is that esd is not really in a good state and not really maintained <elmo> mdz: hmm, it's been a while since I stopped using it.. but initially, I think it just didn't zstrickland@example.net.. even after Ryan hacked around that, it would hang on signficant load <Mithrandir> seb128: got a better suggestion? <mdz> seb128: what is upstream's recommendation? <seb128> no, we are stucked with it for the moment ... <mdz> ok, so we have no choice. sounds like we don't need to take an explicit decision <sabdfl> done. next. <seb128> mdz: keep using esd for the moment since there is nothing else in this area <mdz> a more pressing issue is what to do about the effect that the automounting magic has had on desktop usability <seb128> if you want to have sound events <mdz> and our other desktop changes <mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=980 <seb128> but I think that most of the GNOME guys just don't use sound events <mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=1234 <mdz> there is a usability issue in that users have no discoverable way to unmount things which get automounted <mdz> and there is a functionality issue in that it interferes with CD burning <mdz> the former issue arose because we removed the volume icons on the desktop without providing a replacement <sabdfl> guys i have to step away at this point, please send me the logs <mdz> sabdfl: before you go, your opinion for the record on restoring the volume icons on the desktop when things are automounted? <mdz> that is by far the simplest solution <mdz> ok, guess I missed him <mdz> other opinions? <Keybuk> tricky ... we seem to be getting positive feedback for not having the desktop icons ... but I do feel we need some immediate visual indication somewhere on screen that there's a CD mounted <mdz> the consensus long-term solution in Oxford was to have a tray icon <mdz> but unless someone can build that and have it stable for Warty final, we need an interim solution <mdz> (tray icon? notification icon? whatever they're called) <Keybuk> on a three week timescale? I don't think that's doable :( <npmccallum> mdz: it won't be able to be stable by final <seb128> no, that's not <Keybuk> mdz: "applets" if you listen to Novell <g> <mdz> any proposals other than restoring the volume icons? <seb128> no ... <npmccallum> no <mdz> auto-unmounting when nautilus is closed? <mdz> menu item in nautilus window? <npmccallum> too risky at this stage <npmccallum> (the first one that is) <seb128> menu item no <Keybuk> not enough testing :-/ stuff like that needed to be done by freeze to get enough wide-testing for warty <seb128> agreed <mdz> thing is, I think if sabdfl were here, he would veto the icons <Kamion> I'm not sure auto-unmounting is very good UI either <seb128> if somebody has idea for the umount when all the windows are closed ... <Keybuk> Kamion: mounting/unmounting in *general* is not good UI :-( <mdz> Kamion: agreed, it makes for an awkward transition to the long-term solution too <Kamion> seb128: that would only be good UI if there were a discoverable way to mount it again without having to eject/reinsert <sladen> volume items on the desktop---for automounted items only---seems logical for me as a user; and sensibile given the time constaints and having already been tested <seb128> Kamion: true <mdz> consensus, given release constraints, is that the icons need to come back <Keybuk> Kamion: indeed, it would need to be unmount & eject for CDs <mdz> but we need a fallback position given that sabdfl hasn't spoken on this <Keybuk> which is actually kinda cute <g> you don't need to unmount usb devices because they can be pulled out manually <seb128> just having computer place for this is that bad ? <Keybuk> but anyway <mdz> and I know he feels strongly about this subject <Keybuk> seb128: computer/disks is a bit hard to find <mdz> seb128: the problem is that users can't find it <mdz> because there is no indication on the screen when they insert something <seb128> write in BIG in the doc :) <Keybuk> and until you find it, you really can't eject a CD <mdz> there is nothing to lead them there <Keybuk> seb128: who reads them? <mdz> and ejecting a CD is a damn common use case :-) <seb128> Keybuk: we don't have any good solution ... <Keybuk> mdz: yeah, I wish Mark hadn't wandered off at this exact point because he does have quite strong ideas about this area :- <seb128> so just umount when all the windows are closed <sabdfl> voice of sabdfl from a distance.... "can we get them on the desktop for automounted ones only? so nothing there till you automount it..?" <seb128> so at least you can eject CD with the button <npmccallum> yes <mdz> sabdfl: yes <sabdfl> i don't know how you eject a cd from windows, without pressing the hardware button <Keybuk> sabdfl: as I understand it, yes; you'd only see CD/USB devices on the desktop <npmccallum> sabdfl: right click, eject <mdz> sabdfl: that's precisely what we're proposing <sabdfl> "ugly, this is" <mdz> empty desktop except when you insert a CD or hotplug something <sabdfl> how do you feel about going with that for warty and fix it for panel in hoary? <npmccallum> mdz: if there is a floppy drive in fstab, I'm pretty sure it will show up on the desktop <mdz> that would be my preference <Keybuk> yeah, I'd say that's the best we can do <seb128> mine too <mdz> npmccallum: oh? we can probably fix that <mdz> seb128: what's the gconf magic to turn it on? I'll try right now <Kamion> seb128: not to be a powermac weenie, but what button? :) <mdz> Kamion: the "F12" button <sladen> npmccallum: floppy drives are a pain, since on x86 there's no way to get insert/eject notification <Kamion> mdz: in theory ... <npmccallum> sladen: yes, I hate them <seb128> mdz: /apps/nautilus/desktop/volumes_visible <mdz> I'm more than happy to hide the floppy away <sabdfl> i agree on the understanding the desktop is empty on boot, until something is explicitly automounted <npmccallum> we can hide the floppy I'm sure <npmccallum> thats a lot less intrusive than the other stuff <seb128> yes, should be easy to do <sabdfl> cheers guys. community council next week. <Keybuk> hrm, I don't have a floppy icon on my desktop until I mount the floppy <npmccallum> Keybuk: is it in fstab? <seb128> that's the right behaviour <Keybuk> npmccallum: yes <seb128> only mounted devices <Keybuk> /dev/fd0 /floppy auto rw,users,noauto,sync 0 0 <sladen> only _user_ mounted devices <seb128> yes <mdz> seb128: I did gconftool-2 --type boolean -s /apps/nautilus/desktop/volumes_visible 1 <mdz> and it doesn' tseem to have had an effect <seb128> nautilus manages your desktop ? <mdz> stock Warty <Keybuk> mdz: unless you have something mounted, you shouldn't see anything <mdz> Keybuk: I inserted a CD <mdz> and nautilus opened with it <mdz> but no icon <sladen> mdz: s/1/true/ ? <seb128> no, 1 is fine <mdz> do I need to log out or something? <seb128> no <mdz> ah, there it is <mdz> I re-ran it with true <mdz> ejected, inserted <mdz> and there it is <mdz> ok <mdz> and no floppy <mdz> so, let's do that for Warty <seb128> ok <mdz> seb128: will you take care of it? <npmccallum> I already did it <mdz> ok <seb128> mdz: yes. Could you just open a bug to keep the trace ? <npmccallum> just waiting for upload <seb128> oh ok <seb128> fine <mdz> npmccallum: go ahead, if that's the only change <npmccallum> yup <mdz> just removing the patch from debian/patches, right? <npmccallum> edited it -- cut out the section refering to volume icons only <Keybuk> yeah, it works for me too here; only the mounted stuff shows up, there's no icon for the cd or floppy when not mounted <mdz> ok <mdz> moving on, we have the CD burning issue <mdz> if you've burned CD-RWs with nautilus in Warty, you know what I'm talking about <Keybuk> is this issue when you insert a blank CD? or when you want to write over top of a CD you've just inserted that's got stuff on it? <mdz> Keybuk: only when the CD has stuff on it <mdz> hence CD-RW <Keybuk> can't nautilus' cd burner unmount the thing itself? <mdz> you insert the CD, and it gets mounted and nautilus opens <mdz> dunno <mdz> seb128, npmccallum: ? <Keybuk> that seems the most logical ... user-wise you probably *do* want the window open to check you're about to write over the right CD <npmccallum> it can unmount it, the problem is it automatically gets mounted again on burn completion (if that is a problem) <Keybuk> then when you go to write, the burner app should unmount it <mdz> the other problem is that, even if you unmount it, then it gets mounted again _during_ and after the burning process <mdz> at least for me <Keybuk> npmccallum: getting unmounted after burning sounds right? check it burnt ok? <seb128> my cd writer is out of order, I've not really played with n-c-b ... <Keybuk> during would be broken though? <sladen> mdz: unmount + eject <Keybuk> npmccallum: does the window pop up after it's finished burning? <mdz> ideally, it should unmount at start, prevent mountitng during, and eject after <Kamion> even if you *can* unmount it ... last time I tried, I only had an "Eject" entry on the right-click menu, no "Unmount" <npmccallum> Keybuk: I believe so <mdz> if the user wants to check it, they can close the CD tray <Keybuk> Kamion: eject is friendlier anyway <mdz> Kamion: my sr0 has an 'unmount' * Kamion would also prefer it to eject <mdz> and when i unmount, the icon goes away <Kamion> Keybuk: not if you're trying to burn (say I want to do something strange and therefore want to use cdrecord) <mdz> so there's no place for an eject <npmccallum> keeping it from mounting during burn is the bugger <mdz> there is a separate issue of the command line <mdz> it is very irritating to mount something on the command-line and have it pop up in nautilus on top of your terminal <Keybuk> Kamion: if you're doing that, I'd expect you'd know to unmount it first <Keybuk> what decisions need to be made here? before we wander too much <mdz> the decision to be made is what to do about CD burning <mdz> because that is a real use case which is in bad shape right now <mdz> options: <mdz> (a) work around it in nautilus-cd-burner as best we can <mdz> (b) implement a locking facility in pmount (pitti has written the code for this already) <mdz> (c) use locking in HAL, which upstream has in CVS <mdz> (b) and (c) are sketchy given the release <Keybuk> seb128, npmccallum: you're suggestions? <mdz> locking never gets implemented correctly the first time <seb128> I can have a look on (a) tomorrow <npmccallum> c is out, I don't want to pull cvs in
{'channel': 'ubuntu-meeting', 'month': 10}